Ransomware Forensics : Identifier la Souche : Guide Complet

Face à un incident ransomware, l'une des premières questions opérationnelles est : quelle famille ? L'identification rapide de la souche conditionne tout ce qui suit — l'évaluation de la disponibilité d'un décrypteur gratuit (No More Ransom), l'estimation du mode opératoire probable de l'attaquant, les IOC à chercher sur le reste du réseau, et les règles YARA à activer sur votre EDR. Cette identification repose sur une méthodologie forensique en cinq étapes que nous détaillons ici : analyse de la note de rançon, des extensions de fichiers chiffrés, du comportement du binaire, de son code désassemblé et des services de reconnaissance en ligne. Chaque étape peut être réalisée par un analyste DFIR de niveau intermédiaire avec des outils gratuits.

Étape 1 : Analyse de la note de rançon et des extensions de fichiers

La note de rançon est souvent l'indicateur le plus rapide d'identification. Chaque famille ransomware a un format de note caractéristique, un nom de fichier spécifique et un style de communication distinctif.

Noms de fichiers de notes de rançon courants :

• HOW TO DECRYPT.txt / HOW_TO_DECRYPT.txt → LockBit, nombreuses variantes
• RESTORE_YOUR_FILES.txt → RansomHub (variantes récentes)
• !!!HOW_TO_DECRYPT!!!.txt → Akira
• README_TO_DECRYPT.txt → Cl0p
• decrypt_instructions.html / .onion présent → Play (PlayCrypt)
• #Recover-Files.txt → ALPHV/BlackCat
• README.txt générique → variantes nombreuses, check extension

Extensions de fichiers chiffrés :

• .locked → familles génériques, anciennes variantes Locky
• .akira → Akira
• .play → Play ransomware
• .alphv / .sssppp → ALPHV/BlackCat
• .qilin / aléatoire 5-8 chars → Qilin/Agenda
• .cl0p → Cl0p
• Extension aléatoire 6-10 chars alphanumérique → LockBit 3.0, RansomHub

Si la combinaison note+extension ne suffit pas, l'étape suivante est le service ID Ransomware.

Étape 2 : Identification via ID Ransomware et services en ligne

ID Ransomware (id-ransomware.malwarehunterteam.com) est l'outil de référence : soumettez la note de rançon et/ou un fichier chiffré, et la base de données de plus de 1000 familles répertoriées retourne une identification avec le niveau de confiance associé.

Si ID Ransomware ne trouve pas de correspondance :

• VirusTotal : soumettez le binaire ransomware si vous l'avez isolé. Les signatures AV de 70+ moteurs donnent souvent une identification avec la famille
• Intezer Analyze : analyse de code génétique qui identifie les familles par réutilisation de code, même pour les variantes fortement obfusquées ou les variantes privées vendues sur des forums clandestins
• MalwareBazaar (abuse.ch) : base de données d'échantillons malveillants — recherche par hash SHA-256 du binaire
• Hybrid Analysis / ANY.RUN : exécution en sandbox pour observer le comportement dynamique et la communication réseau

Attention : ne soumettez pas de fichiers contenant des données sensibles de votre organisation sur ces services publics. Soumettez uniquement la note de rançon (qui est déjà publique par nature) et le binaire malveillant.

Étape 3 : Analyse statique du binaire avec PEStudio

Pour les cas où les services en ligne ne donnent pas de résultat ou quand vous avez besoin d'une analyse plus approfondie :

PEStudio fournit une analyse rapide sans exécution :

• Imports DLL : les imports caractéristiques des ransomwares incluent CryptAcquireContext, CryptEncrypt, CreateFileW en masse, FindFirstFileW/FindNextFileW (enumération), DeleteVolumeMountPointW (suppression des sauvegardes)
• Strings : recherchez des URL .onion (C2), des noms d'extensions de fichiers, des paths de notes de rançon, des noms de mutex (anti-double-exécution), des clés de registre de persistance
• Sections PE : entropie élevée (>7.0) dans les sections de code indique du code chiffré ou compressé — signe probable d'un packer ou d'obfuscation
• Certificats de signature : les ransomwares modernes utilisent parfois des certificats de signature volés — vérifiez l'émetteur et la date de révocation

Floss (FireEye) complète PEStudio pour l'extraction des strings obfusquées (XOR encodées, base64, construites dynamiquement sur la pile).

Étape 4 : Désassemblage ciblé avec Ghidra pour les cas complexes

Quand l'identification ne peut être faite qu'au niveau du code, Ghidra (NSA) permet une analyse statique approfondie gratuite. Les cibles prioritaires pour l'identification de famille :

• Algorithme de chiffrement : localiser les constantes cryptographiques dans la section .data ou les blocs de code (constantes AES S-Box : 0x63, 0x7c, 0x77..., constantes ChaCha20 : "expand 32-byte k"). L'algorithme utilisé est souvent distinctif d'une famille
• Nom du mutex : les mutex anti-double-exécution ont des noms uniques par famille — extrayable dans la fonction d'initialisation (généralement appelée depuis WinMain)
• Communication C2 : décompiler la fonction de communication réseau révèle le protocole, le format des requêtes, et souvent l'URL du C2 encodée en dur ou déchiffrée dynamiquement
• Récursion de chiffrement de fichiers : la boucle de parcours de fichiers est caractéristique — certaines familles chiffrent tout, d'autres excluent des extensions système, d'autres chiffrent par blocs intermittents (Qilin)

Étape 5 : Vérification de la disponibilité d'un décrypteur

Une fois la famille identifiée, la première action utile pour la victime est de vérifier si un décrypteur gratuit existe :

• No More Ransom (nomoreransom.org) : le référentiel principal, maintenu par Europol, Kaspersky, McAfee et les forces de l'ordre. Décrypteurs disponibles pour plus de 165 familles
• CERT-FR : publie des décrypteurs pour les familles ayant touché des victimes françaises quand les clés sont saisies lors d'opérations judiciaires
• Émoptet/Avast/Bitdefender Decryptors : décrypteurs spécifiques publiés après opérations de takedown (LockBit, Dharma, GandCrab, etc.)

Si un décrypteur existe, ne restaurez pas depuis une sauvegarde avant d'avoir tenté le décrypteur — cela peut prendre moins de temps et préserver des données qui auraient été perdues entre la compromission et la dernière sauvegarde.

Si aucun décrypteur n'est disponible, les options sont : restauration depuis sauvegarde, négociation (si assureur impliqué), ou abandon des données chiffrées si elles ne sont pas critiques.

Corrélation MITRE ATT&CK et threat intelligence

L'identification de la famille ransomware ouvre l'accès à la documentation MITRE ATT&CK des TTPs connus de ce groupe :

• Sur MITRE ATT&CK Groups (attack.mitre.org/groups), cherchez le nom de la famille
• Identifiez les techniques de mouvement latéral typiques (pour savoir où chercher sur votre réseau)
• Identifiez les persistances habituelles (tâches planifiées, clés registre) pour l'éradication
• Identifiez les outils tier-2 typiquement déployés (Cobalt Strike, Mimikatz, SystemBC) — leurs artefacts doivent être cherchés même sur les systèmes non chiffrés

Cette corrélation transforme l'identification de la souche en plan d'investigation actif : vous savez quoi chercher, où, et sous quelle forme.

Questions fréquentes

La famille identifiée a-t-elle un impact sur l'obligation de payer ?

Oui et non. Certains groupes (LockBit, ALPHV) ont une réputation de fournir effectivement les clés après paiement. D'autres (Cl0p) utilisent principalement l'extorsion de données. Mais la recommandation officielle reste de ne pas payer dans tous les cas.

ID Ransomware est-il fiable ?

Pour les familles courantes, oui à 95%+. Pour les variantes privées ou très récentes, la base de données peut être en retard. L'analyse manuelle est alors nécessaire.

Peut-on identifier la souche sans avoir le binaire ?

Oui — note de rançon + extensions de fichiers + comportement réseau (logs pare-feu) permettent souvent une identification sans jamais avoir le binaire. ID Ransomware accepte la note de rançon seule.

Reconstruction de la timeline d'infection : du patient zéro au chiffrement

Identifier la famille ransomware est l'étape 1. Comprendre comment elle est arrivée sur votre réseau est l'étape 2 — et la plus importante pour éviter une re-compromission. La reconstruction de la timeline forensique répond à quatre questions : quand, comment, depuis où, et jusqu'où.

Sources d'artefacts pour la timeline Windows

Chaque action d'un attaquant sur un système Windows laisse des traces dans plusieurs artefacts :

• $MFT (Master File Table) : enregistre la création, modification et accès de chaque fichier NTFS avec timestamp précis. Un ransomware qui écrit des notes de rançon dans chaque dossier laisse une trace dans le MFT avec des timestamps séquentiels caractéristiques
• Prefetch files (%SystemRoot%\Prefetch) : Windows précharge les applications fréquentes. Si un outil d'attaque (Mimikatz.exe, cobaltlocker.exe) a été exécuté, son entrée prefetch révèle la première et la dernière exécution avec un timestamp
• Windows Event Logs : Security.evtx (événements d'authentification — Event ID 4624, 4625, 4648), System.evtx (services créés, arrêtés), Sysmon.evtx si déployé (création de processus, connexions réseau, modifications registre)
• Shellbags et UserAssist (registre) : traces de navigation dans l'explorateur Windows, programmes exécutés via l'interface graphique
• Amcache.hve : liste des exécutables lancés récemment avec leur hash SHA-1 — permet d'identifier des outils d'attaque même s'ils ont été supprimés
• Srum database (SRUM) : System Resource Usage Monitor, enregistre l'utilisation CPU/réseau/mémoire par processus sur 30 jours — visible même après suppression des processus

La corrélation de ces sources avec Hayabusa (pour les Event Logs) et log2timeline (pour l'agrégation multi-sources) permet de reconstruire une timeline précise avec des résolutions temporelles à la seconde.

Indicateurs de compromission (IOC) : où chercher après identification de la souche

Une fois la famille identifiée, les IOC spécifiques de cette famille sont publiés dans de nombreuses sources. Les utiliser activement pour chercher des traces sur votre réseau est l'étape suivante de l'investigation.

Sources d'IOC par famille

• MITRE ATT&CK (attack.mitre.org/groups) : TTPs documentés, outils utilisés, procédures connues
• Mandiant / Google Threat Intelligence : rapports détaillés sur chaque groupe avec IOC (hashes, IPs C2, domaines, user-agents)
• ANSSI CERT-FR (cert.ssi.gouv.fr) : alertes et rapports de menaces ciblant la France avec IOC vérifiés
• MISP (Malware Information Sharing Platform) : partage d'IOC entre organisations — plusieurs instances publiques et privées disponibles
• OTX (AlienVault Open Threat Exchange) : base collaborative d'IOC, recherche par famille de malware
• MalwareBazaar (abuse.ch) : hashes SHA-256 des échantillons connus avec contexte

Une fois les IOC collectés, leur utilisation opérationnelle :

• Hashes SHA-256 : comparer avec les logs Amcache, les logs EDR, les logs AV pour identifier des exécutions passées
• IP C2 et domaines : interroger les logs firewall et DNS sur les 30 derniers jours — un système qui a communiqué avec le C2 est compromis même s'il n'a pas encore été chiffré
• Noms de mutex : chercher dans les logs Sysmon (Event ID 17/18) ou via Velociraptor
• Chemins de fichiers caractéristiques : présence de fichiers outils dans %AppData%, %Temp%, C:\ProgramData\

Comparaison rapide LockBit / RansomHub / Akira : comment les distinguer

Ces trois familles sont responsables de la grande majorité des incidents en France en 2025-2026. Voici un tableau comparatif des points d'identification rapide :

LockBit 3.0 / 4.0

• Extension : aléatoire 9 chars alphanumérique (ex: .7a3f2c9b1)
• Note : README.txt avec lien .onion unique par victime
• Mutex : pattern "Global\{GUID}" avec GUID dérivé du volume serial
• Suppression shadow : via WMI SELECT * FROM Win32_ShadowCopy puis delete
• Outil d'exfiltration : StealBit (binaire propriétaire) ou Rclone
• C2 : communications HTTPS avec certificat auto-signé, port 443 ou 4433

RansomHub

• Extension : aléatoire 6-8 chars lowercase (ex: .af3b29)
• Note : README_{ext}.txt dans chaque dossier chiffré
• Architecture Go (Windows) et C++ (Linux/ESXi) — deux binaires distincts
• Technique ESXi : SSH activé sur ESXi + commandes esxcli pour arrêter les VMs avant chiffrement
• Exfiltration : MEGA via rclone, ou serveur FTP/SFTP contrôlé par l'affilié

Akira

• Extension : .akira (invariant)
• Note : absente pendant l'exécution, créée en fin de processus, fichier akira_readme.txt
• Interface UI : unique parmi les groupes — propose un "chat" via navigateur sur leur .onion
• Chiffrement intermittent : chiffre les premiers 2 Mo de chaque fichier puis les blocs alternés — très rapide sur de grands fichiers
• Persistance : clé registre HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell

Cette comparaison rapide permet souvent une attribution sans analyse de binaire : extension unique (.akira), style de note distinctif (RansomHub avec le nom de l'extension dans le fichier note), ou comportement caractéristique (LockBit qui délègue la suppression des shadows à WMI).

Quand faire appel à un PRIS ANSSI

Le recours à un Prestataire de Réponse à Incident de Sécurité (PRIS) qualifié ANSSI est recommandé dès que l'incident dépasse la capacité interne de réponse. Les critères qui justifient un appel immédiat :

• Périmètre de compromission inconnu ou en expansion — vous ne savez pas où s'arrête l'attaque
• Systèmes critiques chiffrés sans sauvegarde propre disponible
• Suspicion de double extorsion avec données personnelles exfiltrées — obligation RGPD avec contrainte temporelle
• Incident touchant des OT/SCADA ou des systèmes de sécurité physique
• Première expérience d'incident majeur dans l'organisation

La liste des PRIS qualifiés ANSSI est publiée sur le site de l'agence (ssi.gouv.fr). Ces prestataires ont été évalués sur leurs compétences techniques, leurs procédures et leur confidentialité. Certains assureurs cyber exigent de travailler avec des prestataires de leur réseau — vérifiez ce point avant l'incident pour ne pas perdre de temps lors de la crise.

Si vous êtes une PME sans assurance cyber, le dispositif cybermalveillance.gouv.fr propose un annuaire de prestataires locaux et un accompagnement initial gratuit pour les victimes.

Analyse des variantes : comment les familles évoluent et se fragmentent

L'identification d'un ransomware n'est pas un problème statique. Les familles évoluent constamment, leurs codes sources fuient ou sont vendus, et de nouvelles variantes émergent régulièrement. Comprendre cette dynamique est essentiel pour éviter les erreurs d'identification.

Le cas LockBit : une famille fragmentée en dizaines de variantes

En septembre 2022, le code source du builder LockBit 3.0 a fuité sur Twitter (maintenant X). Ce builder permettait à n'importe qui de générer des exécutables LockBit personnalisés. Le résultat : des dizaines de "variantes" LockBit développées par des acteurs différents, allant de simples script kiddies utilisant le builder sans modification à des groupes structurés qui ont forké le code pour créer DragonForce, LockBit 4.0 et d'autres.

Pour l'identification forensique, cette fragmentation signifie que la présence du code LockBit ne signifie pas forcément le groupe LockBit officiel. Les éléments distinctifs du LockBit "officiel" incluent : l'infrastructure .onion hébergée sur leur domaine connu, le style de note de rançon (pas juste la note générique du builder), et les IOC C2 correspondant aux serveurs connus du groupe.

Les "rebuilds" basés sur des codes sources leakés

Plusieurs familles importantes ont vu leur code source exposé :

• Conti (fuite 2022) : a donné naissance à Quantum, Royal, BlackBasta, et d'autres groupes qui ont recyclé le code
• LockBit 3.0 (fuite 2022) : DragonForce, LockBit 4.0 (avec modifications), nombreuses variantes privées
• Babuk (fuite 2021) : nombreux ransomwares ESXi utilisent encore du code Babuk modifié

Ces fuites de code source compliquent l'attribution mais facilitent parfois la récupération : si deux familles partagent des vulnérabilités d'implémentation cryptographique, un décrypteur développé pour l'une peut fonctionner sur l'autre.

Méthode de différenciation par analyse de code

Intezer Analyze est l'outil de référence pour différencier les variantes basées sur du code partagé. Son analyse de "code genes" quantifie le pourcentage de code partagé avec des familles connues. Un résultat "80% similaire à LockBit 3.0" indique un rebuild basé sur le code source leaké, tandis que "90% similaire" avec les mêmes fonctions clés suggère une variante directe.

Collaboration avec les autorités et partage d'IOC

L'analyse forensique d'un ransomware ne doit pas rester cloisonnée dans votre organisation. Le partage des IOC et des analyses contribue à la lutte collective contre les groupes ransomware.

Partage via CERT-FR

Le CERT-FR (cert.ssi.gouv.fr) encourage activement le partage d'IOC et d'analyses. La déclaration d'incident n'est pas uniquement une obligation (pour les OIV/OSE) — c'est une opportunité d'obtenir du support technique, des IOC additionnels non publics, et de contribuer à la base de connaissances nationale. Le traitement est confidentiel.

Partage via MISP

MISP (misp-project.org) est la plateforme standard de partage d'IOC entre organisations de confiance. Des instances publiques (CIRCL Luxembourg, ANSSI) et sectorielles (CERT Santé, CERT bancaire) permettent d'échanger des informations de menace de manière structurée et contrôlée. Un format standardisé (STIX 2.1) facilite l'import automatique dans votre SIEM.

Contribution à No More Ransom

Si votre analyse identifie une faiblesse cryptographique dans une famille ransomware permettant la récupération des données sans clé, contactez les partenaires du programme No More Ransom (Europol, Kaspersky, McAfee) pour intégrer un décrypteur. Ce processus a permis la récupération des données de plus d'un million de victimes depuis 2016, pour une valeur de rançon non-payée estimée à plus de 900 millions d'euros.

La traçabilité de votre investigation est aussi importante que l'investigation elle-même. Toutes les actions menées (accès aux systèmes, commandes exécutées, fichiers analysés) doivent être documentées avec timestamp, opérateur, et résultat. Cette documentation sert à plusieurs fins : éviter les doublons lors d'investigations en équipe, satisfaire les exigences légales et assurantielles, et permettre la reconstruction de la chronologie d'intervention. Un simple fichier log.txt en cours d'investigation, horodaté et partagé sur un canal sécurisé hors-bande, suffit dans l'urgence. Les outils comme Velociraptor journalisent automatiquement les requêtes — exploitez ces logs systématiquement. Enfin, vérifiez les décrypteurs disponibles sur No More Ransom avant chaque restauration depuis sauvegarde — la base est mise à jour régulièrement et un décrypteur peut exister pour une famille que vous croyiez non-récupérable.

L'identification de la souche ransomware est le point de départ de toute réponse technique, mais elle n'est pas une fin en soi. L'objectif final est la récupération des données, la compréhension du mode opératoire et l'amélioration des défenses. Chaque investigation forensique, même menée dans l'urgence, doit contribuer à ces trois objectifs en parallèle. Les organisations qui traitent l'investigation forensique comme une phase distincte et séquentielle perdent du temps précieux — l'identification, la cartographie du périmètre et la préparation de la récupération doivent avancer simultanément, avec des équipes spécialisées en parallèle.