Slopoly, le malware généré par IA qui s’invite dans les attaques Interlock ransomware

Après PromptSpy, qui exploitait Gemini pour assurer la persistance d’un malware Android, c’est au tour d’un acteur du ransomware de franchir le pas. En début d’année 2026, IBM X-Force a identifié Slopoly, un malware PowerShell vraisemblablement généré par un grand modèle de langage, déployé lors d’une attaque impliquant Interlock ransomware.

Techniquement modeste, Slopoly n’en est pas moins révélateur. Son déploiement par Hive0163, le groupe derrière le ransomware Interlock, suggère que l’IA est désormais activement mobilisée pour accélérer le développement de malwares sur mesure, potentiellement capables de contourner les défenses basées sur les signatures. Un signal débutant, mais dont les implications sont loin d’être négligeables.

Interlock, un acteur établi qui évolue

Interlock ransomware a émergé en 2024 et s’est rapidement distingué par une approche méthodique et une capacité d’adaptation continue. Le groupe opère sous le nom interne Hive0163 dans la nomenclature IBM X-Force : des acteurs à motivation financière dont l’objectif déclaré est l’extorsion par exfiltration massive de données combinée au chiffrement. Leurs cibles ne sont pas anodines. Le système universitaire Texas Tech, la chaîne de dialyse DaVita, l’établissement de santé Kettering Health et la ville de Saint Paul (Minnesota) font partie des victimes revendiquées.

Sur le plan technique, le groupe s’est distingué comme adopteur précoce de ClickFix, une technique d’ingénierie sociale redoutablement efficace dans sa simplicité. La victime est confrontée à une fausse page de vérification de type CAPTCHA qui charge un script malveillant dans son presse-papiers, puis lui demande de l’exécuter manuellement. Aucun exploit de navigateur, aucune vulnérabilité zero-day : juste une manipulation comportementale. Interlock a également adopté une variante baptisée FileFix, et repose par ailleurs sur des courtiers en accès initial comme TA569 (SocGholish) et TAG-124.

L’évolution de l’arsenal ne s’arrête pas aux techniques d’ingénierie sociale. L’équipe FortiGuard IR a documenté en janvier 2026 une intrusion dans laquelle Hive0163 a déployé Hotta Killer, un outil inédit de type BYOVD (Bring Your Own Vulnerable Driver) exploitant une zero-day dans un driver anti-cheat de jeu vidéo (CVE-2025-61155). Renommé UpdateCheckerX64.sys, ce driver noyau sert à identifier et terminer les processus des solutions EDR et antivirus ciblés, dans ce cas, les outils Fortinet. Le groupe a par ailleurs utilisé ScreenConnect comme outil de mouvement latéral après que son accès via des backdoors ait été gêné par les défenses en place, démontrant une capacité à pivoter tactiquement en cours d’opération.

Slopoly : quand l’IA écrit le code malveillant

Au début de l’année 2026, IBM X-Force a répondu à un incident impliquant Interlock et a mis la main sur quelque chose d’inhabituel : un script PowerShell déployé sur un serveur compromis, constituant le composant client d’un framework C2 (commande et contrôle) inédit. Les chercheurs l’ont baptisé Slopoly.

Ce qui frappe immédiatement à l’analyse, c’est le style du code lui-même. Commentaires abondants et structurés, gestion d’erreurs soignée, nommage des variables parfaitement lisible et logique, journalisation détaillée : autant de caractéristiques inhabituelles dans un malware développé par un humain pressé de ne pas laisser de traces. Pour IBM, ces marqueurs constituent de forts indicateurs d’une génération par un grand modèle de langage (LLM). Les chercheurs précisent que le script “contient une fonction Jitter inutilisée, qui pourrait être le résultat d’un développement itératif assisté par un modèle de langage de grande envergure (LLM)”. L’équipe n’a pas pu identifier quel modèle spécifique a été utilisé, mais estime, au vu de la qualité du résultat, qu’il s’agit d’un modèle relativement peu avancé.

Un détail révélateur : le script se décrit lui-même dans ses commentaires comme un “Polymorphic C2 Persistence Client”. Or, IBM X-Force est formel, Slopoly n’est pas polymorphe. Il est incapable de modifier son propre code en cours d’exécution. Ce que le terme recouvre en réalité, c’est la capacité d’un builder à générer de nouveaux clients avec des valeurs de configuration aléatoires différentes, des noms de fonctions randomisés, et des identifiants de session distincts. C’est une pratique courante chez les développeurs de malwares, mais l’IA a visiblement “surestimé” ses propres capacités dans la documentation du code qu’elle produisait. Comme le note IBM : “D’un point de vue purement technique, le script est au mieux médiocre. Comme c’est souvent le cas avec les logiciels générés par l’IA, il prétend être plus avancé qu’il ne l’est en réalité.”

Ce que fait Slopoly concrètement

Slopoly est déployé dans C:\\ProgramData\\Microsoft\\Windows\\Runtime\\ et assure sa persistance via une tâche planifiée nommée “Runtime Broker”, empruntant délibérément le nom d’un processus système légitime Windows pour passer inaperçu. Son comportement est celui d’une backdoor fonctionnelle bien que basique. Les fonctions principales sont les suivantes :

• collecte d’informations système (adresse IP publique, nom de machine, nom d’utilisateur, statut d’élévation de privilèges) transmises en JSON à l’endpoint /api/commands du serveur C2 ;
• envoi d’un beacon heartbeat toutes les 30 secondes ;
• interrogation du serveur pour de nouvelles commandes toutes les 50 secondes ;
• exécution des commandes reçues via cmd.exe et renvoi des résultats ;
• maintien d’un fichier journal rotatif persistence.log, remis à zéro au-delà de 1 Mo.

Les commandes supportées permettent de télécharger et d’exécuter des fichiers EXE, DLL ou JavaScript, d’exécuter des commandes shell, de modifier les intervalles de beacon, de mettre à jour le malware ou d’en terminer le processus.

Sans sophistication particulière, le framework offre néanmoins un contrôle opérationnel suffisant : exécution de fichiers EXE, DLL ou JavaScript, commandes shell avec retour des résultats, pilotage des intervalles de beacon et arrêt ou mise à jour du client à distance.

La chaîne d’attaque : ClickFix comme point d’entrée, un arsenal en couches

L’intrusion analysée par IBM illustre parfaitement la méthodologie en couches d’Hive0163. L’accès initial est obtenu via ClickFix, qui installe NodeSnake : un malware Node.js constituant le premier étage d’un framework C2 plus large. NodeSnake constitue le premier maillon d’un framework modulaire : capable de s’ancrer durablement sur le système et de télécharger les composants suivants à la demande, il prépare le terrain pour les étages plus avancés de l’intrusion.

En deuxième étage, NodeSnake déploie InterlockRAT, une backdoor JavaScript bien plus capable, communiquant via WebSockets. Ses fonctionnalités avancées incluent notamment l’établissement d’un tunnel SOCKS5 et la mise en place d’un reverse shell direct sur la machine infectée. Les deux composants utilisent des serveurs C2 hybrides : une liste de domaines Cloudflare tunnelisés et quelques adresses IP hardcodées.

C’est ensuite via cette infrastructure que Slopoly est déployé, accompagné d’outils classiques des incidents de ransomware : AzCopy pour l’exfiltration et Advanced IP Scanner pour la reconnaissance réseau. La charge utile finale, le ransomware Interlock lui-même, est distribuée via le loader JunkFiction. Ce binaire Windows 64 bits peut s’exécuter en tant que tâche planifiée SYSTEM, utilise l’API Windows Restart Manager pour libérer les fichiers verrouillés avant chiffrement, et appende l’extension .!NT3RLOCK ou .int3R1Ock aux fichiers chiffrés. Le chiffrement combine AES-GCM et RSA via la bibliothèque OpenSSL 3.5.0 liée statiquement.

Un test en conditions réelles, pas encore une arme déployée à grande échelle

Le fait que Slopoly soit apparu en fin de chaîne d’attaque, alors que le groupe disposait déjà de plusieurs backdoors opérationnelles, ne doit pas passer inaperçu. IBM X-Force interprète ce déploiement comme un exercice en conditions réelles plutôt que comme une utilisation opérationnelle mature. Ce n’est pas tant la présence de Slopoly qui interpelle que sa position dans la chaîne : déployé en dernière étape, en doublon d’outils déjà fonctionnels, il ressemble moins à une pièce maîtresse qu’à un composant en phase de rodage sur un terrain d’opération réel. Le serveur C2 associé, plurfestivalgalaxy[.]com (94.156.181.89), n’est plus actif. Les chercheurs n’ont pas pu récupérer les commandes effectivement exécutées pendant la semaine que le malware a passée sur le serveur infecté.

Cette durée s’inscrit dans un schéma plus large documenté par Fortinet : lors d’une autre intrusion analysée par FortiGuard IR, le groupe a maintenu un accès furtif pendant plus de six mois entre le premier pied dans l’environnement (mars 2025) et le déclenchement du chiffrement (octobre 2025), le temps de cartographier le réseau, d’exfiltrer les données et de préparer le déploiement du ransomware. La patience est une signature du groupe, et Slopoly s’inscrit dans cette logique de présence prolongée et discrète.

Autre signal à ne pas sous-estimer : les garde-fous du modèle d’IA ont été contournés. Le nommage des variables dans le code indique clairement que le modèle avait compris qu’il développait un outil à usage malveillant. IBM ne sait pas quel LLM a été utilisé, mais la génération d’un malware fonctionnel malgré des mécanismes de sécurité supposément intégrés est en soi une donnée préoccupante.

Pour les chercheurs d’IBM : l’introduction de malwares générés par IA ne représente pas encore une sophistication technique accrue, mais constitue un multiplicateur de force en réduisant drastiquement le temps et les ressources nécessaires au développement. Une conclusion que le rapport Global Incident Response 2026 de l’Unit 42 de Palo Alto Networks prolonge à l’échelle de plus de 750 incidents : en 2025, l’IA est passée du stade expérimental à un usage opérationnel courant chez les acteurs de la menace, compressant le cycle d’attaque et permettant de mener plusieurs opérations en parallèle avec moins de contraintes humaines.

Ce que Slopoly préfigure pour le secteur

Le cas Slopoly s’inscrit dans un contexte plus large d’adoption croissante de l’IA par les groupes cybercriminels. IBM X-Force note que des acteurs étatiques ou très bien équipés expérimentent déjà les stades suivants : l’IA agentique, capable de prendre des décisions autonomes tout au long de la chaîne d’attaque, et les malwares intégrant directement l’IA dans leur logique d’exécution. Des cas comme PromptSpy, PromptLock ou VoidLink illustrent que ces expérimentations ne sont plus théoriques. Slopoly se situe, lui, dans la première phase d’adoption : l’IA comme outil d’accélération du développement. Ce qui rejoint les prédictions des experts pour l’année 2026.

Pour les équipes défensives, cette étude permet de tirer deux implications structurelles de cette évolution. D’abord, l’attribution va devenir plus difficile : un malware éphémère, re-généré à la demande avec des configurations et des noms de fonctions aléatoires, résiste aux techniques classiques de fingerprinting basées sur les similarités de code. Ensuite, les détections basées sur des signatures ne suffisent plus : un outil généré en quelques minutes n’a pas de signature connue. La réponse, selon IBM, passe par une priorité accordée aux détections comportementales et à la chasse aux indicateurs de compromission (IoC) associés au groupe.

Sur le plan pratique, IBM X-Force recommande notamment de désactiver la commande Win+R ou de surveiller la clé de registre RunMRU pour contrer ClickFix, vecteur initial de cette catégorie d’attaques.

Sources :

IBM X-Force : A Slopoly start to AI-enhanced ransomware attacks

BleepingComputer : AI-generated Slopoly malware used in Interlock ransomware attack

Fortinet Threat Research : Interlock Ransomware: New Techniques, Same Old Tricks

CISA / FBI : #StopRansomware: Interlock

Palo Alto Networks Unit 42 : 2026 Unit 42 Global Incident Response Report