Le ransomware fait à peu près la même chose sur chaque hôte, à chaque fois : énumérer les fichiers, lire chacun, écrire une copie chiffrée, supprimer l'original. Chaque étape atterrit dans $MFT. Si vous connaissez l'aspect de la forme, vous pouvez confirmer qu'un incident est une passe de ransomware en quelques minutes après avoir obtenu la MFT, sans jamais trouver le binaire ni lire la note de rançon.
Voici le motif, les variantes que j'ai vues, et comment je sépare le ransomware d'autres formes d'activité massive de fichiers qui se ressemblent superficiellement.
Les trois signaux
Changements d'extension en masse. Un nouveau fichier apparaît avec le même répertoire parent et nom de base qu'un fichier existant, mais avec une extension différente. report.docx devient report.docx.locked, report.encrypted, report.crypted_{guid} ou report.docx.[victim_id].lockbit. Compter combien de telles paires apparaissent dans une fenêtre courte est l'un des indicateurs les plus propres de ransomware dans $MFT. Des centaines en une minute, sur le profil d'un seul utilisateur ou un partage, est la signature.
Une rafale d'horodatages SI created de $STANDARD_INFORMATION regroupés en quelques secondes. L'activité utilisateur normale crée des fichiers par poussées d'un ou deux. Le ransomware en crée par milliers. Tracez les horodatages SI created en histogramme sur la fenêtre suspectée et la passe de chiffrement apparaît comme un pic vertical qui écrase la baseline. La largeur du pic vous dit à quelle vitesse le ransomware a tourné (les variantes modernes multi-thread terminent un profil utilisateur en moins d'une minute ; les anciennes mono-thread prennent plus de temps et le pic s'étale).
Originaux supprimés correspondant aux duplicatas chiffrés. Pour chaque report.docx.locked, il y a typiquement un report.docx correspondant dont le drapeau IN_USE est désormais effacé. L'enregistrement supprimé reste dans $MFT jusqu'à ce que le slot soit réutilisé. Vous pouvez récupérer le nom, les tailles et les horodatages de l'original directement depuis le slot supprimé. Couplez ceci avec les raisons $UsnJrnl FILE_DELETE dans la même fenêtre et l'ordre des opérations devient sans ambiguïté.
Variantes qu'il faut connaître
Toutes les familles ne suivent pas le même motif. Les variantes que je vois :
- Chiffrement sur place. Certaines familles (anciennes variantes Sodinokibi, certaines builds Conti) ouvrent le fichier original, réécrivent les octets chiffrés dans le même fichier et renomment. Aucun fichier « copie chiffrée » séparé n'existe ; le motif de l'original supprimé disparaît.
DATA_OVERWRITEde$UsnJrnlpour des milliers de fichiers en une minute reste bruyant, et le renommage laisse une paireRENAME_OLD_NAME/RENAME_NEW_NAME. - Chiffrement intermittent. BlackCat et plusieurs familles récentes chiffrent seulement des morceaux du fichier (par exemple un bloc de 100 Ko sur deux) pour accélérer la passe. La taille du fichier change à peine, l'heure de modification se met à jour, mais les clusters
$DATAsont en grande partie intacts. Cela paraît plus léger dans$MFT, mais le journal USN montre toujours les écritures. - Renommage seul. Une poignée de wipers « faux ransomware » renomment les fichiers sans les chiffrer. Le motif MFT est identique à celui d'une vraie passe de ransomware ; seule l'analyse du contenu sépare les deux.
- Impact sur lecteurs réseau. Beaucoup de familles énumèrent les lecteurs mappés et chiffrent à travers le réseau. La MFT locale montre moins de changements qu'attendus pour un vrai incident ; la MFT du serveur de fichiers porte l'essentiel.
Notes de rançon
La plupart des familles déposent une note de rançon dans chaque répertoire affecté, avec un nom comme HOW_TO_DECRYPT.txt, README_FOR_DECRYPT.html, restore-files.txt ou une variante propre à la marque. Les notes ont un contenu identique, une taille identique et des heures de création regroupées dans la même fenêtre que le chiffrement. Parcourir la MFT à la recherche de nombreux fichiers texte ou HTML de taille identique répartis sur de nombreux répertoires parents les trouve souvent avant n'importe quel motif de nom.
Les notes sont aussi utiles forensiquement comme baseline. Leur heure de création est essentiellement l'estampille « le plus tôt où le ransomware a été actif dans ce répertoire ». Si un répertoire a une note datée 02:14 mais des fichiers chiffrés datés 02:09 dans le même répertoire, le ransomware a énuméré et chiffré avant de déposer la note. Cela vous dit un peu sur le flux de la famille.
Ce que $MFT ne vous dit pas
La MFT confirme le quoi et le quand. Elle ne vous dit pas quel processus a fait l'écriture, où l'opérateur est entré ni comment le ransomware est arrivé sur l'hôte. Pour cela :
- Prefetch, Amcache et Shimcache pour des preuves de quel exécutable a tourné dans la fenêtre.
- Sysmon Event ID 1 pour la création de processus avec ligne de commande, parent et hashes.
- Security Event 4688 pour la création de processus si l'audit de ligne de commande était activé.
- Journal USN
$Jpour l'ordre précis des opérations d'ouverture/lecture/écriture/renommage/suppression de fichiers. - Dump RAM si la machine est encore vivante et que le processus de chiffrement est encore résident. Parfois vous obtenez la clé de chiffrement en mémoire.
- Historique du navigateur et artefacts d'e-mail pour le vecteur d'accès initial.
La MFT seule répond aux questions opérationnelles urgentes : quand la passe a commencé, à quel point elle est répandue, et quels fichiers ont été touchés. C'est suffisant pour prendre la décision de récupération. L'attribution est un exercice séparé qui utilise la MFT comme l'une de ses entrées.
La suppression VSS comme indice
La plupart des familles de ransomware essaient de supprimer les Volume Shadow Copies avant de commencer à chiffrer, parce que les snapshots VSS permettraient à la victime de restaurer sans payer. La commande habituelle est vssadmin delete shadows /all /quiet. Cela laisse :
- Une entrée dans le journal d'événements système Windows (
Event ID 8224pour les messages de service VSS). - Un Sysmon Event ID 1 pour l'invocation de
vssadmin.exesi Sysmon est déployé. - L'état VSS frais-mais-vide sur l'hôte.
vssadmin list shadowsne renvoie rien ou seulement des snapshots postérieurs à l'incident.
Si vous voyez un hôte sans snapshots VSS et des numéros de séquence de l'enregistrement MFT \$Extend\$UsnJrnl indiquant une recréation récente, vous avez une préparation de ransomware même si la passe de chiffrement n'a pas commencé visiblement. Voir VSS et $MFT pour ce que vous pourriez encore récupérer.
La séquence de triage que je suis
- Tirez
$MFTet$UsnJrnl:$Jde l'hôte suspecté (ou du snapshot, si VSS en a encore un d'avant). - Parsez la MFT avec MFTECmd ou
mft_dump. Triez SI created descendant. Regardez les 1 000 premières entrées. - Si les premières entrées se regroupent dans une fenêtre de minutes et que beaucoup ont des extensions inhabituelles, vous avez une empreinte de ransomware.
- Tirez les enregistrements supprimés correspondants. Leurs attributs
$FILE_NAMEvous donnent les noms de fichiers originaux. Vous savez maintenant ce qui a été chiffré. - Recoupez avec le journal USN.
FILE_CREATEpour le fichier chiffré plusFILE_DELETEpour l'original au même instant confirme le motif. - Identifiez la note de rançon : un petit fichier au nom inhabituel (HOW_TO_DECRYPT, RECOVERY, README_RESTORE) apparaissant dans beaucoup de répertoires en même temps. Son contenu nomme la famille.
- Pivotez du nom de famille vers des IOC connus : hashes de fichier, domaines C2, persistance registre et artefacts de kill chain connus dans vos autres journaux.
Cette séquence prend généralement moins de trente minutes sur un seul hôte et vous donne assez pour décider du confinement et commencer la planification de la récupération.
Lectures complémentaires
- Les études de cas ransomware de The DFIR Report. Chaque writeup couple les preuves MFT et journal avec le reste de la kill chain.
- Analyses techniques LockBit, BlackCat, Cl0p sur The Record et Microsoft Security Blog. Les empreintes MFT spécifiques aux familles diffèrent dans le détail.
- MITRE ATT&CK, T1486 Data Encrypted for Impact. Le catalogue de techniques pour ce que fait le ransomware et les artefacts que chaque comportement laisse.