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

A seguir ao ransomware, a segunda pergunta de DFIR mais frequente é alguma variante de «saiu alguma coisa daqui?». O journal USN é um dos sítios mais baratos por onde começar a responder. Cada cópia para USB, cada upload por sincronização na cloud e cada operação de despejar-tudo-numa-pasta-temporária-e-comprimir deixa uma forma reconhecível em $J — reconhecível ao ponto de, com dois filtros e um pivot por caminho pai, conseguir triar uma janela candidata a exfiltração em menos de vinte minutos.

Este artigo é o playbook para encontrar esses padrões, organizado por canal de exfiltração.

As drives USB deixam o rasto mais limpo

Quando um utilizador liga um volume amovível, o Windows atribui-lhe uma letra de drive e, se o volume for NTFS, o dispositivo passa a ter o seu próprio $UsnJrnl. Ficheiros copiados para o USB aterram no journal do destino como FileCreate | Close mais um caudal de registos DataExtend | Close. Ficheiros copiados do disco de origem deixam um rasto mais suave do lado da fonte: eventos de abertura e fecho que muitas vezes produzem BasicInfoChange | Close por causa de scans de AV e cache do sistema de ficheiros após a leitura.

O que tipicamente se tem num caso real:

• O journal do disco de origem. Mostra o que foi aberto, eventuais ficheiros temporários ou de arquivo criados e a varredura final de eliminação se o utilizador arrumou atrás de si.
• Os hives do registo. SYSTEM\MountedDevices, SYSTEM\CurrentControlSet\Enum\USBSTOR, NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 e setupapi.dev.log em conjunto identificam que dispositivo físico foi ligado e quando. Faça parse com o parser de registo.
• O journal do volume de destino, se tiver a imagem do USB. É aí que vivem as escritas reais dos ficheiros.

O sinal decisivo do lado da fonte é o padrão arquivo-antes-da-cópia, porque a maioria dos utilizadores com algo a esconder pega no 7-Zip ou na compressão incorporada do Explorer antes de levar a drive: um FileCreate de um .7z, .zip, .rar ou ficheiro com nome aleatório num caminho temporário, seguido de registos DataExtend | Close sustentados até o ficheiro atingir o tamanho final. O caminho costuma ser \Users\<u>\AppData\Local\Temp\, \Users\<u>\Desktop\ ou a raiz do perfil do utilizador.

Para o lado da identificação do USB, cruze os timestamps no journal com os eventos de ligação/desligação em Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx. O parser EVTX torna isso uma tarefa de poucos cliques. Combine com ficheiros LNK em \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ e jump lists para evidência explícita de aberturas pelo utilizador a partir do USB.

O padrão clássico de staging-depois-arquivo

Mapeia para T1074 Data Staged no MITRE ATT&CK e em disco aparece assim:

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, ficheiro cresce muito
FileDelete | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\*  (limpeza)

Três sinais em sequência:

1. Uma rajada de FileCreate num único directório de staging.
2. Um FileCreate subsequente mais DataExtend contínuo sobre um único arquivo, cujo tamanho final se aproxima da soma dos ficheiros em staging.
3. Uma varredura de delete sobre o directório de staging pouco depois do arquivo ser fechado.

Cada sinal isoladamente é ruidoso. Combinados, são diagnósticos. Filtre por FileCreate em \AppData\Local\Temp\, \Users\Public\, \Downloads\ e outras localizações graváveis na árvore do utilizador, depois agrupe por directório pai e procure mais de 50 criações em 60 segundos. Essa cadência apanha staging de roubo interno e a maioria das cargas de infostealers. Retire do filtro caminhos de build conhecidos (node_modules\, target\, Debug\, Release\, obj\, .next\, dist\); produzem rajadas idênticas e, caso contrário, dominam os resultados.

Staging via sincronização na cloud

OneDrive, Dropbox, Google Drive e Box mantêm todos uma pasta local de sincronização e empurram tudo o que lá está assim que o agente o detecta. O journal expõe dois padrões diagnósticos:

RenameNewName em massa para a pasta de sincronização. O novo pai é \Users\<u>\OneDrive\, \Users\<u>\Dropbox\, \Users\<u>\Google Drive\ ou \Users\<u>\Box\; o pai antigo é Desktop\, Documents\ ou Downloads\. A metade do rename preserva a referência ao pai original do ficheiro, o que permite provar a proveniência mesmo depois de o ficheiro ter desaparecido.

DataExtend | Close em ficheiros dentro da pasta de sincronização sem um FileCreate correspondente de aplicação do utilizador. São o próprio agente a escrever — downloads do lado da cloud para a cópia local. As criações são o que pretende para a direcção de upload. Agentes em background como OneDrive.exe e Dropbox.exe também escrevem ficheiros de log em subdirectorias AppData\Local\, o que dá outra forma de delimitar a actividade se a evidência de renomeação for escassa.

Menos comum mas vale a pena saber: alguns operadores escrevem em script um Copy-Item para uma junction ou symlink que aponta para a pasta da cloud, o que produz registos ReparsePointChange para além do par de renomeação.

BITS, ferramentas nativas de upload e exfiltração living-off-the-land

Padrão que tenho visto mais vezes em casos recentes de ransomware: o operador usa bitsadmin.exe ou Start-BitsTransfer do PowerShell para empurrar ficheiros para fora, por vezes para armazenamento na cloud controlado pelo atacante com certificados válidos. O journal mostra:

• FileCreate de ficheiros de estado de jobs BITS em \ProgramData\Microsoft\Network\Downloader\ (correspondendo a qmgr.db, qmgr0.dat, qmgr1.dat).
• Para uploads, os ficheiros de origem postos em staging em \Users\<u>\AppData\Local\Microsoft\BITS\ imediatamente antes da transferência.

Combine com IDs de evento 59 (job criado), 60 (job transferido) e 61 (job concluído) em Microsoft-Windows-Bits-Client%4Operational.evtx — a ponte EVTX para exfiltração via BITS é uma das correlações mais limpas disponíveis.

História semelhante para rclone.exe e MEGAsync.exe. Produzem assinaturas previsíveis de criação de ficheiros nas suas directorias de aplicação e ficheiros de log; verifique \Users\<u>\AppData\Roaming\rclone\ para a configuração que enumera o destino.

Heurísticas que justificam o seu peso

Após casos suficientes, as heurísticas que consistentemente sinalizam exfiltração real:

Rajada de criações. Mais de N eventos FileCreate num único directório em T segundos. Calibre face à baseline; N=50, T=60 é o ponto de partida para hosts desktop.

Arquivo após a rajada. Um único FileCreate de ficheiro com extensão .zip, .7z, .rar, .tar.gz, .tar.zst ou .iso dentro de minutos após uma rajada de criações, com DataExtend contínuos acumulando vários MB. O tamanho do arquivo corresponde grosso modo ao tamanho cumulativo dos ficheiros em staging.

Renomeação em massa que atravessa fronteiras de directórios. Registos RenameNewName cujo caminho do novo pai é estruturalmente diferente do antigo — Documents\ para OneDrive\, Desktop\ para Users\Public\, Downloads\ para \AppData\Local\Microsoft\BITS\. Fácil de expressar como regex sobre os caminhos completos resolvidos pelo MFT.

Rajadas fora de horas. Qualquer das acima fora do horário normal de trabalho do utilizador. Cruze com os logons 4624 em Security.evtx para as fronteiras reais da sessão.

Varredura de delete após o arquivo. Um cluster de FileDelete no directório de staging após o arquivo ser fechado. É o utilizador a tentar arrumar. A forma do cluster — muitos ficheiros eliminados em segundos, todos partilhando um pai — é invulgar fora dos fluxos de desenvolvimento/build.

O parser desta página expõe filtros por janela temporal e por razão que tornam a detecção de rajadas e o clustering de renomeações um clique cada. Para análise fora de horas, exporte para CSV e pivote por hora do dia.

O que não vai ver em $UsnJrnl

Algumas técnicas reais de exfiltração não produzem qualquer sinal USN útil:

• Upload directo a partir de memória via POST do browser, Invoke-WebRequest -InFile a partir de uma variável, ou curl em pipe com Get-Content. Nada aterra em disco.
• Leitura de uma partilha de rede que o lado da fonte não possui. O journal no seu host não tem nada porque o ficheiro não vivia lá.
• Captura de ecrã como exfiltração. Apenas os ficheiros de screenshot aterram em disco; os dados reais saem pela imagem renderizada.
• Impressão. Deixa apenas actividade em \Windows\System32\spool\PRINTERS\, que é o seu próprio artefacto forense.
• Tunneling por DNS ou ICMP. Nada toca em disco; recorra a capturas de rede e evento 3 do Sysmon.

Para estes casos, recorra a EVTX, conexões de rede do Sysmon (evento 3), histórico de browser, SRUM para bytes de rede por processo, dumps de RAM, ou artefactos da fila PRINTERS. A página da táctica Exfiltration do MITRE ATT&CK lista todas as técnicas com notas sobre onde efectivamente deixam resíduo.

Um exemplo trabalhado

O tipo de CSV que se poderia exportar de um caso real para demonstrar exfiltração:

Essa timeline é prova clara. Sem o journal, reconstruí-la-ia a partir do registo, do Prefetch, de shadow copies e dos próprios logs do OneDrive — cinco vezes o trabalho, metade da confiança.

Leituras adicionais

• MITRE ATT&CK — a táctica Exfiltration e T1074 Data Staged para a taxonomia completa.
• CISA, recursos sobre ameaça interna — as suposições de baseline e os limiares de detecção do seu playbook estão próximos do que funciona num ambiente corporativo real.
• The DFIR Report — múltiplas intrusões em formato longo documentam o padrão exfiltrar-depois-cifrar passo a passo, com evidência USN na timeline. É o mais próximo de um corpus público de referência para a aparência destes padrões na prática.