L’analyse de malware par IA a besoin de dossiers de preuves

Zane St. John a acheté un projecteur Android bon marché, a repéré un trafic DNS suspect, puis a utilisé Claude Code comme assistant de rétro-ingénierie pour examiner les applications préinstallées sur l’appareil.¹

Ce qui est intéressant, ce n’est pas qu’un agent IA ait aidé à analyser un malware. Cette affirmation deviendra vite banale. Ce qui compte, c’est la forme de l’artefact produit : comportement réseau observé, noms de packages, chemins de code décompilé, sorties de commandes, notes et indicateurs qu’un humain peut inspecter. Avec des agents, l’analyse de malware ne devient fiable que lorsque le résultat ressemble moins à une réponse qu’à un dossier d’enquête.

L’analyse de malware par IA a besoin de dossiers de preuves. Les agents peuvent accélérer le dépaquetage, la décompilation, la recherche, la synthèse et la formulation d’hypothèses. Mais avant de faire confiance à une conclusion, les analystes ont encore besoin de hachages, de versions d’outils, de commandes, d’indicateurs extraits, de chemins sources, d’étiquettes d’incertitude et de chaînes reliant chaque affirmation à ses preuves.

TL;DR

Microsoft Research décrit Project Ire comme un agent autonome de classification de malware qui effectue la rétro-ingénierie de logiciels et produit une chaîne de preuves avant qu’un validateur ne décide si les éléments réunis suffisent à conclure à un malware.² L’enquête de Zane sur le projecteur Android montre le même schéma à plus petite échelle : un agent peut aider un analyste individuel à parcourir des APK, des journaux, des chaînes de caractères et des chemins de code suspects.¹

La leçon produit à en tirer est précise. Traitez un analyste de malware IA comme un établi, pas comme une autorité. Cet établi peut extraire, organiser et relier les preuves. Il ne devrait pas contacter d’infrastructure active, écrire des clients d’exploitation, exécuter des charges inconnues sur une station de travail ordinaire ni remplacer le jugement humain sur l’impact. Le résultat utile, c’est un dossier de preuves qu’un relecteur peut reproduire.

Points clés

Pour les équipes sécurité : - Demandez aux agents des dossiers de preuves, pas des verdicts. - Conservez ensemble l’identité de l’échantillon, les journaux de commandes, les versions d’outils, les indicateurs extraits et les éléments qui étayent chaque affirmation. - Exigez une validation humaine avant toute exécution dynamique, tout contact réseau ou toute analyse impliquant des identifiants.

Pour les concepteurs d’agents : - Faites de l’analyse statique en lecture seule le comportement par défaut des flux de travail d’analyse de malware. - Séparez l’extraction, l’hypothèse, la vérification et le rapport en étapes distinctes. - Préservez les artefacts bruts et les emplacements sources pour qu’un humain puisse auditer la chaîne.

Pour les équipes produit : - Ne vendez pas « l’analyse autonome de malware » comme de la magie. - Montrez ce que l’agent a inspecté, ce qu’il a déduit, ce qu’il n’a pas vérifié et ce qu’un humain doit encore décider. - Construisez des dossiers de revue avant de construire des tableaux de bord spectaculaires.

Ce que prouve le cas du projecteur Android

L’enquête de St. John a commencé par un comportement observé : des requêtes DNS émises par le projecteur avant une utilisation normale.¹ C’est essentiel, parce que le soupçon venait de l’appareil, pas du modèle. L’agent est intervenu après que l’analyste avait déjà une vraie question à examiner.

Le flux de travail a ensuite traversé des surfaces classiques de rétro-ingénierie :

L’article cite des outils courants de rétro-ingénierie Android comme adb et jadx.¹ Ces outils ne rendent pas une conclusion vraie. Ils rendent l’artefact inspectable. jadx se décrit comme un décompilateur en ligne de commande et à interface graphique qui convertit les fichiers Android Dex et APK en source Java, et peut décoder les ressources Android.³ Apktool se présente comme un outil de rétro-ingénierie des fichiers APK Android, notamment pour le manifeste, les ressources, le smali et les flux de reconstruction.⁴

L’avantage de l’agent se situe au milieu. Il peut chercher dans des packages inconnus, résumer du code, proposer les zones à inspecter en priorité et tenir une liste de tâches. L’analyste doit encore vérifier chaque affirmation par rapport à l’artefact d’origine.

L’IA transforme la rétro-ingénierie en gestion de dossier

L’analyse traditionnelle de malware produit déjà un dossier. Celui-ci peut inclure des hachages, l’origine de l’échantillon, des chaînes, des domaines, des adresses IP, des mutex, des clés de registre, des chemins de fichiers, des captures d’écran, des notes de désassemblage, des sorties d’environnement isolé et un verdict final.

Les agents changent la vitesse et le volume de ce travail. Ils peuvent lire davantage de fichiers, rédiger davantage de notes et produire plus d’hypothèses qu’un analyste seul n’en saisirait manuellement. Sans contrat de sortie plus strict, cette vitesse crée un problème de confiance. Une synthèse trop assurée peut masquer une mauvaise inférence, une branche ignorée ou un nom API halluciné.

Project Ire de Microsoft indique une meilleure forme. Microsoft affirme que le système analyse et classe des logiciels de façon autonome, et construit une chaîne de preuves pour ses conclusions.² Sa conception inclut des outils de rétro-ingénierie ainsi qu’un validateur qui vérifie si les preuves soutiennent le verdict.² Cette idée de validateur compte davantage que le nom de marque. L’analyse de malware a besoin d’un juge séparé pour les preuves, pas seulement d’un narrateur fluide de la conclusion.

Appliquez la même séparation dans des flux de travail plus modestes :

L’agent peut faire beaucoup. La validation décide ce qui mérite d’être cru.

Android offre des surfaces statiques utiles

L’analyse de malware Android a un avantage pratique : les APK exposent plusieurs surfaces statiques avant toute exécution de l’application.

La documentation de sécurité Android répertorie des catégories de risques comme les communications en clair, le chargement dynamique de code, les broadcast receivers non sécurisés, les secrets codés en dur et les erreurs liées aux permissions.⁵ MITRE ATT&CK for Mobile inclut des techniques comme Broadcast Receivers et Téléchargement de nouveau code dans l’environnement d’exécution, ce qui donne aux analystes un vocabulaire pour relier un comportement observé à des modes opératoires d’attaquants.⁶

D’où l’intérêt d’un dossier de preuves fondé d’abord sur l’analyse statique :

Le tableau évite une erreur importante : il ne demande pas d’abord au modèle de décider « malware ou non ». Il demande au système de préserver les preuves qui rendront un verdict vérifiable plus tard.

Le dossier de preuves

Un bon dossier d’analyse de malware par IA devrait suivre une forme prévisible :

La carte des affirmations est le cœur du dossier :

Cette dernière ligne protège l’analyste. Les verdicts de malware ont des conséquences. Un faux positif peut nuire à un fournisseur ou brouiller une réponse à incident. Un faux négatif peut laisser un utilisateur exposé. Le modèle ne devrait pas avoir de raccourci autour des preuves.

Ce que l’agent doit refuser

Le travail sur les malwares exige des limites de refus, même lorsque l’objectif est défensif.

Un agent devrait refuser, ou exiger une autorisation humaine explicite avant de :

• contacter une infrastructure de commande et contrôle active ;
• écrire un client pour une porte dérobée ou un mécanisme de mise à jour suspect ;
• télécharger des charges de deuxième étape depuis une infrastructure contrôlée par un attaquant ;
• exécuter un échantillon inconnu hors d’un laboratoire isolé ;
• utiliser de vrais identifiants utilisateur, des comptes personnels ou des réseaux de production pendant l’analyse ;
• publier des indicateurs actifs susceptibles d’identifier une victime avant une divulgation responsable ;
• transformer une enquête défensive en instructions d’exploitation.

La documentation d’OpenAI sur le shell local avertit qu’autoriser des agents à exécuter des commandes shell arbitraires peut être dangereux, et recommande la mise en bac à sable ou des listes strictes d’autorisation et de refus avant de transmettre des commandes à un shell.⁷ Le guide de bonnes pratiques Claude Code d’Anthropic insiste sur les critères de vérification et la gestion du contexte pour le travail avec agents.⁸ L’analyse de malware a besoin des deux : des limites de commande avant l’action, et des limites de preuve avant la croyance.

La limite de refus devrait apparaître dans la tâche elle-même :

Analyse cet APK statiquement.
Ne l’exécute pas.
Ne contacte aucune infrastructure distante.
N’écris pas de code d’exploitation ni de client.
Retourne uniquement des preuves avec chemins de fichiers, commandes et étiquettes de confiance.
Marque chaque affirmation non étayée comme non vérifiée.

Ce type d’instruction ne rend pas le flux de travail sûr à lui seul. Il donne aux points d’accroche, aux environnements isolés et aux relecteurs quelque chose de concret à faire appliquer.

Le verdict appartient toujours à l’humain

Un agent IA peut faire gagner des heures dans une analyse de malware. Il peut transformer une pile d’APK en courte liste de packages suspects. Il peut résumer des classes, dépaqueter des filtres d’intent, repérer des chaînes de configuration et produire une ébauche de rapport. Ces gains comptent.

L’agent ne devrait pas posséder le verdict.

L’analyste garde la responsabilité de :

• l’autorisation d’analyser l’échantillon ;
• la décision d’exécuter quoi que ce soit dynamiquement ;
• l’interprétation de l’intention et de l’impact ;
• la communication avec les fournisseurs, utilisateurs ou plateformes concernés ;
• les décisions de remédiation et de divulgation ;
• la formulation finale du rapport.

Cette séparation garde l’agent utile. Le modèle fait le travail de liaison fatigant. L’humain conserve la responsabilité éthique, juridique et contextuelle.

Comment construire le flux de travail

Commencez par une petite boucle d’analyse statique :

1. Hachez l’échantillon et notez sa provenance.
2. Extrayez le manifeste, les ressources, les chaînes et le code décompilé dans un dossier de travail en lecture seule.
3. Demandez à l’agent de créer une liste de constats avec les emplacements sources.
4. Demandez à une seconde passe de contester chaque constat et de marquer les affirmations non étayées.
5. Construisez le dossier de preuves.
6. Décidez si le dossier justifie une analyse dynamique en laboratoire.

L’instruction donnée à l’agent devrait exiger une sortie structurée :

Pour chaque constat, inclure :
- affirmation
- chemin de l’artefact
- commande ayant produit l’artefact
- extrait source ou symbole
- confiance
- ce qui réfuterait l’affirmation
- si une analyse dynamique est nécessaire

Cette sortie paraît moins spectaculaire que « le projecteur contient un malware ». Elle est beaucoup plus utile.

La barrière de la preuve s’applique directement. Une affirmation sans preuve ne devrait pas entrer dans la réponse finale. Les dossiers de revue sont la nouvelle réponse finale s’applique aussi : le livrable n’est pas la synthèse rédigée, mais le dossier qui permet à une autre personne de vérifier le travail.

FAQ

Les agents IA peuvent-ils analyser des malwares ?

Oui, dans certaines limites. Les agents peuvent aider à l’analyse statique, à la synthèse, à la navigation dans la décompilation, à l’extraction d’indicateurs et à la rédaction de rapports. Ils ne devraient pas devenir l’autorité finale pour les verdicts de malware sans preuves reproductibles et revue humaine.

Est-il sûr d’utiliser Claude Code ou Codex sur des malwares ?

Seulement dans un flux de travail défensif contrôlé. N’exécutez pas d’échantillons inconnus sur une station de travail ordinaire, ne contactez pas d’infrastructure active et ne donnez pas à l’agent des identifiants ou un accès shell/réseau sans restriction. L’analyse statique dans un dossier de travail isolé est le point de départ le plus sûr.

Que doit contenir un dossier de preuves d’analyse de malware ?

Au minimum : hachages, source de l’échantillon, versions d’outils, commandes, faits du manifeste, indicateurs extraits, emplacements de code, carte reliant affirmations et preuves, étiquettes de confiance, et liste du travail non vérifié.

Un verdict IA compte-t-il comme une preuve ?

Non. La déclaration du modèle est une interprétation. Les preuves viennent des artefacts : hachages, journaux, commandes, chemins de code, manifestes, comportement réseau observé et étapes d’analyse reproductibles.

Les agents devraient-ils relier les constats à MITRE ATT&CK ?

Oui, lorsque les preuves soutiennent la correspondance. Une étiquette de technique sans artefact à l’appui devient décorative. Utilisez ATT&CK Mobile comme vocabulaire, pas comme substitut à la preuve.⁶

Conclusion

L’IA ne retire pas l’analyste de l’analyse de malware. Elle change ce que l’analyste doit exiger.

Le résultat faible est un verdict assuré. Le résultat solide est un dossier reproductible : identité de l’échantillon, commandes, artefacts, indicateurs, preuves des affirmations, incertitude et prochaine action.

Les agents peuvent rendre la rétro-ingénierie plus rapide. Les dossiers de preuves la rendent digne de confiance.

Références