Exercício Integrado SOC - Cadeia de Detecção e Resposta

Primeira nota do capítulo 16 - Exercícios Práticos. Exercício guiado que percorre a cadeia completa de detecção e resposta, do IOC que chega ao CTI até a contenção do IR, sobre um cenário único de phishing com infraestrutura nova.
O objetivo é treinar a esteira integrada em ordem real: CTI valida e distribui o indicador, o SOC faz triagem, o hunting busca amplificação e telemetria de endpoint, e o IR contém e erradica, com consultas KQL de exemplo em cada fase.
Dialoga com os capítulos 03 (IOC), 07 (processo de hunting), 08 (técnicas por TTP), 10 (integração CTI-TH) e com as salvaguardas CTI, DAT, HNT e RES do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Os capítulos anteriores ensinaram peças separadas, validação de IOC, triagem, hipótese, consulta, contenção; este exercício as costura em sequência cronológica sobre um único cenário, porque a competência que falta na maioria dos times não é executar a peça, é saber o momento e o vizinho certo da peça. O formato é guiado: cada fase declara os dados de entrada, a ação esperada, o resultado esperado e uma consulta de exemplo, e o leitor deve executar ou simular cada passo antes de ler o seguinte, com papel para cada integrante do time.

O exercício foi construído para três a quatro horas de mesa técnica, com quatro papéis: analista de CTI, analista de SOC nível 1 e 2, hunter e respondente de IR. O ambiente de referência usa Microsoft Defender for Endpoint com Sentinel (KQL), proxy com log centralizado, gateway de e-mail e um TIP (MISP) interno, e qualquer stack equivalente serve, adaptando a sintaxe. O C2 do cenário, 203.0.113.87, é o mesmo endereço documentado usado nos exemplos de beaconing da biblioteca, o que permite confrontar a saída do exercício com as notas do capítulo 08.

A regra de ouro do exercício é cronológica e sem atalho: cada fase só começa com o produto da anterior na mão, e a pontuação penaliza pular etapas, porque pular triagem para "caçar logo" é exatamente o comportamento que o programa integrado existe para corrigir.

2. Cenário, Atores e Linha do Tempo

O cenário é uma campanha de phishing com infraestrutura nova, disfarçada de aviso de transportadora, que atingiu o setor financeiro da organização fictícia. O adversário registrou domínio dedicado três dias antes do envio, enviou o e-mail com anexo compactado contendo um loader, obteve a execução em uma estação, criou persistência com tarefa agendada e iniciou beaconing para o C2, com preparação de exfiltração já em andamento quando o exercício começa. A linha do tempo é o contrato do exercício, e o relato final do time deve reconstruí-la com evidência:

Os indicadores de referência são o domínio entrega-rapida-avisos.com, o hash do loader (SHA-256 fictício a3f1c8e25b9d4f7a6c0e1d2b3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a) e o IP 203.0.113.87. O IOC chega antes de qualquer alerta interno por um canal externo, que é a condição mais comum de descoberta em organizações reais, e essa assimetria é parte do aprendizado: a primeira fase existirá mesmo sem um alerta acionando o SOC.

3. Fase 1: CTI Recebe, Valida e Distribui o IOC

A validação parte do ciclo de vida do capítulo 03: idade do domínio por WHOIS e DNS passivo, reputação e configuração TLS, e o hash em repositórios públicos, com atenção para não detonar nada na rede de produção. A exposição interna é a pergunta que transforma IOC externo em ação local: quem recebeu, quem clicou, quem executou. A consulta abaixo localiza as mensagens entregues pelo gateway:

EmailEvents
| where Timestamp > ago(7d)
| where SenderMailFromDomain == "entrega-rapida-avisos.com"
   or Subject has_any ("aviso de entrega", "notificação de rastreio", "recibo")
| project Timestamp, RecipientEmailAddress, SenderFromAddress, Subject, DeliveryAction, NetworkMessageId

O produto da fase é o registro no MISP com distribuição TLP:AMBER, confiança declarada e validade de 30 dias, mais o briefing no canal do SOC com os três indicadores e a instrução de busca. O erro clássico desta fase é publicar o IOC sem contexto, ou detonar o anexo fora de sandbox; ambos custam pontos e custariam mais em produção.

4. Fase 2: SOC Faz a Triagem do Alerta de Phishing

A triagem técnica confere SPF, DKIM e DMARC do cabeçalho, o Reply-To divergente do remetente e o comportamento do anexo em sandbox, que revela execução de binário disfarçado com ícone de PDF, o padrão clássico de dupla extensão. A classificação usa o playbook de phishing do capítulo 13, e a busca por destinatários cruza os anexos entregues com as mensagens, fechando o universo de 3 contas e a lista de quem ainda não interagiu:

EmailAttachmentInfo
| where Timestamp > ago(7d)
| where FileName =~ "recibo_8842.pdf.exe"
   or SHA256 == "a3f1c8e25b9d4f7a6c0e1d2b3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a"
| join kind=inner (EmailEvents | where Timestamp > ago(7d)) on NetworkMessageId
| project Timestamp, RecipientEmailAddress, FileName, DeliveryAction, Subject

O produto da fase é o incidente aberto com prioridade justificada pela execução ainda não confirmada, e a instrução de bloqueio imediato do domínio no gateway e no proxy, com expiração de 30 dias, é a primeira ação preventiva do caso. O erro clássico é classificar como spam e fechar, o que converteria uma intrusão real em fila limpa.

5. Fase 3: Hunting de Amplificação

A amplificação é a pergunta de hunting da fase: quem mais tocou essa infraestrutura, por qualquer caminho, e-mail, navegador, aplicativo? A consulta cruza telemetria de rede de endpoint com o domínio e o IP do cenário, e cobre o caso de o anexo ter chegado por outro canal:

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has "entrega-rapida-avisos.com" or RemoteIpAddress == "203.0.113.87"
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName,
          RemoteUrl, RemoteIpAddress, RemotePort, ActionType
| order by Timestamp asc

O resultado esperado mostra resolução e download às 09:30, processo do navegador como origem e a estação WS-FIN-07 como único ponto de contato com a infraestrutura, o que delimita o raio do incidente. A leitura de resultado exige o cuidado do capítulo 03 com falsos positivos: um proxy corporativo pode fazer o domínio aparecer em vários hosts, e a coluna do processo iniciador é a que separa clique humano de varredura de infraestrutura.

6. Fase 4: EDR Hunting de Execução, Persistência e C2

A cadeia de execução começa pelo processo do loader e pelos filhos que ele gera, com a coluna de linha de comando expondo a cópia para o diretório de disfarce:

DeviceProcessEvents
| where Timestamp > ago(2d) and DeviceName == "WS-FIN-07"
| where FileName =~ "recibo_8842.pdf.exe"
   or (FolderPath has_any (@"\Temp\", @"\AppData\Roaming\") and InitiatingProcessFileName =~ "explorer.exe")
| project Timestamp, AccountName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName

A persistência aparece na criação da tarefa agendada, e a consulta usa o evento 4698 do Security, com o nome do content validado por ambiente como a nota 01 do capítulo 08 recomendou:

SecurityEvent
| where TimeGenerated > ago(2d) and Computer == "WS-FIN-07"
| where EventID in (4698, 4702)
| where TaskName contains "OneDrive"
| project TimeGenerated, SubjectUserName, TaskName, TaskContentNew

O beaconing é medido com a lógica de cadência do capítulo 08: conexões para o C2 com contagem e coeficiente de variação baixo, e a preparação de exfiltração aparece na criação de coleta.zip por processo filho do loader. O produto da fase é a linha do tempo mapeada: T1204.002 na execução pelo usuário, T1053.005 na persistência, T1071.001 no C2 e T1560.001 na compactação, com evidência citada para cada técnica. O critério de encerramento do beaconing segue a nota do capítulo 08: cadência média entre 20 e 900 segundos, coeficiente de variação abaixo de 0,10 e mais de 20 conexões confirmam a hipótese de C2 com falso positivo residual.

7. Fase 5: IR Contém, Erradica e Reporta

A contenção executa na ordem de dependência: isolamento de rede do host pelo EDR primeiro, porque corta o C2 e congela o cenário; revogação de tokens e troca de senha da conta em seguida, porque loader ativo é coletor de credencial em potencial; bloqueio do domínio, hash e IP na borda, com expiração; e só então a limpeza, remoção da tarefa e do binário, porque apagar persistência antes de revogar acesso devolve o adversário a um host ainda vivo na rede. A limpeza documentada segue o padrão:

Stop-ScheduledTask -TaskName "OneDriveSyncHealth" -ErrorAction SilentlyContinue
Unregister-ScheduledTask -TaskName "OneDriveSyncHealth" -Confirm:$false
Remove-Item "$env:APPDATA\onedrivesync\recibo_8842.pdf.exe" -Force
Remove-Item "C:\Users\Public\coleta.zip" -Force

O relato fecha o ciclo com as três entregas que o capítulo 07 exige: relato de incidente com a linha do tempo citada por evidência, detecção permanente derivada do caso, o alerta de tarefa agendada com interpretador e binário em caminho de usuário, e a contribuição TLP:GREEN de volta ao ISAC, com o que o cenário ensinou de infraestrutura. A métrica que fecha o exercício é o dwell time simulado, da execução às 09:31 ao isolamento, e a meta do time é demonstrar contenção abaixo de 60 minutos da chegada do IOC.

8. Tabela de Checkpoints

9. Critérios de Avaliação

• Correção das consultas: filtros com janela de tempo, uso correto das tabelas e das colunas de processo iniciador, e nenhuma varredura de tabela inteira sem filtro, que é o vício que derruba ambiente de produção real.
• Ordem e dependência das fases: o time que pulou validação do CTI ou iniciou limpeza antes da revogação de credencial perde pontos, porque a ordem é parte da competência treinada.
• Qualidade da inferência: nenhuma afirmação sem evidência citada, e o que não se sabe entra como incerteza declarada, no padrão da nota 09 do capítulo 05; afirmar exfiltração sem dado é o erro mais caro do exercício.
• Comunicação com TLP: briefing interno rotulado e contribuição externa no nível correto, conforme a nota 06 do capítulo 12.
• Tempo e rastro: exercício completo em até 4 horas, com cada fase datada no relato e a linha do tempo final reconstruída como tabela.
• Conversão de caça a detecção: o exercício só pontua integralmente quando a detecção permanente derivada do caso é escrita e testada, no padrão do capítulo 18.

10. Integração com o Restante da Biblioteca

O exercício é a aplicação ponta a ponta do framework do capítulo 15: a fase 1 executa CTI.4 e PLT.1, a fase 2 e 3 exercem DAT.1 e TH.10, a fase 4 é a caça por hipótese do TH.6 sobre o próprio incidente, e a fase 5 materializa RES.1 a RES.3 com a métrica de dwell time do IR.5. As consultas reaproveitam, sem modificação de lógica, as notas 01, 02 e 06 do capítulo 08, e o hash, o domínio e o C2 do cenário conversam com os exemplos dos capítulos 03 e 08, de modo que o leitor pode confrontar cada passo com a nota que o originou.

O fechamento recomendado é executar o exercício em duas rodadas separadas por um mês, a primeira documentando tudo e a segunda só com checkpoint e cronômetro, e comparar dwell time e número de erros de ordem entre as rodadas; a diferença entre as duas é a medida objetiva de quanto a esteira integrada melhorou, e o relatório da segunda rodada alimenta o exercício de CTI do capítulo, que transforma este incidente em produto de inteligência disseminável.