Dos achados de pentest às deteções do SOC

24.06.20264 min de leituraEquipa Atalaia

A maioria das equipas usa um relatório de pentest uma vez. Os achados viram tickets, os tickets são corrigidos e o relatório é arquivado. Mas um pentest é também o mais próximo que tem de um ataque etiquetado contra os seus próprios sistemas: técnicas conhecidas, alvos conhecidos, horas conhecidas. São exatamente os dados que os engenheiros de deteção querem.

Este guia mostra como transformar achados em deteções que o seu SOC pode correr, usando o MITRE ATT&CK como linguagem comum e o Sigma para regras portáteis.

Porquê corrigir e detetar

Corrigir o bug fecha uma porta. A deteção diz-lhe quando alguém experimenta o puxador dessa porta, ou da próxima que ainda não encontrou. As duas respondem a perguntas diferentes:

• A correção responde: este ataque específico ainda pode ter sucesso?
• A deteção responde: alguém está a tentar esta classe de ataque neste momento?

Uma deteção construída a partir de um finding também apanha regressões. Se uma release posterior reabrir o buraco, o seu alerta pode ser o primeiro sítio onde fica a saber.

O processo, achado a achado

1. RecolherPeça aos testers os IPs de origem, timestamps e pedidos em bruto. Combine isto antes de o trabalho começar.
2. MapearAtribuir a cada finding uma técnica ATT&CK que descreva o que o atacante fez, não qual era o bug.
3. LocalizarEncontrar os logs que registaram a atividade: servidor web, WAF, auditoria da cloud, fornecedor de identidade.
4. EscreverExpressar o comportamento observável como uma regra Sigma.
5. TestarCorrer a regra novamente sobre a janela do pentest. Tem de disparar com o tráfego do tester e ficar calada em dias normais.

Mapear achados para ATT&CK

Mapeie a ação do atacante. Um server-side request forgery é uma classe de bug; o objetivo do atacante ao explorá-lo na cloud é muitas vezes ler as credenciais da instância. Achados típicos de web e cloud mapeiam assim:

Registar o ID da técnica em cada deteção permite ver a cobertura ao longo da matriz e identificar técnicas que testa mas nunca deteta.

Uma regra Sigma a partir de um finding de SSRF

Suponha que os testers chegaram ao endereço de metadados através de um parâmetro de obtenção de imagens. O servidor web registou a query string. Uma regra Sigma para esse comportamento:

title: Possible SSRF Targeting Cloud Metadata Service
id: 8f2b6c1e-4d7a-4b0e-9c3f-2a1d5e6f7a80
status: experimental
description: |
  Detects requests whose URL or query contains the link-local cloud
  metadata address or a common alias. Built from pentest finding PT-2026-11.
references:
  - internal://pentest/2026/PT-2026-11
tags:
  - attack.credential_access
  - attack.t1552.005
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection:
    cs-uri-query|contains:
      - '169.254.169.254'
      - 'metadata.google.internal'
      - '%31%36%39%2e%32%35%34'
      - '0xa9fea9fe'
  condition: selection
falsepositives:
  - Internal health checks that legitimately reference the address
level: high

Converta-a para a linguagem de consulta da sua plataforma com a Sigma CLI, e depois corra-a sobre a janela do pentest:

pip install sigma-cli
sigma plugin list                  # find the backend for your log platform
sigma plugin install "$BACKEND"
sigma convert -t "$BACKEND" ssrf_metadata.yml

Escolha o backend, e um pipeline de processamento se os nomes dos campos forem diferentes, de acordo com a sua plataforma de logs. As variantes codificadas na regra vêm do mesmo raciocínio que um bom reteste: se os testers tentaram uma codificação, os atacantes vão tentar várias.

Junte a regra web a um segundo sinal, mais forte, sempre que possível: audit logs da cloud que mostram as credenciais da role da instância a serem usadas a partir de um endereço fora da sua rede. Isso apanha o resultado, não só a tentativa.

Testar e afinar

• Verdadeiro positivo: a regra dispara em todos os pedidos do tester na janela. Se falhar alguns, veja o que eles mudaram.
• Falso positivo: corra-a sobre uma semana normal. Adicione exclusões estreitas, cada uma com um comentário a explicá-la.
• Responsabilidade: cada regra tem um responsável, um link para o runbook e o ID do finding de pentest que lhe deu origem.
• Controlo de versões: guarde as regras num repositório com revisão e CI, tal como o código da aplicação. Valide-as com sigma check.

O que fazer na segunda-feira

1. Pegue no seu último relatório de pentest e associe cada achado a uma técnica ATT&CK.
2. Pergunte aos testers, ou consulte as suas notas, quais os IPs de origem e a janela de teste.
3. Procure a atividade deles nos seus logs. Anote qualquer achado que não deixou rasto.
4. Escreva uma regra Sigma para o achado de maior impacto e teste-a nessa janela.
5. No próximo trabalho, combine no scope que os testers partilham timestamps e origens, para que as deteções passem a fazer parte do entregável.

Feito assim, cada teste deixa a linha mais difícil de partir e mais atenta a quando alguém tenta.

Onde isto fica na linha