UAC-0099 intègre un « prompt arme nucléaire » dans ses malwares pour aveugler les analystes IA

Le groupe pro-russe UAC-0099 a trouvé une parade originale contre l'analyse automatisée par LLM : planter dans ses malwares un prompt sur des armes nucléaires. Les outils IA déclenchent leurs filtres et refusent d'analyser - un jailbreak inversé qui retourne les garde-fous IA contre les défenseurs.

Quoi : GuardBreaker, un « jailbreak inversé » pour aveugler l'analyse IA

Le groupe UAC-0099, aligné avec la Russie et actif depuis 2022 contre des cibles ukrainiennes et leurs partenaires, a introduit une technique inédite dans ses malwares. Baptisée GuardBreaker par les chercheurs d'ESET, elle consiste à planter dans le code malveillant un prompt en langage naturel demandant conseil sur la fabrication d'armes nucléaires.

L'effet est immédiat et reproductible : les outils d'analyse automatique basés sur des LLM (Large Language Model) refusent d'analyser le fichier dès qu'ils détectent ce contenu, invoquant leurs politiques de sécurité sur les armes de destruction massive. L'analyste se retrouve avec un outil muet. Le malware passe entre les mailles.

La technique dans le détail

UAC-0099 insère le prompt dans des métadonnées, des commentaires ou des chaînes de caractères du binaire. Quand un analyste copie-colle le code dans un LLM ou utilise un plugin d'analyse automatique, le modèle lit ce contenu et déclenche son filtre de sécurité avant même d'analyser le code malveillant proprement dit.

GuardBreaker est une forme de jailbreak inversé : on n'essaie pas de contourner les filtres pour obtenir du contenu dangereux - on les déclenche délibérément pour neutraliser l'outil d'analyse adverse. Une utilisation cynique des garde-fous de sécurité des LLM contre leurs propres utilisateurs.

Qui est impacté

Tout analyste ou SOC (Security Operations Center) qui utilise des LLM comme aide à l'analyse de code suspect. Les plateformes de sandbox automatique intégrant des modèles IA sont également exposées si elles transmettent le contenu brut des fichiers aux modèles sans pré-filtrage.

Que faire

1. Ne jamais passer de fichiers suspects bruts à un LLM sans pré-filtrer les chaînes de caractères non-code (métadonnées, commentaires, ressources embarquées)
2. Utiliser des outils d'analyse statique classiques (IDA Pro, Ghidra, YARA) en parallèle des LLM - ils analysent les opcodes, pas le langage naturel
3. Sensibiliser les équipes SOC : si un LLM refuse d'analyser un fichier pour "raisons de sécurité", c'est un signal d'alerte, pas un résultat d'analyse. Chercher "GuardBreaker ESET" pour les IOCs et règles de détection.
4. Rapporter la technique aux éditeurs d'outils IA pour qu'ils adaptent leurs filtres aux contextes d'analyse de sécurité

À faire maintenant

Si un outil IA refuse d'analyser un fichier suspect en invoquant ses politiques de sécurité : ne pas conclure à une absence de menace. Passer immédiatement à l'analyse statique traditionnelle et traiter le refus lui-même comme un indicateur de compromis potentiel (IoC). Rechercher "GuardBreaker" dans les bases YARA et les threat feeds ESET.