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écompilation — Ghidra (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 sandboxes — ANY.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
| Dimension | SAST (AppSec) | Statique malware | DAST (AppSec) | Dynamique malware |
|---|---|---|---|---|
| Input | Code source | Binaire compilé | Web app en runtime | Binaire exécuté |
| Contrôle du code | Propriétaire | Hostile (adversary) | Propriétaire (app à tester) | Hostile |
| Objectif | Trouver bugs à fix | Comprendre comportement | Trouver vulns exploitables | Observer runtime behavior |
| Outils | Semgrep, CodeQL, Snyk | Ghidra, IDA, Radare2 | ZAP, Burp Pro | Cuckoo, ANY.RUN, x64dbg |
| Contexte | DevSecOps shift-left | Incident response, CTI | Security testing pré-prod | Forensics, threat intel |
| Input typique | .py / .java / .ts | .exe / .dll / .apk | https://example.com | malware.exe |
| Durée typique | Secondes-minutes (CI) | Heures-jours | Heures | Minutes-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
| Outil | Usage | Licence |
|---|---|---|
| x64dbg | Debugger Windows x86/x64, plugins riches | Open-source |
| WinDbg | Debugger Microsoft avancé (kernel + user) | Microsoft gratuit |
| OllyDbg 2.0 | Debugger classique Windows (legacy) | Gratuit (non-commercial) |
| GDB + peda/pwndbg | Debugger Linux/ELF, avec extensions | Open-source |
| Frida | Hooking dynamique multi-plateforme | Open-source, Ole André Vadla Ravnås |
| Process Monitor (Procmon) | Activité registry + filesystem + processus | Sysinternals gratuit |
| Process Hacker / System Informer | Processus + handles + memory | Open-source |
| Wireshark | Capture + analyse réseau | Open-source |
| Fiddler Classic / Everywhere | Proxy HTTP/HTTPS pour intercept traffic | Gratuit/commercial |
| Cuckoo Sandbox / CAPE | Sandbox automation self-hosted | Open-source |
| ANY.RUN | Sandbox interactive cloud | Commercial SaaS |
| Joe Sandbox | Analyse forensique avancée | Commercial |
| Hybrid Analysis / Falcon Sandbox | Sandbox cloud gratuite CrowdStrike | Gratuit (public) |
| Volatility 3 | Memory forensics | Open-source Apache 2.0 |
| FakeNet-NG | Fake C2 responder | Open-source Mandiant |
| INetSim | Simulation services réseau | Open-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/STIX4. Matrice comparative : forces et limites
| Critère | Analyse statique | Analyse dynamique |
|---|---|---|
| Exécution requise | Non | Oui |
| Sécurité analyst | Haute (pas d'exécution) | Moyenne (sandbox fait la barrière) |
| Détection comportement runtime | Non | Oui |
| Packé/obfusqué | Difficile (nécessite unpack) | Contournement naturel (exécute unpacké) |
| Polymorphe / metamorphic | Difficile à signaturer | Observable par TTPs |
| Anti-VM / anti-debug | Peu affecté | Trompable |
| Temps typique sample simple | 30 min - 2h | 10-30 min (sandbox auto) |
| Temps sample complexe | 10-80 h | 2-20 h |
| Couverture code | 100 % theoretical | Branches exécutées seulement |
| Crypto identification | Excellente (constants, S-boxes) | Moyenne (via memory dump) |
| C2 extraction | Possible si hardcoded | Automatique si connexion réelle |
| Automation à l'échelle | YARA, capa, scripts | Sandbox farm, API |
| Réutilisable (cold data) | Oui (binaire persiste) | Non (VM éphémère) |
| Anti-analysis mitigation | Patching manuel | Masquer 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, papers7. Anti-analysis — techniques et contournement
7.1 Anti-debug
| Technique | Détection | Contournement |
|---|---|---|
| IsDebuggerPresent() / CheckRemoteDebuggerPresent() | Appel API Win32 | Plugin ScyllaHide x64dbg |
| NtQueryInformationProcess() + flags | API undocumented | Plugin TitanHide kernel |
| PEB.BeingDebugged manipulation | Check mémoire PEB | Patch PEB manuellement |
| PEB.NtGlobalFlag | Flag 0x70 indique debug | Patch |
| Hardware breakpoints detection | DR0-DR3 registers | Retirer les HW breakpoints |
| Timing attack (GetTickCount, RDTSC) | Délai anormal en debug | Patch ou single-step rapide |
| SEH / VEH tricks | Exception handlers exotiques | Debugger aware |
7.2 Anti-VM / anti-sandbox
| Technique | Détection | Contournement |
|---|---|---|
| Registry HKLM\HARDWARE\DESCRIPTION (VMware, VBox strings) | Lecture registry | Patch registry or hook |
| MAC address OUI check | VMware/VBox MAC prefixes | Randomize MAC |
| Sleep long (> 30 min) | Eviter timeout sandbox | Accélérer time (WinDbg, hook Sleep) |
| Check CPU count, RAM total | Sandbox souvent 1-2 CPU, 2-4 GB | Configure VM réaliste |
| User interaction required | Pas de souris movement | ANY.RUN interactive |
| Recent Files / Browser History | Sandbox vierge | Populate VM |
| VBoxGuest / VMTools services | Check running services | Remove or rename |
| CPUID hypervisor bit | Bit 31 eax=1 | Hypervisor hide (x64dbg plugin) |
| Timing discrepancies RDTSC | Hyperviseur slower | Patch timer |
7.3 Packers et obfuscators
| Packer | Année | Difficulté unpacking |
|---|---|---|
| UPX | 1998 | Trivial (upx -d) |
| ASPack | 2001 | Facile, tutorials publics |
| Themida / WinLicense (Oreans) | 2003 | Difficile, 2-20 h manuel |
| VMProtect (Rusian Ingurgeev) | 2007 | Très difficile, VM custom semaines |
| Enigma Protector | 2011 | Moyen à difficile |
| Obsidium | 2003 | Moyen à difficile |
| Custom crypters (Babadeda, Formbook) | Variable | Variable 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 :
| Plateforme | Statique | Dynamique |
|---|---|---|
| Android | jadx, apktool, Ghidra Android module, MobSF | Frida, Objection, Burp Proxy, Android Emulator |
| iOS | Ghidra / IDA Pro sur Mach-O, class-dump, Hopper | Frida, Objection, Corellium (commercial) |
| Both | MobSF (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, enriched9.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 JSON9.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 identifiedPour 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.







