Six agences publient le 10 août 2026 une synthèse technique sur le rançongiciel Gunra : exploitation d’équipements de bordure, double extorsion, contournement durable de l’authentification multifacteur, et une faiblesse de génération de clés exploitable dans le variant Linux.
Publié sous la référence AA26-222A, l’avis couvre la période allant d’avril 2025 à juillet 2026. Il décrit une opération passée en quatorze mois du statut de variant isolé à celui de plateforme commerciale dotée d’un panneau d’administration, d’un générateur de charge configurable et d’une politique de recrutement d’intermédiaires d’accès. Le document fournit également un élément rarement publié dans ce format : une voie de récupération de fichiers sans paiement, pour les victimes du variant Linux.
Je vous propose une synthèse de cette publication de la CISA entre autres. Je vous souhaite une bonne lecture.
Enjoy !
01. Origine : du code de Conti à Gunra
Le rançongiciel Gunra est observé pour la première fois en avril 2025 par le FBI (1). L’avis est cosigné par la CISA (2), le DC3 (3), la NSA (4), l’USSS (5) et la KNPA (6) sud-coréenne, ce qui indique une couverture d’incidents à la fois nord-américaine et asiatique.
Les agences rattachent Gunra au code source du rançongiciel Conti, divulgué en 2022, et retiennent la formulation prudente d’un code dérivé ou fortement influencé par cette fuite. Les premières campagnes visent des environnements Windows. Un variant Linux apparaît au milieu de l’année 2025 et étend le périmètre de ciblage.
Un site de divulgation, DLS (7), est établi sur Tor dès les premières semaines d’activité. Les victimes qui y sont publiées relèvent de la santé, des services financiers et de l’assurance, de l’industrie et de la construction, des transports et de la logistique, des services publics, des services aux collectivités, de l’enseignement supérieur, des médias, du commerce de détail, et des services professionnels et associatifs. Leur répartition géographique couvre les Amériques, l’Europe, le Moyen-Orient, l’Afrique et la zone Asie-Pacifique.
02. Industrialisation : le programme d’affiliation
En janvier 2026, l’opération formalise un programme d’affiliation RaaS (8), annoncé sur des forums clandestins. Les affiliés reçoivent un panneau de gestion, un générateur de charge configurable, des chiffreurs pour Windows et Linux, ainsi qu’une documentation structurée.
Deux éléments méritent d’être relevés. D’une part, l’adoption d’un alias de marque, Golden Community, employé pour accompagner cette expansion. D’autre part, une politique de recrutement visant explicitement des testeurs d’intrusion, rémunérés par une part de la rançon en échange d’accès à des réseaux d’entreprise. L’accès initial devient ainsi un poste externalisé du modèle économique.
03. Accès initial : les équipements exposés
Le FBI (1) observe un accès initial obtenu principalement par exploitation de vulnérabilités connues sur des équipements exposés sur Internet, en particulier des pare-feu et des concentrateurs d’accès distant. Deux CVE (9) sont citées, toutes deux classées CWE (10) 288, contournement d’authentification par chemin alternatif, et affectant certaines versions de FortiOS et FortiProxy :
| Référence | Nature | Périmètre |
|---|---|---|
| CVE-2024-55591 | Contournement d’authentification | FortiOS, FortiProxy |
| CVE-2025-24472 | Contournement d’authentification | FortiOS, FortiProxy |
L’exploitation de ces deux failles permet d’abuser des tâches planifiées de l’équipement pour créer un compte persistant nommé forticloud-sync, doté de privilèges de super-administrateur et d’un mot de passe codé en dur. Ce nom de compte constitue à lui seul un indicateur de recherche prioritaire sur un parc Fortinet.
La KNPA (6) documente une seconde voie d’entrée : l’exploitation de défauts de contrôle d’accès SSH (11) et d’expositions d’identifiants sur des passerelles d’accès distant exposées. Dans un cas, les acteurs Gunra obtiennent un compte administrateur sur un équipement d’accès distant SSL (12) en réutilisant des identifiants par défaut, en l’absence de mécanisme de verrouillage de compte après échecs répétés.
04. Persistance, identifiants et contournement de l’authentification multifacteur
La séquence documentée par la KNPA (6) sur un même incident constitue la partie la plus instructive de l’avis, parce qu’elle décrit une compromission de la chaîne d’authentification elle-même, et non un simple vol d’identifiants.
Après accès à la console d’administration de l’équipement d’accès distant, les acteurs Gunra identifient un compte inutilisé disposant d’une visibilité sur le réseau exposé et sur le réseau interne. Ils modifient la configuration de ce compte pour neutraliser l’obligation de changement de mot de passe, puis l’emploient pour la suite des opérations.
Ils manipulent ensuite la fonction de contrôle du trafic de l’équipement d’accès distant afin de capter les identifiants et les informations de session transmis par les utilisateurs vers le portail d’authentification de l’infrastructure de bureaux virtuels. Les cookies de session ainsi collectés servent à usurper des sessions légitimes et à atteindre le réseau interne.
Sur ce même portail d’authentification, les fichiers de traitement de l’authentification sont modifiés pour qu’une valeur de mot de passe à usage unique, OTP (13), choisie par les acteurs Gunra soit systématiquement acceptée. Le résultat est une porte dérobée persistante qui neutralise l’authentification multifacteur, MFA (14), sans altérer le fonctionnement apparent du service.
Les acteurs Gunra accèdent également, en SSH (11) depuis un bureau virtuel compromis, à un serveur de contrôle d’accès Hiware, et y dérobent une clé de chiffrement symétrique stockée localement. Cette clé permet de déchiffrer les mots de passe des comptes de serveurs d’entreprise conservés en base, donc d’obtenir des identifiants valides sur l’ensemble du parc serveur.
Le reste de la progression interne s’appuie sur des outils publics :
- déplacement latéral en SMB (15) au moyen des bibliothèques Impacket
psexec.pyetsmbclient.py; - extraction des empreintes de mots de passe depuis les fichiers NTDS (16) des contrôleurs de domaine, au moyen de
secretsdump.py, puis réutilisation par pass-the-hash et pass-the-ticket ; - déplacement en RDP (17) depuis l’environnement de bureaux virtuels, VDI (18), vers le serveur web d’authentification, le serveur Active Directory, AD (19), et les postes virtuels des équipes informatiques ;
- téléchargement d’OpenSSH depuis un serveur contrôlé par les acteurs Gunra, puis établissement de tunnels chiffrés pour maintenir l’accès.
05. Discrétion et logique de sélection avant chiffrement
Les mesures d’évitement décrites sont classiques dans leur principe, mais leur combinaison réduit sensiblement la surface de détection.
Les acteurs Gunra suppriment les journaux système et réseau et effacent l’historique des commandes. Leur activité de reconnaissance interne est concentrée entre 22 h 00 et 06 h 00, plage sur laquelle la supervision humaine est généralement réduite.
Le binaire Windows, de son côté, est autonome : il réalise le chiffrement complet des volumes sans générer d’indicateur réseau observable, ni résolution de nom ni trafic HTTP. Il embarque l’appel IsDebuggerPresent pour détecter une exécution sous débogueur et gêner la rétro-ingénierie.
L’énumération du système de fichiers repose sur les API (20) natives FindFirstFileW et FindNextFileW, appliquées à l’ensemble des lettres de lecteur, de A à Z. Une logique de filtrage en deux temps est appliquée :
- exclusion des répertoires système, notamment
C:\Windows,C:\Program FilesetC:\Program Files (x86); - exclusion des extensions critiques au fonctionnement du système, notamment
.exe,.dllet.sys.
Les fichiers retenus, documents, bases, images et archives, sont placés en file d’attente de chiffrement. Le binaire évite par ailleurs de chiffrer ses propres notes de rançon et de traiter deux fois un fichier déjà chiffré. Cette économie de ressources est un choix opérationnel : elle accélère l’opération et limite le bruit.
06. Exfiltration, chiffrement et double extorsion
La collecte précède le chiffrement. Les acteurs Gunra récupèrent des documents d’exploitation, des bases de données, des données à caractère personnel, PII (21), et des messageries internes. Un exécutable dédié, main.exe, cible spécifiquement les espaces OneDrive et SharePoint.
Les données sont archivées puis transférées vers le service Mega. Le volume exfiltré atteint plusieurs dizaines de téraoctets sur au moins un incident. Les outils publics identifiés sur l’infrastructure des acteurs Gunra comprennent 7-Zip, WinRAR, RClone, FileZilla pour un transfert en FTP (22), ainsi qu’Amass, Sliver, Mimikatz, DBeaver, MobaXterm, AnyDesk, Google Remote Desktop, Slack et Visual Studio Code.
Le chiffrement combine ChaCha20 et RSA-4096, sur une architecture multi-fils qui traite plusieurs fichiers en parallèle. L’extension appliquée est .ENCRT ; un échantillon de juillet 2025 emploie .CRYPT, et le variant Linux applique .GNRA. Une note de rançon nommée R3ADM3.txt est déposée dans chaque répertoire traité.
L’inhibition de la restauration repose sur deux actions distinctes. La première est la suppression des clichés instantanés de volume, initiée en WMI (23) depuis l’interpréteur de commandes :
cmd.exe /c C:\Windows\System32\wbem\WMIC.exe shadowcopy where "ID='{guid of shadowcopy}'" delete
La seconde, observée sur un incident, est la destruction des sauvegardes et des archives stockées sur l’infrastructure de sauvegarde, à la fois sur le site principal et sur le site de secours, avant et après le déploiement du rançongiciel. Sur ce même incident, les actifs chiffrés incluent des serveurs de bases de données et des systèmes de stockage en réseau, NAS (24).
La phase de négociation suit un schéma stable. La victime est dirigée vers un portail Tor, où lui sont attribués un identifiant client et un mot de passe initial, puis vers l’application de messagerie chiffrée qTox. Le délai annoncé est de cinq à sept jours. Les montants initialement demandés dépassent plusieurs dizaines de millions de dollars. Le FBI (1) observe également des prises de contact directes par courriel auprès des dirigeants des entreprises visées, avec un succès limité.
En cas d’absence de paiement, la victime est publiée sur le DLS (7) avec un aperçu qui se limite à l’arborescence des fichiers OneDrive et SharePoint exposés, sans leur contenu. Un miroir sur Internet ouvert, datapub[.]news, a été exploité entre juin et juillet 2025. En mars 2026, le site a été déplacé vers une nouvelle adresse en .onion, sur laquelle les acteurs Gunra proposent désormais la vente de jeux de données à des tiers.
07. Réponse, remédiation et faiblesse du variant Linux
L’élément le plus directement exploitable par un défenseur figure dans la section de réponse à incident. En mars 2026, une faiblesse a été identifiée dans les variants Linux au format ELF (25) : les clés de chiffrement sont produites par un générateur de nombres pseudo-aléatoires, PRNG (26), initialisé par srand(time(NULL)). La graine étant prévisible, les clés peuvent être reconstruites mathématiquement à partir des horodatages de fichiers, et les fichiers récupérés sans paiement.
La conséquence opérationnelle est immédiate : sur un incident impliquant le variant Linux, les fichiers chiffrés, les horodatages, les notes de rançon et les journaux système doivent être préservés en priorité, avant toute action de remédiation susceptible de les altérer.
Les autres actions de réponse recommandées sont les suivantes :
- isoler les hôtes compromis, par mise en quarantaine ou déconnexion ;
- lancer une recherche de compromission pour délimiter l’intrusion, en collectant les artefacts, les journaux et une chronologie d’activité ;
- examiner les journaux des équipements de bordure pour auditer les actions associées aux comptes à privilèges ;
- collecter les notes de rançon afin d’identifier les canaux de communication en cours d’emploi ;
- auditer la création de fichiers récents, en particulier les archives, pour caractériser une exfiltration ;
- identifier et désactiver les comptes contrôlés par les acteurs Gunra, sécuriser les comptes à privilèges légitimes ;
- construire un plan d’éviction au moyen des outils Playbook-NG et COUN7ER de la CISA (2).
Les mesures préventives sont rattachées aux objectifs de performance CPG (27) :
| Mesure | Référence CPG (27) |
|---|---|
| Corriger en priorité les vulnérabilités connues exploitées sur les systèmes exposés, y compris les passerelles d’accès distant et les infrastructures exposant RDP (17) | 2.B |
| Maintenir plusieurs copies des données sensibles sur un emplacement physiquement séparé, segmenté et sécurisé | 3.I, 3.O, 1.C |
| Vérifier l’absence de comptes non reconnus sur les contrôleurs de domaine, serveurs, postes et annuaires | 2.A, 2.E |
| Auditer les comptes à privilèges et appliquer le moindre privilège | 3.G |
| Segmenter le réseau pour contenir la propagation | 3.I |
| Imposer l’authentification multifacteur MFA (14) sur l’ensemble des services, en priorité la messagerie web, l’accès distant et les accès aux systèmes critiques | 3.F |
| Restreindre les activités et permissions en ligne de commande et de script | 3.G, 3.M |
Annexe : indicateurs de compromission
Les agences signalent que ces indicateurs peuvent être historiques et recommandent de les qualifier avant tout blocage.
Fichiers malveillants, SHA-256
| Nom | Empreinte | Rôle |
|---|---|---|
| main.exe | 2dc70a12d158d437e45a55b1d52f3d61c6082a1e1667573302ba3b62813e2751 | Exfiltration OneDrive et SharePoint |
| main.exe | 834efe9b392c6c000877ea5613a079445affc16fe8af5997d68c55cafc95e5d1 | Exfiltration OneDrive et SharePoint |
| cryptor.exe | 91f8fc7a3290611e28a35a403fd815554d9d856006cc2ee91ccdb64057ae53b0 | Exécutable malveillant |
| msmp.exe | a82e496b7b5279cb6b93393ec167dd3f50aff1557366784b25f9e51cb23689d9 | Exécutable malveillant |
Domaines et services cachés
| Indicateur | Première observation | Dernière observation |
|---|---|---|
datapub[.]news | juin 2025 | juillet 2025 |
gunrabxbig445sjqa535uaymzerj6fp4nwc6ngc2xughf2pedjdhk4ad[.]onion | avril 2025 | février 2026 |
nsnhzysbntsqdwpys6mhml33muccsvterxewh5rkbmcab7bg2ttevjqd[.]onion | janvier 2026 | janvier 2026 |
lgiil72vkmdtbc3qv4tyq6wedyjxqr2qd4ze7xl2cxgerdnymxj7soqd[.]onion | mars 2026 | juillet 2026 |
Adresses IP
| Adresses | Période |
|---|---|
23.239.119[.]2 à 23.239.119[.]6 | juillet 2025 à novembre 2025 |
86.54.28[.]216 | juin 2025 à juillet 2025 |
67.43.53[.]10, 70.36.99[.]82, 91.201.66[.]146, 103.125.234[.]14, 123.184.143[.]105, 123.244.187[.]144, 123.246.37[.]108, 182.204.16[.]112, 182.204.21[.]240, 182.204.39[.]118, 211.21.210[.]181 | novembre 2025 à décembre 2025 |
Adresses de messagerie employées pour la négociation
a00f105546345756@proton[.]me 4569f6322bc3b22e9@proton[.]me 6449a3c1e612168526@proton[.]me ilovemycubscout@gmail[.]com
Autres artefacts
| Type | Valeur |
|---|---|
| Compte créé sur équipement Fortinet | forticloud-sync |
| Note de rançon | R3ADM3.txt |
| Extensions de chiffrement | .ENCRT, .CRYPT, .GNRA |
Quatre identifiants qTox sont également publiés dans l’avis d’origine.
Annexe : écarts relevés dans le document source
Deux incohérences internes sont à signaler avant réutilisation des indicateurs.
La note de rançon est désignée R3ADM3.txt dans le corps de l’avis et R34DM3.txt dans le tableau de correspondance MITRE ATT&CK associé à la technique T1657. La première graphie est employée deux fois, la seconde une seule fois.
Le troisième identifiant qTox publié contient le caractère S en trentième position, alors que ce format n’admet que des caractères hexadécimaux. Il s’agit vraisemblablement d’une erreur de transcription, à vérifier auprès de la source avant intégration dans un moteur de détection.
Lexique des acronymes
| N° | Acronyme | Développement |
|---|---|---|
| 1 | FBI | Federal Bureau of Investigation |
| 2 | CISA | Cybersecurity and Infrastructure Security Agency |
| 3 | DC3 | Department of Defense Cyber Crime Center |
| 4 | NSA | National Security Agency |
| 5 | USSS | United States Secret Service |
| 6 | KNPA | Korean National Police Agency |
| 7 | DLS | Dedicated Leak Site, site de divulgation dédié |
| 8 | RaaS | Ransomware-as-a-Service, rançongiciel en tant que service |
| 9 | CVE | Common Vulnerabilities and Exposures |
| 10 | CWE | Common Weakness Enumeration |
| 11 | SSH | Secure Shell |
| 12 | SSL | Secure Sockets Layer |
| 13 | OTP | One Time Password, mot de passe à usage unique |
| 14 | MFA | Multi-Factor Authentication, authentification multifacteur |
| 15 | SMB | Server Message Block |
| 16 | NTDS | NT Directory Services |
| 17 | RDP | Remote Desktop Protocol |
| 18 | VDI | Virtual Desktop Infrastructure, infrastructure de bureaux virtuels |
| 19 | AD | Active Directory |
| 20 | API | Application Programming Interface, interface de programmation |
| 21 | PII | Personally Identifiable Information, données à caractère personnel |
| 22 | FTP | File Transfer Protocol |
| 23 | WMI | Windows Management Instrumentation |
| 24 | NAS | Network Attached Storage, stockage en réseau |
| 25 | ELF | Executable and Linkable Format |
| 26 | PRNG | Pseudorandom Number Generator, générateur de nombres pseudo-aléatoires |
| 27 | CPG | Cross-Sector Cybersecurity Performance Goals |
Sources
- CISA, FBI, DC3, NSA, USSS et KNPA, « #StopRansomware: Gunra Ransomware », avis AA26-222A, 10 août 2026. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-222a
- Breakglass Intelligence, « Gunra Ransomware’s Linux Variant Has a Fatal Flaw », 12 mars 2026.
- CloudSEK, « Inside Gunra RaaS: From Affiliate Recruitment on the Dark Web to Full Technical Dissection of their Locker », 11 février 2026.
- Trend Micro, « Gunra Ransomware Group Unveils Efficient Linux Variant », 29 juillet 2025.
- CYFIRMA, « Gunra Ransomware, A Brief Analysis », 3 mai 2025.
