Phishing no SOC: Triagem, Detecção e Resposta na Prática

Phishing causou cerca de 16% das brechas analisadas no Verizon DBIR 2025 e segue como um dos vetores de acesso inicial que mais consome o turno de um SOC. Para um analista, dominar a triagem, a extração de indicadores e a contenção imediata é o que separa um incidente controlado de uma invasão com vazamento de dados.

Em outras palavras: quase um terço das invasões começa por identidade comprometida via engenharia social. O phishing empatou com o abuso de credenciais roubadas (ambos em 16%) como via de entrada, e ficou atrás apenas da exploração de vulnerabilidades, segundo análise do conjunto de dados do DBIR pela Push Security. Este guia mostra como estruturar o fluxo de triagem, detecção e resposta a phishing no SOC, na prática.

Pontos-chave:

Phishing foi a via de entrada em cerca de 16% das brechas no Verizon DBIR 2025.
O Anti-Phishing Working Group (APWG) registrou 1.003.924 ataques só no primeiro trimestre de 2025 — o maior volume desde o final de 2023.
Um playbook de phishing bem desenhado reduz MTTD e MTTR e padroniza a resposta de todo o turno.
Triagem rápida, extração de indicadores e contenção imediata são os três pilares da resposta.

Volume de ataques em alta

Antes de falar de processo, vale ancorar a urgência em dado real. O relatório do APWG para o primeiro trimestre de 2025, recapitulado pela Fortra, apontou 1.003.924 ataques de phishing no período — o número mais alto desde o final de 2023. Já a edição de 2026 do DBIR, da Verizon, observa que 15% das técnicas de ataque agora são potencializadas por IA generativa e que dispositivos móveis apresentam taxas de clique cerca de 40% maiores, o que muda onde o atacante mira.

O recado para o analista é direto: o phishing não é um problema de conscientização que vai sumir com treinamento. É um fluxo constante de tickets que precisa de processo repetível, automação onde for possível e critério de escalonamento claro. Tratar cada mensagem reportada como um caso isolado é o caminho mais rápido para afundar o turno em ruído.

O que chega ao SOC

Um ticket de phishing típico entra no SOC por três vias. A primeira é o relato do usuário, via botão de denúncia no cliente de e-mail — geralmente baixa qualidade, mas alta cobertura, e por isso indispensável. A segunda é o alerta do gateway de e-mail (Proofpoint, Mimecast, Microsoft Defender for Office), que já passou por uma camada de filtragem. A terceira é a correlação do SIEM, quando um indicador de comprometimento aparece associado a um destinatário interno.

O ponto cego mais comum é depender de uma única fonte. Se o SOC só reage ao botão de denúncia, perde os cliques que ninguém reportou. Se confia só no gateway, perde mensagens que burlaram a filtragem. Cruzar as três fontes no SIEM e manter visibilidade de log de autenticação (onde phishing bem-sucedido vira credential stuffing ou sessão roubada) é o que sustenta uma resposta rápida. A Microsoft descreve essa mesma combinação — SIEM, SOAR e EDR — como a base técnica do SOC moderno.

Triagem: ameaça real ou ruído

A triagem é onde a maioria dos SOCs perde tempo. O objetivo de quem está na posição de Nível 1 não é resolver o incidente, e sim classificá-lo em poucos minutos em uma de três categorias: descartar (falso positivo ou campanha já bloqueada), conter imediatamente (clique confirmado em payload ativo) ou escalar para investigação profunda (indícios de comprometimento, mas sem certeza).

Um checklist de triagem enxuto acelera a decisão sem virar burocracia:

Origem já conhecida? O domínio ou IP do remetente aparece em feeds de inteligência de ameaças ou em tickets anteriores do próprio SOC?
Houve interação? Logs de proxy, EDR e autenticação mostram clique, download ou login suspeito nas horas seguintes à entrega?
Alcance da campanha. Outros destinatários receberam a mesma mensagem? Isso define se é um ticket isolado ou um incidente de escopo maior.
Severidade do ativo. O destinatário tem privilégio administrativo ou acesso a dados sensíveis? Isso muda o critério de escalonamento.

Quem responde essas quatro perguntas com dados — e não com achismo — consegue encaminhar o ticket para o caminho certo antes de o atacante concluir o movimento lateral. Para aprofundar o critério de priorização, vale revisar os playbooks de resposta a incidentes no SOC, que padronizam a decisão de turno e reduzem o ruído sem perder sinal.

Indicadores que realmente importam

Na fase de análise, o que separa um analista experiente de um iniciante é saber onde olhar primeiro. Nem todo campo do cabeçalho merece atenção. Os indicadores de maior valor prático são:

Cabeçalho de autenticação de e-mail: os resultados de SPF, DKIM e DMARC indicam se a mensagem passou ou falhou na validação do domínio. Falha de DMARC com remetente spoofado de marca conhecida é um sinal forte.
URLs redirecionadas: o link visível raramente é o destino final. Expandir redirecionamentos e verificar o domínio de pouso contralistas de reputação é passo obrigatório.
Anexos em sandbox: acionar detonação em ambiente controlado antes de abrir qualquer anexo de mensagem suspeita. Macros, arquivos compactados com senha e atalhos .lnk são bandeiras vermelhas.
Indicadores de comprometimento no endpoint: processos filhos incomuns a partir do cliente de e-mail ou do navegador, conexões para infraestrutura desconhecida e alterações de registro típicas de persistência.

A tentação aqui é coletar dezenas de indicadores para parecer exaustivo. O que reduz MTTR é priorizar os quatro acima e registrar o resto no ticket para pós-incidente. Quem quiser estruturar a lógica de detecção de forma mais ampla pode partir do estudo de cobertura do MITRE ATT&CK no SIEM, que mapeia técnicas de acesso inicial — incluindo phishing — em regras acionáveis.

Resposta: contenção e erradicação

Quando a triagem confirma um phishing ativo com indícios de comprometimento, a resposta não pode esperar. A sequência abaixo é a ordem que melhor corta o ataque no menor tempo:

Bloquear o indicador na borda. Domínio, IP e URL do payload entram imediatamente em firewall, proxy e gateway de e-mail. Isso protege o restante da organização mesmo antes de o ticket ser encerrado.
Isolar o endpoint afetado. Se houve clique confirmado, isolar o host da rede via EDR mantendo o canal de resposta. Preservar a memória e os logs para análise forense posterior.
Revogar sessões e forçar troca de senha. Se credenciais foram inseridas, invalidar tokens ativos e forçar redefinição com MFA. Sessões roubadas sobrevivem à troca de senha — por isso revogar primeiro é essencial.
Buscar propagação. Caçar nos logs do SIEM os mesmos indicadores em outros hosts e usuários, e revisar logins bem-sucedidos em serviços críticos nas janelas de tempo suspeitas.
Comunicar e documentar. Registrar cronologia, indicadores e ações no ticket e avisar a equipe afetada. Documentação limpa é o que sustenta melhoria contínua do playbook.

A ordem importa. Muitos SOCs perdem tempo tentando entender todo o escopo antes de conter — e o atacante aproveita esses minutos. Contenção primeiro, escopo depois.

O playbook que reduz o MTTR

Diferenciar playbook de runbook economiza discussão no turno. O Swimlane resume bem: o runbook trata do como (coletar um log, isolar um host, rodar uma query), enquanto o playbook define o o quê e o por quê — a estratégia de decisão para cada categoria de incidente. A tabela abaixo organiza um playbook de phishing em fases mensuráveis:

Fase	Objetivo	Indicador de sucesso
Detecção	Receber o ticket de qualquer uma das três vias	Tempo até primeiro alerta
Triagem	Classificar em descartar, conter ou escalar	Tempo de decisão do Nível 1
Análise	Extrair indicadores e confirmar interação	Indicadores registrados no ticket
Contenção	Bloquear, isolar e revogar sessões	MTTC (tempo de contenção)
Erradicação	Remover persistência e caçar propagação	Sem indicadores residuais
Pós-incidente	Atualizar regras e alimentar inteligência	Regra nova ou ajuste de detecção

Medir cada fase é o que transforma o playbook em instrumento de melhoria. Sem métricas, ele vence documento que ninguém revisa. Para conectar essas fases a métricas de turno, vale revisar como MTTD, MTTR e KPIs de SOC se traduzem em decisões reais de operação.

Erros que aumentam o MTTR

Alguns padrões se repetem em SOCs que sofrem com phishing recorrente. O primeiro é tratar cada ticket como caso único, sem capitalizar o que já foi visto. Toda campanha nova deve alimentar regras de detecção e listas de bloqueio — caso contrário o mesmo atacante volta a bater na mesma porta. O segundo é depender de clínica manual para tudo: detonar anexo, expandir URL e consultar reputação são tarefas que a automação faz em segundos e libera o analista para o que exige julgamento.

O terceiro erro é escalonar por pânico, não por critério. Quando tudo vira incidente crítico, nada é. Definir severidade pelo ativo afetado e pela confirmação de interação — não pelo medo do gestor — mantém o turno operável. E o quarto, talvez o mais caro: revogar senha sem revogar a sessão. Sessão roubada continua válida depois da troca de credencial, e é exatamente por isso que ataques de AiTM (adversário no meio) funcionam. Quem quiser entender essa classe específica de ameaça pode revisar a detecção de AiTM com Tycoon 2FA, que explora roubo de token em tempo real.