Hunting por Exfiltração (Data Volume, Horários atípicos)

Nota 07 do capítulo 08 (Técnicas de Hunting por TTPs), cobrindo a tática de Exfiltration da MITRE ATT&CK com foco em volume, horário e staging.
Estrutura o baseline de volume por host e usuário, os vetores de exfiltração e suas assinaturas, e a distinção prática entre backup e exfiltração.
Continua a nota 06, que trata o mesmo canal de rede no papel de comando e controle, e dialoga com o TH.12 e o TH.15 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Exfiltração é o momento em que o incidente deixa de ser hipótese e vira dano mensurável: dados saem do perímetro e a pergunta da caça deixa de ser se o adversário está dentro e passa a ser o que ele levou. Diferente do beaconing, que se apoiava em regularidade, a exfiltração se apoiada em duas dimensões estatísticas complementares, que são volume fora do padrão e horário fora do padrão. O adversário pode controlar uma das dimensões, mas controla as duas com dificuldade, porque mover dados em massa é caro em tempo e em assinatura de rede.

O posicionamento na biblioteca é o de contraponto direto da nota 06: lá o sinal era cadência, aqui o sinal é quantidade e momento. A nota consome o baseline de normalidade descrito nos controles INS.5 e TH.2 do capítulo 15, porque exfiltração só é detectável contra uma referência de quanto é normal, e alimenta a resposta do capítulo 13 com a resposta à pergunta de escopo de dados. A distinção backup versus exfiltração é o coração conceitual da nota, porque é exatamente a ambiguidade que produz falsos positivos em volume e queima a credibilidade do programa de hunting.

2. Vetores de Exfiltração e suas Assinaturas

Os vetores se dividem entre aqueles que abusam de serviços aprovados e aqueles que usam canais próprios do adversário, e essa divisão define a telemetria necessária. Upload para armazenamento em nuvem pessoal esconde o tráfego atrás de endpoints legítimos e só se revela no log de proxy com identidade do usuário; exfiltração por DNS carrega dados em consultas e é detectável no resolver; exfiltração volumétrica sobre HTTPS usa o próprio canal de C2 e se revela por volume; e-mail é o vetor clássico de insider e de dados em pequeno volume; e o staging local é o precursor de todos, porque dados raramente são comprimidos e empacotados sem intenção de sair. A tabela consolida os vetores com as técnicas ATT&CK correspondentes.

A leitura operacional da tabela é que nenhum vetor se resolve com uma única consulta: upload para nuvem pessoal exige proxy com identidade, DNS exige resolver com log completo e staging exige telemetria de processo e de arquivo no endpoint. O hunting maduro encadeia os vetores em sequência, porque o padrão real de incidente é compressão seguida de upload, e não um evento isolado; a seção 6 mostra esse encadeamento no exemplo de caça.

3. Baseline de Volume por Host e Usuário

O baseline de volume é construído com agregação diária de bytes enviados por usuário e por host, em janela histórica de 30 dias, calculando média e percentil 95 como referências de normalidade. A média sozinha engana, porque funções de trabalho têm distribuições assimétricas: um engenheiro de vídeo pode ter upload diário de dezenas de gigabytes como rotina, e o percentil 95 absorve muito melhor esses picos legítimos. Exceções conhecidas, como agentes de backup, estações de publicação e jobs de migração, devem ser registradas por identidade e destino, e não removidas à mão da consulta, para que a exceção seja auditável e expire com o motivo. O desvio relevante para exfiltração é aquele em que o upload do dia supera de longe o histórico da própria identidade, e não apenas o limite genérico da rede.

// Desvio de upload diario por usuario contra o proprio historico de 30 dias
let Historico = 30d;
let Base = CommonSecurityLog
| where TimeGenerated > ago(Historico)
| where ApplicationProtocol in~ ("HTTP", "HTTPS") and SentBytes > 0
| summarize UploadDiario = sum(SentBytes) by Usuario = SourceUserName, Dia = bin(TimeGenerated, 1d)
| where isnotempty(Usuario);
Base
| summarize Media = avg(UploadDiario), P95 = percentile(UploadDiario, 95) by Usuario
| join kind=inner (
    Base
    | where Dia > ago(1d)
    | summarize Upload24h = sum(UploadDiario) by Usuario
) on Usuario
| extend Razao = round(Upload24h / max_of(Media, 1.0), 1)
| where Upload24h > 536870912 and Razao > 3
| project Usuario, Upload24h, Media, P95, Razao
| order by Upload24h desc

Dois ajustes definem a qualidade desse baseline. Primeiro, o corte mínimo de volume absoluto, aqui em 512 MB por dia, evita que desvios percentuais em usuários de tráfego baixo virem fila de triagem sem valor; o número deve ser calibrado pelo perfil da organização. Segundo, a comparação deve ser contra a própria identidade e não contra a média global, porque a média global pune exatamente os perfis com maior necessidade legítima de mover dados, que são também os mais visados em campanhas de ransomware e de roubo de propriedade intelectual.

4. Horários Atípicos como Sinal Independente

Horário atípico é calculado comparando o upload por hora do dia contra o histórico do mesmo usuário na mesma hora, e não contra um horário comercial genérico. Turnos, colaboração internacional e workaholics legítimos criam padrões individuais que um limite global destrói, então a referência correta é a própria identidade: um usuário que nunca enviou mais de 50 MB na faixa das 2h e de repente envia 2 GB às 3h merece atenção, mesmo que o volume total do dia pareça normal. O horário funciona como multiplicador de prioridade quando combinado com volume, e como sinal independente quando o adversário usa transferências pulverizadas para manter o volume diário dentro do baseline.

// Upload fora do padrao horario: comparacao por usuario e hora do dia
let Base = CommonSecurityLog
| where TimeGenerated > ago(30d)
| where ApplicationProtocol in~ ("HTTP", "HTTPS") and SentBytes > 0
| extend Hora = hourofday(TimeGenerated), UploadMB = todouble(SentBytes) / 1048576.0;
Base
| summarize UploadMedioHora = avg(UploadMB) by Usuario = SourceUserName, Hora
| join kind=inner (
    Base
    | where TimeGenerated > ago(24h)
    | summarize Upload24h = sum(UploadMB) by Usuario = SourceUserName, Hora = hourofday(TimeGenerated)
) on Usuario, Hora
| where UploadMedioHora < 50 and Upload24h > 1024
| project Usuario, Hora, UploadMedioHora, Upload24h
| order by Upload24h desc

A interpretação de horário deve considerar o fuso e o contexto do usuário, porque ferramentas de sincronização de nuvem rodam de madrugada por desenho e geram picos noturnos legítimos em massa. A saída prática é exigir segundo fator de confirmação, como processo de origem não padrão ou destino novo, antes de escalar um achado puramente horário. O histórico de viagem e férias do usuário, quando disponível no RH ou no IdP, resolve a maior parte da ambiguidade restante sem custo técnico adicional.

5. Staging Local como Precursor de Exfiltração

O staging é o elo que converte suspeita volumétrica em caso com evidência: arquivos são selecionados, frequentemente comprimidos com senha para escapar de inspeção e DLP, colocados em diretório de usuário e enviados em seguida. A telemetria necessária é a de processo e de arquivo no endpoint, com eventos de criação de arquivo e linha de comando completa, porque a flag de senha em compressores aparece na linha de comando e não em log de rede. Ferramentas de resposta a ransomware descobriram o mesmo padrão de hunting pelo outro lado: grupos como LockBit e ALPHV exfiltram com rclone antes de criptografar, e a linha de comando do rclone com parâmetros de transferência em massa é um dos achados mais valiosos de toda a caça de exfiltração.

// Precursors de staging: compressao com senha e ferramentas de transferencia em massa
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("7z.exe", "rar.exe", "winrar.exe", "tar.exe", "powershell.exe")
    or FileName in~ ("rclone.exe", "winscp.com", "mega-cmd.exe", "filezilla.exe")
| where ProcessCommandLine has_any ("-p", "-hp", "Compress-Archive", "rclone", "copy", "sync", "--transfers")
| where not(InitiatingProcessFileName in~ ("backup-agent.exe", "veeam.exe"))
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc

A consulta exige clareza sobre o que é padrão do ambiente: equipes de desenvolvimento comprimem artefatos, times de infraestrutura usam WinSCP para entregas e o agente de backup legítimo deve estar na lista de exclusão documentada. O refinamento que reduz falsos positivos sem matar o sinal é cruzar a compressão com senha em diretório de usuário com o evento de upload subsequente para destino externo, porque a sequência completa em janela de horas é o padrão que importa, e não o evento isolado de compressão.

A telemetria de arquivo complementa a de processo e vale por si só em ambientes sem cobertura de linha de comando, porque mostra o artefato de staging mesmo quando o compressor foi executado por binário não inventariado. O alvo são arquivos comprimidos criados recentemente em diretórios de usuário e temporários, com tamanho grande o bastante para interessar a um adversário e nome sugestivo de conteúdo sensível.

// Artefatos de staging: arquivos comprimidos recentes em diretorios de usuario
DeviceFileEvents
| where Timestamp > ago(7d)
| where ActionType in~ ("FileCreated", "FileRenamed")
| where FolderPath has_any ("C:\\Users\\", "C:\\Temp\\", "\\AppData\\Local\\Temp\\")
| where FileName endswith ".7z" or FileName endswith ".rar" or FileName endswith ".zip"
| summarize Arquivos = count(), Ultimo = max(Timestamp),
            Exemplos = make_set(FileName, 3)
            by DeviceName, AccountName, FolderPath
| where Arquivos >= 3
| order by Arquivos desc

6. Distinção Backup versus Exfiltração

A distinção entre backup e exfiltração é uma matriz de cinco dimensões que devem ser verificadas em conjunto, porque cada dimensão isolada é imitável pelo adversário. Backup legítimo usa agente assinado conhecido, destino corporativo homologado, agendamento estável, volume previsível e roda com identidade de serviço; exfiltração quebra pelo menos duas dessas dimensões, e o padrão real de incidentes quebra três ou mais. A tabela abaixo dá os critérios que o analista deve marcar antes de classificar um achado de volume.

O erro inverso também existe e é pior: chamar exfiltração de backup durante um incidente real atrasa a contenção e fecha a janela em que o dado ainda poderia ser recuperado da fila do provedor. Quando a matriz não fecha em nenhuma das duas categorias, a decisão correta é classificar como indeterminado com prazo de 24 horas para resposta, e não devolver o caso ao silêncio, porque a ambiguidade prolongada é a pior saída possível para o negócio.

7. Exemplo de Caça Completa

O roteiro do caso simula a investigação de um engenheiro de pesquisa cujo upload diário disparou 18 vezes acima do percentil 95 pessoal na madrugada de um domingo. A hipótese estruturada é: se um usuário comprometido preparou dados para sair, então existe compressão com senha em diretório de usuário seguida de upload para destino de nuvem fora da lista homologada dentro de uma janela de horas. A caça segue quatro passos com critérios de saída explícitos.

1. Confirmar o desvio com a consulta da seção 3 e medir o tamanho real do pico em MB e em número de conexões, separando upload para destinos corporativos de destinos externos; o objetivo é transformar um número agregado em lista de conexões endereçáveis.
2. Extrair a lista de destinos externos do período e classificar por categoria no serviço de reputação do proxy, marcando nuvem pessoal, domínios jovens e destinos sem histórico; reter candidatos cuja categoria não esteja homologada para a função do usuário.
3. Correlacionar no endpoint, com a consulta da seção 5, os eventos de criação de arquivo comprimido e as linhas de comando com flag de senha na mesma janela, conferindo se o arquivo local tem tamanho compatível com o volume do upload; a compatibilidade de tamanho é o elo de evidência mais forte do caso.
4. Consolidar a linha do tempo com horário de início da sessão do usuário, origem da sessão e eventos de autenticação do mesmo dia, porque exfiltração executada em sessão iniciada de IP desconhecido muda a classificação de vazamento de dados para comprometimento de conta e aciona a resposta do capítulo 13.

O vetor de e-mail merece um passo opcional quando o caso envolve insider ou volumes pequenos pulverizados, porque é o caminho que menos assina em rede e mais assina no gateway. O hunting complementar conta anexos externos por usuário e por dia, com atenção a envios que combinam arquivos comprimidos, destinatário externo novo e domínio do destinatário registrado há poucos dias. Esse passo custa pouco, funciona com telemetria que todo gateway de e-mail já produz e cobre exatamente a lacuna que o baseline de rede não cobre.

O veredicto do caso é construído com três evidências concorrentes, na mesma lógica da nota 06: volume fora do baseline pessoal, sequência de staging compatível e destino não homologado. Falta uma evidência, e o caso desce para fila de monitoramento com registro no baseline; faltam duas, e o caso é fechado como falso positivo documentado com as exceções atualizadas. Essa disciplina de encerramento é o que diferencia hunting de coleção de dossiês, e é também o que produz as métricas de precisão cobradas no controle MET.2 do capítulo 15.

8. Erros Comuns e Pontos de Atenção

• Usar limites globais de volume: médias e máximos da rede inteira punem perfis legítimos de alto tráfego e deixam passar exfiltração pulverizada em usuários de tráfego baixo; o baseline correto é por identidade, com percentil 95 e exceções auditáveis por destino.
• Caçar exfiltração sem identidade no proxy: tráfego agregado por IP de endpoint transforma todo achado em investigação de quem estava usando a estação, que é a pergunta errada; exigir proxy com autenticação ou EDR com processo de origem antes de prometer hunting de exfiltração.
• Tratar horário atípico como prova: turnos, fuso e sincronização automática geram picos noturnos legítimos em massa; horário é multiplicador de prioridade e precisa de segundo fator, como staging compatível ou destino novo, para virar caso.
• Ignorar o canal de resposta do incidente: quando o dado já saiu, a prioridade muda de detecção para contenção e negociação, e a janela do provedor de nuvem para reverter upload é de horas; a consulta que roda depois da semana de fato não é hunting, é autópsia.
• Esquecer canais não HTTP: exfiltração por DNS, por FTP legado e por serviços de desenvolvedor como repositórios externos escapam do baseline de proxy; incluir o resolver e logs de transferência de arquivos na cobertura, conforme o inventário do controle TH.1 do capítulo 15.
• Medir exfiltração apenas em bytes: volume baixo e repetido ao longo de semanas carrega propriedade intelectual tão valiosa quanto um pico único, e a consulta que corta por limite absoluto perde o adversário paciente; combinar corte absoluto com desvio relativo ao histórico e com frequência de destinos novos cobre as duas geometrias.

9. Integração com o Restante da Biblioteca

Esta nota fecha a dupla de caça em rede iniciada pela nota 06: lá o sinal era cadência de C2, aqui são volume e horário, e as duas consultas compartilham a mesma telemetria de proxy e de endpoint com fontes descritas no capítulo 02. O baseline de volume é aplicação direta dos controles INS.5 e TH.2 do capítulo 15, e a distinção backup versus exfiltração é um caso concreto de hipótese estruturada do controle TH.6 com critérios de encerramento do TH.4. A nota 09 reaproveita a detecção de staging em Windows com eventos Sysmon 11 e 4688, a nota 11 estende o volume para SaaS com download em massa de SharePoint e OneDrive, e o capítulo 13 recebe o material consolidado quando a classificação sobe para comprometimento de conta. As consultas que sobreviverem à prática devem ser transformadas em regras de analytics no capítulo 18, com limiares calibrados pelo ciclo de medição do controle MET.2, e os achados confirmados alimentam o perfil de ator no capítulo 01 quando há atribuição plausível, completando o ciclo hunting para inteligência descrito no controle INT.2.