Detectar exfiltração de dados e cópias para USB com o journal USN

Depois do ransomware, a segunda pergunta de DFIR mais comum é «saiu alguma coisa daqui?». O journal USN é um dos lugares mais baratos para responder. Ele registra cada criação, cada renomeação, cada extensão de dados — o que significa que a exfil via USB, o staging para sync na nuvem e o clássico «jogar tudo em uma pasta temp antes de zipar» aparecem todos muito distintos numa timeline.

Este artigo é o playbook para encontrar esses padrões.

USBs são modo fácil

Quando um usuário conecta um volume removível, o Windows atribui uma nova letra de unidade e o filesystem do dispositivo recebe seu próprio $UsnJrnl se for NTFS. Mas quando arquivos são copiados do sistema investigado para o USB, o journal do volume origem ainda registra o lado de leitura como uma série de acessos — e, mais importante, o journal de destino (se você tiver a imagem da USB) mostra as gravações.

O que você tipicamente tem:

• O journal do disco fonte — mostra o que foi aberto/fechado e os arquivos temporários.
• As hives do registro — SYSTEM\MountedDevices, NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 e os eventos Setup de hardware para identificar qual USB foi conectado.
• O journal do volume de destino, se o dispositivo era NTFS e você consegue imageá-lo — é aí que você vê os arquivos reais.

Primeiro sinal no lado fonte: um cluster de aberturas de arquivo numa janela apertada apontando para a árvore documents/desktop/downloads do usuário. Aberturas nem sempre produzem registros USN, mas os caches do filesystem e os escaneamentos AV que as seguem frequentemente produzem (tocar atributos dispara BasicInfoChange | Close).

Um sinal mais decisivo chega se o atacante zipa primeiro: um FileCreate de um .7z, .zip, .rar ou arquivo com nome aleatório num caminho temp, seguido de registros DataExtend | Close sustentados até o arquivo atingir o tamanho final.

O padrão clássico staging-depois-cópia

Um padrão comum, mapeado para T1074 Data Staged no MITRE ATT&CK:

FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
DataExtend | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\customers.csv
DataExtend | Close   ...
…
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3.zip
DataExtend | Close   ...           ← muitos, o arquivo cresce
FileDelete | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\*  (limpeza)

Três sinais juntos:

• Uma rajada de FileCreate em um único diretório de staging.
• DataExtend subsequentes em um único arquivo cuja dimensão final aproxima a soma dos arquivos staged.
• Uma varredura de exclusão do diretório de staging logo após a criação do arquivo.

Filtrar FileCreate em \AppData\Local\Temp\, \Public\, \Downloads\ ou outros locais graváveis da árvore do usuário, e buscar clusters no tempo de >50 arquivos em <60 segundos. É assim que parecem operações de furto interno ou infostealer no disco.

Staging por sync na nuvem

OneDrive, Dropbox, Google Drive — todos mantêm uma pasta local de sync. Qualquer coisa solta nela é enviada assim que o agente percebe. Dois sinais:

• RenameNewName em massa para a pasta de sync a partir de Desktop\, Documents\ ou Downloads\. A metade rename te diz o pai anterior; o novo pai é a pasta de sync.
• DataExtend | Close em arquivos dentro da pasta de sync sem um FileCreate correspondente de nenhum app do usuário. O próprio agente de sync grava esses — ou seja, são downloads — mas os creates são o que você quer para uploads.

Para um filtro por nome, os diretórios canônicos de sync no Windows são \Users\<u>\OneDrive\, \Users\<u>\Dropbox\ e \Users\<u>\Google Drive\. As ferramentas listadas nos recursos insider threat TLP-WHITE da CISA têm suposições de baseline parecidas.

Heurísticas que realmente funcionam

Após várias missões, as heurísticas que tendem a sinalizar exfil real são:

1. Rajada de creates: mais de N FileCreate em um único diretório em T segundos. Calibrável à baseline. Começamos com N=50, T=60.
2. Arquivo após rajada: um único FileCreate de um arquivo com extensão conhecida de archive (.zip, .7z, .rar, .tar.gz) em minutos após uma rajada, com DataExtend subsequentes acumulando vários MB.
3. Renomeio em massa cruzando fronteiras: registros RenameNewName cujo novo caminho pai é estruturalmente diferente do antigo (Documents → OneDrive, Desktop → Public etc.). Fácil de expressar como regex sobre os caminhos completos resolvidos.
4. Rajadas fora do horário: qualquer uma das anteriores fora do horário comercial daquele usuário. Acoplar com os eventos de logon Security.evtx para confirmação.

O parser deste site expõe filtros por janela temporal e por razão que tornam 1–3 um clique cada. Para (4), exportar para CSV e pivotar por hora do dia.

O que você não verá

Algumas técnicas de exfil reais produzem nenhum sinal USN útil:

• Upload direto a partir da memória via navegador ou PowerShell — os dados nunca tocam o disco, o journal não tem nada.
• Leitura de um compartilhamento de rede — a fonte é o filesystem onde o compartilhamento mora, frequentemente não o seu.
• Captura de tela como exfil — produz só a criação de um ou dois arquivos de imagem.
• Impressão — deixa apenas atividade em \Windows\System32\spool\PRINTERS\, que é um artefato forense próprio, não realmente uma questão USN.

Para uma visão mais ampla de modelo de ameaça, a página Exfiltration do MITRE ATT&CK lista cada técnica e onde deixa resíduos. USN cobre diretamente talvez um terço; o resto precisa de logs de eventos, capturas de rede ou histórico de navegador.

Exemplo prático

O tipo de CSV que se exportaria de uma missão real para demonstrar exfil:

Essa timeline é evidência esmagadora. Sem o journal, teria que ser reconstruída a partir do registro, Prefetch e shadow copies — cinco vezes mais trabalho, metade da confiança.