Rétro-Ingénierie de Ransomware : Analyse Technique

Les attaques par ransomware ont causé plus de 20 milliards de dollars de dommages en 2025, faisant de la rétro-ingénierie de ces malwares une compétence stratégique pour les organisations. L'analyse d'un échantillon de ransomware récupéré lors d'un incident permet non seulement de chercher des faiblesses cryptographiques exploitables pour le déchiffrement, mais aussi d'extraire les indicateurs de compromission (IP des serveurs C2, mutex de détection, clés de registre de persistance) qui alimentent les règles de détection YARA et les signatures SIEM pour protéger l'organisation contre les variantes futures. La compréhension des techniques d'anti-rétro-ingénierie utilisées par les APT est essentielle car les ransomwares modernes intègrent des protections anti-analyse sophistiquées. L'utilisation de Ghidra pour le reverse engineering fournit les bases techniques nécessaires pour cette analyse. Les techniques de déobfuscation des malwares polymorphes sont directement applicables aux packers utilisés par les ransomwares. L'analyse des malwares fileless en mémoire complète les techniques d'analyse pour les variantes les plus évasives. Les ressources de NoMoreRansom.org publient les décrypteurs développés par la communauté et les forces de l'ordre, et les rapports de Mandiant documentent les tactiques, techniques et procédures des groupes ransomware actifs.

Reconstruction des algorithmes propriétaires et cas pratiques

Certains ransomwares utilisent des variantes propriétaires ou des implémentations non-standard des algorithmes cryptographiques. Cette originalité peut être intentionnelle (compliquer l'analyse) ou le signe d'une implémentation amateur (introduisant des faiblesses exploitables). La reconnaissance et la reconstruction de ces algorithmes est une compétence avancée qui peut parfois permettre une récupération sans paiement.

Cas 1 : XOR simple avec clé dérivée du PID

Certains ransomwares amateur utilisent un XOR simple avec une clé générée à partir du PID du processus. Si le PID est connu (depuis les logs système), le contenu peut être récupéré trivialement. Indicateur dans le désassemblé : boucle XOR avec GetCurrentProcessId() comme source de la clé, sans expansion de clé.

Cas 2 : AES avec IV constant (erreur de déploiement)

Plusieurs familles ont déployé AES-CBC avec un vecteur d'initialisation (IV) constant ou prévisible. Cette erreur, documentée dans des variantes de Dharma et certains ransomwares de bas de gamme, rend possible la récupération si l'IV et la clé sont obtenus depuis un autre fichier chiffré ou depuis le binaire lui-même. Identifier ce pattern : dans Ghidra, chercher des blocs AES-CBC initialisés avec une constante 0x00...00 ou une valeur hardcodée.

Cas 3 : Implémentation faible de ChaCha20

RansomHub et ses variantes utilisent ChaCha20 correctement. Mais des familles dérivées ont introduit des faiblesses : compteur de bloc non incrémenté correctement (réutilisation de keystream), ou nonce généré depuis rand() non seedé de manière cryptographique. Si le nonce est prévisible (basé sur le timestamp de modification du fichier, visible dans les métadonnées), le keystream peut être reconstruit.

Méthodologie systématique pour les algorithmes inconnus

1. Identifier la fonction de chiffrement par fichier (souvent le cœur de la boucle de traitement)
2. Localiser la génération de clé et de IV/nonce — tracer les paramètres depuis l'appel à la fonction crypto
3. Identifier l'algorithme par les constantes caractéristiques (tables S-Box AES, constantes Salsa20/ChaCha20, courbes elliptiques)
4. Vérifier si la clé est dérivée de données locales (temps système, PID, volume serial) ou transmise au C2
5. Si la clé est locale et dérivable : écrire un script de récupération Python avec pycryptodome
6. Si la clé est transmise au C2 : vérifier si des captures réseau ont été faites pendant l'exécution

Ce travail est chronophage (plusieurs jours pour un analyste senior) mais peut être déterminant pour les victimes sans assurance cyber et sans sauvegarde récente. La publication des résultats contribue à la communauté défensive — No More Ransom intègre les décrypteurs ainsi développés.

Ressources de référence pour la cryptanalyse des ransomwares : les publications de Kaspersky GReAT (Securelist), les analyses Mandiant (now Google), et les dépôts GitHub des équipes CERT-ANSSI. Ces équipes publient régulièrement leurs méthodologies d'analyse pour les familles actives en France.

Ressources et références pour la rétro-ingénierie de ransomware

La rétro-ingénierie de malware est une discipline qui s'apprend par la pratique et la lecture. Les ressources suivantes constituent une bibliothèque de référence :

• Practical Malware Analysis (Sikorski & Honig) : la bible du sujet, couvre tous les aspects de l'analyse statique et dynamique avec des exercices pratiques sur des échantillons réels
• The Art of Memory Forensics (Ligh et al.) : référence pour l'analyse Volatility et la forensique mémoire
• OpenSecurityTraining2 (opensecuritytraining2.info) : cours gratuits et approfondis sur l'architecture x86/x64, l'analyse de malware, Ghidra
• MalwareBazaar + ANY.RUN : sources d'échantillons pour la pratique — commencez par des familles simples avant les ransomwares modernes
• OALabs (Unpacked) : chaîne YouTube et blog spécialisés sur l'analyse de malware, avec des walk-throughs détaillés de familles récentes
• Securelist (Kaspersky GReAT) : analyses approfondies régulières des groupes ransomware actifs, avec détails techniques et IOC

La pratique régulière sur des environnements isolés (FlareVM pour Windows, REMnux pour Linux) est le seul moyen de maintenir et développer ces compétences. Un analyste IR qui n'a pas analysé de malware depuis 6 mois aura des lacunes au moment où ça compte vraiment.

Phase 1 : triage rapide et identification

Le triage rapide en 15 minutes détermine si un décrypteur existe déjà et oriente l'analyse approfondie. L'identification de la famille utilise les chaînes caractéristiques dans le binaire (notes de rançon, extensions de fichiers chiffrés, mutex), les signatures YARA communautaires et les bases de données en ligne (ID Ransomware, VirusTotal). La vérification sur NoMoreRansom.org identifie les décrypteurs publics disponibles pour plus de 170 familles de ransomware. Si un décrypteur existe, l'analyse approfondie n'est pas nécessaire pour le recovery immédiat mais reste pertinente pour la threat intelligence.

L'extraction des métadonnées du binaire fournit les premières informations : l'analyse PE avec pestudio identifie le compilateur, la date de compilation et les imports suspects (CryptEncrypt, CryptGenRandom, BCryptEncrypt pour les APIs cryptographiques Windows). Le calcul des hashes (MD5, SHA-256, imphash) permet la recherche dans les bases de signatures et la corrélation avec des échantillons connus pour déterminer la génération et la variante spécifique du ransomware analysé.

Phase 2 : analyse statique avec Ghidra

L'analyse statique dans Ghidra commence par l'identification des fonctions cryptographiques importées ou implémentées en interne. Les ransomwares modernes utilisent typiquement une combinaison RSA + AES : RSA-2048 ou RSA-4096 pour chiffrer une clé AES-256 unique par fichier, et AES-256 en mode CBC ou CTR pour chiffrer le contenu du fichier. L'identification des constantes cryptographiques (S-box AES, constantes RSA) dans le code désassemblé confirme les algorithmes utilisés même lorsque les imports sont obfusqués.

La recherche de faiblesses cryptographiques se concentre sur cinq erreurs d'implémentation courantes : l'utilisation de PRNG faibles pour la génération des clés (rand() au lieu de CryptGenRandom), la réutilisation d'IV ou de nonce entre les fichiers, le stockage temporaire de la clé en mémoire après le chiffrement, l'utilisation du mode ECB au lieu de CBC/CTR, et la dérivation de clé prévisible à partir de paramètres machine. Ces faiblesses permettent la reconstruction de la clé de déchiffrement dans environ 30% des cas selon les statistiques NoMoreRansom, un ratio qui justifie l'investissement en temps d'analyse pour chaque nouvelle variante.

Phase 3 : analyse dynamique et extraction de clés

L'analyse dynamique exécute le ransomware dans un environnement sandbox instrumenté (FlareVM avec x64dbg, Process Monitor, Fakenet-NG) pour observer son comportement en temps réel. Les breakpoints sur les fonctions cryptographiques (CryptEncrypt, BCryptEncrypt, ou les implémentations internes d'AES) capturent les clés et les IV au moment du chiffrement. La surveillance des opérations fichiers identifie l'ordre de chiffrement, les extensions ciblées, les répertoires exclus et le mécanisme de suppression des shadow copies (vssadmin delete shadows).

L'interception des communications C2 avec Fakenet-NG ou INetSim capture les échanges réseau du ransomware avec son infrastructure de commande et contrôle. Les ransomwares modernes transmettent la clé RSA publique du serveur C2 au client et remontent la clé AES chiffrée par RSA. L'analyse de ces échanges révèle le protocole de communication, le format des données échangées et potentiellement les clés de déchiffrement si le serveur C2 a été saisi par les forces de l'ordre, une situation de plus en plus fréquente grâce aux opérations internationales contre les infrastructures ransomware.

Conclusion

La rétro-ingénierie de ransomware combine analyse statique et dynamique pour identifier les faiblesses cryptographiques, extraire les clés de déchiffrement lorsque possible, et produire les IOC nécessaires à la défense. Le triage rapide en 15 minutes et la méthodologie en 5 phases structurent un processus reproductible applicable à toute variante de ransomware rencontrée lors d'un incident de sécurité.

Synthèse et points clés

Les éléments présentés dans cet article mettent en évidence l'importance d'une approche structurée et méthodique. La combinaison de contrôles techniques, de processus organisationnels et de formation continue constitue le socle d'une posture de sécurité mature et résiliente face aux menaces actuelles.

Analyse de malwares & rétro-ingénierie

Analyse de code malveillant, reverse engineering, threat intelligence — rapport IOC complet.

Phase 4 : extraction des clés de chiffrement en mémoire

Si vous analysez un ransomware pendant qu'il s'exécute — ou dans les minutes suivant son exécution, avant que la machine soit redémarrée — il est parfois possible d'extraire les clés de chiffrement directement depuis la mémoire vive. Cette fenêtre d'opportunité est courte (quelques minutes au plus) mais peut permettre la récupération des données sans payer la rançon.

La technique s'appuie sur le fait que les ransomwares doivent maintenir les clés en mémoire pendant le processus de chiffrement. Même si la clé finale est chiffrée avec une clé publique RSA avant d'être envoyée au C2, la clé symétrique (AES, ChaCha20) reste en mémoire pendant l'opération.

Outil principal : Volatility 3

• Acquisition mémoire avec winpmem_mini_x64.exe mem.raw (à faire AVANT reboot)
• Identification des processus suspects : vol -f mem.raw windows.pslist.PsList
• Dump de la mémoire du processus ransomware : vol -f mem.raw windows.memmap.MemMap --pid [PID] --dump
• Recherche des patterns de clés AES (16, 24 ou 32 octets avec entropie élevée) dans le dump

Pour les ransomwares utilisant ChaCha20 (RansomHub, Akira, Qilin), le nonce de 12 octets est souvent stocké adjacent à la clé. Un script Python avec la librairie pycryptodome peut tenter des combinaisons clé/nonce sur un fichier chiffré échantillon pour valider une clé candidate.

Pour les ransomwares utilisant AES-256 CTR (variantes LockBit), les schedulers Windows IOCP et les pools de clés permettent parfois de retrouver les clés individuelles par fichier dans les structures de données du processus. C'est un travail laborieux mais documenté — les chercheurs de Kaspersky ont publié les offsets pour LockBit 3.0 en 2024.

La règle d'or : avant de redémarrer un système compromis, acquérez toujours une image mémoire. Même si vous n'avez pas les compétences en interne pour l'analyser immédiatement, un PRIS ou un chercheur externe pourra le faire après coup.

Phase 5 : construction du profil de menace et corrélation MITRE ATT&CK

L'analyse technique d'un ransomware ne se termine pas à la compréhension du chiffrement. L'objectif final est de construire un profil de menace complet qui permettra à la fois de renforcer les défenses et d'attribuer l'attaque à un groupe connu. Cette attribution n'est pas qu'une curiosité intellectuelle — elle détermine si vous êtes soumis à des obligations de notification (ANSSI, CNIL) et si vos assureurs peuvent contester la couverture (exclusions guerre/attaque étatique).

La cartographie MITRE ATT&CK d'un incident ransomware typique couvre :

• Initial Access (TA0001) : phishing (T1566), exploitation de VPN vulnérables (T1190), achat d'accès sur des marketplaces (Initial Access Brokers)
• Persistence (TA0003) : création de tâches planifiées (T1053.005), modification du registre Run (T1547.001), backdoor via GPO (T1484.001)
• Defense Evasion (TA0005) : désactivation des EDR (T1562.001), living-off-the-land (T1218 — LOLBins), processus hollowing (T1055.012)
• Credential Access (TA0006) : dump LSASS (T1003.001), Kerberoasting (T1558.003), pass-the-hash (T1550.002)
• Lateral Movement (TA0008) : PsExec (T1021.002), WMI (T1047), exploitation de services exposés en interne
• Impact (TA0040) : chiffrement (T1486), destruction des sauvegardes (T1490), exfiltration pour double extorsion (T1567)

Les TTPs caractéristiques permettent souvent d'identifier la famille :

• Utilisation de Cobalt Strike + Mimikatz + Rclone → LockBit, ALPHV
• Utilisation de Brute Ratel + SystemBC → BlackCat, Play
• Exploitation ESXi via Python/Golang → Akira, Qilin, RansomHub
• Utilisation de GoSomethingProxy ou Socks5Systemz comme proxy C2 → DragonForce

Documentez chaque TTP dans un format standardisé (STIX 2.1 si possible) pour pouvoir soumettre votre analyse à l'ANSSI/CERT-FR. Ces contributions alimentent la base de connaissances nationale et aident d'autres organisations à se défendre contre les mêmes acteurs.

Construire des règles de détection à partir de l'analyse : YARA et Sigma

L'aboutissement de toute analyse de ransomware doit être la production de règles de détection réutilisables. Sans cette étape, le travail de rétro-ingénierie reste académique et ne profite pas directement à la posture de sécurité.

Règle YARA — pour la détection du binaire et ses variantes :

rule Ransomware_Generic_Mutex_Check {
    meta:
        description = "Détecte les patterns de mutex anti-double-exécution"
        author = "Ayi NEDJIMI"
        date = "2026-05"
    strings:
        $mutex_pattern = { 43 72 65 61 74 65 4D 75 74 65 78 } // CreateMutex
        $ransom_ext = ".locked" wide ascii nocase
        $shadow_delete = "vssadmin delete shadows" nocase
        $wbadmin = "wbadmin delete catalog" nocase
    condition:
        uint16(0) == 0x5A4D and
        filesize < 10MB and
        2 of ($mutex_pattern, $shadow_delete, $wbadmin)
}

Règle Sigma — pour la détection comportementale dans le SIEM :

title: Ransomware Shadow Copy Deletion
status: stable
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine|contains:
            - 'vssadmin delete shadows'
            - 'wmic shadowcopy delete'
            - 'bcdedit /set {default} recoveryenabled no'
            - 'wbadmin delete catalog'
    condition: selection
falsepositives:
    - Scripts d'administration légitimes (à exclure par process parent)
level: high
tags:
    - attack.impact
    - attack.t1490

Ces règles doivent être versionnées dans votre référentiel de détection, testées régulièrement contre des échantillons connus (via une sandbox isolée), et mises à jour à chaque nouvelle variante analysée. La communauté CERT-FR et les dépôts publics (Elastic Detection Rules, Sigma HQ) sont des sources de règles de base qu'il est possible d'adapter à votre contexte.

Points clés à retenir

• L'acquisition mémoire avant le reboot est critique — c'est la seule fenêtre pour extraire les clés de chiffrement in vivo
• Volatility 3 et ses plugins Windows permettent de localiser les processus malveillants et leurs allocations mémoire
• La cartographie MITRE ATT&CK transforme l'analyse technique en renseignement actionnable pour durcir les défenses
• Les TTPs caractéristiques (outils utilisés, comportements C2, techniques d'évasion) permettent souvent d'attribuer l'attaque à un groupe connu
• Toute analyse doit se terminer par des règles YARA et Sigma publiables — c'est la contribution à l'écosystème défensif collectif
• La soumission des analyses au CERT-FR alimente la base de connaissances nationale et aide à la détection précoce des campagnes

Contacter un expert [email protected]