Hunting em E-mails e Campanhas de Phishing

Nota 15 do capítulo 08 (Técnicas de Hunting por TTPs), levando a caça ao vetor de acesso inicial mais frequente das campanhas reais.
Estrutura a telemetria de e-mail (gateway, headers, SPF/DKIM/DMARC), as TTPs de phishing e BEC e os padrões de caça acionáveis.
Complementa as notas 12 a 14 com a fonte de identidade e conteúdo; dialoga com os capítulos 03 e 05 e com o TH.10 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

O e-mail segue como porta de entrada dominante das intrusões: os anexos de spearphishing correspondem ao T1566.001 do ATT&CK, os links ao T1566.002, e cadeias de ransomware como LockBit e ALPHV mostram, caso a caso, a entrada por e-mail ou por credencial colhida em phishing. Atores modernos como Scattered Spider combinam mensagem de e-mail com voz e SMS para vencer MFA, o que reforça que a caça precisa cobrir o evento de entrega e a consequência posterior. Enquanto as notas de rede tratam de milhões de registros por dia, a telemetria de e-mail é de alto sinal e volume modesto, o que a torna o terreno mais produtivo para programas de caça em início de maturidade.

O posicionamento na biblioteca é duplo. No eixo da campanha, esta nota alimenta a análise de agrupamentos do capítulo 05, porque encontrar mensagens irmãs e a infraestrutura por trás delas é matéria-prima de cluster. No eixo da vítima, a nota fecha o arco até o clique, o consentimento OAuth e o login do adversário, conectando a mensagem ao restante da telemetria de identidade. As consultas seguem o TH.10 do capítulo 15 quando partem de IOC, e a gramática de hipótese do capítulo 07 quando partem de TTP.

2. Telemetria de E-mail Disponível para Caça

A caça de e-mail começa pelo inventário honesto do que existe. O gateway entrega o veredito por mensagem; os headers entregam a rota real; a autenticação SPF, DKIM e DMARC entrega a prova de quem pode falar pelo domínio; e a telemetria de caixa e de identidade entrega o que aconteceu depois da entrega. A tabela abaixo organiza as fontes e os campos de maior valor para caça.

Três detalhes técnicos fazem diferença na leitura. O SPF valida o domínio do envelope, o Return-Path, contra o IP que conectou; o DKIM valida a assinatura do domínio d=; e o DMARC verifica o alinhamento desses dois com o domínio exibido no From, que é o que o usuário vê. A cadeia de Received se lê de baixo para cima, e o primeiro salto revela o IP de origem real, frequentemente um VPS barato em gama de hosting reconhecível. O X-Mailer cumpre no e-mail o papel do user agent no HTTP, e campanhas automatizadas denunciam mass mailers onde a marca supostamente remetente usaria cliente corporativo. Em ambiente Microsoft, as tabelas EmailEvents, EmailAttachmentInfo, EmailUrlInfo e UrlClickEvents concentram o essencial; em gateways como Proofpoint e Mimecast, os logs exportados cobrem o mesmo papel. Preserve o .eml completo no caso, porque vereditos mudam e a retrocaça depende do header original.

3. TTPs de Phishing, BEC e Fraude por E-mail

A tabela abaixo amarra as TTPs de maior prevalência à manifestação observável e ao mapeamento ATT&CK. BEC (Business Email Compromise) merece destaque porque quebra a suposição de que caça de e-mail busca anexo: a fraude financeira frequentemente não tem payload, só texto urgente e conta bancária nova.

O sequestro de conversa é a TTP que mais engana filtros e usuários, porque chega dentro de um thread real, com assunto autêntico e histórico aparente. O sinal de caça é estrutural: o In-Reply-To e o assunto referenciam conversa que existe no tenant, mas o remetente nunca participou dela, e a cadeia de Received é curta demais para mensagem que se diz resposta. Em BEC, os padrões de caça combinam display name que espelha executivo interno com domínio externo, Reply-To divergente do From, e mensagem sem anexo nem link enviada a financeiro fora do horário. OAuth phishing fecha o espectro: a mensagem pede aprovação de aplicativo, e o evento de caça não está no gateway, está no log de consentimento do IdP.

4. Caça por Padrões: Consultas de Exemplo

O primeiro padrão é o remetente externo novo com anexo ativo, hipótese que parte do baseline de domínios remetentes dos últimos 90 dias. O formato da consulta abaixo agrupa por domínio, arquivo e hash, e o comentário lembra que os valores de FileType variam por conector.

// Anexos ativos entregues nos ultimos 7 dias; ajustar valores de FileType ao conector
EmailAttachmentInfo
| where Timestamp > ago(7d)
| where FileType in~ ("iso", "img", "lnk", "exe", "html", "docm", "xlsm")
| summarize Anexos = count(), Destinatarios = dcount(RecipientEmailAddress),
            PrimeiraEntrega = min(Timestamp) by SenderFromDomain, FileName, SHA256
| where Anexos >= 3
| order by Anexos desc

O segundo padrão cruza falha de autenticação com domínio externo fora da lista corporativa, base da caça de lookalike que o caso da seção 5 executa de ponta a ponta.

// Falhas de autenticacao com dominio externo; campo AuthenticationDetails embute spf/dkim/dmarc
EmailEvents
| where Timestamp > ago(7d)
| where EmailDirection == "Inbound"
| where AuthenticationDetails has "dmarc" and AuthenticationDetails has "fail"
| where SenderFromDomain !in ("atlas-manutencao.com.br", "atlas.com.br", "atlasmanutencao.com.br")
| summarize Mensagens = count(), Destinatarios = dcount(RecipientEmailAddress)
          by SenderFromDomain, SenderDisplayName
| order by Mensagens desc

O terceiro padrão parte da vítima: cliques permitidos após entrega, que transformam mensagem entregue em incidente candidato. O quarto sobe para o IdP e procura consentimentos OAuth recentes, priorizando permissões de leitura e escrita de e-mail e de persistência.

UrlClickEvents
| where Timestamp > ago(7d)
| where IsClickedThrough == true
| summarize Cliques = count(), Usuarios = dcount(AccountUpn),
            PrimeiroClique = min(Timestamp) by Url, ActionType
| order by Cliques desc

// Consentimentos OAuth no Entra ID; avaliar permissoes pedidas como Mail.ReadWrite e offline_access
AuditLogs
| where TimeGenerated > ago(30d)
| where ActivityDisplayName == "Consent to application"
| extend Aplicacao = tostring(TargetResources[0].displayName)
| extend Usuario = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, Usuario, Aplicacao, Result

A caça de lookalike por similaridade fecha o arsenal. O script abaixo compara domínios externos coletados do gateway com a lista corporativa e imprime razões de similaridade a partir de 0,90, que entram em revisão manual. Homoglifos com caracteres cirílicos e gregos escapam da razão de string, então a rotina madura adiciona normalização Unicode e comparação visual dos candidatos altos.

# lookalike.py: compara dominios externos com a lista corporativa
import sys
from difflib import SequenceMatcher

corporativos = {"atlas-manutencao.com.br", "atlas.com.br", "atlasmanutencao.com.br"}
vistos = set()
for linha in sys.stdin:
    dominio = linha.strip().lower()
    if not dominio or dominio in corporativos or dominio in vistos:
        continue
    vistos.add(dominio)
    for alvo in sorted(corporativos):
        razao = SequenceMatcher(None, dominio, alvo).ratio()
        if razao >= 0.90:
            print(f"{razao:.3f} {dominio} aproxima-se de {alvo}")

A lista de padrões operacionais abaixo completa o repertório e deve virar itens de rotina do catálogo de caça, cada um com dono e cadência.

• Novo remetente com anexo ativo: baseline de 90 dias de domínios remetentes, fila direta para domínio novo com anexo executável ou macro habilitada.
• Reply-To divergente do From: verificação em toda mensagem com anexo ou link, porque é a barreira mais barata contra BEC.
• Thread referenciada sem participação do remetente: sinal estrutural do sequestro de conversa, verificável por Message-ID e In-Reply-To.
• Clique em ambiente móvel após e-mail com imagem grande e pouco texto: proxy do padrão de quishing que os filtros de URL em texto deixam passar.
• Consentimento OAuth de aplicativo novo por usuário não administrador: fila de prioridade máxima quando as permissões alcançam a caixa de entrada.
• X-Mailer incompatível com a marca remetente: mass mailer genérico onde a mensagem diz ser sistema corporativo.

5. Caso de Caça: Campanha Lookalike

O caso da biblioteca acompanha a Atlas Manutenção, empresa com domínio atlas-manutencao.com.br, e aplica a hipótese de BEC com lookalike. O primeiro passo roda o lookalike.py sobre os domínios remetentes externos de 90 dias e destaca atlas-manutenca.com.br, com razão de 0,98 sobre o domínio oficial e registro de 11 dias atrás em registradora conhecida por abuso, com privacidade de WHOIS. O passo seguinte caça o gateway por esse domínio: 34 mensagens entregues em seis dias para o time financeiro, assunto no formato RE: Fatura 2025-0412 com ajustes bancários urgentes, dmarc fail, dkim none, spf fail e X-Mailer de mass mailer PHP, sem anexo, com link para portal de faturas sob o domínio do lookalike.

O terceiro passo caça a consequência: UrlClickEvents confirma dois cliques no link, e o proxy registra POST de credenciais para o portal falso; em paralelo, os logs do IdP mostram, na madrugada seguinte, tentativas de login com a senha colhida de uma das vítimas, bloqueadas por política de país e MFA, o que conecta a campanha à telemetria de identidade da nota 04 do capítulo 02. A resposta combinou bloqueio do domínio e do padrão no gateway, solicitação de takedown à registradora, reset de senha e revogação de sessões das vítimas que clicaram, abertura de IR para a vítima que digitou credenciais e comunicação dirigida ao time financeiro com o exemplo real. A conversão em inteligência fechou o ciclo: o cluster entrou no MISP com TLP:AMBER para compartilhamento setorial, e duas detecções permanentes saíram do caso, regra de gateway por X-Mailer e padrão de assunto, e consulta agendada de dmarc fail com domínio similar ao corporativo.

A lição de medida do caso é dupla e entra no capítulo 11: o tempo entre primeira entrega e primeiro clique foi de 41 horas, e a taxa de bypass, mensagens entregues com veredito limpo sobre o total da campanha, ficou em 34 de 61. Esses dois números, que só a caça entrega, justificaram ajuste de filtro e treinamento direcionado, e viraram linha de tendência acompanhada por campanha.

6. Erros Comuns e Pontos de Atenção

• Caçar apenas o que o gateway bloqueou; efeito: o esforço se concentra no que já foi defendido e o bypass fica invisível; correção: priorizar entregas com veredito limpo que casam com TTPs do capítulo 03.
• Ignorar a telemetria pós-entrega; efeito: campanha parece inofensiva porque ninguém olhou cliques e logins; correção: casar sempre entrega com clique, consentimento e autenticação posterior.
• Basear BEC em busca de anexo; efeito: a fraude financeira típica não tem payload e escapa à caça técnica; correção: caçar padrões de autenticação, identidade exibida e conteúdo.
• Usar apenas similaridade de string para lookalike; efeito: homoglifos e variações de Unicode passam ou confundem; correção: normalizar Unicode, somar idade do domínio e revisar manualmente os candidatos altos.
• Descartar headers ao responder e encaminhar; efeito: Return-Path, Received e Authentication-Results originais se perdem e a evidência esfria; correção: preservar o .eml completo no caso com hash de integridade.
• Tratar QR code como curiosidade de laboratório; efeito: evasão sistemática de filtros que só leem texto; correção: incluir na rotina o par imagem grande com pouco texto seguido de clique móvel.
• Manter a watchlist de domínios corporativos fora de controle de versão; efeito: o lookalike compara contra lista velha e o domínio novo da marca escapa; correção: fonte única versionada, com dono e revisão trimestral.

7. Integração com o Restante da Biblioteca

O ciclo de vida dos IOC do capítulo 03 é o destino natural dos domínios, hashes e URLs desta nota, e as plataformas do mesmo capítulo, MISP e OpenCTI, recebem o cluster pronto para compartilhamento sob TLP 2.0. A análise de campanhas e a atribuição do capítulo 05 consomem o agrupamento que a caça produz, e o TH.10 do capítulo 15 dá o formato de execução quando a caça parte de indicador em vez de TTP. A conversão dos padrões confirmados em regras de gateway e em consultas agendadas pertence ao capítulo 18, e as métricas de taxa de bypass e de tempo até clique alimentam o capítulo 11.

A fronteira com a nota 16 é a que mais cresce em relevância: quando o phishing entrega consentimento OAuth em vez de credencial, a caça sai do gateway e entra no plano de identidade e SaaS, e a resposta deixa de ser reset de senha e passa a ser revogação de concessão de aplicativo. Programas maduros tratam os dois cenários como um só pipeline, e-mail para identidade, e mantêm no catálogo de caça a consulta de consentimento rodando na mesma cadência das consultas de anexo e de clique.