Analyser un malware en local avec un agent, sans l'exfiltrer

Un centre de réponse à incident qui reçoit un exécutable suspect a longtemps eu deux options : l'envoyer à un service d'analyse hébergé, ou le confier à un rétro-ingénieur expérimenté. REA, le serveur MCP qui donne à un agent de code les outils de la rétro-ingénierie, ouvre une troisième voie. Son README l'affirme : « REA analyzes targets locally »¹. Le binaire ne part pas sur un serveur tiers. Cette promesse a deux limites que l'équipe sécurité doit connaître avant le premier échantillon.

Local, mais pas privé de bout en bout

La même ligne du README poursuit : l'agent reçoit les résultats des outils, et le fournisseur du modèle applique sa propre politique de données¹. Le pseudocode, les chaînes extraites, les adresses de serveurs de commande trouvées dans l'échantillon partent donc chez Anthropic, OpenAI ou Google si l'agent tourne sur leurs modèles. Pour un malware qui cible votre organisation, ces chaînes peuvent contenir des noms de machines internes, des comptes ou des chemins réseau.

Pour une analyse confinée de bout en bout, il faut un modèle exécuté chez vous. Les modèles à poids ouverts le permettent désormais en cybersécurité : Aikido Security a compressé GLM-5.3 de 1,51 To à 328 Go pour le faire tourner sur quatre GPU H200 sans connexion à internet (voir notre analyse d'Aikido Altar). Le choix du modèle devient une décision de politique de sécurité, documentée comme telle.

La règle d'or : ne jamais lancer l'échantillon

La seconde limite tient à REA lui-même. Sa politique de sécurité précise qu'il n'est pas un bac à sable et qu'ouvrir un binaire non fiable confie son analyse au moteur local avec les permissions de l'utilisateur². Les détails sont dans REA n'est pas un sandbox. Pour un malware, la conséquence est simple : analyse statique uniquement. Vous lisez l'échantillon, vous le faites décompiler par Ghidra, vous tracez les chaînes, les imports et les références. Vous ne l'exécutez pas, et vous tenez les outils de capture à l'exécution de REA à l'écart, puisque ceux-ci lancent la cible avec vos droits¹.

Le guide communautaire publié le 12 octobre dans les discussions du dépôt, rédigé par un amateur qui teste REA, place le malware en VM au sommet de son échelle de difficulté. Sa règle : ne jamais lancer un échantillon sur sa machine principale. Il explique aussi pourquoi l'interdiction d'exécuter est absolue avec un modèle hébergé : la VM doit rester en ligne pour joindre le modèle, donc un échantillon lancé aurait accès au réseau³.

Monter l'environnement

Prévoyez une VM dédiée à l'analyse, sans dossier partagé ni presse-papiers commun avec l'hôte, avec un instantané propre restauré après chaque échantillon. Aucun identifiant de l'entreprise ne doit y être présent. Avec un modèle local, coupez le réseau. Avec un modèle hébergé, limitez les sorties au seul point d'accès du fournisseur. Récupérez les échantillons auprès de sources de recherche connues, jamais par un lien reçu au hasard.

Mise à jour du 19 octobre 2026. L'image Docker communautaire psyb0t/docker-reverse-engineer-anything, publiée le 18 octobre, propose deux modes⁴. En serveur MCP, elle tourne en lecture seule, sans capacités Linux, et publie un endpoint local protégé par jeton ; c'est l'exemple en ligne de commande qui coupe le réseau (--network none). Elle vise surtout l'analyse d'APK (JADX, Apktool, adb). Ghidra n'est pas inclus dans l'image : le conteneur le télécharge au premier démarrage si l'on positionne REA_INSTALL=ghidra, soit environ 900 Mo. Projet non officiel et récent : lisez-la comme un exemple de durcissement à reproduire dans votre propre image.

Le risque d'injection par le contenu

Un auteur de malware sait désormais que des agents lisent son code. Des chaînes rédigées comme des consignes peuvent orienter l'agent : Brian Crawford et Patrick McClure ont montré, dans un article déposé sur arXiv le 29 mai 2026, qu'un binaire piégé peut amener un agent de rétro-ingénierie à décrire le comportement d'un autre programme⁵. L'analyste garde donc l'approbation des outils active, vérifie chaque conclusion importante dans l'assembleur, et traite le rapport de l'agent comme une hypothèse. Les inconnues signalées par REA comptent autant que ses trouvailles.

Le cadre

Le DISCLAIMER de REA range l'analyse de malwares et d'incidents parmi les usages légitimes, aux côtés de la recherche de vulnérabilités et de la divulgation coordonnée⁶. En France, l'article 323-3-1 du Code pénal réprime la détention et la diffusion d'outils conçus pour attaquer un système « sans motif légitime, notamment de recherche ou de sécurité informatique »⁷. Une équipe qui analyse des échantillons a donc intérêt à documenter son cadre : mandat, finalité, conservation des échantillons, accès restreint. Le panorama juridique de la rétro-ingénierie est dans clean-room ou reverse engineering.

Questions fréquentes

Puis-je exécuter l'échantillon avec REA ?

Non. Analyse statique seulement, dans une VM dédiée. Les outils de capture à l'exécution lancent la cible avec vos droits.

REA envoie-t-il le binaire à un service en ligne ?

Non, l'analyse est locale. Les résultats des outils, eux, vont au fournisseur du modèle utilisé par l'agent.

Comment éviter l'injection par le contenu du binaire ?

En gardant l'approbation des outils active, en ne laissant pas l'agent exécuter sans supervision et en vérifiant les conclusions dans l'assembleur.

Un modèle local suffit-il en cybersécurité ?

Les modèles à poids ouverts ont rattrapé une partie de l'écart avec les modèles fermés en 2026. Leur choix se fait cas par cas, selon la sensibilité de l'échantillon et le matériel disponible.

L'offre AI Cyber de SFEIR aide les équipes sécurité à monter ces environnements d'analyse, avec le modèle et le confinement adaptés à leurs contraintes de souveraineté.

Sources

1. morluto/rea, README, FAQ « Does REA upload my app? » et tableau des cibles — github.com, consulté le 14 octobre 2026.
2. morluto/rea, SECURITY.md — github.com, consulté le 14 octobre 2026.
3. Discussion n° 2412, New to RE with AI? What to reverse engineer first, and how to ask, guide communautaire — github.com, 12 octobre 2026.
4. psyb0t, docker-reverse-engineer-anything, release v0.1.1 — github.com, 18 octobre 2026.
5. Brian Crawford, Patrick McClure, Investigating Detection and Obfuscation of Prompt Injection Attacks Against Software Reverse Engineering AI Agents, arXiv:2605.30677 — arxiv.org, 29 mai 2026.
6. morluto/rea, DISCLAIMER.md — github.com, consulté le 14 octobre 2026.
7. Code pénal, livre III, titre II, chapitre III « Des atteintes aux systèmes de traitement automatisé de données », article 323-3-1 (rédaction issue de la loi n° 2013-1168 du 18 décembre 2013) — legifrance.gouv.fr.