Contexte
La forensique mémoire produit des constats — un processus suspect, une correspondance YARA, une technique d’injection — qui restent trop souvent dans un rapport PDF au lieu de devenir une règle de détection. MemHunter part d’un moteur de forensique mémoire existant et ajoute ce qui, à mes yeux, manquait pour qu’une investigation nourrisse directement le travail de détection : relier chaque finding à MITRE ATT&CK, et en sortir un brouillon de règle exploitable plutôt qu’une ligne de texte dans un rapport.
Le projet part de l’architecture d’un outil existant (Dumplyzer,
Apache-2.0 — attribution complète dans NOTICE) et y ajoute trois choses qui n’y étaient pas : un
vrai CLI headless, le mapping ATT&CK avec génération de règle, et un support natif Linux pour les
images mémoire (pas seulement Windows).
Ce que l’outil fait
- Analyse guidée Windows et Linux : processus, lignes de commande, modules, réseau, handles — détecté et adapté automatiquement selon l’OS de l’image mémoire, indépendamment de l’OS hôte.
- Détection par signatures : 56 règles YARA bundlées (vol de credentials, C2, injection, malware, reconnaissance, scripts), chacune taguée avec ses techniques MITRE ATT&CK réelles — vérifiées une à une, pas générées en masse.
- CAPA / FLOSS sur les exécutables reconstruits depuis la mémoire.
- Couverture ATT&CK : agrège tout ce que CAPA et YARA ont produit pour une image donnée, par technique — pour voir d’un coup d’œil ce qu’une image mémoire démontre.
- Génération de règle : depuis n’importe quel finding, un brouillon Sigma ou YARA pré-rempli (logsource, technique, indicateur), explicitement marqué comme brouillon à affiner — jamais une détection prête à déployer sans relecture.
- CLI headless :
memhunter import / analyze / yara-scan / attck / gen-rule / report— le même moteur que l’app desktop, scriptable dans un pipeline CI ou un runbook de réponse à incident.
Validation sur un cas réel
Plutôt que de valider sur des données synthétiques, j’ai fait tourner le pipeline complet sur un
challenge DFIR public : import, analyse complète, scan de signatures, couverture ATT&CK, export.
Le résultat n’a rien d’inventé — l’image contenait une vraie trace de vol de credentials via
rundll32 comsvcs.dll, MiniDump sur LSASS, correctement détectée et mappée sur T1003.001
(OS Credential Dumping) et T1218.011 (System Binary Proxy Execution), avec un brouillon de
règle Sigma généré directement depuis ce finding.
Ce que ça a demandé de résoudre
- Mapper 56 règles YARA sur ATT&CK sans en inventer : chaque technique associée à chaque règle a été vérifiée individuellement contre la définition MITRE réelle, pas devinée par famille de malware.
- Support Linux réel, pas symbolique : trouver les bons plugins Volatility 3
linux.*(noms de colonnes, schémas de sortie) équivalents aux plugins Windows, avec bascule automatique Windows → Linux à l’import selon ce que l’image révèle d’elle-même. - Conformité légale multi-licences : Volatility 3 (licence copyleft spécifique qui impose que le code source du wrapper reste public), bulk_extractor (GPL-3.0, isolé en sous-processus séparé pour ne jamais contaminer le reste du code en Apache-2.0), CAPA/FLOSS (Apache-2.0) — chaque composant tiers documenté avec sa licence réelle, ses hachages SHA-256 vérifiés indépendamment, jamais copiés d’une source tierce sans re-vérification.
- Packaging Linux depuis zéro : bulk_extractor n’a pas de binaire Linux portable officiel, seulement un paquet Snap — extraction de l’image squashfs, puis réécriture du RPATH pour qu’il tourne hors du confinement Snap, sans dépendre de snapd.
Prochaines étapes
- Exposer la génération de règle directement dans l’interface desktop pour CAPA et YARA (déjà fonctionnel en CLI)
- Étendre la bibliothèque de règles au-delà des 56 actuelles, en gardant la même rigueur de vérification technique par technique
- Pipeline d’intégration continue Linux pour construire et tester automatiquement les paquets
.debet AppImage à chaque changement