Résumé exécutif

L'unpacking malware avancé constitue l'étape préliminaire indispensable à toute analyse statique approfondie : plus de soixante-dix pour cent des menaces modernes s'appuient sur des packers ou des crypters pour dissimuler leur code aux moteurs antivirus comme aux analystes. Le principe reste constant : le packer compresse ou chiffre le payload malveillant, puis embarque un stub de décompression chargé de restaurer le code original en mémoire à l'exécution. Tant que cette couche protectrice n'est pas retirée, le désassemblage ne révèle que le stub, sans les chaînes, les imports ni la logique réelle de la charge utile. En 2026, les familles les plus sophistiquées combinent chiffrement polymorphe, anti-debug, anti-VM et déchiffrement progressif en mémoire, rendant les approches purement automatisées insuffisantes. Maîtriser ces techniques et ces outils devient donc une compétence structurante pour tout analyste.

  • Méthodologie d'analyse et outils utilisés
  • Structures internes et mécanismes de protection
  • Techniques d'obfuscation et de contournement
  • Applications pratiques en réponse aux incidents

Le packing est la technique de protection la plus répandue dans l'écosystème malware : elle empêche l'analyse statique directe du code malveillant et réduit drastiquement le taux de détection par les moteurs antivirus basés sur les signatures. Les packers commerciaux (UPX, Themida, VMProtect, Enigma Protector) et les crypters custom développés par les acteurs de la menace ajoutent une couche de protection que l'analyste doit retirer avant de pouvoir étudier le comportement réel du malware. La maîtrise des techniques d'unpacking est un prérequis fondamental pour l'analyse dynamique avancée qui observe le code dépacké en exécution. La déobfuscation des malwares polymorphes complète ces techniques pour les protections multiniveaux. L'utilisation de Ghidra pour le reverse engineering est la destination finale du processus d'unpacking qui produit un binaire analysable. Les techniques d'anti-rétro-ingénierie des APT combinent packing et obfuscation pour créer des protections multicouches. Les tutoriels d'OALabs et les publications de hasherezade documentent les techniques d'unpacking des familles de malwares les plus récentes.

  • 70% des malwares avancés utilisent un packer ou un crypter pour protéger leur code
  • Le point d'entrée original (OEP) est le moment clé où le code est restauré en mémoire
  • Le dump mémoire à l'OEP capture le code déchiffré et les données restaurées
  • La reconstruction IAT avec Scylla reconstitue les imports pour un binaire fonctionnel
  • L'automatisation avec CAPE gère 200+ packers connus pour le triage à grande échelle

Identification du packer et analyse d'entropie

L'identification du packer utilise Detect It Easy (DIE) qui reconnaît plus de 400 packers par signatures et heuristiques. L'analyse d'entropie des sections PE confirme le diagnostic : une entropie supérieure à 7.0 sur 8.0 indique une section compressée ou chiffrée (le code natif x86/x64 a typiquement une entropie entre 5.5 et 6.5). La taille brute (raw size) significativement inférieure à la taille virtuelle (virtual size) d'une section indique que le contenu sera décompressé en mémoire. Les packers custom ne sont pas reconnus par DIE mais partagent les mêmes caractéristiques entropiques et structurelles que les packers connus, permettant leur identification par analyse heuristique.

Les protections multiniveaux combinent plusieurs packers en série : un crypter externe (souvent généré par un service MaaS de crypting) protège le loader intermédiaire qui déchiffre et charge le packer interne protégeant le payload final. L'unpacking requiert alors un processus itératif où chaque couche est retirée séquentiellement pour atteindre le malware original. La documentation des couches rencontrées et de l'ordre de dépackage est essentielle pour la reproductibilité de l'analyse et le développement de signatures de détection ciblant chaque couche indépendamment.

Unpacking manuel avec x64dbg

L'unpacking manuel avec x64dbg repose sur l'identification du point d'entrée original (OEP) où le contrôle est transféré du stub de décompression vers le code malveillant restauré. Les techniques pour localiser l'OEP incluent : breakpoints sur VirtualAlloc et VirtualProtect (le stub alloue de la mémoire pour le code décompressé), hardware breakpoint on exécution sur la section .text restaurée, single-stepping à travers le stub de décompression pour les packers simples (UPX), et breakpoints conditionnels sur les instructions de transfert de contrôle (JMP/CALL vers des adresses dans les sections décompressées).

⚡

Retour terrain

Lors de l'analyse d'un échantillon de malware soumis par un client du secteur industriel, j'ai identifié une technique d'évasion inhabituelles : le payload était encodé dans les métadonnées EXIF d'une image JPEG téléchargée depuis un compte Twitter légitime. Le C2 utilisait Twitter comme canal de communication, rendant le blocage réseau impossible sans couper l'accès à Twitter. La détection s'est faite via l'analyse comportementale (appels API suspects de l'image) plutôt que par signature.

Le dump mémoire au point d'entrée original capture l'image du processus avec le code déchiffré en clair. Les outils de dump (x64dbg plugin Scylla, OllyDumpEx, PE-bear) sauvegardent l'image mémoire du processus en corrigeant les alignements de sections PE. Le binaire dumpé contient le code malveillant en clair mais nécessite la reconstruction de l'Import Address Table pour être analysable dans Ghidra ou IDA car les pointeurs d'imports résolus en mémoire ne correspondent plus aux entrées de l'IAT du fichier PE sur disque.

Reconstruction IAT et finalisation

Scylla est l'outil de référence pour la reconstruction de l'Import Address Table. Il scanne la mémoire du processus dumpé pour identifier les pointeurs vers les fonctions exportées des DLL système (kernel32.dll, ntdll.dll, user32.dll, advapi32.dll) et reconstruit l'IAT en associant chaque adresse à son nom de fonction. Les cas problématiques incluent les imports par ordinal (sans nom de fonction), les imports de DLL non standard (bibliothèques tierces) et les techniques d'import mangling utilisées par certains packers avancés qui résolvent les imports via des tables de hashing custom au lieu de l'IAT standard.

La validation du binaire reconstruit vérifie que le fichier PE dumpé et réparé est fonctionnel : chargement dans Ghidra avec identification correcte des fonctions et des strings, exécution en sandbox pour vérifier que le comportement est identique à l'échantillon original, et comparaison des appels API observés en dynamique avec les imports reconstruits dans l'IAT. Les divergences indiquent des imports manquants ou incorrects qui nécessitent une correction manuelle dans l'IAT reconstruite par Scylla pour obtenir un binaire parfaitement analysable.

Control flow flattening : technique d'obfuscation qui remplace la structure de contrôle naturelle du programme (if/else, boucles, switch) par un dispatcher central qui sélectionne le prochain bloc de code à exécuter via une variable d'état, rendant le graphe de contrôle illisible dans les désassembleurs et empêchant l'analyse statique efficace.

PackerDifficultéTechnique d'unpackingAutomatisable
UPXTrivialupx -d ou OEP + dumpOui (upx -d)
MPRESSFacileOEP + dump + IAT fixOui (CAPE)
ThemidaDifficileVM analysis + dumpPartiel
VMProtectExpertVM bytecode analysisNon
Custom APTVariableManual OEP + dumpNon

L'analyse d'un dropper APT ciblant le secteur aérospatial européen présentait trois couches de protection : un crypter commercial (Enigma Protector) protégeant un loader .NET obfusqué avec ConfuserEx qui déchiffrait un shellcode final en mémoire. Le dépackage itératif a nécessité 2 jours : d'abord le retrait d'Enigma Protector par dump mémoire avec x64dbg, puis la décompilation du loader .NET avec de4dot pour retirer ConfuserEx, et enfin l'extraction du shellcode par breakpoint sur VirtualAlloc. Le payload final était un implant custom communiquant via DNS-over-HTTPS avec un C2 hébergé sur une infrastructure cloud légitime.

Mon avis : l'investissement en compétences d'unpacking est le meilleur différenciateur pour un analyste malware. Les outils automatisés gèrent le quotidien mais échouent systématiquement sur les échantillons APT et les packers custom. La capacité à unpacker manuellement un binaire est ce qui distingue un analyste junior d'un analyste senior capable de traiter les menaces les plus sophistiquées.

Comment identifier le packer utilisé par un malware ?

Detect It Easy identifie les packers connus par signatures. Pour les packers custom, analysez l'entropie des sections PE (supérieure à 7.0 indique compression/chiffrement) et la disparité entre taille brute et taille virtuelle des sections.

Peut-on automatiser l'unpacking de tous les malwares ?

Non. Les outils automatisés gèrent les packers connus. Les packers avancés comme Themida, VMProtect et les packers custom APT nécessitent un unpacking manuel avec x64dbg et des techniques spécifiques à chaque packer.

Qu'est-ce que la reconstruction d'IAT et pourquoi est-elle nécessaire ?

L'Import Address Table liste les fonctions système importées. Après le dump mémoire, les adresses sont invalides. Scylla reconstruit l'IAT en résolvant les adresses vers les noms de fonctions DLL pour un binaire analysable.

Conclusion

L'unpacking de malware est le prérequis technique à toute analyse statique efficace. La combinaison d'identification de packer, dump mémoire à l'OEP, reconstruction IAT avec Scylla et déobfuscation du control flow produit un binaire analysable qui révèle le comportement réel du malware protégé. La maîtrise de ces techniques manuelles complète les outils automatisés pour traiter les menaces les plus sophistiquées.

Investissez dans les compétences d'unpacking manuel pour votre équipe d'analyse malware. Les outils automatisés gèrent le triage quotidien mais la capacité à dépacketer manuellement est ce qui fait la différence face aux APT et aux malwares protégés par des packers custom.

Article suivant recommandé

Rétro-Ingénierie de C2 : Cobalt Strike et Brute Ratel →

Analyse technique des frameworks C2 par rétro-ingénierie : extraction de configuration Cobalt Strike, analyse Brute Rate

Analyse des impacts et recommandations

L'analyse des risques associés à cette problématique révèle des impacts potentiels significatifs sur la confidentialité, l'intégrité et la disponibilité des systèmes d'information. Les recommandations présentées s'appuient sur les référentiels de l'ANSSI et du NIST pour garantir une approche structurée de la remédiation.

Surface d'attaque : Ensemble des points d'entrée exploitables par un attaquant pour compromettre un système, incluant les services exposés, les interfaces utilisateur et les API.

La rétro-ingénierie de logiciels peut enfreindre les conditions d'utilisation et la législation sur la propriété intellectuelle. Assurez-vous de disposer des autorisations nécessaires avant toute analyse.

Commencez toujours l'analyse d'un binaire par l'identification statique (strings, imports, headers) avant de passer au débogage dynamique. Cela permet de repérer rapidement les fonctions clés.

Automatisation du unpacking et intégration dans les pipelines de threat intelligence

L'unpacking manuel de malware est chronophage et ne passe pas à l'échelle dans un contexte de veille threat intelligence où des centaines d'échantillons sont traités quotidiennement. L'automatisation s'appuie sur des sandboxes d'analyse dynamique spécialisées qui émulent l'exécution jusqu'au point de déchiffrement de la charge finale. Des solutions comme Cape Sandbox (Community Automated Payload Extraction) automatisent spécifiquement l'extraction de configs de malware connus — Cobalt Strike, AsyncRAT, Amadey, LummaC2 — avec des extracteurs de configuration dédiés mis à jour par la communauté. Any.run et Tria.ge proposent des APIs permettant la soumission automatisée d'échantillons avec récupération du rapport structuré.

Pour les packers inconnus ou les protections multi-couches qui résistent à l'analyse dynamique automatisée, une approche hybride combine : émulation statique via QILING Framework (émulateur de code multi-architecture sans OS complet) pour exécuter les routines de déchiffrement dans un environnement contrôlé, dump mémoire automatisé à des points clés de l'exécution via des breakpoints scriptés dans x64dbg (plugin ScriptDLL), et classification du packer via Detect-It-Easy pour orienter vers le bon outil d'unpacking. L'intégration de ces workflows dans une plateforme de threat intelligence comme MISP ou OpenCTI permet de corréler automatiquement les IOCs extraits des payloads avec les campagnes et acteurs documentés dans la base de connaissances.

Ayi NEDJIMI

Analyse de malwares & rétro-ingénierie

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

Pour aller plus loin

Les concepts présentés dans cet article constituent une base solide pour approfondir le sujet. Ces ressources complémentaires permettent d'aller plus loin dans la compréhension et la mise en pratique.

Ressources officielles de référence

  • ANSSI — Guides et recommandations techniques — La bibliothèque technique de l'ANSSI publie régulièrement des guides à jour sur tous les aspects de la sécurité des systèmes d'information. Disponibles gratuitement sur ssi.gouv.fr.
  • NIST Cybersecurity Framework — Référentiel international structurant la gestion des risques cyber en 6 fonctions. Version 2.0 publiée en 2024, disponible sur nist.gov.
  • MITRE ATT&CK — Base de connaissances des techniques adversariales, régulièrement mise à jour avec les nouvelles menaces observées dans le monde réel.

Formation continue

  • Certifications professionnelles reconnues : CISSP, CISM (management), OSCP, CEH (technique)
  • Plateformes de formation pratique : HackTheBox, TryHackMe, Hack The Box Academy
  • Veille quotidienne : bulletins CERT-FR, alertes CISA, flux RSS NVD

Mise en réseau professionnel

La communauté cybersécurité française est active et ouverte : les clubs RSSI, l'OSSIR, le CLUSIF, et les conférences comme le FIC (Forum International de la Cybersécurité) et les SSTIC sont des points de rencontre essentiels pour les professionnels du secteur. Ces échanges permettent de rester à jour sur les menaces émergentes et les bonnes pratiques réelles.

Mise en œuvre pratique : étapes et livrables

La conformité réglementaire génère une documentation substantielle qui doit être maintenue à jour et accessible lors des audits. Une organisation structurée de ces livrables simplifie considérablement les exercices de conformité et réduit le temps consacré à leur préparation.

Livrables documentaires essentiels

Quel que soit le référentiel de conformité concerné, les livrables fondamentaux incluent : un registre des traitements (obligatoire RGPD, utile pour tout SMSI) maintenu par le DPO ou le RSSI ; une politique de sécurité de l'information (PSI ou PSSI) approuvée par la direction et diffusée à tous les collaborateurs ; des procédures opérationnelles documentées pour les processus critiques (gestion des incidents, accès privilégiés, sauvegardes) ; un plan de continuité d'activité (PCA) testé annuellement ; et des rapports d'audit internes et de revue de direction formalisés. Ces documents constituent le «squelette» du SMSI et sont systématiquement vérifiés lors des audits de certification.

Gouvernance et responsabilités

La conformité réglementaire est un effort collectif qui ne peut pas reposer uniquement sur le RSSI ou le DPO. Une gouvernance efficace définit clairement les rôles : le COMEX assume la responsabilité globale de la conformité (risque financier et réputationnel) ; les DSI et RSSI mettent en œuvre les mesures techniques ; les métiers identifient les données et processus critiques à protéger ; et les DPO/compliance officers assurent la cohérence réglementaire. Les comités de sécurité trimestriels, impliquant toutes ces parties prenantes, garantissent l'alignement entre les exigences réglementaires et les capacités opérationnelles de l'organisation. Le suivi des actions de remédiation dans un outil de GRC (Governance, Risk & Compliance) formalise ce processus et facilite la production des preuves d'audit.

Sanction et contrôle : ce que les autorités vérifient

Comprendre les priorités de contrôle des autorités de régulation permet aux organisations de concentrer leurs efforts sur les domaines qui font l'objet d'une surveillance accrue. Les autorités de supervision (CNIL, ANSSI, ACP pour le secteur bancaire, HAS pour le secteur santé) publient régulièrement leurs priorités de contrôle.

Priorités de contrôle 2025-2026

Les domaines prioritaires identifiés par les autorités françaises pour 2025-2026 : la sécurité des données de santé (contrôles HDS en forte augmentation suite aux incidents hospitaliers) ; l'IA et le traitement des données personnelles (CNIL a annoncé 300 mises en demeure liées à l'IA en 2025) ; les sous-traitants et tiers (vérification des DPA et des audits de sécurité des fournisseurs) ; et la notification des violations de données dans les délais légaux (72h RGPD, 24h NIS 2 pour les entités essentielles). Les organisations qui documentent proactivement leur conformité dans ces domaines réduisent significativement leur exposition aux sanctions et bénéficient généralement d'une procédure d'audit moins contraignante.

Programme de préparation aux audits

Un programme structuré de préparation aux audits réduit le stress et améliore les résultats. Douze mois avant un audit de certification : gap analysis interne pour identifier les non-conformités. Six mois avant : corrections des écarts majeurs et préparation de la documentation. Trois mois avant : audit blanc interne conduit par un consultant externe indépendant. Un mois avant : formation des équipes sur les procédures et livrables à présenter. Cette approche systématique, validée par des centaines d'organisations certifiées ISO 27001, transforme l'audit de certification d'une épreuve redoutée en une validation formelle d'un travail déjà accompli.

Bonnes pratiques et recommandations complémentaires

Au-delà des techniques et outils présentés dans cet article, plusieurs principes transverses guident les professionnels de la cybersécurité dans leur approche quotidienne. La défense en profondeur (defense-in-depth) reste le principe fondateur : aucune mesure de sécurité unique n'est suffisante, et la multiplication des couches de protection — même imparfaites individuellement — crée une résilience globale supérieure à la somme de ses parties.

Veille et mise à jour continue

La cybersécurité est un domaine où l'obsolescence est rapide. Une technique ou un outil efficace en 2024 peut être contourné en 2026. Les équipes sécurité maintiennent leur efficacité en s'appuyant sur des sources de veille fiables : bulletins CERT-FR et ANSSI, advisories des éditeurs (Microsoft MSRC, Google Project Zero, Cisco Talos), recherches académiques (USENIX Security, IEEE S&P, CCS), et publications de la communauté (threat intel reports des grands éditeurs, articles de blog de chercheurs reconnus).

Documentation et partage de connaissances

La capitalisation des connaissances est un enjeu organisationnel critique dans les équipes de sécurité. Les runbooks d'investigation, les post-mortems d'incidents, les procédures de réponse documentées, et les bases de connaissance internes permettent de maintenir la cohérence des pratiques indépendamment des rotations d'équipe et de réduire le temps de résolution des incidents récurrents. L'utilisation d'un wiki sécurisé (Confluence, Notion avec contrôles d'accès stricts) pour centraliser ces connaissances est une pratique adoptée par la majorité des équipes SOC matures. La documentation proactive, rédigée juste après les incidents pendant que les détails sont frais, est systématiquement plus précise et utile que la documentation rédigée après coup.

Points d'attention avancés pour les auditeurs et RSSI

Au-delà de la conformité de surface, les auditeurs expérimentés et les RSSI cherchent à évaluer la robustesse réelle du dispositif de sécurité. Ce niveau d'analyse requiert de dépasser la vérification documentaire pour s'intéresser à l'efficacité opérationnelle des contrôles.

Pièges courants dans les audits de conformité

Plusieurs patterns d'échec reviennent régulièrement lors des audits de renouvellement. La conformité sur papier sans effectivité opérationnelle : des politiques formalisées mais non appliquées, des procédures documentées mais inconnues des équipes, des contrôles déclarés actifs mais non supervisés. La dérive post-certification : les organisations qui traitent la certification comme une fin en soi plutôt que comme un jalons d'un processus continu connaissent systématiquement une dégradation de leur posture sécurité entre deux audits. La gestion insuffisante des tiers : plus de 60% des violations impliquent un fournisseur ou un prestataire, mais les contrats de sous-traitance et les audits tiers sont souvent les parents pauvres des programmes de conformité. Adresser ces trois points avant l'audit réduit significativement le risque de non-conformité majeure.

Métriques de maturité à présenter en audit

Les auditeurs modernes s'intéressent aux indicateurs de fonctionnement réel du SMSI plutôt qu'à la simple existence des documents. Préparer : statistiques de gestion des incidents sur 12 mois (nombre, délai de traitement, taux de récidive) démontrant une amélioration continue ; résultats des exercices de continuité avec les actions correctives entreprises ; données de sensibilisation (taux de participation aux formations, taux d'échec aux simulations de phishing) ; et résultats des audits internes avec suivi des actions de remédiation. Ces métriques transforment l'audit en démonstration de la maturité de l'organisation plutôt qu'en exercice de conformité documentaire, et constituent la meilleure défense contre les questions inattendues des auditeurs sur l'efficacité opérationnelle des contrôles.