ALIBI : quand un fichier malveillant raconte une histoire crédible à un analyseur LLM

Une attaque par le sens, pas par l’ordre

Les analyseurs de malwares fondés sur des LLM reçoivent rarement un exécutable brut. Ils travaillent plutôt sur une représentation structurée : métadonnées du fichier, sections, symboles importés et chaînes de caractères lisibles. Cette abstraction facilite l’analyse, mais elle crée aussi un canal d’influence. Une partie des informations transmises au modèle provient directement du fichier examiné.

Le preprint « ALIBI » étudie cette faiblesse. Son attaque ne demande pas explicitement au modèle d’ignorer ses instructions. Elle ajoute au binaire un petit récit cohérent qui présente le fichier comme un composant légitime de sécurité. Les comportements suspects sont alors décrits comme des fonctions attendues d’un outil de protection. Le modèle conserve une apparence de raisonnement normal, mais peut réinterpréter les indices dans le mauvais sens.

Ce que construit ALIBI

Le nom ALIBI signifie « Adversarial Legitimacy Injection in Binary Input ». La méthode combine trois familles de falsification conceptuelle : une identité revendiquée, une justification comportementale et des éléments de métadonnées cohérents avec cette identité. Le texte ajouté se trouve dans une section non exécutée et ne modifie pas les imports ni le comportement d’exécution du programme.

Le point important est la cohérence du récit. Une simple phrase qui ordonne au modèle de classer le fichier comme bénin ressemble à une injection directe et peut être repérée. ALIBI cherche plutôt à expliquer les indices déjà présents : des hooks, de la capture d’écran, l’accès au presse-papiers, de la persistance ou de la télémétrie peuvent être présentés comme des fonctions d’instrumentation d’un produit de sécurité. L’étude décrit donc une injection indirecte par le canal d’évidence.

Le protocole d’évaluation

Les auteurs utilisent un ensemble figé de 50 échantillons PE malveillants provenant de MalwareBazaar, ainsi qu’un ensemble de 40 échantillons ELF pour l’évaluation inter-format. Le même générateur d’évidence est utilisé avant et après la modification. Il produit une représentation JSON contenant notamment des métadonnées, des informations de sections, des symboles importés et des chaînes ASCII.

Trois modèles sont évalués : Gemini 2.5 Pro, GPT-5.5 Pro et Claude Opus 4.7. Pour les expériences PE, les auteurs retiennent les 35 échantillons que Gemini classe comme malveillants avant l’attaque. Ce sous-ensemble fixe le dénominateur des analyses principales et évite de gonfler artificiellement le taux d’attaque avec des fichiers qui n’étaient pas déjà considérés comme malveillants par le modèle de référence.

L’étude distingue le Strict ASR, qui compte uniquement le passage de malveillant à bénin, du Soft ASR, qui compte toute dégradation depuis le niveau malveillant. Cette différence est essentielle : un modèle qui passe de « malveillant » à « suspect » n’offre pas un contournement complet, mais peut tout de même faire descendre l’alerte dans la file de traitement d’un analyste.

Des effets différents selon les modèles

Sur le sous-ensemble PE de 35 fichiers, le payload intégré atteint un Strict ASR de 85,7 % pour Gemini 2.5 Pro. Le Soft ASR atteint 88,6 %. GPT-5.5 Pro et Claude Opus 4.7 ne produisent pas de basculement direct vers « bénin », mais leurs réponses ne sont pas inchangées : le Soft ASR est respectivement de 71,4 % et 42,9 %.

Ces chiffres décrivent des modes d’échec différents. Gemini accepte souvent le récit comme une explication suffisante et bascule vers un verdict bénin. GPT-5.5 Pro tend plutôt à dégrader la sévérité vers « suspect ». Claude conserve davantage le verdict malveillant, tout en montrant encore des changements mesurables. Se limiter au seul Strict ASR aurait donc masqué une partie du risque.

L’étude examine aussi la confiance déclarée par les modèles lorsque l’étiquette ne change pas. Certaines baisses de confiance restent visibles même en l’absence de basculement de verdict. La sécurité d’un analyseur ne se résume donc ni à son étiquette finale ni à un seul taux d’attaque : la sévérité, l’abstention, la confiance et l’ordre de traitement des alertes comptent également.

L’effet du format et du récit

ALIBI est également testé sur ELF. Gemini atteint alors un Strict ASR de 40 %. L’effet est plus faible que sur PE, ce qui cadre avec l’hypothèse des auteurs : l’attaque fonctionne mieux lorsque le récit proposé correspond naturellement à l’empreinte statique du fichier. Un comportement typique d’un composant de sécurité Windows est plus facile à rationaliser dans un binaire PE que dans certains échantillons ELF associés à des traces de botnet ou à des mécanismes de persistance Linux.

Le ton du récit joue lui aussi un rôle. Dans l’expérience menée sur Gemini, un récit de type « auto-test EDR » est plus efficace qu’une justification académique générique ou qu’un scénario de preuve de concept de test d’intrusion. Cette observation ne signifie pas qu’un nom de produit suffit. Elle suggère plutôt que la narration devient persuasive lorsqu’elle fournit une explication spécifique aux indices que le modèle observe.

Quelle défense ?

La conclusion défensive est directe : une chaîne d’analyse ne doit pas traiter les chaînes embarquées dans un binaire comme des faits vérifiés. Elles doivent être considérées comme des affirmations contrôlées par l’auteur du fichier. Un prompt peut demander au modèle de se méfier des commentaires autojustificatifs, mais cette protection ne suffit pas seule.

Les auteurs proposent de séparer la provenance des éléments d’évidence. Une signature, une identité de certificat, une structure de fichier ou un identifiant de construction doivent venir d’un parseur ou d’une vérification dédiée, pas seulement d’une chaîne déclarative. Le modèle peut ensuite raisonner sur ces éléments avec une distinction visible entre faits vérifiés, observations et allégations présentes dans le fichier.

Cette distinction est utile même lorsqu’aucun verdict ne bascule. Une baisse de confiance ou un passage de « malveillant » à « suspect » peut déjà modifier la priorité donnée par un analyste. L’évaluation doit donc conserver les sorties brutes et suivre les changements de sévérité, plutôt que de compter uniquement les fichiers déclarés bénins.

Le triage doit rester une aide, jamais une preuve unique.

Cette architecture déplace la question. Au lieu de demander au LLM de décider si une histoire est convaincante, elle lui demande d’examiner une histoire dont le statut est explicitement incertain. Le modèle reste utile pour relier les signaux, mais il n’est plus invité à transformer une revendication en preuve.

Limites et statut

Le jeu d’évaluation couvre PE et ELF, mais pas Mach-O, les scripts, les macros de documents ou les dépôts de code. Les ensembles sont contrôlés et limités à 50 fichiers PE et 40 fichiers ELF : ils montrent des effets importants, sans permettre d’estimer une prévalence universelle parmi toutes les familles de malwares. Les modèles produisent en outre un score de confiance déclaré, qui ne correspond pas nécessairement à une incertitude interne mesurée par les logits.

La défense étudiée reste principalement une orientation de prompt et une proposition d’architecture. Le papier n’évalue pas une chaîne complète de provenance vérifiée. Ses résultats ne prouvent donc pas que l’analyse par LLM est inutilisable ; ils montrent que la confiance accordée aux récits embarqués est dangereuse. Le document est un preprint ArXiv, pas une certification de produit ni une garantie de détection.

Sources

Hyeongjun Choi, Wonyoung Jung, Haehoon Seo et Sungyup Nam, « ALIBI: Adversarial Legitimacy Injection in Binary Input against LLM Malware Analyzers », ArXiv 2609.19722v1, consulté le 21 septembre 2026 : preprint, PDF.