Analyse de Shellcode : Techniques de Rétro-Ingénierie

Le shellcode est omniprésent dans les attaques modernes : il est le composant d'exécution des exploits de vulnérabilités mémoire (buffer overflow, use-after-free, type confusion), le payload initial des loaders de malware injectés via des macros Office ou des scripts PowerShell, et le mécanisme de chargement réflectif utilisé par les frameworks C2 pour déployer leurs implants en mémoire. La capacité à analyser le shellcode en profondeur permet de comprendre la chaîne d'exploitation complète, d'extraire les indicateurs de compromission et de développer des détections proactives. L'analyse mémoire forensique extrait fréquemment du shellcode depuis les régions RWX des processus compromis. L'unpacking de malware avancé révèle les shellcodes embarqués dans les packers multi-étapes. La rétro-ingénierie des C2 analyse les shellcodes stager de Cobalt Strike et Brute Ratel. Les techniques d'anti-analyse malware protègent les shellcodes avancés contre la détection et l'émulation. La documentation d'Unicorn Engine et les plugins speakeasy de Mandiant sont les outils de référence pour l'émulation de shellcode.

Désassemblage et identification structurelle

Le désassemblage du shellcode commence par le chargement du binaire brut dans Ghidra (format Raw Binary, processeur x86 ou x86:LE:64:default) ou l'utilisation de Capstone en Python pour un désassemblage programmable. L'identification de la structure du shellcode révèle les composants fonctionnels : le décodeur (boucle XOR, RC4, ou AES qui déchiffre le payload principal), le résolveur d'API (technique PEB walking qui localise les fonctions Windows en mémoire), le payload principal qui effectue les actions malveillantes (téléchargement, injection, exécution), et optionnellement un stager de seconde étape qui télécharge un implant plus complet depuis le serveur C2.

La technique PEB walking est le mécanisme fondamental de résolution d'API dans le shellcode. Comme le shellcode ne peut pas utiliser les imports PE normaux (il n'est pas un fichier PE), il parcourt les structures internes de Windows pour localiser les fonctions dont il a besoin : accès au PEB via le registre de segment FS (x86) ou GS (x64), parcours de la liste InMemoryOrderModuleList pour trouver kernel32.dll, puis parsing de l'Export Address Table de kernel32.dll pour localiser GetProcAddress et LoadLibraryA qui permettent ensuite de résoudre toute autre fonction Windows. Les hashes CRC32 ou djb2 des noms de fonctions permettent au shellcode de localiser les API sans stocker leurs noms en clair dans le code.

Décodage multicouche et extraction de payload

Les encodages multicouches protègent le payload du shellcode contre la détection par signature et l'analyse statique superficielle. L'encodage XOR single-byte est le plus simple : une boucle de quelques instructions déchiffre le payload en XOR avec une clé d'un octet. Les encodages plus avancés utilisent XOR multi-octets (clé de 4 à 32 octets), RC4 avec une clé dérivée du contexte d'exécution, ou AES-128/256 avec une clé embarquée. Les shellcodes sophistiqués implémentent un décodage en cascade où chaque couche de déchiffrement révèle la suivante, nécessitant l'exécution séquentielle de 3 à 5 décodeurs avant d'accéder au payload final.

Émulation avec Unicorn Engine et speakeasy

L'émulation avec Unicorn Engine exécute le shellcode dans un environnement entièrement simulé sans accès au système d'exploitation réel. Le script Python configure un espace mémoire virtuel, charge le shellcode, simule les structures Windows essentielles (PEB, TEB, Export Tables) et exécute le code instruction par instruction en enregistrant les accès mémoire et les valeurs des registres. Les breakpoints programmables arrêtent l'émulation aux points d'intérêt (après le décodage, avant l'appel aux API système) pour extraire le payload déchiffré en mémoire virtuelle. L'outil speakeasy de Mandiant étend Unicorn avec une simulation complète des API Windows qui permet l'émulation de shellcodes complexes utilisant les API réseau et fichier.

Signatures et détection proactive

Les patterns invariants du shellcode fournissent des signatures YARA robustes contre les variantes. Les séquences d'instructions de PEB walking (accès FS:[0x30] ou GS:[0x60], parcours InMemoryOrderModuleList), les boucles de hashing de noms de fonctions (constantes CRC32, rotations pour djb2), et les structures de décodage (boucle XOR avec compteur, setup RC4) sont des patterns qui persistent à travers les modifications cosmétiques du shellcode. Les signatures combinant un pattern de résolution API avec un pattern de décodage atteignent un taux de détection supérieur à 90% sur les variantes de la même famille de shellcode.

L'intégration dans le pipeline de détection déploie les signatures YARA sur les solutions endpoint (CrowdStrike, SentinelOne, Defender for Endpoint) et les sandboxes d'analyse (CAPE, Joe Sandbox) pour la détection automatisée. Les règles Suricata/Snort basées sur les patterns réseau des stagers de shellcode (téléchargement de la seconde étape) complètent les détections endpoint. Le monitoring des régions mémoire RWX dans les processus par les EDR, combiné avec les signatures YARA ciblant les patterns de shellcode, constitue la défense la plus efficace contre les attaques exploitant des vulnérabilités mémoire pour l'injection de shellcode.

Conclusion

L'analyse de shellcode par rétro-ingénierie est la compétence technique avancée qui permet de comprendre la chaîne d'exploitation complète et de développer des détections proactives. Le désassemblage, l'émulation avec Unicorn Engine et l'extraction des payloads multicouches transforment un fragment de code machine en intelligence actionnable pour la protection de l'organisation.

Analyse de malwares & rétro-ingénierie

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

Contacter un expert [email protected]

Développement de Signatures YARA pour Shellcodes Polymorphiques

La création de règles YARA efficaces pour la détection de shellcodes repose sur l'identification de patterns invariants qui persistent malgré le polymorphisme et les techniques de mutation. Les shellcodes x86 et x64 contiennent plusieurs classes de patterns exploitables : les séquences d'opcodes caractéristiques de la résolution dynamique de l'adresse de base kernel32.dll via le PEB (Process Environment Block), les chaînes de hachage utilisées pour la résolution des noms de fonctions API sans les importer explicitement, et les structures de bootstrap spécifiques aux stagers Metasploit, Cobalt Strike et Brute Ratel.

L'approche meta-signature cible les structures algorithmiques plutôt que les octets spécifiques. Un shellcode qui appelle GetProcAddress via hachage de chaîne utilise invariablement une boucle de calcul de hash avec un polynôme caractéristique — ce polynôme est plus stable que les opcodes environnants qui varient selon le compilateur et les options d'obfuscation. La combinaison d'une règle YARA sur la structure du calcul de hash avec une condition sur la taille du shellcode (généralement inférieure à 4 Ko pour les stagers) et l'entropie du code (élevée pour les shellcodes chiffrés) produit une règle à fort taux de détection et faible taux de faux positifs.

Les outils de validation des règles YARA sur des corpus de malwares sont indispensables avant le déploiement en production. VirusTotal Hunting permet de tester une règle sur la base de données de fichiers analysés et de mesurer son efficacité réelle sur des échantillons réels. La rétroconversion des samples positifs — analyse des shellcodes détectés par la règle pour confirmer qu'ils appartiennent bien à la famille ciblée — affine les règles et élimine les faux positifs. Un corpus de fichiers légitimes doit également être testé pour garantir l'absence de faux positifs sur des binaires de développement ou des shellcodes de tests d'intrusion autorisés.