Como é que o ransomware se apresenta no journal USN?

Uma rajada sustentada de registos DataOverwrite | Close em milhares de ficheiros numa janela curta, seguida de eventos RenameNewName | Close em massa cujos novos nomes partilham um sufixo idêntico ou uma extensão aleatória. Algumas famílias também escrevem o ciphertext num ficheiro novo e eliminam o original — um FileCreate de um ficheiro com a mesma raiz mas extensão diferente, emparelhado com um FileDelete do original no mesmo segundo.

Que técnica do MITRE ATT&CK mapeia a rajada de cifragem?

Primariamente T1486 Data Encrypted for Impact para a própria rajada de DataOverwrite/RenameNewName, com técnicas adjacentes a aparecer em evidências de journal próximas: T1490 Inhibit System Recovery (eliminação de Volume Shadow Copies), T1485 Data Destruction, e T1083 File and Directory Discovery para a enumeração pré-cifragem.

O journal USN diz-me que processo executou o ransomware?

Não. O journal regista o ciclo de vida dos ficheiros, não a identidade do actor. Combine o timestamp da rajada de cifragem com o evento 4663 do Security.evtx (acesso a objecto — exige SACLs configuradas previamente) ou o evento 11 do Microsoft-Windows-Sysmon/Operational (criação de ficheiro) para atribuir um processo e um utilizador à rajada.

Como distingo ransomware da conversão do BitLocker ou do software de backup?

Três diferenciadores. A conversão do BitLocker produz DataOverwrite contínuo mas nenhum RenameNewName — o ransomware renomeia sempre. O software de backup (Veeam, Macrium) ataca um volume de destino, não as directorias do perfil do utilizador da origem. As rajadas de autosave do Office são transitórias; as taxas de DataOverwrite do ransomware permanecem monotónicas até o host ficar sem ficheiros.

O que é a eliminação de shadow copy e aparece em $UsnJrnl?

A eliminação de shadow copy é o passo do ransomware que remove as Volume Shadow Copies para impedir um rollback. O estado real do VSS vive em namespaces geridos por $WSC e não aparece directamente em $UsnJrnl. O que se vê no journal momentos antes da rajada de cifragem é FileCreate de ficheiros temporários lançados por vssadmin.exe e, em hosts instrumentados, os correspondentes registos de criação de processo do evento 1 do Sysmon.

Detectar actividade de ransomware no journal USN

O ransomware é um dos sinais mais limpos que alguma vez vai ler no journal USN. O que quer que o operador tenha feito mais cedo na cadeia — roubo de credenciais, movimentação lateral, implants de persistência, eliminação de shadow copy — a fase de cifragem toca no filesystem com um padrão uniforme, de elevado volume e monotonicamente crescente, que se destaca do ruído circundante mesmo meses depois. Todos os operadores a que já respondi tentaram camuflar uma parte da kill chain. Ninguém ainda conseguiu camuflar cifrar dezenas de milhares de ficheiros em cinco minutos.

Este artigo é o playbook para encontrar esse padrão. O cenário assume que já extraiu o $J e o parseou, e que a bitmask de razão já não é um mistério.

O padrão canónico da fase de cifragem

A maioria do ransomware moderno (LockBit 3.0, BlackCat/ALPHV, Royal, Akira, os vários derivados pós-Conti, Play, Black Basta) segue a mesma receita de três passos por ficheiro:

Abrir o ficheiro para leitura.
Sobrescrever o conteúdo no mesmo sítio, ou escrever um ficheiro novo ao lado e eliminar o original.
Renomear para acrescentar uma extensão marcadora (.locked, .lockbit, uma string aleatória de 8 a 16 caracteres ou, em algumas famílias, nenhuma).

No journal isso produz, por ficheiro:

DataOverwrite | Close
DataOverwrite | Close
...           ← um por bloco de escrita
RenameOldName | Close   (antigo: document.docx)
RenameNewName | Close   (novo: document.docx.locked)

Ao longo de milhares de ficheiros em alguns minutos. Os dois sinais diagnósticos são:

Rajadas de DataOverwrite numa janela curta. A actividade normal de Windows raramente produz DataOverwrite sustentado em ficheiros não-base-de-dados. Gravar no Office, compactação de cache de browser e recompilações de IDE produzem picos transitórios; o ransomware produz um piso monotónico que não cede até o host ficar sem ficheiros para cifrar ou o operador parar o binário.

Eventos RenameNewName em massa com um sufixo de novo nome agrupado de forma compacta. A razão de RenameNewName em relação ao total de ficheiros activos explode durante a cifragem. A assinatura do cluster — mesma string fixa, ou mesmo padrão aleatório .{8}, em 80%+ das renomeações da janela — é o que separa o ransomware de qualquer carga de trabalho legítima.

Isto corresponde primariamente a T1486 Data Encrypted for Impact no MITRE ATT&CK, com evidência adjacente no journal a cobrir T1490 (Inhibit System Recovery) e T1485 (Data Destruction).

Uma receita de detecção que aguenta em tribunal

Trabalhando num journal parseado:

Histograma de DataOverwrite por minuto. Agrupe por minuto e procure o degrau. Um host Windows na baseline corre com DataOverwrite por minuto na ordem das unidades. A cifragem sobe para 50–500× isso e fica lá. Trace o gráfico ou pivote numa folha de cálculo — a forma diz-lhe imediatamente.
Agrupe RenameNewName pela nova extensão. Agrupe pela extensão do novo nome ou por uma regex sobre o novo nome. Se 80%+ das renomeações de uma janela partilham um sufixo idêntico ou casam o mesmo padrão aleatório de comprimento fixo, é um encriptador.
Emparelhe FileDelete | Close com FileCreate de mesma-raiz-extensão-diferente. Algumas famílias (variantes antigas do LockBit, entre elas) escrevem o ciphertext num ficheiro novo e eliminam o original. Procure um FileCreate cuja raiz coincide com um ficheiro recentemente eliminado, ambos no mesmo segundo de relógio. O mesmo FileReferenceNumber no create e numa renomeação recente é conclusivo.
Percorra os directórios pai via $MFT. Resolva a referência pai para os ficheiros afectados. O ransomware varre perfis de utilizador, drives de rede mapeadas e Users\Public\. Um âmbito limitado a um único subdirectório é muito mais provavelmente autosave do Office ou uma ferramenta de backup mal configurada.

O parser desta página expõe directamente a filtragem por razão. Configure-o para DataOverwrite no passo 1 e RenameNewName no passo 2. Os passos 3 e 4 pedem uma exportação CSV e uma tabela dinâmica.

Como se parece em dados reais

Um excerto censurado de um caso LockBit 3.0 em que trabalhei:

2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  RenameOldName Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  RenameNewName Close   C:\Users\ana\Desktop\notes.docx.HLJkNskOq
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\quarterly.xlsx
...

Cada ficheiro do directório foi cifrado dentro do mesmo segundo de relógio. A nova extensão é uma string aleatória uniforme de nove caracteres — um sinal de cluster forte para o passo 2 e o marcador que o LockBit 3.0 usa para ligar o ciphertext ao keystream específico do operador.

Para além da fase de cifragem

O journal também apanha comportamentos preparatórios e de limpeza em redor da rajada.

Eliminação de shadow copy não é visível directamente em $J — o estado do VSS vive em namespaces geridos por $WSC — mas invocações lançadas pelo operador de vssadmin.exe, wmic.exe shadowcopy delete, wbadmin.exe delete catalog e bcdedit.exe /set tocam todas em ficheiros temporários em \Windows\Temp\ ou \Users\<u>\AppData\Local\Temp\. Esses registos FileCreate aparecem momentos antes da rajada de cifragem. Combine com o evento 1 do Sysmon para a árvore de processos real.

Scans de discovery são em grande parte invisíveis para o journal — enumerações apenas-leitura de directórios não produzem nada. Mas drops de ferramentas sim. adfind.exe, PsExec.exe, a saída do SharpHound do BloodHound e ferramentas semelhantes produzem eventos FileCreate nas suas directorias de trabalho, geralmente em \ProgramData\, \Users\Public\ ou \Users\<u>\AppData\Local\Temp\.

Entrega da nota de resgate. Todas as famílias modernas deixam uma nota em cada directório cifrado. README.txt, HOW_TO_DECRYPT.html, restore-my-files.txt, nomes específicos da família. Um FileCreate do mesmo nome de ficheiro em muitos directórios pai no mesmo minuto é a regex preguiçosa que apanha a grande maioria deles.

Staging pré-cifragem. Alguns operadores fazem staging para exfiltração antes de cifrar — ver o artigo sobre detecção de exfiltração. Procure eventos FileCreate de arquivos com extensões .zip, .7z, .rar na hora anterior à rajada de cifragem.

O que o journal não lhe vai dizer

O journal regista mudanças, não actores. Para atribuir um utilizador ou processo à rajada de cifragem:

Evento 4663 do Security.evtx (acesso a objecto) — exige SACLs configuradas previamente, o que quase nunca acontece.
Evento 11 (criação de ficheiro) e evento 1 (criação de processo) do Microsoft-Windows-Sysmon%4Operational.evtx — o padrão de ouro se o Sysmon estiver instalado.
Prefetch e AmCache para o próprio binário do ransomware, mesmo depois de o operador o ter eliminado.

Para o playbook de resposta mais amplo, o guia #StopRansomware da CISA é a referência autoritativa.

Distinguir ransomware de rajadas legítimas

Algumas cargas reais de trabalho podem superficialmente parecer-se com ransomware num filtro errado:

A conversão inicial do BitLocker produz DataOverwrite contínuo mas nenhum RenameNewName. O ransomware renomeia sempre. Se a contagem de RenameNewName for plana, não é ransomware.

Software de backup (Veeam, Macrium, Acronis) produz DataOverwrite no volume de destino, não em Documents e Desktop do utilizador. Cruze utilizador e caminho.

Autosave do Office e recompilações do Visual Studio picam durante alguns segundos e param. O ransomware é monotónico. O histograma por minuto torna isso óbvio.

Restauro de imagem de disco escreve grandes quantidades de dados, mas para um caminho de dispositivo \\?\Volume{...}, não para um perfil de utilizador. A resolução do directório pai apanha isso.

Se a sua lógica de detecção produz zero alertas numa baseline saudável, está sub-especificada. O sinal que pretende é a combinação da taxa de DataOverwrite, da taxa de RenameNewName e do clustering de extensão idêntica — não qualquer um deles isoladamente.

Leituras adicionais

CISA, guia #StopRansomware — o playbook de resposta ponto a ponto autoritativo.
O walkthrough do LockBit 3.0 do The DFIR Report e write-ups longos semelhantes de intrusões — a melhor fonte pública para a cadência real, ao relógio, de um caso de ransomware.
Microsoft Defender Research, Ransomware-as-a-service — útil como contexto do lado do operador para aquilo que as evidências do seu journal efectivamente representam.