SalatStealer : des chargeurs qui publient leurs clés, une configuration C2 identique sur 204 builds et un repli sur la blockchain TON

Catégorie : Infostealer

Analyste : Gordon PEIRS (@ozer0x777)

Famille : SalatStealer (aussi suivi sous le nom WEB_RAT), voleur et outil d'accès distant en Go, avec une réécriture en Rust

Méthode : Analyse purement statique (désassemblage, extraction de configuration, YARA) de 16 fichiers téléchargés individuellement, des 75 scripts batch et de 204 builds UPX publiés sur MalwareBazaar sous l'étiquette SalatStealer entre le 2026-10-27 et le 2026-10-30, complétée par de l'OSINT strictement passif (journaux de transparence des certificats, RDAP, DNS public, abuse.ch, historique public de la blockchain TON via tonapi.io, RIPEstat, API publique anonyme de GitHub pour les métadonnées de comptes, AlienVault OTX et rapports publics de CYFIRMA et de Solar 4RAYS). Aucun échantillon n'a été exécuté. Aucune connexion directe n'a été ouverte vers un serveur de l'opérateur, ni vers les comptes GitHub qui hébergeaient les secondes charges.

Résumé

SalatStealer (aussi suivi sous le nom WEB_RAT) est un voleur et outil d'accès distant écrit en Go, compilé pour Windows 32 bits (module salat, Go 1.24.0). Les rapports publics décrivent déjà ses capacités, une partie de sa configuration et les portefeuilles TON de son infrastructure (CYFIRMA en septembre 2025, Solar 4RAYS le 24 septembre 2026). Cette analyse recoupe ces sources de façon indépendante et ajoute ce qui les entoure : comment le voleur arrive (dépôts GitHub jetables, paquets de contournement de blocage piégés, trois formes de conteneurs), comment sa configuration est protégée, et ce que le tout laisse voir de l'opérateur et de ses paiements.

Le vecteur est un paquet de contournement de blocage piégé. Le script batch est un zapret-discord.bat glissé dans une copie d'un bundle public de contournement de blocage Discord et YouTube (le README cite le projet d'origine) : le reste du paquet est légitime, y compris le winws.exe dont le hash est identique à celui qu'un binder .NET du tag utilise comme leurre. Le fichier ajouté n'est pas listé dans le SHA256SUMS.txt du paquet. Les 75 scripts batch du tag décodent tous vers le même PE (fcaf1f46...) ; leur seule différence est un commentaire final de 16 caractères hexadécimaux. Les autres leurres du tag sont dans le même thème : un binder .NET qui embarque winws.exe, un RAT Python déguisé en « SoundCloud Unblock » et un chargeur nommé TgWsProxy.exe (le README du paquet recommande un outil nommé tg-ws-proxy).

Les chargeurs publient leurs propres secrets. Une partie des échantillons n'est pas Salat mais un chargeur Go qui contient la charge chiffrée en ChaCha20-Poly1305 (blob CBOR de 48 à 79 morceaux), puis télécharge une seconde charge sur une release GitHub. La clé de 32 octets et l'URL de la seconde charge sont passées en -ldflags "-X main.pass=... -X main.url=...". L'option -s -w retire les symboles mais pas ces informations de build, de sorte que la clé se lit avec un simple strings. Un extracteur qui essaie toutes les chaînes de 64 caractères hexadécimaux et laisse le tag Poly1305 trancher déchiffre les 6 chargeurs essayés (aucune adresse figée).

La configuration C2 de Salat est la même dans 204 builds sur 204. La protection est un enchaînement de couches (clé AES dérivée de la chaîne biba, clé XOR de 26 octets elle-même chiffrée, adresses stockées comme messages RSA-4096 à exposant public 65537) dont le module et les clés sont dans le binaire : un analyste qui a le fichier récupère tout. Résultat sur les 204 builds : un seul module RSA, un seul jeu de 10 entrées (quatre domaines HTTPS, un port alternatif, quatre noms .ton et un point d'accès TON), une seule version de Go. Seul l'identifiant de build bld varie : 13 valeurs, dont une porte 192 échantillons. Le même module RSA signe aussi la configuration de 76 builds Go plus anciens du tag salat (du 2026-03-22 au 2026-10-18) : c'est une clé d'opérateur stable depuis au moins sept mois, et l'état de la liste de C2 a changé trois fois sur cette période (§4).

Le repli passe par des enregistrements DNS de la blockchain TON. Lorsque les domaines tombent, Salat lit l'adresse « wallet » d'un nom .ton, qui n'est pas une adresse mais une liste d'hôtes en ASCII (32 octets complétés par des zéros). L'historique public de ces enregistrements donne la rotation de l'infrastructure sur 16 mois : neuf valeurs successives sur le seul nom webratpanel.ton, de 62.109.0.189 (2025-07-01) à policlinika.top avec 196.196.208.18 (2026-10-28). Un domaine .top enregistré le jour même du changement indique une infrastructure encore en mouvement.

Salat existe aussi en Rust, caché dans un « joiner ». TgWsProxy.exe est un stub C++ qui annexe, derrière un en-tête masqué et un AES-256-CBC, une vraie application Python de proxy et un Salat réécrit en Rust (vsekromeds.exe). Les trois formes de livraison du tag (batch piégé, binder .NET, joiner) reprennent le même procédé : un outil de contournement de blocage populaire sert d'appât et la charge cachée est un Salat.

Chaque build UPX porte l'adresse de son dépôt GitHub. Un marqueur de fabrication (GBZAP-PACK-UNIQUE) ajouté en fin de fichier contient un chemin compte/dépôt : 192 builds distincts pointent vers 135 dépôts de 55 comptes jetables, tous nommés d'après des outils de contournement de blocage (Discord, Telegram, YouTube). Ces 55 comptes existent encore : ils ont été créés par vagues automatisées (6 le 2026-08-18, 22 le 2026-08-23 en 12 minutes, 27 le 2026-09-08 en 34 minutes), n'ont aucun abonné, et leurs 191 dépôts portent tous une description russe quasi identique. Les 122 chemins compte/dépôt relevés dans les binaires existent tous publiquement. 155 de ces dépôts portent une release : un paquet « zapret-discord-youtube » en .zip et en .rar, d'empreinte propre à chaque dépôt, téléchargé 41 877 fois au total ; l'examen de quatre archives montre un paquet de contournement fonctionnel dont les scripts lancent la charge Salat cachée dans bin\.wd\ et, en secours, dans stun.bin, en ajoutant des exclusions Defender.

Qui est derrière, d'après les sources publiques. CYFIRMA et Solar 4RAYS attribuent le panneau « WebRat » (le vendeur de Salat) au groupe NyashTeam, que F6 et The Record décrivent comme un vendeur de DCRat et de WebRat par des bots Telegram. Les recoupements de cette analyse vont dans ce sens : l'hôte du panneau cité par CYFIRMA (62.109.0.189) est la première valeur écrite dans le dead drop TON (2025-07-01), et le portefeuille racine que j'ai suivi est le portefeuille de paiement « utilisé jusqu'en mai » décrit par Solar. Aucun canal Telegram, jeton, webhook ni contact n'est embarqué dans les 446 fichiers examinés. Je n'ai obtenu aucun identifiant de canal par ces sources.

Les paiements convergent vers un échange. Deux portefeuilles de paiement parallèles ont reçu des montants dans une bande de prix fixe (environ 15 à 16 USD) de 634 payeurs distincts entre juillet 2025 et juin 2026, ce qui recoupe le prix d'environ 1500 roubles indiqué par Solar. Un troisième portefeuille, décrit par Solar comme destinataire des fonds déplacés le 17 mai, fait transiter des sommes à solde nul et ne verse qu'à quatre portefeuilles que l'explorateur public étiquette « Bybit » (environ 106 000 USDT et 40 000 TON entre octobre 2025 et mai 2026). Je ne sais pas si ce portefeuille sert uniquement à l'opérateur.

Tout est reproductible depuis runbook.md. Les scripts sont dans tools/. Les réponses brutes des API (osint/raw/) pèsent 23 Mo et restent hors paquet.

1. Périmètre et sources

Composition des 500 entrées : 425 exécutables et 75 scripts batch. Parmi les exécutables, 204 sont des builds Salat sous UPX (imphash 6ed4f5f0...) déposés par un même rapporteur, 210 sont leurs équivalents dépackés automatiquement par abuse.ch (imphash 1aae8bf5...), et 11 sont d'autres types (chargeurs du §3 et fichiers du §9). Les dépôts vont de 91 à 112 exécutables par jour, et 73 des 75 scripts batch datent du 2026-10-30.

2. Chaîne reconstituée

1. Un script batch de 13 345 633 octets (13 345 611 dans l'archive d'origine, sans commentaire final) reconstruit un PE par lignes echo <base64>>> %TEMP%\vcomp140.tmp, le décode avec certutil -decode vers %TEMP%\vcomp140.exe (nom emprunté à une DLL du runtime Visual C++), supprime le fichier temporaire et lance le résultat avec start /b.
2. Ce PE est un chargeur Go. Il se relance en administrateur par ShellExecuteW avec le verbe runas s'il ne l'est pas déjà, attend un délai aléatoire, déchiffre sa charge embarquée, l'écrit sous %LOCALAPPDATA%\Microsoft\updater_<aléatoire>.exe et la lance dans une goroutine.
3. Après une pause de 60 à 539 secondes, il décode l'URL de la seconde charge, la télécharge (net/http) et la lance de la même façon. Les deux comptes GitHub cités dans les échantillons renvoient « Not Found » à la date d'analyse : le contenu de service.exe est inconnu.
4. Les charges embarquées sont des builds Salat sous UPX, qui contactent leurs C2 (§4 et §5).

Le paquet d'origine, référencé par ThreatFox pour l'URL de la seconde charge (échantillon 5c554838..., déposé le 2026-10-20), est une archive ZIP de 44 fichiers qui reprend le contenu d'un bundle public de contournement de blocage dont le README cite Flowseal/zapret-discord-youtube (nom lu dans le README ; je n'ai pas comparé le contenu au dépôt amont). Comparée à la release 1.9.9d du projet d'origine (publiée le 2026-07-04, téléchargée depuis son dépôt public), l'archive contient 42 fichiers identiques octet pour octet, n'a plus service.bat (présent en amont et listé dans SHA256SUMS.txt), et contient deux fichiers en plus : zapret-discord.bat, qui est le dropper ci-dessus, et un fichier .salt de 32 caractères hexadécimaux daté du 2026-10-18. Les écarts de contrôle relevés dans SHA256SUMS.txt (une ligne pour service.bat absent, une pour le fichier lui-même) existent déjà en amont. Le paquet piégé est donc la release légitime dont un fichier de lancement est retiré et un dropper ajouté.

Les 75 scripts batch du tag ont tous la même taille. Tous ont été décodés (tools/decode_bat.py, osint/salat_bat_decoded.csv) : ils produisent le même PE de 9 851 392 octets (SHA-256 fcaf1f46...), ont le même squelette une fois le commentaire final retiré, et portent 75 commentaires :: <16 caractères hexadécimaux> distincts. Ce commentaire change l'empreinte du fichier sans changer son contenu.

3. Les chargeurs Go

Trois noms de module ont été vus : 5q7z, rogw (Go 1.25.3, 386, clé et URL dans les ldflags) et stub (amd64, Go 1.25.3 puis 1.26.4, -trimpath, sans ldflags lisibles). Dans tous les cas la structure est la même : un paquet uac (élévation par runas), un paquet stealth (anti-débogage et contrôles de bac à sable : mémoire, disque), et un main aux fonctions renommées de façon aléatoire. La variante stub ajoute un paquet defender qui exclut un chemin de Windows Defender par une commande dont les arguments sont des chaînes base64.

Le conditionnement de l'anti-analyse est compilé : RunStealth reçoit un booléen issu de la comparaison d'une variable chaîne avec true, que l'opérateur peut fixer par -X. Dans les deux chargeurs dont les ldflags sont lisibles, l'opérateur ne la renseigne pas, donc les contrôles ne tournent probablement pas dans ce build (déduit de la lecture du code, non vérifié à l'exécution).

Les 6 charges extraites (3 sous UPX, 3 non packées) et leurs 3 versions dépackées sont toutes des PE Go 32 bits au module salat. Sur ces 9 fichiers distincts, 8 sont absents de MalwareBazaar au moment de l'analyse.

4. Configuration de Salat

Le déchiffrement a été reconstitué par la lecture de main.main, main.dec, main.gb, main.GetHWID et main.getEp :

Cette protection ne résiste pas à un analyste qui a le fichier, puisque chaque constante est présente. Elle gêne surtout les recherches de chaînes et les signatures par domaine. Les dix entrées en clair :

Historique de la liste, relevé sur 76 builds Go plus anciens dont la configuration a pu être extraite (sur 128 exécutables du tag salat téléchargés, déposés du 2026-03-22 au 2026-10-18 pour ces 76 ; osint/salat_older_configs.jsonl) et sur les 204 builds d'octobre :

Les quatre noms .ton sont présents dans tous ces états. Le premier build qui les contient date du 2026-03-22, soit onze jours après la création de shyetootval.ton (2026-03-11), ce qui est cohérent avec l'historique de la blockchain (§5). Le module RSA obfusqué occupe 129 mots à la même forme dans chaque build ; la règle Salat_Config_RSA_Module_Table en tire une signature. Empreinte SHA-256 du module (512 octets, grand-boutiste) : 71abd3648c95e4b1e6081ecfb7842b77d99a54aca60c24bafdbf65b12d4daaf2. Les 52 autres fichiers anciens du tag n'ont pas de configuration extraite : 32 ne sont pas des binaires Go (version Rust ou autres) et 20 n'ont pas livré de configuration (non analysés un à un). Un build plus ancien parmi les charges extraites ajoute salat.cn et wrat.in à la liste. Une collecte complémentaire faite le 2026-10-31, après l'analyse principale (84 échantillons récents des tags salat et SalatStealer absents du corpus, osint/new_since_pull.json), donne 53 binaires Go dépackés dont 52 avec configuration : le module RSA est toujours 71abd364..., la liste de C2 est l'un des états déjà décrits (50 avec sa1atik.cn et wruser.org:992, 2 avec salat.cn et wrat.in), 48 portent l'identifiant de build WF8wvauqSa11NbxrdPwN (celui des archives de release du §7) et 4 portent deux nouveaux identifiants (izkRynzwIFF8ePxY9NW4 et RJbYNitmnDxaIro9xFj4, deux builds chacun). Les 17 autres binaires de la collecte ne sont pas des Salat Go : conteneurs PyInstaller et .NET, scripts batch de 13 à 15 Mo du même type que ceux du §2, et un document Office ; ils n'ont pas été analysés un à un (osint/new_since_configs.jsonl). Le tag continue de grossir : le corpus principal est un instantané.

L'identifiant de build est le troisième morceau d'une concaténation avec l'identifiant matériel et le nom d'hôte, hachée en MD5 ; le résultat sert à forger un identifiant de victime de forme UUID et de clé XOR dérivée (lecture du code, non confirmée par exécution). Les 13 valeurs de bld et leurs dates de dépôt sont dans osint/salat_builds.csv.

Les noms de fonctions Go sont restés en clair, ce qui donne les capacités sans exécuter le programme : session WebSocket avec interface de commandes (wsSess, recvWss, shellCommand, startShell), journalisation de frappes, flux d'écran et de webcam (screenStream, ffwcam), transfert de fichiers et archives (downloadFile, zipFiles), proxy SOCKS pair à pair (p2pSocks), vol de mots de passe et cookies pour les navigateurs Chromium, Gecko et Yandex, de jetons Discord et de sessions Steam, déchiffrement de la clé « app-bound » de Chromium (StartAPPB, GetAppBoundKey), usurpation de jeton SYSTEM et DPAPI, auto-suppression (selfDelete, Suicide). Je n'ai pas vérifié leur fonctionnement.

5. Le repli TON

main.getBC interroge les noms .ton, extrait l'adresse « wallet » de la réponse, la décode en texte (decodeFromTonAddress) et en tire une liste d'hôtes séparés par des virgules, validés par l'expression régulière isValidString puis transformés en https://<hôte>/sa1at/. main.tonResolve fait le même travail par la méthode dnsresolve d'un contrat TON via la passerelle publique. Les deux voies ne reposent que sur des services tiers tout à fait ordinaires.

L'historique des transactions change_dns_record de ces noms, lu sur tonapi.io, donne :

Le tableau complet (quatre noms, vingt mises à jour) est dans osint/ton_dns_history.csv. Les mêmes valeurs ont été écrites sur plusieurs noms à quelques minutes d'intervalle, ce qui indique une administration commune. Trois adresses de portefeuille possèdent les quatre noms ; elles sont reliées entre elles et au portefeuille racine par des virements de 5 TON le 2026-03-10 et par un transfert de NFT le 2026-03-11. J'estime avec une confiance moyenne qu'il s'agit d'un seul opérateur. Solar 4RAYS a publié les mêmes quatre noms, les mêmes trois adresses propriétaires et la même carte de neuf C2 le 24 septembre 2026, et précise que l'adresse « wallet » d'un nom n'est pas contrôlée par l'opérateur : elle ne fait qu'encoder des hôtes. Mes lectures de la blockchain recoupent donc cette source, elles ne l'avancent pas. Elles y ajoutent l'historique complet des mises à jour jusqu'au 2026-10-28 et la valeur la plus ancienne, 62.109.0.189, que CYFIRMA désigne comme l'hôte du panneau.

Les adresses vues dans le dead drop appartiennent à des hébergeurs ordinaires : SpaceWeb (AS44112, deux adresses), Beget (AS198610), VDSina (AS48282), JSC IOT (AS29182) et, depuis octobre 2026, 196.196.208.0/24 chez PacketExchange (AS58065, enregistré en Afrique du Sud).

6. Infrastructure et OSINT passif

Les serveurs de noms de la plupart des domaines sont ceux de Cloudflare, mais les enregistrements A de salator.es, sa1atik.cn et wruser.org pointent directement vers des adresses non Cloudflare : le service ne sert ici que de DNS, l'origine est visible. Les deux adresses d'origine (46.173.27.15, 196.196.208.17) sont des cibles directes de signalement.

Domaines et adresses historiques du panneau, relevés dans les sources publiques et vérifiés par les données passives (Cloudflare n'y sert que de DNS, sauf mention) :

Un seul domaine, policlinika.top, est proxifié par Cloudflare. Il est enregistré le 2026-10-28 chez Devexpanse Ltd., soit le jour où le nom .ton a été mis à jour pour le contenir, et signalé dans ThreatFox le 2026-10-29.

Recoupements avec des rapports publics complémentaires

La note CERT-UA#20032, avec ses indicateurs, dont les quatre chemins /sa1at/ :

La constante de 32 octets b31c6e241ac846728da9c1fac4936651cffb944d143ab816276bcc6da0284787 (en base64 sxxuJBrI...) est présente dans 280 des 332 builds Go dépackés et dans le build Rust, en majuscules, à côté de la chaîne GetAppBoundKey. Breakglass y voit une clé liée à l'identifiant matériel. Sa position et sa valeur correspondent plutôt à la clé AES de 32 octets que les outils publics de déchiffrement des cookies Chromium « v20 » donnent pour le service d'élévation de Chrome : c'est une constante du navigateur, commune à tous les voleurs, qui ne désigne pas Salat (cette identification repose sur ma connaissance de ces outils, je ne l'ai pas revérifiée dans le code de Chromium). Elle ne doit pas servir de signature de famille.

7. Distribution par dépôts GitHub jetables

Les builds UPX portent à leur fin, dans la zone de remplissage laissée par le packer, un marqueur de fabrication de la forme :

GBZAP-PACK-UNIQUE\n<étiquette>\n<propriétaire/dépôt>\n<nom du fichier d'origine>\n<32 octets répétés>GBZAPUNQ2

tools/extract_pack_marker.py le lit sans rien exécuter. Il est présent dans 193 fichiers (192 builds distincts), la valeur de 32 octets étant propre à chaque build. Dans 178 cas l'étiquette est git-root et le champ suivant est un chemin compte/dépôt ; dans 14 cas l'étiquette est le nom flowseal, suivi d'un nom de dépôt, ce qui reprend le nom d'un auteur légitime d'outils de contournement de blocage comme s'il était propriétaire du dépôt (usurpation, je n'ai pas vérifié ce compte). Le nom d'origine du fichier est wdvcache.exe (67 builds), webrat.exe (62), zapret.exe (49) ou s.exe (14). Le nom webrat.exe relie directement ces builds au produit « WebRat ».

Ce dispositif se lit ainsi : des comptes jetables créés par un script hébergent chacun quelques dépôts qui imitent un outil de contournement de blocage populaire ; la release de chaque dépôt est un paquet de contournement dont la charge est un build UPX de Salat qui reçoit, au moment de sa fabrication, le nom du dépôt. Les noms de dépôt aléatoires et les descriptions copiées indiquent une génération automatique. Le contenu de quatre archives de release a été examiné (sous-section suivante) ; les autres dépôts n'ont été lus que par leurs métadonnées publiques (osint/github_accounts.csv). Les comptes websalat (cité par CYFIRMA comme hébergeant 7z.exe et ffmpeg.exe) et nyashteam n'existent pas (HTTP 404).

Contenu des archives de release

Les 155 archives .zip des releases ont été téléchargées sans être exécutées et analysées en mémoire (tools/analyze_release_zips.py, osint/release_zip_analysis.csv) ; leur SHA-256 correspond à chaque fois à celui que GitHub publie. Quatre d'entre elles ont aussi été extraites sur disque et lues (ringdesignerlaud/discord-unban, Blockadeeuclip/youtube-fix, CommercialDominate/zaPRet-DIScORD-yOUTUbe, Playiesculpt/ObhodDiscord). Chacune contient 55 fichiers : le paquet de contournement zapret-discord-youtube (versions 1.9.9c, 1.10.3 pour la dernière) avec ses 20 scripts general*.bat et service.bat modifiés, 8 fichiers de listes, des signatures réseau, winws.exe, WinDivert.dll, WinDivert64.sys et cygwin1.dll, auxquels s'ajoutent :

Les 21 scripts .bat portent le marqueur GBZAP_INSTANT : leur troisième ligne exécute bin\.wd\webrat.exe avant même le reste du paquet, puis un second bloc (GBZAP_INLINE_ELEVATE) vérifie les droits d'administrateur, exige la présence de winws.exe et des pilotes, et recopie la charge si besoin. Le paquet reste donc fonctionnel (le contournement de blocage fonctionne), ce qui masque l'infection. Ce mécanisme est différent du paquet d'origine du §2 (un .bat de plus de 10 Mo qui reconstruit un exécutable par certutil).

Résultat sur les 155 archives : toutes ont 55 fichiers, les 21 scripts .bat portent le marqueur GBZAP_INSTANT dans chacune, bin/.wd/ contient trois copies identiques de la charge, et cette charge est identique à celle cachée dans stun.bin. Aucun fichier inattendu n'a été trouvé. Le mécanisme est donc le même dans toutes les releases. Les archives portent 45 charges distinctes (UPX, Salat Go) : la charge dépend du nom du dépôt, pas du compte, car le marqueur de fabrication de 154 d'entre elles (étiquette flowseal, nom d'origine s.exe) ne contient que le nom du dépôt ; des comptes qui reprennent le même nom de dépôt reçoivent la même charge (jusqu'à 16 comptes pour un nom). La 155e archive n'a pas de marqueur. Une fois dépackées, les 45 charges ont le même module RSA (71abd364...), le même identifiant de build (WF8wvauqSa11NbxrdPwN), go1.24.0 et la même liste de C2 (salator.es, wruser.org, websalat.top, sa1atik.cn, wruser.org:992 et les noms .ton) que les builds d'octobre du §4 (osint/release_payload_configs.jsonl). 33 de ces 45 charges sont dans MalwareBazaar (signature SalatStealer, vues du 2026-10-20 au 2026-10-27) ; 12 n'y ont jamais été déposées, et seules 5 des 45 étaient dans mon jeu de 204 builds (osint/release_payloads_mb.json). Chaque archive reste unique (les scripts portent des variantes de quelques octets), ce qui explique les 310 empreintes distinctes : le défenseur doit détecter le mécanisme, pas un hash. Les règles Salat_Release_Package_GBZAP_Scripts et Salat_Release_Package_Stun_Host couvrent les scripts et le stun.bin piégé.

Le dépôt ringdesignerlaud/discord-unban tel qu'il se présente : un seul contributeur, zéro étoile, une description russe, et les scripts general (ALT*).bat du paquet légitime.

Sa page de release copie le journal des modifications du projet légitime, cite ses vrais contributeurs, et demande de décompresser puis de lancer zapret-discord.bat en administrateur.

Cette distribution recoupe les descriptions publiques du produit : faux correctifs d'applications bloquées en Russie, vidéos de présentation sur YouTube avec lien vers une archive protégée par mot de passe, comptes GitHub qui se font passer pour des utilitaires (Solar 4RAYS, 2025) ; faux outils, « cracks » et triches sur GitHub et YouTube (The Record, à propos de NyashTeam).

8. Opérateurs, canaux de communication et paiements

8.1 Attribution d'après les sources publiques

Dans ses indicateurs de NyashTeam, F6 (juillet 2025) liste sa1at.ru, webr.at, webrat.ru, webrat.su, webrat.top, posholnahuy.ru et pidorasina.ru : des domaines de Salat et de WebRat se trouvent donc aussi dans une source indépendante de CYFIRMA. Recoupements propres à cette analyse : (a) 62.109.0.189, désigné par CYFIRMA comme l'hôte du panneau, est la première valeur réelle écrite dans le dead drop TON (2025-07-01 18:52 UTC) ; (b) webr.at, domaine de panneau, résout vers 141.95.112.163, adresse que ThreatFox a saisie comme C2 de Salat le 2026-10-11 ; (c) le nom de fichier webrat.exe figure dans les marqueurs de fabrication de 62 builds ; (d) le portefeuille racine est le portefeuille de paiement décrit par Solar. Ces quatre points relient le produit WebRat, le malware Salat et l'infrastructure TON sans passer par l'attribution à un groupe, qui reste celle des sources publiques.

8.2 Canaux de communication

• Dans le code. Recherche dans 446 fichiers distincts (builds Go dépackés, Rust, binders, chargeurs, scripts Python extraits) de liens t.me, de jetons de bots Telegram, de webhooks Discord, d'adresses .onion, de courriels et de comptes GitHub (tools/scan_channels.py, osint/channels_scan.txt) : aucun canal d'opérateur. Les marqueurs de CYFIRMA (nyashsupbot, Lightshot, Procmon, alive.php, sniff_domain_list.txt) sont absents des builds Go ; seul RuntimeBroker se retrouve, comme chemin d'installation du Salat Rust (§9.1).
• Liste des identifiants. Tous les comptes, canaux, domaines, adresses TON et IP cités par le code ou par des sources publiques sont dans comptes_et_canaux.md, avec leur source et leur niveau de confiance. Rien n'a été contacté.
• Dans les sources publiques. Le panneau affiche des identifiants de bots Telegram et de comptes d'administration, avec une liste de revendeurs, et le support et les paiements passent par des bots (CYFIRMA, sans reproduire les identifiants). Une chaîne de distributeurs sur Telegram existe (Solar 4RAYS, 2025, sans nom). F6 a obtenu le retrait d'un canal Telegram qui hébergeait le code source de WebRat. Les seuls identifiants Telegram publiés sont nyashsupbot (chaîne d'une règle YARA de CYFIRMA) et PalachPro (canal cité à propos d'UAC-0252, sans lien établi avec NyashTeam) ; F6 ne publie aucun nom de canal ni de bot. Je ne l'ai pas contacté et je ne l'ai pas cherché sur Telegram.
• Moyens de paiement cités par CYFIRMA. Cryptobot, RUCARD, LOLZ, skins Steam ; abonnement mensuel de 1199 roubles pour le panneau, hébergement à 999 roubles pour deux mois.
• Distribution. GitHub (§7), YouTube, forums de triche pour jeux (sources publiques).

Conclusion de cette section : aucun identifiant de canal d'opérateur n'a été obtenu par l'analyse du code ni par les sources publiques accessibles ; l'accès au panneau, aux bots et aux canaux relève d'un accès actif que je n'ai pas tenté.

8.3 Paiements

Solar 4RAYS décrit des paiements entrants vers des adresses « roses » qui alimentent des adresses « noires » propriétaires des domaines, un prix d'environ 1500 roubles et deux portefeuilles de paiement successifs (jusqu'en mai, puis en juin). Les adresses brutes de ces portefeuilles, calculées à partir de leurs adresses publiées, sont :

Les deux portefeuilles de paiement ne partagent que 12 payeurs sur 634 distincts, ce qui est cohérent avec deux périodes de vente successives (les périodes se recouvrent de janvier à mai 2026). Le prix quasi fixe observé (bande de 9 à 13 TON ou de 14 à 17,5 USD₮, soit environ 15 à 16 USD) recoupe le « prix de licence fixe » de Solar. Le portefeuille de juin se vide dans ce portefeuille de conservation, qui ne reçoit plus rien après le 2026-07-22. Je n'ai pas identifié de portefeuille de vente actif depuis juillet 2026 ; je n'ai relié aucun payeur à une identité (les adresses de contreparties restent dans les réponses brutes hors paquet).

Le portefeuille 0:0e4d1a5a... ne verse qu'à quatre contreparties, que l'explorateur public étiquette « Bybit 7 » à « Bybit 10 » (portefeuilles de dépôt de l'échange), pour environ 106 000 USDT et 40 000 TON du 2025-10-03 au 2026-05-21. Il compte 90 contreparties entrantes distinctes : je ne peux pas dire qu'il appartient à l'opérateur seul. C'est une piste pour une demande de conformité auprès de l'échange, qui peut associer ces dépôts à des comptes vérifiés.

8.4 Chronologie reconstituée

9. Autres fichiers du tag

9.1 Le Salat réécrit en Rust

sanert.exe (SHA-256 dépacké 11fc792b...) est un PE 64 bits de 6,4 Mo qui envoie User-Agent: salat/2.0 et consulte tonapi.io et orbs.network : mêmes services que le repli TON de la version Go. Les chemins de compilation donnent ses modules (config, crypto, net, ws, tunnel, hwid, install, elevate, makelog/invdump/{chrome,gecko,steam,processes,users}, camera, sound, screen, dxgi_capture, filemanager, taskmanager, shell) et ses crates (tokio-tungstenite pour le WebSocket, h3 et quinn pour QUIC, rustls, aes-gcm, chacha20poly1305, rusqlite, nokhwa et cpal pour la caméra et le son). Il énumère des dizaines de navigateurs Chromium et Gecko, des extensions de portefeuilles, les clients Telegram (Telegram Desktop, AyuGram, Kotatogram), Exodus, Electrum, Atomic, Coinomi et Jaxx. La configuration de tunnel est une chaîne à cinq champs séparés par des barres (p2_host|p2_port|key|target_host|target_port). Aucun domaine C2 n'est en clair. La structure de configuration est construite par une seule fonction (0x1400ea1cd) qui décode des chaînes base64 : le mutex Global\WEBR_4D285JK5EBIZ (le préfixe WEBR est celui du panneau WebRat), le chemin d'installation $Appdata\RuntimeBroker.exe, le script PowerShell qui ajoute Program Files, %APPDATA% et %LOCALAPPDATA% aux exclusions de Defender, un jeton de 20 caractères (SHA-256 5a974e5f62be2a490074d946cffd3db2e63fb29c47287acf7701a9d4a1ba92fb, non reproduit ici car il peut servir d'authentification) et une série de délais (30 s, 1 min, 5 min, 30 min, 8 s, 5 s). Deux champs de texte de cette structure sont vides dans ce build : aucune adresse de serveur n'est donc embarquée, ni en clair ni chiffrée, et l'adresse est fournie autrement (argument d'exécution, repli par tonapi.io ou configuration déposée plus tard). La chaîne d'exécution se remonte ainsi : la structure de configuration (0x110 octets) est copiée dans la fermeture d'un fil d'exécution (0x1400e734f), qui lance l'exécuteur asynchrone tokio (0x14001c27d), lequel appelle la tâche réseau (0x1400dae5d) puis la résolution TON (0x1400dc26a). Les délais de la configuration (30 s, 8 s, 5 s) sont ceux de cette résolution ; les deux champs de texte vides sont les seuls emplacements possibles d'une adresse. Deux autres builds Rust, plus récents (HDSDriver.exe, vus le 2026-10-31 : SHA-256 0280901c2740795149dee80475e7819b8ac93a95d87413f15dd944eaad17a03b dépacké et 9aad498becf1c9c0b025bf6ee4f88e66c4c90404f49a8065afcef0625b0341fb sous UPX, qui se dépacke en un fichier identique de 6 492 160 octets), ont la même structure avec un autre mutex (Global\WEBR_AXTARNHZ7RS5), un autre jeton de 20 caractères (SHA-256 b3c92aedb9c97cd47f2be2ed2bb4580d7c0e5f320b5dcf54f0b9c70cb1f1da94), trois champs vides au lieu de deux (le chemin d'installation est vide) et les clés install, install_count, install_autorun, autorun_service, set_comment et install_paths juste après le jeton. Le mutex et le jeton changent donc d'un build à l'autre : ce sont des identifiants par build ou par client, et les champs vides sont des options choisies à la fabrication (installation désactivée), pas des champs oubliés. Aucun des builds Rust connus n'a de champ pour une adresse de serveur : elle vient du canal de commande (résolution par tonapi.io) ou d'une configuration reçue ensuite, ce que les clés install_* suggèrent. Sur les 41 échantillons récents d'étiquette RustyStealer examinés (2026-10-20 au 2026-10-31), seuls ces deux builds et sanert.exe portent salat/2.0, src/hwid.rs et tonapi.io ; les 37 autres n'en portent aucun. Le RSA du build (rsa_encrypt, bourrage PKCS#1 v1.5, src/crypto.rs) chiffre une clé de session de 32 octets et un vecteur de 16 octets pour protéger les données envoyées : il ne sert pas à déchiffrer la configuration comme dans la version Go. MalwareBazaar le suit sous l'étiquette RustyStealer (qui regroupe aussi des familles sans rapport : douze échantillons de janvier et février 2026 de cette étiquette ont été vérifiés, aucun ne porte salat/2.0, src/hwid.rs ni tonapi.io) (version UPX déposée le 2026-10-29, version dépackée générée par abuse.ch le même jour), en plus de SalatStealer.

9.2 TgWsProxy.exe : un joiner qui cache le Salat Rust

L'exécutable de 24 Mo est un petit stub C++ (MinGW, environ 300 Ko) suivi d'un overlay chiffré de 24 Mo. Le stub lit les 16 derniers octets de son propre fichier : un offset de 64 bits, une graine de 32 bits et un contrôle (graine ^ 0x3f8a7d2b). À l'offset indiqué, un en-tête de 28 octets est masqué par un flux pseudo-aléatoire (générateur congruentiel linéaire de constantes 0x5851f42d4c957f2d et 0x9e3779b97f4a7c15, initialisé par la graine). Il contient la version (4), des drapeaux, le schéma de chiffrement, un délai, les longueurs de clé (32) et de nonce (16) et le nombre de fichiers (2). La clé et le nonce suivent, masqués par le même flux. Chaque fichier annexé est ensuite stocké en clair pour son nom et ses tailles, chiffré pour son contenu (ici AES-256-CBC, bourrage PKCS#7) puis compressé en LZNT1. tools/joiner_extract.py reproduit l'ensemble : les tailles obtenues après décompression sont exactement celles que l'en-tête annonce.

Ni l'un ni l'autre n'est dans MalwareBazaar. Le stub dépose les fichiers dans un répertoire temporaire, puis démarre les exécutables avec CreateProcessW (lecture du code décompilé ; l'ordre et les drapeaux de lancement n'ont pas été reconstitués au-delà de la structure de l'en-tête).

10. Faiblesses exploitables par les défenseurs

• La clé et l'URL de seconde charge des chargeurs sont lisibles en clair : un défenseur qui détient un chargeur détient sa charge.
• Les 204 builds partagent module RSA, clés et jeu d'adresses : une seule règle de configuration couvre tout, et un nouveau build à un seul bld différent reste détecté.
• Le dead drop TON est public et horodaté : on peut surveiller les mises à jour de webratpanel.ton, remoteadministratortool.ton, webratxaye1.ton et shyetootval.ton pour anticiper les prochains C2.
• Le trafic vers tonapi.io et ton.access.orbs.network émis par un processus qui n'est pas un navigateur ou un client TON connu est un signal fort.

11. Portée et limites

• Le tag est plus grand que les 500 entrées lues : l'API refuse limit=1000. Les nombres de builds par jour sont des minorants. La requête par signature donne la même fenêtre de 500 entrées (du 27 au 31 octobre), la requête par étiquette salat remonte à mars 2026 (128 exécutables téléchargés, §4) et celle par étiquette RustyStealer à janvier 2026 (étiquette générique : les échantillons vérifiés n'ont pas de lien avec Salat).
• ThreatFox renvoie au plus 1000 indicateurs par requête, surtout des hash des sept derniers jours ; les indicateurs réseau antérieurs ont été obtenus par étiquettes (webrat, TON, dead-drop, Github).
• Le contenu de service.exe est inconnu : les deux comptes GitHub n'existent plus, et le rapport Triage du paquet d'origine (261020-fpe2zacz4w) ne contient que le script (score 3) sans seconde charge. ThreatFox classe l'URL du premier compte comme livraison de charge SalatStealer (confiance 75, rapporteur tiers, 2026-10-20) ; je n'ai aucun hash pour ce fichier.
• Aucune exécution : les capacités de Salat sont déduites du code. Les chaînes littérales confirment le vol de navigateurs (mots de passe, cookies, saisie automatique, jetons), de Telegram Desktop et de portefeuilles, la persistance par la clé Run, l'exécution via cmd.exe, l'élévation runas et la capture d'écran. La lecture des appels d'API confirme aussi la capture de la webcam et du bureau (lancement de %TEMP%\ffmpeg.exe avec une entrée dshow et video=), le proxy SOCKS (connexion TCP sortante), l'auto-suppression (renommage puis suppression du fichier par SetFileInformationByHandle, suppression de la tâche planifiée par la bibliothèque taskmaster, puis os.Remove) et l'enregistrement de frappes (processus fils lancé par os/exec, avec une fonction qui charge des API Windows). Le détail des frappes enregistrées et du protocole WebSocket n'a pas été relu.
• Le Salat réécrit en Rust n'embarque aucune adresse de serveur dans ce build (§9.1) : le module RSA du build Go n'y figure sous aucun de six encodages, sa structure de configuration ne contient que le mutex, le chemin d'installation, le script Defender, un jeton et des délais, et l'origine de l'adresse (argument, résolution par tonapi.io ou configuration ultérieure) n'est pas établie. Les appels de la fonction de résolution TON n'ont pas pu être rattachés à une adresse de portefeuille. Ses canaux de communication sont donc inconnus.
• Les ventes ne sont visibles que jusqu'en juin 2026 : le portefeuille de juin se vide dans un portefeuille de conservation inactif depuis le 2026-07-22 et je n'ai pas trouvé de portefeuille de vente plus récent. Je n'ai relié aucun payeur à une identité. Le portefeuille « conduit » reçoit de 90 contreparties : je ne le tiens pas pour exclusivement lié à l'opérateur. Pour chercher un portefeuille plus récent, j'ai lu les événements publics des 60 payeurs les plus récents des deux portefeuilles de paiement (dernier paiement du 2026-05-03 au 2026-06-15) et compté, après le 2026-06-16, les destinataires de leurs virements dans la même bande de prix : aucun destinataire n'est commun à deux payeurs. Les ventes ont pu passer par un service de paiement à solde interne (CYFIRMA cite Cryptobot parmi les moyens de paiement), dont les dépôts ne laissent pas de portefeuille commun visible, ou s'arrêter.
• Aucun canal Telegram, forum ou panneau n'a été interrogé ni recherché directement, par choix : ce serait contacter l'infrastructure ou les comptes de l'opérateur. Les identifiants de canaux restent donc inconnus. Les noms d'abonnés du panneau cités par CYFIRMA n'ont pas été reproduits.
• L'attribution à NyashTeam repose sur CYFIRMA et Solar 4RAYS ; le nom Kapchenka sur CYFIRMA seul. Je n'ai pas relu leurs preuves. La note CERT-UA#20032 a été lue à la source : elle établit l'usage de Salat par UAC-0252, pas l'attribution à NyashTeam.
• Les 155 archives .zip de release ont été analysées ; les 155 archives .rar (même contenu supposé, non vérifié) et le contenu des dépôts eux-mêmes n'ont pas été téléchargés. La version amont 1.9.9c n'a pas été comparée ligne à ligne.
• Le stub du joiner a été relu pour sa structure ; le déroulé exact de ses lancements n'est pas reconstitué.

12. Détection

Douze règles YARA dans salatstealer.yar :

Aucune correspondance sur /usr/bin, /usr/lib et /opt. Les autres signaux : exécution de certutil -decode vers %TEMP%\vcomp140.exe, fichiers updater_*.exe sous %LOCALAPPDATA%\Microsoft, exclusion Defender ajoutée juste après le premier lancement, résolutions et connexions vers les indicateurs de iocs.csv.

13. Reproduire l'analyse

Le détail pas à pas et les commandes sont dans runbook.md, les outils dans tools/. Les indicateurs sont dans iocs.csv, les recommandations dans remediation.md, les règles dans salatstealer.yar et la liste des comptes, canaux et portefeuilles dans comptes_et_canaux.md.