Security Blog publie un retour d’expérience détaillé sur l’usage d’LLMs (GPT‑5.1/mini, Claude Sonnet 4.6/Opus) dans un labo d’analyse de malwares, basé sur des tests concrets (dont CVE‑2017‑11882) et l’intégration d’outils via MCP.

🧪 Mise en place et premiers essais

  • L’auteur déploie deux VMs (Remnux et Windows 10) et connecte des serveurs MCP (remnux, remnux-docs, x64dbg, virustotal, ssh-mcp, ghidra-mcp) pour piloter analyse statique/dynamique.
  • Sur un document Office exploitant CVE‑2017‑11882 (Equation Editor), GPT‑5.1‑mini échoue (faux positifs, mauvaise lecture d’oletools “decalage.info”, échecs avec Unicorn/Speakeasy).
  • GPT‑5.1 et Claude Sonnet 4.6 réussissent avec guidage : extraction du shellcode, émulation Speakeasy et récupération de l’URL du stage suivant. Sonnet 4.6 identifie seul l’exploit et la zone du shellcode, mais requiert l’émulation pour obtenir l’URL.

🚀 Efficacité vs fiabilité

  • Sur un échantillon complexe (décryptage multi‑étapes), GPT‑5.1 et Sonnet 4.6 génèrent en ~30 min un script Python spécifique (contre ~6 h “à l’ancienne”), validé ensuite manuellement.
  • L’auteur développe une compétence de reporting avec passes de vérification (IPs, hashes, chemins, offsets, etc.). Malgré cela, les rapports comportent encore des erreurs fréquentes (IoCs, relations, persistance) et ne sont pas dignes de confiance.
  • Les verdicts sont jugés peu fiables (biaisés par VirusTotal, changements multiples en cours d’analyse). Un analyste expérimenté reste nécessaire pour cadrer et corriger.

🛠️ Outillage et méthodologie

  • Le choix d’outils/compétences par type d’échantillon est déterminant (sinon surconsommation de tokens). L’ajout de Ghidra headless via MCP améliore nettement l’analyse (préférer la décompilation à la simple désassemblage).
  • x64dbg MCP est gourmand en tokens mais utile; SSH MCP permet l’analyse .NET/Powershell, deobfuscation dynamique et appels Sysinternals, moyennant des rappels explicites au LLM.
  • LLMs couvrent rapidement de larges bases (ex. détection d’un chemin de debug oublié dans un projet de ~10k fichiers) et apportent un contexte parfois méconnu de l’analyste.
  • Préférer la génération de scripts (extracteurs, unpackers, déobfuscation) pour bénéficier d’un retour d’exécution vérifiable, plutôt que des assertions de rapport.

💻 Coûts et déploiement

  • Un labo autonome se monte aisément sur du matériel modeste (ex. laptop 12 ans, 16 Go RAM) avec snapshots et allocation mémoire ajustée (Remnux/Windows/x64dbg/Ghidra non simultanés si RAM limitée).
  • Le paiement à la consommation peut rendre une analyse coûteuse (≈ 5–20 €), l’abonnement étant souvent plus rentable.

⚠️ Conclusion

  • L’analyse autonome par LLM est jugée très utile pour gagner en efficacité, si elle est correctement encadrée. L’auteur alerte toutefois sur l’âge de la désinformation: des services payants d’analyse LLM “automagiques” risquent d’être perçus à tort comme des « machines à faits ».

IoCs

  • Aucun IoC spécifique publié.

TTPs observés/illustrés

  • Exploitation d’Office Equation Editor: CVE‑2017‑11882.
  • Shellcode construisant dynamiquement l’URL du stage suivant (staging).
  • Obfuscation/chiffrement avec génération de scripts de décryptage/unpacking.
  • Émulation (Mandiant Speakeasy) et décompilation (Ghidra) pour l’analyse.

Il s’agit d’une analyse technique visant à documenter, par l’expérience, l’apport réel et les limites des LLMs en analyse de malwares.

🧠 TTPs et IOCs détectés

TTP

Exploitation d’Office Equation Editor: CVE-2017-11882, Shellcode construisant dynamiquement l’URL du stage suivant (staging), Obfuscation/chiffrement avec génération de scripts de décryptage/unpacking, Émulation (Mandiant Speakeasy) et décompilation (Ghidra) pour l’analyse.

IOC

Aucun IoC spécifique publié.

🔗 Source originale : https://blog.gdatasoftware.com/2026/03/38381-llm-malware-analysis