Métier malware analyst - Outils, workflow et méthodologie

Un malware analyst prend des samples suspects (binaires Windows, APK Android, IPA iOS, scripts, documents Office avec macros) et en extrait l'intelligence opérationnelle : que fait ce code, comment, contre qui, pour qui, quoi faire. Ce guide couvre le métier sous l'angle technique et méthodologique : workflow quotidien, outils de référence 2026 (Ghidra, IDA Pro, Cuckoo, YARA, Volatility), lab setup, phases d'analyse statique puis dynamique, écriture de rapports, intégration threat intel. Complémentaire à qu'est-ce qu'un malware analyst qui traite le parcours carrière et les salaires.

1. Ce que fait un malware analyst au quotidien

1.1 Les 5 missions typiques

1. Triage : un sample arrive (via SOC, IR, CTI, partenaire). Décider rapidement s'il mérite analyse approfondie.
2. Static analysis : extraire info du binaire sans l'exécuter (strings, sections, imports, hash, metadata).
3. Dynamic analysis : exécuter en sandbox contrôlée, observer comportement (syscalls, network, file I/O, registry).
4. Reverse engineering : si nécessaire, désassembler/décompiler pour comprendre la logique interne.
5. Rapport et partage : produire un document qui transforme l'analyse en valeur opérationnelle (IoCs, TTPs MITRE ATT&CK, YARA rules, détection, remédiation).

1.2 Contextes de travail

Les malware analysts opèrent dans plusieurs contextes :

• Vendor AV/EDR : CrowdStrike, Microsoft Defender, Kaspersky, ESET, Malwarebytes — analyse en masse pour alimenter les moteurs de détection.
• CERT / CSIRT : ANSSI, CERT-FR, CERT-US, CERT sectoriels. Analyse incidents publics et privés.
• Incident Response (IR) : firmes spécialisées (Mandiant, CrowdStrike Services, KPMG, PwC) qui interviennent sur incidents clients.
• CTI (Cyber Threat Intelligence) : Recorded Future, Mandiant, Flashpoint, SentinelOne. Attribution, tracking acteurs.
• SOC interne : grandes entreprises avec équipe dédiée malware analysis.
• Éditeurs de sécurité offensifs : red teams qui étudient les malwares pour s'en inspirer.
• Recherche académique : labs universitaires, entreprises R&D.

1.3 Temporalité et pression

• Malware triage : quelques minutes à 1h par sample.
• Analyse approfondie standard : 1-3 jours.
• Analyse approfondie d'un APT sophistiqué : semaines à mois.
• Campagne nouvelle (0-day, ransomware majeur) : 24/7 pendant quelques jours.

La pression opérationnelle est élevée en contexte IR (incident en cours chez un client) et en contexte vendor (nouveaux samples chaque heure).

2. Phases d'analyse - le workflow canonique

2.1 Phase 1 - Triage (30 min max)

Objectif : estimation rapide sans exécuter le sample.

Outils et actions :

• Hash : SHA-256 du binaire. Chercher sur VirusTotal, MalwareBazaar, Any.Run, Hybrid Analysis.
  • Si connu avec classification claire : triage rapide, passer à la remédiation.
  • Si inconnu : analyse requise.
• Type de fichier : file binary.exe, pefile, exiftool.
• Taille et structure : anomalies (exe gonflé, sections trop petites).
• Imports/API calls (statiques, avant exécution) : signatures typiques de familles.
• Strings : URLs, IPs, paths, bitcoin addresses.
• Compilation metadata : timestamp PE (souvent falsifié mais parfois révélateur), PDB path.

Résultat : hypothèse initiale sur la famille (ransomware ? loader ? infostealer ?) et priorisation.

2.2 Phase 2 - Static analysis

Analyse du binaire sans exécution. Plus sûr (pas d'infection possible) mais limité par l'obfuscation.

Outils principaux :

• Ghidra (NSA, open source) : désassembleur + décompilateur. Devenu référence depuis 2019.
• IDA Pro (Hex-Rays) : commercial, longtemps dominant, plus rapide sur certains binaires.
• Binary Ninja : commercial, IL (Intermediate Language) élégant.
• radare2 / Cutter : open source CLI + GUI.
• PEStudio (Windows PE) : extraction rapide des signes suspects.
• Detect It Easy (DiE) : identifier packers/obfuscators.
• Strings + FLOSS (FireEye) : extraction de strings y compris obfusquées.
• CAPA (Mandiant) : détection de capabilities (persistence, credential access, C2) par pattern matching.
• YARA : règles sur patterns binaires.

Workflow typique :

1. Ouvrir dans Ghidra.
2. Identifier les imports critiques : VirtualAlloc, CreateRemoteThread, WinExec, InternetConnectW, RegSetValueEx, CryptEncrypt.
3. Examiner les strings extraites.
4. Chercher les fonctions "main" ou entry points suspects.
5. Décompiler les fonctions critiques.
6. Noter les IoCs (URLs, domains, mutex names, registry keys).

Challenges :

• Packers (UPX, ASPack, Themida, VMProtect, Enigma) : binaire chiffré/compressé, nécessite unpacking avant.
• Obfuscation : control flow flattening, string encryption, junk code.
• Anti-disassembly : tricks qui empêchent les outils de désassembler correctement.

2.3 Phase 3 - Dynamic analysis

Exécution du sample dans un environnement contrôlé et instrumenté pour observer son comportement réel.

Sandbox d'analyse :

• Cuckoo Sandbox / CAPE Sandbox (fork améliorable) : open source, déployable localement.
• ANY.RUN : sandbox cloud interactive, très populaire.
• Joe Sandbox : commercial, très détaillé.
• Hatching Triage : moderne, rapide, bon free tier.
• Hybrid Analysis (CrowdStrike) : cloud, gratuit avec limites.

Ce qu'on observe :

• Processus créés (process tree).
• Fichiers écrits (notamment dans %AppData%, %Temp%, System32, StartUp).
• Registry keys (persistence, config).
• Network traffic : DNS, HTTP(S), C2 beacons.
• Syscalls : instrumentation via Windows ETW, WinAPI monitoring.
• Mutex créés (signature de famille).
• Injections dans d'autres processus.

Outils runtime complémentaires :

• Process Hacker / Process Explorer (Sysinternals) : exploration runtime interactive.
• Procmon : enregistre tous les accès filesystem et registry.
• Wireshark / tcpdump : capture réseau.
• Fakenet-NG : simule internet pour observer le C2 sans le laisser atteindre ses serveurs.
• FakeDNS : intercepte les résolutions DNS.
• INetSim : simule de nombreux services réseau.

Règle sécurité : l'analyse dynamique se fait toujours dans un lab isolé (VMs dédiées, pas de credentials corporate, pas d'accès au réseau interne, snapshot avant chaque analyse).

2.4 Phase 4 - Reverse engineering approfondi

Pour les samples sophistiqués (APT, ransomware custom, nouvelles familles), triage + sandbox ne suffisent pas.

Workflow :

• Débogage dynamique avec x64dbg / OllyDbg (Windows) ou gdb/LLDB (Linux).
• Décompilation approfondie dans Ghidra/IDA.
• Unpacking manuel si packer non automatisable.
• Analyse du C2 : reverse du protocole, identification des paramètres, extraction de clés crypto.
• Analyse des algorithmes : chiffrement custom, compression, encodage.
• Yara rules écrites pour détecter la famille.

Compétences requises :

• x86/x64 assembly read/write (ou ARM pour mobile).
• Windows internals : PE format, loader, WinAPI, syscalls, structures PEB/TEB.
• Cryptographie appliquée (reconnaître AES, RC4, XOR rolling, custom schemes).
• Network protocols (HTTP, TLS, custom binary protocols).
• Anti-analysis : VM detection (CPUID, registry checks), anti-debug (IsDebuggerPresent, PEB BeingDebugged), timing attacks.

Les reverses approfondis peuvent prendre semaines. C'est là que les profils seniors apportent le plus de valeur.

2.5 Phase 5 - Memory forensics (si applicable)

Si le sample opère principalement en mémoire (fileless malware, packed samples qui ne touchent pas le disque en clair), la memory analysis devient critique.

Outils :

• Volatility 3 : framework open source de référence, Python.
• Rekall (Google, déprécié mais toujours utilisable).
• MemProcFS : memory analysis via file system interface.

Workflow :

1. Capture mémoire de la machine infectée (via DumpIt, FTK Imager, LiME sous Linux).
2. Volatility avec plugins : pstree, netscan, malfind, dlllist, cmdline, handles, svcscan.
3. Extraction des payloads cachés en mémoire.
4. Reverse sur les payloads extraits.

Utile quand le malware est packed on-disk mais unpacked en mémoire (cas très fréquent).

2.6 Phase 6 - Rapport et diffusion

Un malware analysis sans rapport n'apporte aucune valeur. Le rapport est le livrable.

Composantes :

• Executive summary : 1 page, lisible par un RSSI/manager.
• Technical analysis : détails techniques complets.
• IoCs (Indicators of Compromise) : hashes, URLs, IPs, domains, mutex, registry keys, file paths.
• TTPs (MITRE ATT&CK mapping) : techniques utilisées (ex. T1055 Process Injection, T1547 Registry Run Keys, T1486 Data Encrypted for Impact).
• YARA rules : règles pour détecter la famille.
• Sigma rules : règles de détection pour SIEM.
• Snort/Suricata signatures : détection réseau.
• Remédiation : actions pour nettoyer les machines infectées.

Format typique : Markdown ou Word, partagé via MISP, ThreatConnect, ou email signé.

3. Outils de référence 2026

3.1 Reverse engineering et désassembleurs

3.2 Debuggers

3.3 Analyse statique spécialisée

3.4 Sandboxing

3.5 Detection et threat intel

3.6 Memory forensics

3.7 Mobile

4. Lab setup

4.1 Architecture type

Un lab malware analysis typique :

• Host : machine physique Windows/Linux/macOS avec hyperviseur (VMware, VirtualBox, QEMU, Hyper-V, Proxmox).
• VMs d'analyse : snapshots fréquents, restauration rapide.
  • Windows 10/11 (victim typique).
  • Linux (Debian, Ubuntu pour ELF).
  • macOS optionnel (Mach-O).
  • Android x86 virtuel ou Genymotion.
• VM "INetSim" : simule internet (DNS, HTTP, SMTP, FTP, etc.).
• Réseau isolé : hostonly ou internal network, pas de NAT ou bridged.
• Outils installés sur chaque VM : Ghidra, x64dbg, Wireshark, Process Hacker, Procmon, etc.

4.2 Précautions de sécurité

• Aucun accès réseau externe depuis les VMs d'analyse.
• Pas de credentials réels stockés dans les VMs.
• Snapshots avant chaque analyse, rollback systématique après.
• Données sensibles jamais partagées entre host et VMs (bi-directionnel clipboard désactivé, shared folders limités).
• Analyse APT : envisager un host physique dédié air-gap pour éviter compromis de l'hyperviseur (VM escape).

4.3 Lab moderne - FLARE VM, REMnux

• FLARE VM (Mandiant) : distribution Windows préconfigurée avec tous les outils d'analyse. Gratuite, installation automatisée.
• REMnux : équivalent Linux (Ubuntu-based), outils d'analyse pré-installés. Gratuit, par Lenny Zeltser.
• SIFT Workstation (SANS) : DFIR + malware analysis, Ubuntu-based.

Ces distributions évitent des jours de setup manuel et sont mises à jour régulièrement.

4.4 Détection d'anti-analysis

Beaucoup de malwares détectent qu'ils sont en VM/sandbox et changent de comportement (dormant, benign, evasive). Techniques de mitigation :

• VMs durcies : retirer les "signes" évidents (VirtualBox Guest Additions, VMware Tools, registry keys spécifiques).
• Timing tricks : malwares qui mesurent le temps d'exécution d'instructions (Cuckoo peut émuler).
• User activity simulation : bouger la souris, ouvrir des fichiers récents.
• Bare metal analysis : exécuter sur hardware réel quand nécessaire.

Outils : al-khaser (vérifie les signes d'analyse), VMware-Hardened-Loader.

5. Familles de malware et spécificités

5.1 Ransomware

Objectif : chiffrement des fichiers pour rançon.

• Analyse : trouver l'algorithme crypto (souvent AES pour fichiers + RSA pour protection de clé), le schéma de gestion de clés (serveur C2, embedded key), l'extension ajoutée.
• Parfois : possibilité de décrypteur si faille dans l'implémentation.
• Cas historiques : WannaCry 2017 (kill switch), NotPetya 2017 (destructif), LockBit, BlackCat, Play, Conti.

5.2 RAT (Remote Access Trojan)

Objectif : contrôle à distance, espionnage.

• Analyse : protocole C2 (HTTP, HTTPS, DNS tunneling, custom binary), commandes supportées (shell, file upload/download, screenshot, keylogging), persistence (Run keys, scheduled tasks, services).
• Familles : njRAT, DarkComet, Remcos, AsyncRAT, QuasarRAT, nanoCore.

5.3 Infostealer

Objectif : exfiltrer credentials, cookies, tokens, crypto-wallets.

• Analyse : modules de stealing par application (Chrome, Firefox, Edge, Outlook, FileZilla, wallets crypto), mécanisme d'exfiltration (HTTP POST, Telegram bot, Discord webhook).
• Dominant en 2024-2026 : RedLine, Vidar, Raccoon, Lumma, StealC, LummaC2.

5.4 Loader / Dropper

Objectif : télécharger et exécuter d'autres payloads.

• Analyse : source du payload (URL hardcodée, chaîne chiffrée, C2), mécanisme d'injection (process hollowing, reflective DLL loading).
• Familles : SmokeLoader, Amadey, Bumblebee, IcedID.

5.5 Rootkit / Bootkit

Objectif : persistence profonde, dissimulation.

• User-mode rootkit : hooks d'API Windows.
• Kernel rootkit : drivers malveillants.
• Bootkit : infection du bootloader, UEFI (LoJax, MosaicRegressor, CosmicStrand, BlackLotus).
• Analyse très avancée, nécessite kernel debugging (WinDbg, kd).

5.6 Banking trojans

• Dormino, Ursnif, TrickBot, Emotet historique, maintenant fragmentés.
• Analyse : webinjects (manipulation DOM en temps réel), ATS (Automated Transfer Systems).

5.7 Mobile malware

Android : Anatsa, SharkBot, Cerberus, Hydra (banking), Pegasus/Predator (spyware).

iOS : principalement spyware ciblé (Pegasus, Predator via 0-days), plus difficile à analyser sans jailbreak.

Analyse : JADX/apktool pour Android, Hopper/Ghidra pour iOS, Frida pour instrumentation runtime.

6. Kill chain et MITRE ATT&CK mapping

6.1 Importance du mapping

Chaque analyse moderne produit un mapping MITRE ATT&CK. Voir MITRE ATT&CK expliqué.

Bénéfices :

• Vocabulaire commun pour dialoguer avec SOC, CTI, management.
• Détection : les TTPs s'intègrent dans les règles de détection.
• Threat intel : comparer avec des acteurs connus pour attribution.

6.2 Exemple de mapping - LockBit ransomware

6.3 Outils automatiques

• CAPA (Mandiant) : identifie les capabilities et les mappe sur ATT&CK.
• Triage reports : ANY.RUN, Joe Sandbox génèrent déjà le mapping.
• VirusTotal Intelligence : enrichit avec TTPs.

7. Écrire une règle YARA efficace

7.1 Structure de base

rule Example_Infostealer_Family {
    meta:
        author = "Jane Doe"
        date = "2026-04-26"
        description = "Detects ExampleStealer family"
        sample_hash = "sha256:abc123..."
        reference = "https://example.com/report"
    
    strings:
        $str1 = "GET /gate.php?user=" ascii
        $str2 = "ExampleStealer v2." ascii
        $hex1 = { 68 65 6c 6c 6f 00 [2-4] 77 6f 72 6c 64 }
        $api1 = "CryptGenKey" ascii
        $api2 = "BCryptEncrypt" ascii
    
    condition:
        uint16(0) == 0x5A4D and  // MZ header
        filesize < 5MB and
        2 of ($str*) and
        any of ($api*)
}

7.2 Bonnes pratiques

• Spécificité vs génericité : viser un équilibre. Trop spécifique = faux négatifs facilement (un byte différent et la rule ne matche plus). Trop générique = faux positifs.
• Meta : documenter la famille, date, auteur, sample de référence.
• Condition robuste : combiner plusieurs indicateurs pour éviter FP.
• Tester : valider contre une banque de samples connus avant déploiement.

7.3 YARA en CI

Pipeline typique :

1. Nouvelle règle écrite par analyst.
2. Test automatique contre corpus positif (samples connus) et négatif (goodware).
3. Si ratio FP/TP acceptable, déploiement dans EDR, SIEM, sandbox rules.

8. CTI - Cyber Threat Intelligence

8.1 Du sample au renseignement

Un malware analysis produit souvent des indices qui peuvent être exploités par la CTI :

• IoCs : hashes, IPs, domains, mutex.
• TTPs : comportements mappés ATT&CK.
• Attribution clues : strings révélatrices, timezones, langues, similarités avec autres samples.

8.2 Plateformes CTI

• MISP : standard open source pour partage d'indicateurs structurés.
• OpenCTI : plateforme orientée STIX 2.1, open source.
• ThreatConnect, Anomali, Recorded Future, Mandiant Advantage : commerciaux.
• ThreatFox, URLhaus (abuse.ch) : feeds publics.
• ISAC sectoriels : sharing entre orgs du même secteur.

8.3 Attribution

Un malware analyst senior contribue à l'attribution :

• Code similarities : comparaison avec binaries connus (via BinDiff, Diaphora, Karta).
• Infrastructure overlap : même domaines, même certificats TLS, mêmes hosts.
• TTP signatures : certains acteurs ont des préférences reconnaissables.
• Metadata : langues, timezones, strings oubliées.

Attribution est un art, pas une science. Les rapports sérieux communiquent les niveaux de confiance ("high confidence", "moderate confidence").

9. Compétences et formation

9.1 Base technique

• Assembly x86, x64, ARM : lecture fluide, écriture occasionnelle.
• Windows internals : PE, WinAPI, syscalls, loader, memory layout, PEB/TEB.
• Linux internals : ELF, syscalls, ptrace, /proc.
• Langages bas niveau : C, C++, parfois Rust (pour samples modernes).
• Scripting : Python (essentiel), PowerShell (AD), bash.
• Cryptographie appliquée : reconnaître AES, RC4, XOR rolling, custom.
• Réseau : HTTP, TLS, DNS, tunnelling techniques.

9.2 Lecture de code obfusqué

Compétence centrale. Techniques :

• Patience et méthodologie.
• Re-implémenter le deobfuscateur en Python.
• Utiliser FLOSS, unipacker, capemon pour automatiser.

9.3 Certifications utiles

• SANS FOR610 (GIAC Reverse Engineering Malware - GREM) : la référence.
• Offensive Security Exploit Developer (OSED) : côté offensif.
• eCRE (eLearnSecurity) : certification reverse engineer.
• CREST Certified Malware Reverse Engineer (CCMRE).

9.4 Ressources d'apprentissage

• Practical Malware Analysis (Sikorski, Honig) : la bible.
• The Art of Memory Forensics (Ligh, Case, Levy, Walters) : Volatility.
• Practical Binary Analysis (Dennis Andriesse).
• Windows Internals (Mark Russinovich) : référence Windows.
• Crackmes.one : challenges de reverse gratuits.
• Flare-On (Mandiant) : CTF annuel de reverse/malware.
• malware-traffic-analysis.net (Brad Duncan) : analyses détaillées publiques.

10. Éthique et aspects légaux

10.1 Possession de samples

Posséder et analyser des samples malware est légal dans un contexte professionnel ou de recherche dans la plupart des juridictions (France incluse). Conditions :

• Intention non-offensive (pas de déploiement malveillant).
• Conditions de stockage sécurisées (pas de diffusion accidentelle).
• Respect des obligations de divulgation (si sample observé en prod, notification possible).

10.2 Ce qui n'est pas autorisé

• Déployer le malware contre un système qu'on ne possède pas.
• Vendre le malware sans licence recherche.
• Republier le code source hors contexte professionnel (discussion grise).
• Utiliser les IoCs pour bloquer des tiers légitimes.

10.3 Disclosure responsable

Si tu découvres une vulnérabilité exploitée par le malware :

• Coordonner avec l'éditeur concerné (MSRC Microsoft, PSIRT Google, etc.).
• Période d'embargo typique 90 jours.
• Publication coordonnée dans les conférences (Black Hat, DEF CON, SSTIC, Troopers).

10.4 Attribution nuancée

Attribution publique sans preuves solides = risque juridique et diplomatique. Les vendors sérieux communiquent avec niveaux de confiance et séparent les faits des hypothèses.

11. Métriques et maturité

11.1 Pour un analyst individuel

• Samples analysés par mois : 20-50 en vendor, 5-10 en IR.
• Time to classify : minutes pour triage, heures pour analyse standard, semaines pour APT.
• YARA rules écrites : plusieurs par mois.
• Contributions publiques : blog posts, talks, samples partagés.

11.2 Pour une équipe

• Coverage : nouveaux samples détectés vs. échappés.
• Time to detection d'une nouvelle famille.
• Integration avec SOC : règles fournies et utilisées.
• Publications : thought leadership, crédibilité marché.

12. Évolution 2026 et au-delà

12.1 Tendances observées

• AI pour obfuscation : malwares qui utilisent LLMs pour générer des variantes uniques.
• AI pour analyse : CoPilot-style tools pour aider les analysts (CodeQL, Binary Ninja AI, Ghidra ML plugins).
• Fileless / LOLBins : utilisation d'outils légitimes Windows (PowerShell, WMI, certutil) pour malveillance → moins d'artefacts binaires à analyser.
• Mobile supply chain attacks : apps Play Store / App Store compromises.
• Post-quantum cryptography dans les ransomware modernes (prévention de déchiffrement futur).

12.2 Défis

• Volume : millions de samples uniques par jour. Automation devient essentielle.
• Sophistication : APT avec anti-analysis avancé, nécessitent des semaines d'analyse.
• Attribution : plus difficile avec commoditization du malware-as-a-service.

12.3 Compétences à développer

• AI/ML appliqué à l'analyse.
• Cloud-native malware (crypto-miners dans K8s, Lambda abuse).
• LLM prompt injection et sécurité IA.
• Supply chain : analyse de packages malveillants (npm, PyPI, Maven).

13. Verdict et posture Zeroday

Le malware analyst est un métier technique exigeant qui combine reverse engineering, systems programming, cryptographie appliquée, et méthodologie rigoureuse. La demande reste forte en 2026 : chaque organisation qui subit un incident a besoin d'analystes, chaque vendor d'AV/EDR en a besoin en masse, chaque CTI agency également. Profil rare et bien rémunéré : en France, malware analyst senior atteint 70-100 k€.

Pour un junior : commencer par maîtriser Ghidra et la static analysis, puis ajouter la dynamic analysis via Cuckoo. Pratiquer via crackmes, Flare-On, MalwareBazaar samples. Viser une première certification (GREM) en 18-24 mois.

Pour un senior : la valeur ajoutée est dans l'analyse approfondie d'APTs, la contribution publique (blog, talks, YARA rules), et l'articulation avec le CTI et le SOC. Le métier évolue vers plus d'automation et d'AI-assisted, il faut suivre.

Pour une organisation : avoir au moins un malware analyst interne devient de plus en plus la norme pour les orgs de grande taille. Pour les plus petites : partenariats avec des firmes de IR et vendors CTI.

Pour approfondir : qu'est-ce qu'un malware analyst pour le parcours carrière et les salaires, métier reverse engineer pour le rôle voisin, threat hunting définition pour l'articulation avec la chasse proactive, MITRE ATT&CK expliqué pour le framework de mapping, niveaux SOC L1/L2/L3 pour l'articulation avec les équipes SOC qui consomment les rapports.