Mobile, reverse & malware

Analyse statique vs dynamique : malware et reverse 2025

Analyse statique vs dynamique en malware analysis et reverse engineering : outils (Ghidra, IDA, Cuckoo, ANY.RUN), workflow, anti-analysis, stack 2025.

Naim Aouaichia
18 min de lecture
  • Analyse statique
  • Analyse dynamique
  • Malware analysis
  • Reverse engineering
  • Ghidra
  • Sandbox
  • YARA

En malware analysis et reverse engineering de binaires, l'analyse statique (examen sans exécution) et l'analyse dynamique (observation runtime) sont deux approches structurellement complémentaires qui se combinent systématiquement dans le workflow d'un analyst senior 2025. L'analyse statique repose sur des outils de disassembly + décompilationGhidra (NSA, Apache 2.0 2019, version 11.x en 2025), IDA Pro (Hex-Rays depuis 1990, décompilateur référence industrie), Binary Ninja (Vector 35 2016, intermediate language puissant), Radare2/Rizin (open-source CLI scriptable) — permettant d'extraire strings, imports, sections, compile timestamps, pseudo-code C décompilé, règles YARA de classification. L'analyse dynamique utilise des sandboxesANY.RUN (commercial SaaS interactif), CAPE Sandbox (open-source successeur Cuckoo), Joe Sandbox (enterprise forensics), Hybrid Analysis (Falcon Sandbox gratuit) — et des debuggers (x64dbg, WinDbg, OllyDbg legacy, GDB + peda/pwndbg) pour observer syscalls, API calls, network traffic PCAP, modifications registry/filesystem, dumps mémoire. Chaque approche a ses limites structurelles : la statique échoue sur le code packé/obfusqué (UPX trivial à unpack, Themida/VMProtect/WinLicense demandent des heures à semaines) ; la dynamique échoue sur le malware qui détecte le sandbox (anti-VM, anti-debug, sleep long, environment checks). Le workflow standard 2025 combine les deux en 5 phases : triage (VirusTotal, format, entropy), statique initiale (strings FLOSS, imports, Ghidra first pass), dynamique sandbox (CAPE/ANY.RUN, config extraction, MITRE ATT&CK tagging auto), statique approfondie (décompilation fonctions critiques, dump OEP unpacked, reconstruction IAT via Scylla), rapport (IoCs, TTPs, YARA/Sigma rules, partage MISP/OpenCTI). Durée typique : 1-4 jours-homme par sample moyen. Cet article détaille la différence avec SAST/DAST applicatif, les mécanismes et outils par approche, la matrice comparative forces/limites, la stack de référence 2025, le workflow combiné pas-à-pas, les techniques anti-analysis (anti-VM, anti-debug, packers) et leur contournement, les applications aux 3 contextes (malware, binaires, mobile), et l'automation à l'échelle via YARA rules + sandboxing cloud. Pour le contexte applicatif SAST/DAST/IAST, voir SAST vs DAST vs IAST. Pour le framework CTI et IoCs, CTI définition.

1. Définition et différence avec SAST/DAST applicatif

1.1 Analyse statique en malware analysis

Examen d'un binaire sans l'exécuter. Le fichier est examiné comme un artefact statique : headers de format (PE Windows, ELF Linux, Mach-O macOS, APK/DEX Android, IPA/Mach-O iOS), sections, imports, exports, ressources, certificats digitaux, strings extractibles, code désassemblé, code décompilé vers pseudo-C.

Objectifs : identifier la famille de malware, extraire les indicateurs de compromission (IoCs), comprendre les capacités théoriques, détecter les algorithmes crypto, localiser les constantes magiques.

1.2 Analyse dynamique en malware analysis

Exécution contrôlée du binaire dans un environnement isolé, observation du comportement runtime. Environnement typique : VM Windows 10/11 ou Linux bare metal isolée (pas de réseau prod, snapshots pour restauration, agents monitoring).

Objectifs : observer le comportement réel, capturer le traffic réseau C2, identifier les processus lancés, les fichiers droppés, les clés registry créées/modifiées, les mutex, les persistence mechanisms.

1.3 Vs SAST/DAST applicatif

DimensionSAST (AppSec)Statique malwareDAST (AppSec)Dynamique malware
InputCode sourceBinaire compiléWeb app en runtimeBinaire exécuté
Contrôle du codePropriétaireHostile (adversary)Propriétaire (app à tester)Hostile
ObjectifTrouver bugs à fixComprendre comportementTrouver vulns exploitablesObserver runtime behavior
OutilsSemgrep, CodeQL, SnykGhidra, IDA, Radare2ZAP, Burp ProCuckoo, ANY.RUN, x64dbg
ContexteDevSecOps shift-leftIncident response, CTISecurity testing pré-prodForensics, threat intel
Input typique.py / .java / .ts.exe / .dll / .apkhttps://example.commalware.exe
Durée typiqueSecondes-minutes (CI)Heures-joursHeuresMinutes-heures

Les disciplines partagent des concepts (graphe de contrôle de flux, flux de données) mais granularité et finalité radicalement différentes. Pour le pendant applicatif complet voir SAST vs DAST vs IAST.

2. Analyse statique : mécaniques et outils

2.1 Pipeline d'analyse statique standard

Pipeline analyse statique malware — étapes
───────────────────────────────────────────
 
1. IDENTIFICATION
   ├─ file sample.exe  → PE64, x86_64, console
   ├─ sha256sum        → hash pour VirusTotal / MISP
   ├─ DIE (Detect It Easy) / PE-bear → packer detection
   └─ PEframe, capa    → capabilities + anomalies
 
2. EXTRACTION SURFACE
   ├─ strings / FLOSS     → chaînes imprimables + unicode + stacked
   ├─ CFF Explorer        → PE headers, imports, exports, resources
   ├─ Sigcheck            → signatures digitales Microsoft
   └─ pescan              → pattern matching anomalies
 
3. ENTROPY & SECTIONS
   ├─ bintropy            → entropy par section
   │                         > 7.0 = probablement chiffré/packé
   │                         < 5.0 = normal compilé
   └─ pestudio            → score de risque par section
 
4. DÉSASSEMBLAGE
   ├─ Ghidra              → GUI + décompilateur multi-arch
   ├─ IDA Pro             → référence industrie Hex-Rays
   ├─ Binary Ninja        → IL puissant, scripting moderne
   └─ Radare2 / Rizin     → CLI scriptable, open-source
 
5. DÉCOMPILATION
   ├─ Ghidra decompiler   → pseudo-C multi-arch gratuit
   ├─ Hex-Rays (IDA)      → pseudo-C référence, commercial
   ├─ Binary Ninja HLIL   → intermediate high-level
   └─ RetDec (Avast)      → open-source, moins mature
 
6. CLASSIFICATION
   ├─ YARA rules          → signatures pattern matching
   ├─ capa                → high-level capabilities
   ├─ MAEC (Malpedia)     → taxonomie malware
   └─ Intezer Analyze     → code genetics (commercial)

2.2 Exemple concret — extraction strings FLOSS

FLOSS (FLARE Obfuscated String Solver, Mandiant FLARE team 2018+) extrait les strings classiques + les strings décodées dynamiquement par des stackstrings ou deobfuscation runtime :

# Installation FLOSS
pip install flare-floss
 
# Extraction strings avec decoding
floss sample.exe > strings_output.txt
 
# Output typique :
# ASCII strings (4+ chars):
#   CreateProcessW
#   kernel32.dll
#   http://attacker-c2-domain.tld/gate.php
#   Mozilla/5.0 (Windows NT 10.0; Win64; x64)
#
# Unicode strings:
#   C:\Users\Public\update.exe
#   RegSvcMutex_2024
#
# Stack strings (decoded):
#   Software\Microsoft\Windows\CurrentVersion\Run
#   powershell -nop -w hidden -EncodedCommand ...

2.3 YARA — classification statique à l'échelle

YARA (Victor Alvarez, VirusTotal, 2008) est le standard de facto pour écrire des règles de classification malware. Syntaxe déclarative qui matche bytes, strings, regex, conditions booléennes.

rule APT_SampleFamily_Loader_2024 {
    meta:
        author = "malware analyst"
        date = "2026-04-24"
        description = "Loader family X observed Q1 2024"
        reference = "https://example-report.tld/analysis"
        hash1 = "e19ccf75ee54e06b06a5907af13cef42a8b2cd1234567890abcdef1234567890"
 
    strings:
        // String unique à la famille
        $s1 = "MzNLoaderMutex_"
        $s2 = "Software\\Microsoft\\Windows\\CurrentVersion\\MzNLoader"
        $s3 = { 68 65 6C 6C 6F 5F 77 6F 72 6C 64 5F 73 74 61 67 65 31 }  // "hello_world_stage1" hex
 
        // Import DLL suspect
        $api1 = "VirtualAllocEx"
        $api2 = "WriteProcessMemory"
        $api3 = "CreateRemoteThread"
 
        // Payload decoder signature
        $decoder = { 48 8B ?? ?? 48 83 ?? ?? 48 89 ?? ?? E8 ?? ?? ?? ?? }
 
    condition:
        uint16(0) == 0x5A4D and          // DOS MZ header
        filesize < 5MB and
        all of ($s*) and
        2 of ($api*) and
        $decoder
}

YARA rules sont ingérées par VirusTotal, ClamAV, Cuckoo, CAPE, LOKI / Thor (Nextron), services SIEM (Elastic, Splunk).

3. Analyse dynamique : mécaniques et outils

3.1 Environnement d'exécution contrôlé

Architecture sandbox malware typique
─────────────────────────────────────
 
Host physique (analyst workstation ou serveur dédié)

  ├─ Hyperviseur (VMware / VirtualBox / QEMU-KVM)
  │   │
  │   └─ Guest VM vulnérable (Windows 10 typique)
  │       │  snapshot clean pre-infection
  │       │
  │       ├─ Agent monitoring
  │       │   ├─ Sysmon v15+ avec config SwiftOnSecurity
  │       │   ├─ Procmon (Sysinternals)
  │       │   ├─ API Monitor / Wireshark
  │       │   └─ Agent sandbox (Cuckoo, CAPE, Joe)
  │       │
  │       └─ Malware sample exécuté

  ├─ Network isolation
  │   ├─ Option 1 : réseau entièrement isolé, INetSim fake C2
  │   ├─ Option 2 : VPN sortant via TOR / serveur dédié monitoré
  │   └─ Option 3 : FakeNet-NG pour intercepter et répondre aux requêtes

  └─ Collecte logs
      ├─ PCAP réseau
      ├─ Events Windows (Sysmon, Security, Application)
      ├─ Changes registry / filesystem
      └─ Dumps mémoire périodiques (Volatility analyzable)

3.2 Stack outils dynamique 2025

OutilUsageLicence
x64dbgDebugger Windows x86/x64, plugins richesOpen-source
WinDbgDebugger Microsoft avancé (kernel + user)Microsoft gratuit
OllyDbg 2.0Debugger classique Windows (legacy)Gratuit (non-commercial)
GDB + peda/pwndbgDebugger Linux/ELF, avec extensionsOpen-source
FridaHooking dynamique multi-plateformeOpen-source, Ole André Vadla Ravnås
Process Monitor (Procmon)Activité registry + filesystem + processusSysinternals gratuit
Process Hacker / System InformerProcessus + handles + memoryOpen-source
WiresharkCapture + analyse réseauOpen-source
Fiddler Classic / EverywhereProxy HTTP/HTTPS pour intercept trafficGratuit/commercial
Cuckoo Sandbox / CAPESandbox automation self-hostedOpen-source
ANY.RUNSandbox interactive cloudCommercial SaaS
Joe SandboxAnalyse forensique avancéeCommercial
Hybrid Analysis / Falcon SandboxSandbox cloud gratuite CrowdStrikeGratuit (public)
Volatility 3Memory forensicsOpen-source Apache 2.0
FakeNet-NGFake C2 responderOpen-source Mandiant
INetSimSimulation services réseauOpen-source

3.3 Exemple concret — ANY.RUN analysis

Workflow ANY.RUN typique (3-10 minutes)
────────────────────────────────────────
 
1. Upload sample ou URL
2. Choisir OS target (Win 10, Win 7, Linux Ubuntu)
3. Démarrer analyse → VM live visible en streaming
4. Interagir si nécessaire (clic sur fichier, saisie credentials leurres)
5. Laisser tourner 5-10 min
6. Examiner résultats :
   ├─ Processus lancés avec CLI args
   ├─ Fichiers droppés (téléchargeable)
   ├─ Connexions réseau avec géoloc
   ├─ MITRE ATT&CK techniques taggées
   ├─ Indicators of compromise auto-extraits
   ├─ Video capture VM
   └─ Rapport exportable JSON/STIX

4. Matrice comparative : forces et limites

CritèreAnalyse statiqueAnalyse dynamique
Exécution requiseNonOui
Sécurité analystHaute (pas d'exécution)Moyenne (sandbox fait la barrière)
Détection comportement runtimeNonOui
Packé/obfusquéDifficile (nécessite unpack)Contournement naturel (exécute unpacké)
Polymorphe / metamorphicDifficile à signaturerObservable par TTPs
Anti-VM / anti-debugPeu affectéTrompable
Temps typique sample simple30 min - 2h10-30 min (sandbox auto)
Temps sample complexe10-80 h2-20 h
Couverture code100 % theoreticalBranches exécutées seulement
Crypto identificationExcellente (constants, S-boxes)Moyenne (via memory dump)
C2 extractionPossible si hardcodedAutomatique si connexion réelle
Automation à l'échelleYARA, capa, scriptsSandbox farm, API
Réutilisable (cold data)Oui (binaire persiste)Non (VM éphémère)
Anti-analysis mitigationPatching manuelMasquer VM, hypervisor stealth

Règle 2025 : les deux approches sont toujours combinées. Aucun malware analyst sérieux ne fait uniquement l'un ou l'autre.

5. Stack d'outils 2025 — vision complète

5.1 Statique — incontournables 2025

Stack statique malware analyst 2025
────────────────────────────────────
 
Identification / triage
  ├─ file + sha256sum                      [Linux natif]
  ├─ DIE (Detect It Easy) 3.x              [OSS GitHub horsicq]
  ├─ PE-bear                               [OSS hasherezade]
  ├─ CFF Explorer                          [gratuit Daniel Pistelli]
  └─ VirusTotal Intelligence                [commercial Google]
 
Extraction
  ├─ strings (GNU binutils)
  ├─ FLOSS (Mandiant FLARE)                [OSS, stackstrings decoder]
  ├─ pestudio Pro                          [commercial Marc Ochsenmeier]
  └─ capa (Mandiant FLARE)                 [OSS, capabilities ATT&CK]
 
Désassemblage / décompilation
  ├─ Ghidra 11.x                           [NSA OSS, référence 2025]
  ├─ IDA Pro 9 + Hex-Rays                  [commercial ~7000 $]
  ├─ Binary Ninja 4                        [commercial ~500-2000 $]
  └─ Radare2/Rizin + Cutter                [OSS, CLI + GUI]
 
Classification
  ├─ YARA 4.x + LOKI/Thor (Nextron)        [OSS + commercial]
  ├─ DIE signatures
  ├─ Intezer Analyze                       [commercial genetics]
  └─ Malpedia / MAEC                        [base taxonomique]

5.2 Dynamique — incontournables 2025

Stack dynamique malware analyst 2025
─────────────────────────────────────
 
Debugger
  ├─ x64dbg + plugins (Scylla, HyperDbg)   [OSS mrexodia + community]
  ├─ WinDbg Preview                         [Microsoft gratuit]
  ├─ GDB + pwndbg / peda                    [OSS]
  └─ Frida 16+                              [OSS]
 
Sandbox automated
  ├─ CAPE Sandbox (fork Cuckoo)             [OSS, self-hosted]
  ├─ ANY.RUN                                [commercial SaaS ~299 $/mois]
  ├─ Joe Sandbox                            [commercial ~10-50 k$/an]
  ├─ Falcon Sandbox / Hybrid Analysis       [gratuit public]
  └─ VMRay Analyzer                         [commercial enterprise]
 
Network
  ├─ Wireshark 4.x                          [OSS]
  ├─ tcpdump                                 [OSS]
  ├─ FakeNet-NG (Mandiant)                  [OSS fake services]
  ├─ INetSim                                 [OSS]
  └─ mitmproxy                              [OSS Python]
 
Memory forensics
  ├─ Volatility 3                            [OSS Python]
  ├─ Rekall (legacy Google)                 [OSS]
  └─ MemProcFS (Ulf Frisk)                  [OSS filesystem view]
 
Monitoring runtime
  ├─ Sysmon v15+ (Sysinternals)             [Microsoft gratuit]
  ├─ Procmon                                 [Sysinternals]
  ├─ Process Hacker / System Informer       [OSS]
  └─ API Monitor                             [gratuit rohitab.com]

6. Workflow combiné — 5 phases

6.1 Phase 1 — Triage (5-30 min)

# Hash + lookup VirusTotal
sha256sum sample.exe
# e19ccf75ee54e06b06a5907af13cef42a8b2cd1234567890abcdef1234567890
 
curl -s -H "x-apikey: $VT_API_KEY" \
    "https://www.virustotal.com/api/v3/files/e19ccf75ee54e06b06a5907af13cef42a8b2cd1234567890abcdef1234567890" \
    | jq '.data.attributes | {
        meaningful_name,
        type_description,
        first_submission_date,
        last_analysis_stats,
        sandbox_verdicts
    }'
 
# Format identification
file sample.exe
# sample.exe: PE32+ executable (GUI) x86-64, for MS Windows
 
# Packer detection
die sample.exe
# Protector: VMProtect (3.2+) [detected]

6.2 Phase 2 — Statique initiale (30 min - 2 h)

# Strings avec FLOSS
floss sample.exe --output-format json > strings.json
 
# Capabilities
capa sample.exe --rules-dir capa-rules
 
# Imports PE via pefile Python
python3 -c "
import pefile
pe = pefile.PE('sample.exe')
for entry in pe.DIRECTORY_ENTRY_IMPORT:
    print(f'[{entry.dll.decode()}]')
    for imp in entry.imports:
        print(f'  {imp.name.decode() if imp.name else hex(imp.ordinal)}')
"

6.3 Phase 3 — Dynamique sandbox (1-3 h)

Soumission à CAPE / ANY.RUN / Joe Sandbox. Attente 5-10 min par sample. Collecte :

  • Processus lancés + CLI.
  • Files droppés (hashes + paths).
  • Clés registry modifiées.
  • Traffic réseau PCAP + DNS résolutions.
  • Mutex créés.
  • MITRE ATT&CK techniques matchées.

6.4 Phase 4 — Statique approfondie (3-20 h)

Si packé : dump mémoire à OEP après exécution dynamique, reconstruction IAT via Scylla, ouverture du dump dans Ghidra.

Décompilation des fonctions critiques :

  • Entry point : WinMain, DllMain — flow global.
  • Crypto : identification algorithmes (AES, RC4, ChaCha20 via constants ou S-boxes), extraction keys.
  • C2 : URL parsing, request building, command dispatcher.
  • Persistence : registry Run keys, WMI subscriptions, scheduled tasks, services.
  • Payload decoder : souvent stage 2 chiffré/encodé.

6.5 Phase 5 — Rapport (2-5 h)

Livrables types :

Rapport d'analyse malware — structure standard
───────────────────────────────────────────────
 
1. Executive Summary (1-2 pages)
   Résumé pour direction / client
 
2. Sample metadata
   ├─ SHA256, MD5, SSDEEP
   ├─ File size, compile timestamp
   ├─ PDB path, language/compiler
   └─ First seen VT, samples similaires
 
3. IoCs (Indicators of Compromise)
   ├─ Hashes (SHA256, MD5)
   ├─ Network (IPs, domains, URLs, user-agents)
   ├─ Host (mutex, files created, registry keys)
   └─ Strings caractéristiques
 
4. TTPs MITRE ATT&CK
   Tableau techniques + sous-techniques observées
 
5. Analyse technique
   ├─ Flow global
   ├─ Crypto identifiée + clés si extractibles
   ├─ C2 protocol reverse engineered
   ├─ Persistence mechanisms
   └─ Anti-analysis observé
 
6. Règles de détection
   ├─ YARA rule
   ├─ Sigma rule
   └─ Suricata / Snort rule si réseau
 
7. Attribution (si possible avec haute confiance)
   Threat actor suspected, avec justification preuves
 
8. Références
   Samples similaires, rapports publics, papers

7. Anti-analysis — techniques et contournement

7.1 Anti-debug

TechniqueDétectionContournement
IsDebuggerPresent() / CheckRemoteDebuggerPresent()Appel API Win32Plugin ScyllaHide x64dbg
NtQueryInformationProcess() + flagsAPI undocumentedPlugin TitanHide kernel
PEB.BeingDebugged manipulationCheck mémoire PEBPatch PEB manuellement
PEB.NtGlobalFlagFlag 0x70 indique debugPatch
Hardware breakpoints detectionDR0-DR3 registersRetirer les HW breakpoints
Timing attack (GetTickCount, RDTSC)Délai anormal en debugPatch ou single-step rapide
SEH / VEH tricksException handlers exotiquesDebugger aware

7.2 Anti-VM / anti-sandbox

TechniqueDétectionContournement
Registry HKLM\HARDWARE\DESCRIPTION (VMware, VBox strings)Lecture registryPatch registry or hook
MAC address OUI checkVMware/VBox MAC prefixesRandomize MAC
Sleep long (> 30 min)Eviter timeout sandboxAccélérer time (WinDbg, hook Sleep)
Check CPU count, RAM totalSandbox souvent 1-2 CPU, 2-4 GBConfigure VM réaliste
User interaction requiredPas de souris movementANY.RUN interactive
Recent Files / Browser HistorySandbox viergePopulate VM
VBoxGuest / VMTools servicesCheck running servicesRemove or rename
CPUID hypervisor bitBit 31 eax=1Hypervisor hide (x64dbg plugin)
Timing discrepancies RDTSCHyperviseur slowerPatch timer

7.3 Packers et obfuscators

PackerAnnéeDifficulté unpacking
UPX1998Trivial (upx -d)
ASPack2001Facile, tutorials publics
Themida / WinLicense (Oreans)2003Difficile, 2-20 h manuel
VMProtect (Rusian Ingurgeev)2007Très difficile, VM custom semaines
Enigma Protector2011Moyen à difficile
Obsidium2003Moyen à difficile
Custom crypters (Babadeda, Formbook)VariableVariable selon version

8. Applications aux 3 contextes

8.1 Malware analysis

Cas d'usage dominant en incident response et CTI. Workflow 1-4 jours-homme par sample décrit section 6. Livrables : IoCs, TTPs, YARA, Sigma rules, rapport technique.

8.2 Reverse binaire / firmware

Similaire techniquement mais objectifs différents :

  • Audit produit tiers pour trouver vulnérabilités (bug bounty hardware, recherche 0-day).
  • Compréhension protocole propriétaire (inter-opérabilité, reverse API).
  • Firmware IoT / industriel : extraction via binwalk, analyse Ghidra ARM/MIPS, recherche backdoors.
  • Cartes à puce / Secure Elements : voir Carte à puce, JavaCard, APDU.

8.3 Mobile (Android / iOS)

Stack spécifique :

PlateformeStatiqueDynamique
Androidjadx, apktool, Ghidra Android module, MobSFFrida, Objection, Burp Proxy, Android Emulator
iOSGhidra / IDA Pro sur Mach-O, class-dump, HopperFrida, Objection, Corellium (commercial)
BothMobSF (MobSF unified framework)Appium + MobSF

Frida (Ole André Vadla Ravnås, 2013+) est l'outil dynamique central 2025 pour mobile reverse : injection JavaScript dans applications en cours, hook d'APIs, bypass SSL pinning, root/jailbreak detection.

9. Automation à l'échelle

9.1 YARA scanning à l'échelle

# Scan d'un répertoire de samples avec une règle
yara -r rules.yar /path/to/samples/
 
# Scan production via LOKI (Nextron, OSS)
python loki.py --path C:\ --rules-folder custom-rules/
 
# Scan enterprise via Thor (Nextron, commercial)
# Déployable via EDR agent, multi-thread, enriched

9.2 CAPE automation API

# Soumission automatisée à CAPE Sandbox self-hosted
import requests
 
CAPE_URL = "https://cape.example.com/apiv2"
API_KEY = "your_api_key_here_abc123def456"
 
files = {"file": open("sample.exe", "rb")}
data = {"package": "exe", "platform": "windows10x64", "timeout": 300}
headers = {"Authorization": f"Token {API_KEY}"}
 
response = requests.post(
    f"{CAPE_URL}/tasks/create/file/",
    files=files,
    data=data,
    headers=headers,
)
task_id = response.json()["data"]["task_ids"][0]
 
# Poll status jusqu'à complétion puis récupération rapport JSON

9.3 Pipeline CTI automatisé

Pipeline automation analyse malware enterprise 2025
────────────────────────────────────────────────────
 
Email attachment / download → Detection EDR (CrowdStrike, SentinelOne)


                           Extraction automatique sample


                        Soumission parallèle :
                        ├─ VirusTotal API
                        ├─ CAPE self-hosted
                        └─ ANY.RUN (paid slots)


                        YARA scan avec règles internes


                        Extraction IoCs automatique


                        Enrichissement MISP / OpenCTI


                        Auto-publication indicators
                        vers SIEM / EDR / firewall


                        Alerte équipe CTI si high-confidence
                        malware family identified

Pour l'articulation avec CTI, voir CTI définition. Pour le contexte détection, Détection d'intrusion : les bases.

10. Points clés à retenir

  • Statique = analyse sans exécution : strings, imports, disassembly (Ghidra/IDA/Binary Ninja/Radare2), décompilation, YARA classification.
  • Dynamique = exécution contrôlée sandbox : comportement runtime, API calls, network traffic, memory dumps, MITRE ATT&CK tagging.
  • Vs SAST/DAST AppSec : concepts similaires, outils différents, contextes opposés (code propriétaire vs binaire hostile).
  • Stack 2025 statique : Ghidra (OSS, référence 2025 pour 80 % cas), IDA Pro (commercial premium), Binary Ninja (IL moderne), Radare2 (OSS CLI), + FLOSS + capa + YARA.
  • Stack 2025 dynamique : CAPE (OSS self-hosted), ANY.RUN (SaaS interactif ~299 $/mois), Joe Sandbox (enterprise forensics), x64dbg (debugger Windows), Frida (hooking cross-platform).
  • Workflow combiné 5 phases : triage (5-30 min) → statique initiale (30 min-2 h) → dynamique sandbox (1-3 h) → statique approfondie (3-20 h) → rapport (2-5 h). Total 1-4 jours-homme par sample moyen.
  • Anti-analysis : anti-debug (IsDebuggerPresent, PEB flags), anti-VM (registry strings, MAC, CPU count), packers (UPX trivial → VMProtect semaines). Arms race permanente justifiant budgets CTI 100-500 k€/an.
  • Applications 3 contextes : malware analysis (CTI / IR), reverse binaire/firmware (audit, bug bounty), mobile Android/iOS (Frida + Objection + MobSF).
  • Automation : YARA enterprise (LOKI / Thor), CAPE API, pipeline CTI intégré EDR → VirusTotal → CAPE → MISP/OpenCTI → SIEM.

Pour le pendant applicatif voir SAST vs DAST vs IAST. Pour le framework CTI structuré, CTI définition. Pour le contexte détection SOC, Détection d'intrusion : les bases. Pour le reverse de secure elements hardware, Carte à puce, JavaCard, APDU. Pour la désérialisation comme vecteur récurrent dans malware Java/.NET, Désérialisation insecure.

Questions fréquentes

  • Quelle différence entre analyse statique et dynamique pour un malware ?
    Deux approches complémentaires pour comprendre un malware. Analyse statique : examen du binaire sans l'exécuter — strings, imports PE/ELF, sections, entropy, disassembly avec Ghidra / IDA Pro / Binary Ninja / Radare2, décompilation vers pseudo-code C, règles YARA pour classification. Révèle structure, algorithmes, chaînes de caractères indicatives, fonctions importées, mais manque le comportement runtime si code chiffré/packé. Analyse dynamique : exécution contrôlée dans sandbox (Cuckoo, CAPE, ANY.RUN, Joe Sandbox) ou debugger (x64dbg, WinDbg), observation des syscalls, appels API, traffic réseau, modifications registry/filesystem, dumps mémoire. Révèle le comportement réel, mais peut être trompée par anti-analysis (anti-VM, anti-debug, sleep long). Stack 2025 = combinaison systématique des deux, selon un workflow triage → statique rapide → dynamique sandbox → statique approfondi post-dump → corrélation.
  • Analyse statique vs SAST applicatif : c'est la même chose ?
    Conceptuellement oui (examen sans exécution), pratiquement non en termes d'objectifs et outils. SAST (Static Application Security Testing — Semgrep, CodeQL, Snyk Code, Checkmarx) analyse du code source applicatif qu'on développe soi-même pour détecter vulnérabilités (SQL injection, XSS, déserialisation insecure) avant déploiement. Contexte : shift-left DevSecOps. Analyse statique malware analyse un binaire compilé qu'on ne contrôle pas pour comprendre son comportement (family, capabilities, C2 servers, IoCs). Contexte : incident response, threat intelligence, reverse engineering. Stack outils distinct : Semgrep/CodeQL pour SAST code source, Ghidra/IDA/Radare2 pour statique binaire. Les deux disciplines partagent des concepts (graphe de contrôle de flux, analyse de flux de données) mais avec granularité, format input et finalité radicalement différentes.
  • Pourquoi utiliser Ghidra plutôt qu'IDA Pro en 2025 ?
    Deux leaders en disassembler/décompilateur avec des profils distincts. Ghidra (NSA, publié 2019 open-source Apache 2.0) : gratuit, scripts Python et Java, décompilation native multi-architectures (x86, ARM, PowerPC, MIPS, RISC-V, plus exotiques), courbe d'apprentissage modérée, interface moderne plus que IDA classique. Version 11.x en 2025, commits actifs équipe NSA + communauté. IDA Pro (Hex-Rays, depuis 1990) : commercial (~7000 $ licence + ~1800 $/an maintenance), décompilateur Hex-Rays référence industrie, support loader/format très large, plugins historiques FLIRT, scripts IDAPython. Version 9 en 2025. Binary Ninja (Vector 35, 2016) : alternative commerciale (~500-2000 $) avec intermediate language LLIL/MLIL/HLIL puissant. Radare2/Rizin : open-source pur CLI, courbe difficile mais très scriptable. Choix pragmatique 2025 : Ghidra par défaut pour 80 % cas d'usage open-source, IDA Pro si budget + besoins pro (loaders exotiques, plugins commerciaux), Binary Ninja pour scripting moderne, Radare2 pour CI/CD automation.
  • ANY.RUN vs Cuckoo Sandbox vs CAPE : lequel pour quoi ?
    Trois approches de sandboxing avec trade-offs distincts. ANY.RUN (commercial SaaS, ~109-299 $/mois) : interactive cloud sandbox, l'analyste voit l'écran en live et peut interagir (clics, saisies) — crucial pour malware interactif type banker qui attend pattern utilisateur. Résultats MITRE ATT&CK tagués automatiquement, partage public de samples. Cuckoo Sandbox (open-source, Python 2 legacy, déprécié 2020 par projet officiel mais forks actifs) : self-hosted, API programmable, intégration SIEM. Complexité maintenance élevée. CAPE Sandbox (fork actif de Cuckoo, Kevin Ross, open-source) : successeur de facto de Cuckoo, Python 3, features modernes (config extraction, memory dumping automatique), intégration VirusTotal. Joe Sandbox (commercial, 10-50 k$/an) : leader analyse approfondie entreprise, détection anti-VM robuste. Pattern 2025 : ANY.RUN pour quick analysis interactive, CAPE self-hosted pour automation privée, Joe Sandbox pour analyses forensiques avancées.
  • Les packers comme UPX, Themida, VMProtect rendent-ils l'analyse impossible ?
    Non, mais ils augmentent significativement le temps d'analyse. UPX (Ultimate Packer for Executables, open-source) : packer générique, unpacking trivial avec 'upx -d' ou breakpoint sur l'OEP après trampoline — accessible débutant. Themida et WinLicense (Oreans) : commercial premium, obfuscation avancée avec VM customs, anti-debug multiple, recycling de code, anti-VM. Unpacking manuel peut prendre 2-20 heures selon version. VMProtect (commercial, Rusian Ingurgeev) : virtualisation bytecode custom qui transforme chaque instruction en séquence d'opérations dans une VM interne, unpacking exige désassemblage manuel de la VM (reverse engineering de l'interpréteur) — travail de semaines. Mitigation pratique 2025 : dynamique d'abord pour observer comportement en dépit du packer, dump mémoire à OEP unpacked, puis statique sur le dump. Outils : Scylla pour reconstruction IAT, debugger x64dbg avec plugins UnpacMe ou UnPackMe. Certains malware (Emotet, TrickBot historiques, Bumblebee) emploient plusieurs couches de packing successives.
  • Comment construire un workflow combiné statique + dynamique en 2025 ?
    Workflow standard incident response / threat intelligence en 5 phases. Phase 1 triage (5-30 min) : hash SHA256, VirusTotal lookup, file format identification (file, PE-bear, DIE), entropy. Phase 2 statique initiale (30 min-2h) : strings imprimables + unicodes (FLOSS tool), imports PE, sections, compile timestamp, PDB path, signatures digitales, premier pass Ghidra/IDA sur les fonctions importantes (WinMain, DllMain, entry point). Phase 3 dynamique sandbox (1-3h) : CAPE/ANY.RUN/Joe Sandbox avec 5-10 min runtime, capture network PCAP, extraction config C2 auto si supporté, behavioral tags MITRE ATT&CK. Phase 4 statique approfondie (3-20h) : décompilation fonctions critiques (crypto, C2, persistence, payload decoder), reconstruction structures/enums, annotations. Si packé : dump mémoire à OEP + Scylla + re-scan. Phase 5 rapport (2-5h) : IoCs (hashes, IPs, domains, mutex, registry, paths), TTPs MITRE ATT&CK, règle YARA/Sigma custom, partage MISP/OpenCTI. Durée totale : 1-4 jours-homme par sample moyen.

Écrit par

Naim Aouaichia

Expert cybersécurité et fondateur de Zeroday Cyber Academy

Expert cybersécurité avec un master spécialisé et un parcours hybride : développement, DevOps, DevSecOps, SOC, GRC. Fondateur de Hash24Security et Zeroday Cyber Academy. Formateur et créateur de contenu technique sur la cybersécurité appliquée, la sécurité des LLM et le DevSecOps.