Aurora, le ransomware qui utilise Cursor : des mois d’attaques conçues avec Claude Sonnet

Le répertoire ouvert d’une infrastructure attribuée au groupe Aurora a permis à CloudSEK et Gambit Security de reconstituer des mois d’activité : plus de vingt organisations touchées entre avril et juillet 2026, dix cibles contre lesquelles l’agent de Cursor a été utilisé et un chiffreur écrit en Zig pour Windows, Linux et ESXi. Les historiques de chat récupérés montrent que l’opérateur planifiait les attaques en russe et confiait à Claude Sonnet des tâches opérationnelles concrètes, pas seulement des scripts génériques.

L’exposition de l’infrastructure et les victimes recensées

CloudSEK a identifié un répertoire ouvert qui a laissé visibles des mois d’activité du groupe russophone connu sous le nom d’Aurora ou Aur0ra. Les données font état de plus de vingt organisations dans neuf pays, attaquées entre avril et juillet 2026 ; quatre victimes sont ensuite apparues sur le site de fuite de données du groupe. L’opérateur utilisait Cursor pour planifier les attaques en russe, en excluant sans exception les adresses IP et les domaines des pays de la Communauté des États indépendants.

Aurora est apparu publiquement fin mai 2026, lorsque CYFIRMA décrivait ses attaques visant surtout des systèmes Windows et une mise à jour continue des fonctionnalités. Selon le site Ransomware.Live, au 31 août 2026, les victimes recensées sont au nombre de 33, concentrées principalement aux États-Unis, en Allemagne, aux Pays-Bas, au Canada et au Royaume-Uni.

Les noms des entreprises touchées n’ont pas été divulgués par les sociétés de sécurité, mais Reuters a cité Christeyns, Teckentrup, Helideck Certification Agency, Bayou Title, un distributeur pharmaceutique argentin et un fabricant italien.

La chaîne d’attaque, de l’email bombing au chiffreur

Black Hills Information Security a reconstitué un cas début août 2026. L’accès initial a été obtenu au moyen d’un email bombing agressif, suivi d’appels téléphoniques au cours desquels l’attaquant se faisait passer pour du personnel du help desk informatique. Après avoir convaincu la victime, le groupe a établi un accès distant via Xray-core, un utilitaire open source.

À partir de là, la chaîne se poursuit par un déplacement latéral via SMB, LDAP, WinRM, RDP et RPC, l’acquisition de comptes administrateur à hauts privilèges, la suppression des journaux et la désactivation de Microsoft Defender. Ce n’est qu’ensuite qu’interviennent l’exfiltration des données sensibles et la distribution du chiffreur.

Comment l’opérateur utilise Cursor Agent sur les dix cibles

Gambit Security a observé l’opérateur Aurora utiliser Cursor Agent, qui exécute Claude Sonnet d’Anthropic, pour des activités pratiques d’exploitation contre dix cibles entre le 8 avril et le 21 mai 2026. Dans ces cas, l’agent recevait des identifiants ou une voie d’accès déjà existante vers l’organisation victime, puis se voyait confier des tâches d’exploitation.

Parfois, l’attaquant demandait simplement à l’agent d’atteindre un objectif, par exemple « dis-moi quels sont les droits de l’utilisateur ». Dans d’autres cas, il indiquait l’outil à utiliser ou imposait de suivre un plan d’attaque pré-généré. Dans certaines situations, l’agent proposait une liste d’étapes suivantes et l’attaquant répondait par un numéro.

Les tâches déléguées comprenaient :

• l’installation d’un client VPN ou de proxychains, la configuration et la connexion à la victime avec des identifiants fournis ou via un tunnel SOCKS existant ;
• l’analyse des sous-réseaux internes avec Nmap ou NetExec ;
• l’énumération du domaine pour rapporter les privilèges d’un utilisateur spécifique, en utilisant le collecteur BloodHound de NetExec ;
• des tentatives d’attaque NTLM relay en forçant l’authentification avec PetitPotam, Coerce Plus et PrinterBug, à l’aide d’Impacket ntlmrelayx pour relayer l’authentification résultante ;
• des attaques contre les certificats avec Certipy.

La plupart des commandes n’atteignaient pas l’objectif du premier coup : il fallait affiner continuellement commandes et scripts. Certaines finissaient par aboutir, d’autres échouaient et ne renvoyaient à l’attaquant qu’un rapport des tentatives.

Les historiques de chat montrent également un plan complet d’exploitation d’Active Directory Certificate Services rédigé en russe, signe que Cursor était utilisé pour concevoir des phases entières de la campagne.

Le chiffreur Zig partagé entre Windows, Linux et ESXi

CloudSEK a identifié des versions Windows et Linux d’Aurora écrites en Zig. Les deux binaires — sap.exe pour Windows et encrypt.out pour Linux/ESXi — sont des builds statiques issus d’une même base de code Zig compilée pour différentes cibles, et non une réécriture séparée. Le binaire Windows contient en interne des exemples d’utilisation de la build Linux, vestige d’une arborescence source partagée.

La variante Windows empêche la restauration du système en supprimant les clichés instantanés de volume et en désactivant la restauration du système directement via le Registre. La variante Linux/ESXi tente quant à elle de forcer l’arrêt de chaque machine virtuelle présente sur l’hôte avant de lancer le chiffrement.

Dans les campagnes impliquant la version Linux, un script Python nommé esxi_finder.py a été utilisé pour localiser les hyperviseurs VMware ESXi et les serveurs vCenter sur le réseau de la victime.

Une clé récupérée du chiffreur aurait permis d’accéder à une négociation de rançon et à un cluster de quatre portefeuilles de cryptomonnaie. Les données montrent des répartitions variables : les affiliés reçoivent entre 54 % et 79 % de la rançon, proportion décidée pour chaque victime selon le montant demandé et les revenus de l’organisation ; le reste revient aux administrateurs.

Gryxa, le toolkit construit par l’IA contre 324 hôtes

ReliaQuest a découvert un toolkit distinct, appelé Gryxa, utilisé par un acteur motivé financièrement pour une opération d’accès initial contre 324 hôtes. Selon les chercheurs, c’est le premier cas observé où l’IA a construit l’intégralité de l’opération, du toolkit à la console de gestion.

Gryxa transforme des logiciels légitimes de remote monitoring and management (RMM) en accès furtif, maintient la persistance à l’aide de mécanismes de redémarrage indépendants et vole les identifiants enregistrés dans les navigateurs basés sur Chromium. Lorsque la connexion avec l’attaquant est interrompue, il tente de désactiver ou de désinstaller l’agent de protection des points de terminaison, par exemple Microsoft Defender, dans les 10 à 13 minutes. Lorsque le relais redevient joignable, il réactive Defender.

Les éléments indiquent que l’acteur a jailbreaké un agent de codage IA, en présentant le développement comme un « déploiement interne autorisé ». Le toolkit est probablement distribué par email de phishing ; une fois exécuté, il met en place la persistance au moyen de tâches planifiées et peut contourner les protections de chiffrement lié à l’application (app-bound encryption) de Chromium. Les identifiants collectés sont transmis via Telegram.

L’aspect le plus inhabituel est l’enregistrement des activités de remédiation : après la suppression de l’implant RMM visible, un composant caché collecte les journaux Windows et les artefacts de l’hôte, puis les téléverse vers l’infrastructure de l’attaquant. La console inclut une tâche prédéfinie appelée collect-forensics, ce qui indique une capacité de routine et non une réponse à un incident unique. Gryxa fait pivoter les fichiers journaux lorsqu’ils dépassent 200 Ko, préservant ainsi l’activité récente pour les intervenants rapides.

Défense : quoi chercher et pourquoi les garde-fous ne suffisent pas

Aucune recommandation de mitigation spécifique publiée par les chercheurs n’est disponible. Le tableau technique fournit néanmoins des indicateurs utiles pour les défenseurs : trafic vers Xray-core, présence de Nmap, NetExec, BloodHound, Certipy ou Impacket ntlmrelayx, tentatives d’attaque NTLM relay et modifications anormales des clichés instantanés ou du Registre. Dans le cas de Gryxa, il convient de surveiller les processus RMM non autorisés, les tâches planifiées suspectes et l’envoi d’archives via Telegram.

Le cas Aurora montre que les garde-fous des fournisseurs de modèles d’IA n’ont pas empêché l’utilisation opérationnelle de Cursor Agent. L’attaquant n’a pas eu besoin d’écrire des exploits originaux : il a fourni à l’agent des accès déjà valides et l’a guidé avec des objectifs, des numéros et des plans pré-générés. Le risque n’est pas une IA qui deviendrait autonome, mais une IA qui abaisse le coût de chaque étape au sein d’un réseau déjà compromis.