Microsoft décrit « Lazarus », backdoor par neurones dormants

Microsoft rapporte une technique baptisée « Lazarus » qui insère une porte dérobée en reprogrammant moins de dix neurones dormants d’un LLM, sans réentraînement. L’attaque peut rester invisible aux évaluations, se déclencher sur un simple signal — jusqu’à une date — et pousser un agent outillé à exécuter du code d’attaquant. Le groupe met en avant la provenance et l’intégrité des poids comme axes de défense, avec des contrôles Foundry et des protections supplémentaires en cours.

La sécurité reste bornée par la provenance des poids

Microsoft indique qu’aucun scan ne peut attester avec certitude qu’un modèle est sûr. Selon ses équipes, une détection fiable suppose la comparaison avec des poids originaux non modifiés, d’où l’importance de la provenance. Le risque ne disparaît pas pour autant : un fournisseur de confiance peut être compromis, par son infrastructure d’entraînement ou un initié. L’éditeur prévoit en outre la signature des modèles avec une provenance vérifiable et des audits à l’épreuve des falsifications. L’attaque ne requiert qu’un accès en écriture à un point de contrôle, ce qui expose également des modèles développés en interne. Un compte, un pipeline ou un stockage compromis peut suffire. Dans cette approche, l’intégrité des poids et leur origine sont déterminantes.

La méthode « Lazarus » modifie moins de dix neurones

Les chercheurs décrivent une reprogrammation de moins de dix neurones dormants d’un LLM pour installer une porte dérobée, sans réentraînement. Les neurones rarement actifs peuvent être transformés en détecteurs de déclencheurs. Cette manipulation s’appuie sur des représentations internes suffisamment structurées pour qu’un classificateur linéaire ajusté sur environ 50 exemples sépare les entrées avec déclencheur de celles sans. Une fois réactivé, un neurone peut forcer l’injection d’un token dans le flux résiduel, et l’enchaînement de plusieurs neurones permet des charges utiles arbitraires exécutées dans un terminal. L’opération ne nécessite que des ressources d’inférence : une machine dotée de la RAM suffisante pour exécuter un modèle a assez de ressources pour le modifier dans l’espace des poids.

Des agents outillés peuvent obéir à un signal caché

Un modèle ainsi altéré passe les évaluations standard et fonctionne normalement jusqu’à l’apparition d’un déclencheur. Ce déclencheur peut être trivial, comme un passage à minuit en 2027, moment où l’agent peut émettre une commande téléchargeant et exécutant du code d’attaquant. L’agent exécute ensuite avec les accès qui lui ont été délégués. Microsoft estime la menace particulièrement sévère pour des agents ayant un terminal ou des outils. Ces systèmes offrent une large surface d’attaque et un modèle piégé peut, sur signal, émettre des commandes malveillantes tout en ayant franchi les contrôles usuels.

Détection possible mais non décisive sans original de référence

Des agents de pointe peuvent repérer des modifications anormales des poids lorsqu’on les sollicite dans ce sens. Toutefois, Microsoft précise qu’aucun scan ne garantit la sûreté d’un modèle et que la comparaison avec les poids d’origine reste essentielle. Dans cette optique, des modèles avec porte dérobée s’apparentent à des logiciels compromis. Les recommandations consistent à traiter les modèles comme des risques potentiels d’initiés, à limiter leurs capacités et à surveiller leurs actions.

Foundry applique des contrôles de sourcing et d’exécution

Microsoft Foundry annonce des vérifications de provenance, un lien explicite entre chaque modèle et son éditeur de confiance et des scans de l’environnement logiciel avant l’intégration de modèles à poids ouverts. Les dispositifs de sécurité englobent aussi bien Azure Direct Models que les modèles provenant de Hugging Face, en garantissant la traçabilité de leur origine. Chaque modèle est associé à son éditeur initial grâce aux contrôles de sourcing, cette information figurant sur la fiche dédiée, puis l’exécution se déroule dans les conteneurs Microsoft, lesquels font l’objet d’un scan indépendant pour repérer d’éventuelles failles critiques. L’ensemble de ces dispositifs a pour objectif de garantir à la fois la provenance du modèle et l’intégrité du logiciel utilisé.

Outils en préparation : red-teaming et scan de poids

Microsoft annonce travailler sur un système de scan des poids basé sur l’IA, des solutions de red-teaming permettant d’identifier des altérations inhabituelles, ainsi que sur la signature cryptographique des modèles assortie de journaux d’audit infalsifiables. La société précise avoir entamé la mise en place de recommandations et travailler conjointement avec ses équipes internes de sécurité IA afin d’établir un référentiel de red-teaming. Elle explore aussi l’usage d’agents de pointe pour fournir un signal supplémentaire lors de l’intégration de poids ouverts. Ces travaux s’inscrivent dans une collaboration continue entre chercheurs et équipes sécurité, et sont présentés comme une réponse aux problématiques nouvelles posées par les agents.

Une genèse expérimentale impliquant Claude Code

Le projet a démarré en mars par une expérience consistant à demander à Claude Code avec Opus 4.5 de créer une porte dérobée en câblant des activations, sans entraînement, ce qui a fonctionné et a lancé une étude de plusieurs mois. Les auteurs estiment que les poids devraient être audités comme du code et que les scans par agents de pointe, encore peu pratiqués, doivent se généraliser. Ils attribuent à Claude Code avec Opus 4.5 la découverte autonome de la plupart des éléments de la méthode.