Détecter l'activité ransomware dans le USN journal

Même quand le binaire a disparu, un ransomware laisse une empreinte très distinctive dans $UsnJrnl:$J. Un parcours des motifs à chercher, avec les combinaisons de Reason codes correspondantes.

Par 7 min de lecture

Le ransomware est l'un des signaux les plus propres que tu liras dans le USN journal. Quoi que l'opérateur ait fait en amont — vol d'identifiants, mouvement latéral, implants de persistance, suppression de shadow copy — la phase de chiffrement touche le système de fichiers avec un motif uniforme, à fort volume et monotone croissant qui se détache du bruit ambiant même des mois plus tard. Chaque opérateur auquel j'ai jamais répondu a essayé de camoufler une partie de la kill chain. Personne n'a encore trouvé comment camoufler le chiffrement de dizaines de milliers de fichiers en cinq minutes.

Ce billet est le playbook pour trouver ce motif. Le setup suppose que tu as déjà extrait $J et l'as parsé, et que la bitmask Reason n'est plus un mystère.

Le motif canonique de la phase de chiffrement

La plupart des ransomwares modernes (LockBit 3.0, BlackCat/ALPHV, Royal, Akira, les divers spin-offs post-Conti, Play, Black Basta) suivent la même recette en trois étapes par fichier :

  1. Ouvrir le fichier en lecture.
  2. Écraser le contenu sur place, ou écrire un nouveau fichier à côté et supprimer l'original.
  3. Renommer pour ajouter une extension marqueur (.locked, .lockbit, une chaîne aléatoire de 8 à 16 caractères, ou dans quelques familles aucune).

Dans le journal ça produit, par fichier :

DataOverwrite | Close
DataOverwrite | Close
...           ← un par bloc d'écriture
RenameOldName | Close   (ancien : document.docx)
RenameNewName | Close   (nouveau : document.docx.locked)

À travers des milliers de fichiers en quelques minutes. Les deux signaux diagnostiques sont :

Rafales de DataOverwrite dans une fenêtre courte. L'activité Windows normale produit rarement du DataOverwrite soutenu sur des fichiers qui ne sont pas des bases de données. La sauvegarde Office, la compaction du cache navigateur et les rebuilds d'IDE produisent des pics transitoires ; le ransomware produit un plancher monotone qui ne lâche pas jusqu'à ce que l'hôte n'ait plus de fichiers à chiffrer ou que l'opérateur arrête le binaire.

Événements massifs RenameNewName avec un suffixe nouveau-nom serré dans un cluster. Le ratio de RenameNewName sur les fichiers actifs totaux explose pendant le chiffrement. La signature du cluster — même chaîne fixe, ou même motif aléatoire .{8}, sur 80 %+ des renommages dans la fenêtre — c'est ce qui sépare le ransomware de n'importe quelle charge légitime.

Ça correspond principalement à T1486 Data Encrypted for Impact dans MITRE ATT&CK, avec des preuves journal adjacentes couvrant T1490 (Inhibit System Recovery) et T1485 (Data Destruction).

Une recette de détection qui tient en justice

En parcourant un journal parsé :

  1. Histogramme DataOverwrite par minute. Bucket par minute et cherche la falaise. Un hôte Windows de base tourne à un nombre à un chiffre de DataOverwrite par minute. Le chiffrement monte à 50-500× ça et y reste. Plot ou pivot dans un tableur — la forme te le dit instantanément.
  2. Clusterise les événements RenameNewName par nouvelle extension. Groupe sur l'extension du nouveau nom ou sur une regex sur le nouveau nom. Si 80 %+ des renommages dans une fenêtre partagent un suffixe identique ou matchent le même motif aléatoire de longueur fixe, c'est un encryptor.
  3. Apparie FileDelete | Close avec FileCreate de même-radical-extension-différente. Certaines familles (les variantes plus anciennes de LockBit parmi elles) écrivent le chiffré dans un nouveau fichier et suppriment l'original. Cherche un FileCreate dont le radical correspond à un fichier récemment supprimé, les deux dans la même seconde d'horloge. Même FileReferenceNumber sur le create qu'un renommage récent est concluant.
  4. Remonte les répertoires parents via $MFT. Résous la référence parent des fichiers affectés. Le ransomware balaie les profils utilisateurs, les lecteurs réseau mappés et Users\Public\. Une portée limitée à un seul sous-répertoire a beaucoup plus de chances d'être de l'autosave Office ou un outil de sauvegarde qui a déraillé.

Le parser sur cette page expose le filtrage par raison directement. Mets-le sur DataOverwrite pour l'étape 1 et RenameNewName pour l'étape 2. Les étapes 3 et 4 veulent un export CSV et un tableau croisé.

À quoi ça ressemble sur des vraies données

Un extrait expurgé d'un cas LockBit 3.0 sur lequel j'ai travaillé :

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
...

Chaque fichier dans le répertoire chiffré dans la même seconde d'horloge. La nouvelle extension est une chaîne aléatoire uniforme à neuf caractères — un signal de cluster fort pour l'étape 2 et le marqueur que LockBit 3.0 utilise pour lier le chiffré au keystream spécifique de l'opérateur.

Au-delà de la phase de chiffrement

Le journal attrape aussi des comportements préparatoires et de nettoyage autour de la rafale.

La suppression de shadow copy n'est pas visible directement dans $J — l'état VSS vit dans des namespaces gérés par $WSC — mais les invocations lancées par l'opérateur de vssadmin.exe, wmic.exe shadowcopy delete, wbadmin.exe delete catalog et bcdedit.exe /set touchent toutes des fichiers temp dans \Windows\Temp\ ou \Users\<u>\AppData\Local\Temp\. Ces enregistrements FileCreate apparaissent juste avant la rafale de chiffrement. Apparie avec Sysmon événement 1 pour l'arbre de processus réel.

Les scans de découverte sont largement invisibles au journal — les énumérations de répertoire en lecture seule ne produisent rien. Mais les drops d'outils si. adfind.exe, PsExec.exe, la sortie SharpHound de BloodHound et des outils similaires produisent des événements FileCreate dans leurs répertoires de travail, généralement dans \ProgramData\, \Users\Public\ ou \Users\<u>\AppData\Local\Temp\.

Livraison de note de rançon. Chaque famille moderne dépose une note dans chaque répertoire chiffré. README.txt, HOW_TO_DECRYPT.html, restore-my-files.txt, des noms spécifiques aux familles. Un FileCreate du même nom de fichier à travers de nombreux répertoires parents dans la même minute est la regex paresseuse qui attrape la grande majorité.

Staging pré-chiffrement. Certains opérateurs préparent l'exfiltration avant de chiffrer — voir le billet sur la détection d'exfil. Cherche des événements FileCreate d'archive avec les extensions .zip, .7z, .rar dans l'heure précédant la rafale de chiffrement.

Ce que le journal ne te dira pas

Le journal enregistre les changements, pas les acteurs. Pour rattacher un utilisateur ou un processus à la rafale de chiffrement :

  • Événement 4663 (object access) de Security.evtx — nécessite des SACL configurées à l'avance, ce qui n'est presque jamais le cas.
  • Événements 11 (file create) et 1 (process create) de Microsoft-Windows-Sysmon%4Operational.evtx — l'étalon-or si Sysmon était déployé.
  • Prefetch et AmCache pour le binaire ransomware lui-même, même après que l'opérateur l'ait supprimé.

Pour le playbook de réponse plus large, le guide #StopRansomware de CISA est la référence faisant autorité.

Distinguer le ransomware des rafales légitimes

Quelques charges de travail réelles peuvent superficiellement ressembler à un ransomware avec le mauvais filtre :

La conversion initiale BitLocker produit du DataOverwrite continu mais aucun RenameNewName. Le ransomware renomme toujours. Si ton comptage de RenameNewName est plat, ce n'est pas du ransomware.

Le logiciel de sauvegarde (Veeam, Macrium, Acronis) produit du DataOverwrite sur le volume de destination, pas sur les Documents et Desktop de l'utilisateur. Croise l'utilisateur et le chemin.

L'autosave Office et les rebuilds Visual Studio pique pendant quelques secondes et s'arrête. Le ransomware est monotone. L'histogramme par minute le rend évident.

La restauration d'image disque écrit de grandes quantités de données mais vers un chemin de device \\?\Volume{...}, pas un profil utilisateur. La résolution de répertoire parent l'attrape.

Si ta logique de détection produit zéro alerte sur une base de référence saine, elle est sous-spécifiée. Le signal que tu veux est la combinaison de taux DataOverwrite, taux RenameNewName et clustering de même extension — pas l'un de ces trois seul.

Lectures complémentaires

  • CISA, guide #StopRansomware — le playbook de réponse de bout en bout faisant autorité.
  • Le walkthrough LockBit 3.0 de The DFIR Report et autres writeups d'intrusion long format — la meilleure source publique pour la cadence horloge d'un engagement ransomware réel.
  • Microsoft Defender Research, Ransomware-as-a-service — utile comme contexte côté opérateur pour ce que ta preuve journal représente réellement.