MetaStealer (1/2) : Un stealer très sophistiqué

Dans son Panorama de la cybermenace 2025 publié en mars 2026, l’ANSSI/CERT-FR souligne une tendance de fond : les attaquants, qu’ils soient étatiques ou cybercriminels, s’appuient de plus en plus sur des logiciels légitimes pour les détourner à des fins malveillantes. Outils d’administration à distance comme AnyDesk ou ScreenConnect, services de stockage comme Dropbox ou Google Drive, tout y passe. Cette stratégie répond à une logique simple : en se camouflant derrière des marques connues et de confiance, les attaquants franchissent plus facilement les défenses techniques et contournent la vigilance des utilisateurs.

Ce n’est pas un phénomène nouveau. Depuis plusieurs années, des campagnes d’infostealers exploitent le recours massif aux outils de prise en main à distance popularisés par le télétravail. TeamViewer, AnyDesk, ScreenConnect : ces logiciels sont devenus des leurres de choix. Un utilisateur qui cherche à télécharger AnyDesk pour dépanner un collègue n’est pas naturellement méfiant face à un domaine comme anydeskt.app ou anydesck.net – la différence d’une lettre passe souvent inaperçue.

MetaStealer illustre parfaitement cette tendance. Actif depuis 2022 et observé jusqu’en fin d’année dernière, ce malware-as-a-service (MaaS) a fait de la tromperie par logiciel légitime l’un de ses vecteurs privilégiés. Dans cet article, nous reconstituons la première* des deux chaînes d’infection dont les artéfacts sont analysés sur la plateforme GLIMPS Malware Expert. Un parcours de cinq stades : du fichier LNK au payload Delphi protégé par machine virtuelle commerciale, qui illustre la sophistication croissante des opérateurs de MetaStealer.

*une seconde chaîne (downloader BAT → dropper → stealer .NET) sera traitée dans un prochain article.

Le 17 mars 2022, un acteur connu sous le pseudonyme _META_ publie une annonce sur le forum cybercriminel russophone WWH-Club : un nouvel infostealer est disponible à la vente. Tarif : 125 dollards par mois ou 1 000 dollards pour un accès illimité. Son pitch commercial est sans détour : il revendique « les mêmes fonctionnalités, le même code et le même panneau que RedLine Stealer, avec quelques améliorations. »

Ce n’est pas une vantardise. L’analyse technique ultérieure le confirmera : META Stealer n’est pas inspiré de RedLine, il est RedLine, légèrement modifié. Les deux malwares partagent le même créateur. La quasi-totalité du code est identique, avec de simples remplacements de la chaîne « RedLine » par « Meta ». Les certificats de signature des panneaux de contrôle sont communs, les schémas d’authentification utilisent les mêmes clés AES et RSA, et le module backend Nodes.Api traite indifféremment les requêtes des deux serveurs C2.

Trajectoire et démantèlement

En 2022, MetaStealer capture rapidement 11% du marché des infostealers, se positionnant en troisième position derrière RedLine (56%) et Raccoon Stealer (15%). La famille est activement utilisée dans des campagnes ciblées : les chercheurs de Mandiant documentent en juin 2024 son usage par le groupe UNC5537 pour compromettre des centaines d’instances Snowflake en exfiltrant des credentials depuis des machines de sous-traitants.

Le chapitre judiciaire s’ouvre le 28 octobre 2024 avec l’Opération Magnus : la police néerlandaise, le FBI et Eurojust coordonnent le démantèlement simultané de RedLine et MetaStealer. Trois serveurs sont saisis aux Pays-Bas, deux domaines confisqués, deux personnes arrêtées en Belgique, et des charges sont retenues aux États-Unis contre Maxim Rudometov, identifié comme l’un des développeurs et administrateurs de RedLine.

Analyse et mode opératoire

Cette chaîne est la plus sophistiquée que nous ayons observée pour MetaStealer. Elle mobilise cinq stages distincts : du fichier LNK jusqu’au payload final, en combinant typosquatting, file pumping et protection par machine virtuelle commerciale.

Stage 1 : les fichiers LNK, leurres AnyDesk

Documentée également par Huntress dans le cadre d’une variante ClickFix, cette technique repose sur des fichiers LNK distribués via des répertoires ouverts (serveur WsgiDAV) hébergés sur des domaines imitant AnyDesk :

• anydeskt.app — ajout d’un « t »
• anydesck.net — ajout d’un « c »

GLIMPS Malware permet de rapidement qualifier ces fichiers :

À l’inspection, ces raccourcis sont convaincants : leur icône est celle d’un document PDF (icon index 11 de msedge.exe), leur fenêtre s’exécute en mode minimisé (SW_SHOWMINNOACTIVE), et leur cible affichée est cmd.exe. La ligne de commande embarquée illustre la mécanique :

L’icône à l’index 11 de msedge.exe correspond à un visuel pdf

Trois actions simultanées :

1. Leurre : ouverture du vrai site anydesk.com dans Edge — la victime voit une navigation ordinaire
2. Téléchargement silencieux : curl récupère le payload MSI sous une fausse extension .pdf
3. Installation et effacement : msiexec /qn installe sans interface ; Taskkill supprime la fenêtre cmd

L’analyse comparative de deux LNK produits par le même opérateur révèle qu’ils ont été créés à la même seconde (2024-05-23 19:29:00 UTC), sur la même machine (desktop-gm3ka0f), avec le même SID utilisateur, preuve d’un outillage de génération automatisé.

Un second LNK utilise une légère variante syntaxique (/c et && au lieu de /k et &), avec une étape de renommage explicite du fichier téléchargé, et exploite un domaine différent (anydesck.net). Cette diversité indique plusieurs itérations du générateur de LNK, déployées en parallèle pour multiplier les vecteurs.

Nos bases de Threat Intelligence référencent l’ensemble de ces indicateurs. Les deux hashs LNK sont connus et tagués metastealer. Le domaine anydesck.net est tracké via l’URL de téléchargement du MSI, avec les labels infostealer, metastealer, msi, payload, stealer. Les deux domaines de typosquatting et l’IP de livraison 87.120.219.100 sont répertoriés comme « Malware payload delivery host », avec les tags metastealer et opendir, – confirmation que ces serveurs hébergent les payloads via des répertoires ouverts accessibles directement.

IoCs – LNK

Stage 2 : le MSI « Docusign Edit », packaging soigné

Le MSI téléchargé se présente comme « Docusign Edit 6.7.3.5« , packagé avec l’outil légitime MSI Wrapper (version 11.0.53.0). Les métadonnées internes trahissent cependant son origine : si la codepage de surface est 1252 (Western European), la codepage interne est 1251 (Cyrillic) et la locale est 1049 (Russe) – indicateur de l’environnement de compilation de l’auteur.

L’arbre de fichiers révélé par GLIMPS Malware décompose la chaîne :

Le script 1.js mérite une attention particulière : via WScript.Shell + Scripting.FileSystemObject, il supprime l’intégralité de %TEMP% après un délai de 5 secondes, effaçant toutes les traces de l’installation. Notre nouveau modèle de détection et explicabilité « Multiscripts » (très bientôt disponible !) apporte une compréhension de ce fichier js.

Le payload ls26.exe pèse 740 Mo, non pas parce que le code est volumineux, mais par file pumping : le binaire est gonflé avec du padding à faible entropie (~1.4) pour dépasser les limites de scan des antivirus et des sandboxes contraintes en taille ou en durée.

IoCs – MSI

Nos bases de Threat Intelligence apportent ici un éclairage complémentaire. Le MSI est référencé avec les labels metastealer, msi et un label notable : anydeesk-ink – ce même label se retrouve sur le CAB, aux côtés de file-pumped, ls26, metastealer et d’un identifiant setup8491 qui pourrait correspondre à un marqueur de campagne ou de build.

L’une des adresse ip remontée 185.39.207.39 est confirmée comme « Malware payload delivery host » (tag opendir). Plusieurs composants sont également présents dans les bases communautaires attestant que cette campagne a été observée et signalée au-delà de notre périmètre d’analyse.

Le label anydeesk-ink est particulièrement intéressant : il relie directement le MSI au vecteur LNK, confirmant que l’ensemble de la chaîne, de la distribution jusqu’au payload, s’inscrit dans une campagne cohérente de typosquatting AnyDesk.

Stage 3 : ls26.exe, un stealer Delphi très sophistiqué sous armure commerciale

Afin de mener l’analyse de ce fichier, nous en avons généré une version stripped (débarassée de ses motifs répétitifs servant à « pump’) Le payload se présente donc comme Microsoft Edge PWA Launcher dans ses métadonnées PE – une mascarade soignée avec copyright Microsoft, version Edge 139.0.3405.102, et OriginalFilename: msedge_pwa_launcher.exe. Deux templates non résolus (@LANGUAGE_STRING@, @UPSTREAM_VERSION_NUMBER_STRING@) trahissent néanmoins l’injection artificielle de ces métadonnées.

La sandbox de GLIMPS Malware identifie les comportements suspects suivants :

• Vérification de la locale système (HKLM\...\Nls\CustomLocale\en-GB)
• Heuristique « détection de sandbox« 
• Règle YARA GLIMPSCTI.shellcode.potential_nopSled sur les dumps mémoire La sandbox ne remontant pas plus d’informations, nous avons tenté d’en faire l’analyse statique plus approfondie.

Structure PE : un premier niveau d’opacité

Avant même d’exécuter une instruction, la structure du binaire trahit une obstruction délibérée. Les sections portent des noms aléatoires sans signification (.vopxwd, .vrbell, .wegeem, .qoseon…) – aucun compilateur standard ne les génère.

La section .wegeem (~5,2 Mo, entropie 7.95) est quasiment indistinguable d’un flux aléatoire : elle contient le bytecode P-Code et la configuration, entièrement chiffrés. La section .vopxwd présente un écart massif entre sa taille virtuelle (3,3 Mo) et sa taille sur disque (6 Ko) : elle est quasi-vide dans le fichier et ne sera peuplée qu’en mémoire, après déchiffrement.

La table d’imports se limite à trois fonctions de kernel32.dll : LoadLibraryA, GetProcAddress, ExitProcess. Tout le reste – plusieurs dizaines d’APIs Windows – est résolu dynamiquement à l’exécution, après déchiffrement des noms.

La protection ssLamePCode : une VM commerciale Delphi détournée

L’analyse statique révèle la raison de la résistance de ce sample à l’analyse : le code malveillant est protégé par ssLamePCode, un framework commercial de protection pour applications Delphi. Les unités RTTI identifiées dans le binaire – ssLamePCode, ssLameCrypt, ssZLib, SecurityEngine, Licensing, RegistrationDialog, EngineAPI, PreLoader – confirment la nature commerciale du produit, ici détourné comme couche de protection. La présence d’unités Licensing et RegistrationDialog indique que les opérateurs ont acquis ou cracké une licence de ce logiciel commercial.

Le fonctionnement repose sur cinq couches imbriquées, chacune potentiellement chiffrée par la précédente :

Loader PE custom (FUN_008a1680)
    ├── Parse headers PE
    ├── Init config chiffrée (localise la clé dans .wegeem)
    ├── CreateMutexW — anti-double-exécution
    ├── Applique relocations (table chiffrée)
    ├── Résout tous les imports (noms chiffrés → LoadLibrary + GetProcAddress)
    ├── Charge rehlpic-x32.pll (plugin packer complémentaire)
    ├── Exécute TLS callbacks (config chiffrée)
    └── Patche l'OEP → JMP Dispatcher indirect
              │
              ▼
    Dispatcher indirect (FUN_0089d294)
    Déchiffre un RVA depuis la config, calcule l'adresse absolue,
    appelle la cible — toutes les fonctions sont appelées ainsi,
    aucune xref statique possible
              │
              ├──► Anti-analyse (FUN_0089ab5c)
              │    timing check (GetTickCount vs seuil chiffré),
              │    registry check, sleep conditionnel, compteur d'exécutions
              │
              ├──► VM wrapper → Interpréteur P-Code (FUN_0089c904)
              │    24 opcodes, 10 registres virtuels, pile dédiée,
              │    accès natif aux APIs Windows (opcode CALL_NATIVE),
              │    génération de shellcode dynamique (opcode SHELLCODE_EMIT)
              │
              └──► Code stealer natif x86 (section .vopxwd déchiffrée)

On s’aperçoit clairement que le binaire a été conçu, by design, pour ralentir la rétroconception.

L’algorithme ssLameCrypt est un cipher XOR-SUB-XOR en cascade, octet par octet, avec trois propriétés:

• Chaînage CBC-like : chaque octet déchiffré dépend de l’octet chiffré précédent, propagé comme nouvelle clé de chaînage
• Parcours inverse de la clé : le buffer clé est consommé en sens inverse (décrémentation)
• Dépendance positionnelle : un XOR final avec le compteur de position lie chaque octet à sa place dans le flux

La clé elle-même est les 4 096 premiers octets du flux de configuration, embarquée à l’offset 0x489DD0 dans le fichier PE. Toutes les données sensibles – noms d’API, paramètres de configuration, RVAs de fonctions, noms de mutex, chaînes GUI – sont stockées chiffrées et résolues dynamiquement par ce mécanisme. Résultat : aucune string lisible dans le binaire, résolution d’imports entièrement dynamique.

L’extraction de la configuration ssLamePCode chiffrée a permis de récupérer 58 entrées (malheureusement ce ne sont pas des configurations liées aux fonctionnalités du stealer en lui même) :

dont on a l’interprétation suivante :

Le code stealer s’exécute en x86 natif dans la section .vopxwd une fois déchiffrée – le P-Code n’orchestre que la phase de dépackage, pas le stealer lui-même. La section déchiffrée contient 2 643 fonctions au total : 17 fonctions logiques réelles (>2 Ko, avec des appels internes) pour 2 626 wrappers junk (~1,5 Ko chacun, aucun appel interne, aucune xref sortante) générés par le framework ssLamePCode pour gonfler le code et noyer l’analyse – un ratio de 99,4% de bruit. Les deux fonctions les plus volumineuses (~12 Ko et ~10 Ko) accèdent directement au PEB Windows via fs:[0x30] pour la résolution d’adresses en mémoire, technique caractéristique des stealers cherchant à éviter les hooks.

A l’heure actuelle, l’analyse statique n’est pas encore terminée mais nous avons déjà beaucoup d’éléments permettant de qualifier cette menace.

Observables – Payload ls26.exe

Ce que l’analyse révèle des capacités de MetaStealer

La chaîne que nous venons de reconstituer – et en particulier l’analyse du payload ls26.exe – permet de déduire certaines capacités potentielles de la famille. Ce que le sample ne dit pas explicitement dans ses strings (elles sont toutes chiffrées et obfusquées), il le révèle dans son comportement dynamique et dans la structure de son code déprotégé :

• Vol de credentials navigateurs : décryptage AES-GCM, 3DES et DPAPI pour extraire mots de passe, cookies et données de cartes bancaires des profils Chromium et Firefox
• Lecture directe des bases SQLite des navigateurs
• Vol de tokens Discord avec validation en temps réel via l’API officielle
• Capture d’écran et collecte d’informations système (processeurs, GPU, liste des processus et programmes installés)
• Communication C2 via WCF/NetTcp – protocole rarement filtré par les proxies d’entreprise
• Exfiltration de wallets crypto dans certaines variantes

Le tout délivré en MaaS clé en main, accessible à des affiliés sans compétences techniques avancées – et protégé par une VM commerciale.

Chaîne d’infection

A partir des indices révélés lors de notre analyse, nous pouvons modéliser la chaine d’infection suivante:

Techniques MITRE ATT&CK

Conclusion : MetaStealer, une chaîne d’infection à cinq étapes

Cette chaîne d’infection illustre la maturité opérationnelle des opérateurs MetaStealer : chaque étape est conçue pour tromper un niveau de défense différent. Le LNK abuse de la confiance envers AnyDesk et Edge. Le MSI se cache derrière Docusign et un packager commercial légitime. Le payload se protège derrière une VM commerciale Delphi en se faisant passer pour Edge. Et le file pumping neutralise les sandboxes contraintes en ressources.

L’Opération Magnus d’octobre 2024 a démantelé l’infrastructure centrale, mais les techniques restent actives. Comme le rappelle l’ANSSI, les logiciels légitimes continueront d’être détournés comme leurres tant que les utilisateurs et les outils de défense ne les traiteront pas avec la même méfiance que des fichiers inconnus.

À suivre : de RedLine à MetaStealer ?

La chaîne LNK → MSI que nous venons de documenter est la plus sophistiquée que nous ayons observée pour MetaStealer. Mais ce n’est pas la seule. Dans le prochain article, nous analysons une seconde chaîne d’infection à l’aide de GLIMPS Malware – plus directe, mais tout aussi révélatrice.

Références externes

• ANSSI — Panorama de la cybermenace 2025 (CERTFR-2026-CTI-002, mars 2026)
• ESET — Life on a crooked RedLine: Analyzing the infamous infostealer’s backend
• Intel 471 — RedLine and Meta: The Story of Two Disrupted Infostealers
• Huntress — The ClickFix Attack That Wasn’t: From a Fake AnyDesk Installer to MetaStealer
• BleepingComputer — Redline, Meta infostealer malware operations seized by police
• The Hacker News — Dutch Police Disrupt Major Info Stealers RedLine and MetaStealer in Operation Magnus