Estudos de Caso Documentados

Nota 08 do capítulo 27 - Governança da Biblioteca de CTI. Reúne cinco estudos de caso sintéticos e educativos, inspirados em intrusões públicas conhecidas, para calibrar a antecipação da CTI e a produtividade do hunting.
Cada caso traz contexto, cadeia de ataque resumida, o que a inteligência deveria ter antecipado, o que o hunting encontraria e as lições de governança, fechando com tabela comparativa e padrões transversais.
Dialoga com o ciclo e as metodologias dos capítulos 06 e 07, com os templates da nota 07 deste capítulo e com os datasets da nota 09, que permitem reproduzir cada caso em laboratório.

1. Contexto e Posicionamento na Biblioteca

A biblioteca ensina conceitos, frameworks e consultas, mas conhecimento só vira capacidade quando é testado contra a lógica real de intrusões que aconteceram. Os estudos de caso desta nota cumprem esse papel de ponte: são relatos sintéticos, construídos a partir de padrões públicos e amplamente documentados de intrusões de ransomware, fraude financeira, espionagem e abuso de identidade, escritos com o formato fixo que o capítulo governa. O objetivo não é recontar incidentes de terceiros em detalhe forense, e sim extrair de cada um a tríade que treina o analista: o que a CTI deveria ter antecipado, o que o hunting teria encontrado e o que muda na operação depois da lição.

O formato fixo é deliberado e reaproveita o template da nota 07. Cada caso cabe em uma página, pode ser usado como exercício de discussão em reunião de time e serve de material para os labs da nota 09, onde o aluno caça nos mesmos padrões dentro de datasets simulados. A tabela comparativa da seção 8 permite ver, de uma vez, quais táticas se repetem entre casos diferentes e por que uma única lacuna de cobertura, como autenticação anômala, aparece em três cenários aparentemente distintos.

Vale registrar que os casos são compostos por padrões públicos consolidados, e não por cópias de dossiês confidenciais, e que os nomes de grupos citados servem como referência de estilo operacional conhecido. Essa escolha é intencional da governança: o acervo da biblioteca precisa poder circular internamente com rótulo TLP:CLEAR em sua maior parte, e relatos compostos com técnicas bem documentadas cumprem o papel didático sem expor fontes nem vítimas específicas.

2. Como Ler e Reaproveitar Estudos de Caso

Leia cada caso duas vezes com lentes diferentes. Na primeira leitura, siga a cadeia de ataque como narrativa e identifique os pontos em que a organização tinha dados para saber o que acontecia, porque esses pontos são as oportunidades de detecção e de caça. Na segunda leitura, olhe para trás, da perspectiva da CTI, e liste o que estava disponível publicamente antes da intrusão: relatos de campanha contra o setor, TTPs conhecidas do grupo, indicadores já compartilhados em comunidades, avisos de agências. A distância entre o que era sabível e o que foi acionado é a medida real da maturidade do programa, e é exatamente essa distância que a biblioteca tenta encurtar.

Para reaproveitar o caso em treinamento, converta a cadeia de ataque em hipóteses de caça no template da nota 07, atribua técnicas ATT&CK a cada passo e verifique se a organização teria as fontes de dados necessárias em cada elo da cadeia. Um caso bem usado produz entre cinco e oito hipóteses reutilizáveis, e cada hipótese que termina em negativo com fonte de dados confirmada ainda assim melhora a métrica de cobertura documentada no capítulo 11.

A extração muda de forma conforme o papel de quem lê, e vale fixar essa diferença para orientar sessões de estudo em grupo, nas quais perfis diferentes leem o mesmo caso e depois cruzam conclusões.

3. Caso 1: Ransomware com Dupla Extorsão

Contexto: intrusão em empresa de médio porte com objetivo de criptografia e extorsão, no padrão das operações de grupos como LockBit e ALPHV, em que o atacante exfiltra dados antes de criptografar e pressiona a vítima duas vezes, com bloqueio operacional e com publicação em leak site. O acesso inicial típico começa com credencial de VPN ou acesso remoto comprada de corretor de acesso inicial, muitas vezes sem MFA no perímetro exposto.

Cadeia de ataque resumida:

1. Acesso por credencial válida de VPN obtida de corretor de acesso inicial, sem segundo fator.
2. Reconhecimento de diretório com comandos nativos de rede e enumeração de contas privilegiadas.
3. Dump de credenciais da memória do processo LSASS em estações de administrador.
4. Escalada para conta de serviço com privilégio de domínio e criação de persistência leve.
5. Exfiltração de dados sensíveis para serviço de armazenamento em nuvem do atacante.
6. Desativação de proteções, exclusão de shadow copies e criptografia em massa via ferramenta de administração remota.

O que a CTI deveria ter antecipado: monitoramento de leak sites e de corretores de acesso que anunciam credenciais do setor, correlação de credenciais corporativas vazadas em fóruns, e a previsão de que a dupla extorsão cria uma janela de dias entre exfiltração e criptografia, em que o beacon de C2 e o volume de saída incomum são detectáveis. O relatório tático sobre o grupo deveria alimentar regras para T1003.001 e T1490 antes do primeiro contato.

O que o hunting encontraria: execuções de vssadmin ou wbadmin em servidores que nunca fizeram backup por linha de comando, processos de administração remota criados por contas recém-privilegiadas, beaconing para infraestrutura recém-registrada e picos de upload para serviços de nuvem fora do padrão do host. A caça da nota 07, no exemplo do plano HUNT-2026-014, cobre exatamente a fase de C2 deste caso.

Lições: MFA no perímetro remoto elimina a porta mais barata do atacante; a janela da dupla extorsão é tempo de reação comprado, e o time precisa de playbook que trate exfiltração como incidente de criptografia em potencial; e credencial de administrador em memória de estação é o elo que transforma uma intrusão pequena em desastre de domínio.

4. Caso 2: BEC com Fraude de Fornecedor

Contexto: fraude de pagamento no padrão de grupos de crime financeiro como FIN11 e células de engenharia social de Scattered Spider, em que o atacante compromete ou imita a caixa de correio de um fornecedor real, acompanha um thread de faturamento legítimo por dias e substitui, na hora do pagamento, a conta bancária por conta controlada por ele. Não há malware na vítima em boa parte dos casos, o que desafia times que só caçam em endpoint.

Cadeia de ataque resumida:

1. Credencial do fornecedor obtida por phishing de faturamento ou comprada de vazamento anterior.
2. Regra de encaminhamento silenciosa configurada na caixa comprometida para manter acesso.
3. Observação passiva de threads de cobrança e pagamento para mapear o ciclo do pagamento.
4. Domínio typosquat registrado imitando o fornecedor, para rodapés de conversa.
5. Substituição de boleto ou fatura com nova conta bancária, no momento certo do ciclo.
6. Cobrança confirmada e movimentação rápida de fundos por rede de laranjas.

O que a CTI deveria ter antecipado: monitoramento de domínios typosquat parecidos com parceiros estratégicos, verificação de credenciais de fornecedores em vazamentos, e alerta de novo beneficiário bancário como evento de risco de negócio, não apenas financeiro. A inteligência de fraude regional, com padrões de PIX e boleto, complementa a CTI genérica importada.

O que o hunting encontraria: regras de encaminhamento criadas em caixas de fornecedor e de financeiro, com T1114.003 como âncora, consentimentos e logins de caixa de outro país ou ASN novo, e correspondências com anexo de fatura alterada cujo autor difere do histórico da thread. Caça em log de auditoria de e-mail é o único caminho quando não há malware.

Lições: BEC é caso de governança de identidade e de processo financeiro tanto quanto de segurança; a verificação de mudança de conta bancária por canal fora do e-mail é controle barato e decisivo; e logs de auditoria de SaaS são telemetria de primeira classe para o hunting, tema que a nota do capítulo 08 sobre cloud e SaaS aprofunda.

5. Caso 3: Intrusão APT com Persistência Prolongada

Contexto: espionagem no padrão de grupos como APT29, com acesso inicial por phishing sofisticado ou por senha de prestador, movimento discreto e objetivo de coleta prolongada. A assinatura do caso é a paciência: o adversário usa ferramentas nativas, mantém baixo ruído e sobrevive a pelo menos uma troca de estação de trabalho do usuário comprometido, o que puxa o dwell time para meses.

Cadeia de ataque resumida:

1. Phishing direcionado com anexo de arquivo containerizado entregue a alvo específico.
2. Execução via sideload de DLL em aplicativo legítimo assinado, evitando alerta de AV.
3. Persistência por tarefa agendada e por técnica de run key em host de pouca supervisão.
4. Uso de ferramenta remota legítima de administração para movimento lateral com credencial válida.
5. Túnel de C2 por DNS ou HTTPS para domínio de aspecto benigno, com baixo volume.
6. Coleta em cadência lenta e exfiltração fragmentada para não gerar pico de tráfego.

O que a CTI deveria ter antecipado: o relato do grupo com suas TTPs documentadas converte em hipóteses de caça imediatas, como sideload em binários assinados e tarefas agendadas criadas por processo inusitado; a lista de prestadores com acesso remoto vira superfície priorizada; e o ciclo de disseminação da nota 03 do capítulo 07 deveria entregar o perfil do grupo ao time antes da campanha que o usou contra o setor.

O que o hunting encontraria: relações de processo pai e filho anômalas, como aplicativo de escritório iniciando script interpreter, tarefas agendadas sem histórico anterior no host, autenticações do mesmo usuário em duas geografias e conexões de saída de baixo volume e alta regularidade para domínio de idade recente. Caças comportamentais, baseadas em TTP e não em IOC, são a única abordagem viável contra adversário que recicla infraestrutura a cada campanha.

Lições: contra adversário paciente, a corrida é de cobertura e de retenção de dados, não de alertas; a detecção de sideload e de persistência em host de pouca supervisão depende de linha de base construída antes; e IOC isolado envelhece em dias, enquanto comportamento documentado em ATT&CK envelhece em anos, tese central da pirâmide de dor do capítulo 04.

6. Caso 4: Password Spray em Cloud

Contexto: campanhas de password spray, associadas publicamente tanto a atores de espionagem quanto a grupos de extorsão, em que o adversário testa poucas senhas comuns contra milhares de usuários, distribuídas em muitos endereços IP, para contornar bloqueio por tentativas repetidas. O alvo é o tenant de identidade em nuvem, e o sucesso depende menos de força bruta e mais de contas sem MFA e de senhas fracas ou reaproveitadas.

Cadeia de ataque resumida:

1. Enumeração de nomes de usuário válidos por OSINT, footprint de e-mail ou endpoint de tenant.
2. Distribuição das tentativas entre redes residenciais e proxies para diluir o volume por origem.
3. Teste de senhas de dicionário e de padrões sazonais contra todo o diretório, em cadência baixa.
4. Acesso bem-sucedido a conta sem MFA, seguido de silêncio inicial para não alertar o usuário.
5. Registro de dispositivo ou consentimento de aplicativo para persistir sem a senha.
6. Leitura de correio e coleta de documentos, com possibilidade de elevação a outros serviços.

O que a CTI deveria ter antecipado: avisos públicos de campanhas de spray ativas contra o setor e os padrões de user agent e ASN usados, que os provedores publicam nos relatórios de threat intelligence de identidade; a auditoria de contas sem MFA e de contas de serviço com senha fixa é requisito de CTI aplicada, e o mapa de exposição do capítulo 21 ajuda a identificar identidades fora do domínio corporativo.

O que o hunting encontraria: falhas de autenticação com mesma senha testada contra muitos usuários, agrupadas por user agent incomum em vez de por IP, picos de falha por ASN de rede residencial e logins com sucesso imediatamente seguidos de consentimento de aplicativo ou registro de autenticador. KQL e SPL de identidade, documentados no capítulo 08, cobrem a detecção com consultas simples de agregação.

Lições: proteção de identidade é a superfície de menor custo e maior retorno do programa; bloqueio por IP é insuficiente contra spray distribuído, e o sinal correto é a razão entre usuários tentados e origens; e silêncio pós-compromisso exige caça por mudança de configuração, porque o ladrão discreto não gera alerta de volume.

7. Caso 5: Abuso de OAuth em SaaS

Contexto: abuso de consentimento OAuth em ambientes de produtividade em nuvem, no padrão de campanhas de consent phishing e de operações que usam aplicativos maliciosos para persistência em SaaS, observadas em atores como Scattered Spider e em campanhas de espionagem financeira. O atacante não precisa de senha nem de malware: basta que o usuário autorize um aplicativo de terceiros com permissões amplas de leitura de correio, e o aplicativo sobrevive a troca de senha e a revogação de sessão.

Cadeia de ataque resumida:

1. Phishing com página de consentimento legítima do provedor, pedindo autorização a app de terceiros.
2. Usuário autoriza aplicativo com permissões de leitura de correio e de contatos.
3. Aplicativo sincroniza caixa e contatos em cadência contínua, fora da visão de endpoint.
4. Uso das permissões para coleta de documentos e para envio interno de novos phishing com confiança herdada.
5. Persistência administrativa por registro de service principal ou concessão de papel adicional quando há conta privilegiada.
6. Remoção do app pela interface somente quando a anomalia é reportada, meses depois.

O que a CTI deveria ter antecipado: relatos públicos de campanhas de consent phishing com nomes de aplicativos e publisher IDs, políticas de bloqueio de consentimento a apps não verificados e inventário de aplicativos já autorizados no tenant, que a maioria dos ambientes nunca revisou. A inteligência de campanha alimenta a lista de apps proibidos antes da chegada do golpe.

O que o hunting encontraria: consentimentos novos a apps com publisher não verificado ou recém-criado, apps com permissão de leitura de correio sem correspondência com processo de negócio, picos de chamada de API de leitura por aplicativo e trilhas de e-mail interno com padrão de envio em massa por conta humana. A caça em log de auditoria de SaaS é a única visão real desse adversário.

Lições: identidade em SaaS inclui identidade de aplicativo, e programa que só olha usuários está cego para metade do tenant; bloqueio por padrão de consentimento a apps não verificados é controle de alto impacto e baixo custo; e a revisão periódica de apps autorizados pertence ao ciclo semestral da nota 11, como item de verificação fixo.

8. Tabela Comparativa dos Casos

A tabela a seguir compara os cinco casos pelos eixos que mais ensinam: vetor de entrada, objetivo do adversário, assinatura comportamental mais confiável, maior lacuna típica de CTI e a caça prioritária que cada cenário recomenda ao leitor.

O padrão transversal da tabela é explícito: quatro dos cinco casos começam em identidade, e nenhum depende de malware sofisticado para chegar ao objetivo. O programa que investe a maior parte do orçamento em endpoint e nada em telemetria de identidade e de SaaS cobre o elo que os casos mostram secundário e abandona o elo que todos eles usam de fato, e é essa distorção que a tabela existe para evidenciar.

9. Lições Transversais e Erros Comuns

A primeira lição transversal é que o tempo é a variável decisiva em todos os casos: a janela entre exfiltração e criptografia, os dias de observação do thread de faturamento, os meses de persistência silenciosa, o silêncio pós-spray e a sobrevivência do app OAuth à troca de senha. CTI madura compra tempo antecipando, e hunting maduro usa o tempo comprado para caçar dentro da janela ainda aberta. O erro comum é tratar o estudo de caso como curiosidade de leitura, sem converter a cadeia em hipóteses e em requisitos de telemetria, o que reduz o exercício a entretenimento técnico.

O segundo erro comum é superajustar a defesa ao caso específico, criando regra para o loader da semana e nada para a classe de comportamento. A conversão correta segue a pirâmide de dor: IOC da campanha vira bloqueio tático, mas o valor permanente está na detecção comportamental de shadow copy, de regra de encaminhamento, de sideload e de consentimento novo. Por fim, cuidado com a narrativa de caso incompleta: relatos públicos são visão parcial, e o analista deve tratar lacunas do relato como hipóteses a testar no próprio ambiente, nunca como prova de que a técnica não ocorreu.

Um cuidado final de governança é a higiene da coleta de casos novos: quando o time introduzir um estudo de caso próprio, derivado de incidente interno, ele deve entrar no acervo já anonimizado, sem dados de clientes, sem indicadores sensíveis e com rótulo TLP definido desde a primeira linha. O acervo que mistura material didático com material operacional sensível perde a capacidade de ser lido com segurança por novos contratados, que são justamente o público que mais se beneficia dos estudos de caso.

10. Integração com o Restante da Biblioteca

Os casos amarram os capítulos do acervo em exercício único: a cadeia de ataque usa o vocabulário do capítulo 04, a antecipação aplica o ciclo de inteligência do capítulo 01 e a disseminação do capítulo 07, o hunting usa as técnicas do capítulo 08 e as metodologias do capítulo 23, e a lição final alimenta as métricas do capítulo 11 e as boas práticas do capítulo 12. Dentro do próprio capítulo, os casos servem de material para os templates da nota 07 e para os laboratórios da nota 09, que permitem caçar os mesmos padrões em datasets simulados.

Para usar esta nota em treinamento, escolha um caso por mês, rode a cadeia contra o ambiente real com as consultas sugeridas e registre o desfecho no quadro de caça do time. Cinco casos convertidos em hipóteses executadas rendem um ciclo de cobertura documentado que qualquer avaliação de maturidade reconhece, e os negativos, devidamente registrados, valem tanto quanto os positivos.