Prendre la poudre d'escampette : un cadre d'évasion commerciale utilisé de manière abusive dans la nature 

Introduction

Elastic Security Labs observe plusieurs campagnes qui semblent exploiter le cadre commercial d'évasion AV/EDR, SHELLTER, pour charger des logiciels malveillants. SHELLTER est commercialisé auprès de l'industrie de la sécurité offensive pour des évaluations de sécurité sanctionnées, permettant aux opérateurs de l'équipe rouge de déployer plus efficacement leurs cadres C2 contre les solutions anti-malware contemporaines.

Principaux points abordés dans cet article

• Le cadre d'évasion commerciale SHELLTER acquis par des groupes de menace
• SHELLTER a été utilisé dans de multiples campagnes d'infostealer depuis avril 2025, comme indiqué dans les métadonnées de la licence.
• SHELLTER utilise des capacités uniques pour échapper à l'analyse et à la détection.
• Elastic Security Labs publie un décompresseur dynamique pour les binaires protégés par SHELLTER

Throughout this document we will refer to different terms with “shellter” in them. We will try to 
maintain the following style to aid readability:
  *  “Shellter Project” - the organization that develops and sells the Shellter evasion framework
  *  “Shellter Pro Plus/Elite” - the commercial names for the tools sold by the Shellter Project
  *  “SHELLTER” - the loader we have observed in malicious usage and are detailing in this report
  *  “SHELLTER-protected” - a descriptor of final payloads that the SHELLTER loader delivers

SHELLTER Vue d'ensemble

SHELLTER est un cadre d'évasion commerciale qui aide les équipes rouges depuis plus de dix ans. Il permet aux fournisseurs de services de sécurité offensifs de contourner les outils antivirus et, plus récemment, les outils EDR. Cela permet aux équipes rouges d'utiliser leurs cadres C2 sans avoir à les développer en permanence, ce qui est généralement le cas lorsque les fournisseurs de solutions de sécurité rédigent des signatures de détection pour eux.

While the Shellter Project does offer a free version of the software, it has a limited feature-set, 
only 32-bit .exe support, and is generally better understood and detected by anti-malware 
products. The free version is not described in this article.

SHELLTER, comme beaucoup d'autres outils de sécurité offensifs (OST), est un produit à double usage. Les acteurs malveillants, une fois qu'ils y ont accès, peuvent utiliser SHELLTER pour prolonger la durée de vie de leurs outils. Les fournisseurs de sécurité offensive réputés, tels que le projet Shellter, mettent en œuvre des mesures de protection pour réduire le risque d'utilisation malveillante de leurs produits. Ces mesures comprennent des limites géographiques de vente, une diligence organisationnelle et des accords de licence pour l'utilisateur final (EULA). Malgré ces efforts, les acteurs malveillants très motivés restent un défi.

À la mi-juin, nos recherches ont permis d'identifier de multiples campagnes de voleurs d'informations à motivation financière qui ont utilisé SHELLTER pour emballer des charges utiles à partir de la fin du mois d'avril 2025. Tout porte à croire qu'il s'agit de la version 11.0 de Shellter Elite, qui a été publiée en avril 16, 2025.

SHELLTER est un projet complexe qui offre un large éventail de paramètres configurables adaptés à des environnements opérationnels spécifiques, à des mécanismes de livraison de charges utiles et à des paradigmes de cryptage. Ce rapport se concentre exclusivement sur les caractéristiques observées dans les campagnes malveillantes identifiées. Bien que certaines caractéristiques semblent communes, un examen exhaustif de toutes les caractéristiques disponibles dépasse le cadre du présent document.

SHELLTER Loader - Détails techniques

Les sections suivantes décrivent les capacités qui ressemblent à certaines des caractéristiques exclusives à l'élite publiées par le projet Shellter. Notre évaluation indique que nous observons l'élite Shellter. Cette conclusion repose sur l'examen de la documentation publique du développeur, sur l'observation de divers échantillons provenant de différentes versions avec un degré élevé de similitude du code, et sur la prévalence de fonctions d'évasion rarement observées.

Code poubelle polymorphe

Les échantillons protégés par SHELLTER utilisent généralement un shellcode auto-modifiant avec une obfuscation polymorphe pour s'intégrer dans des programmes légitimes. Cette combinaison d'instructions légitimes et de code polymorphe permet à ces fichiers d'échapper à la détection statique et aux signatures, ce qui leur permet de ne pas être détectés.

En plaçant un point d'arrêt sur VirtualAlloc dans un échantillon de RHADAMANTHYS protégé par SHELLTER, nous pouvons voir la pile d'appels de cet échantillon de logiciel malveillant.

Ce type de code polymorphe perturbe les désassembleurs statiques et entrave les efforts d'émulation. Ces instructions apparaissent lors de l'étape de déballage, appelant l'une de ces paires de fonctions de l'API Windows pour allouer de la mémoire à un nouveau stub de shellcode :

• GetModuleHandleA / GetProcAddress
• CreateFileMappingW / MapViewOfFile

La fonctionnalité SHELLTER est contenue dans une nouvelle fonction substantielle. Il est atteint après un déballage supplémentaire et des instructions inutiles dans le stub du shellcode. IDA Pro ou Binary Ninja peuvent décompiler le code avec succès à ce stade.

Décrochage des modules du système via les File-mappings

Pour contourner les techniques de crochetage d'API des fournisseurs d'AV/EDR, SHELLTER mappe une nouvelle copie de ntdll.dll via NtCreateSection et NtMapViewOfSection.

Il existe également une deuxième option de décrochage qui consiste à charger une version propre de ntll.dll à partir du répertoire KnownDLLs via NtOpenSection et NtMapViewOfSection.

Cryptage et compression des données utiles

SHELLTER chiffre ses charges utiles finales définies par l'utilisateur en utilisant le mode AES-128 CBC. Ce cryptage peut se produire de deux manières :

• Clé/IV intégrée : une paire clé/IV générée de manière aléatoire est intégrée directement dans la charge utile SHELLTER.
• Clé/IV extraite du serveur : la paire clé/IV est extraite d'un serveur contrôlé par l'adversaire.

Pour les échantillons qui utilisaient l'option intégrée, nous avons réussi à récupérer la charge utile sous-jacente.

Les blobs chiffrés se trouvent à la fin de chaque charge utile SHELLTER.

La clé AES et l'IV sont des constantes chargées dans les variables de la pile au tout début de la charge utile, dans le cadre de sa routine d'initialisation.

Dans Shellter Elite v11.0, par défaut, les charges utiles sont compressées à l'aide de l'algorithme LZNT1 avant d'être cryptées.

Préchargement de DLL & Évasion de la pile d'appels

La fonction "Force Preload System Modules" permet de précharger des DLL essentielles du sous-système Windows, telles que advapi32.dll, wininet.dll, et crypt32.dll, afin de prendre en charge les opérations de la charge utile sous-jacente. Les trois options configurables sont les suivantes

• --Force-PreloadModules-Basic (16 modules à usage général)
• --Force-PreloadModules-Networking (5 modules spécifiques au réseau)
• --Force-PreloadModules-Custom (jusqu'à 16 modules définis par l'utilisateur)

Ces modules sont chargés par l'intermédiaire de LoadLibraryExW ou LdrLoadDll. Les détails relatifs à l'utilisation de l'API par le biais de gestionnaires d'exception vectoriels (VEH) personnalisés seront abordés dans une section ultérieure.

Vous trouverez ci-dessous un exemple de liste de modules préchargés dans une charge utile protégée par SHELLTER qui correspond à l'option --Force-PreloadModules-Basic, trouvée dans un échantillon qui déploie un simple client de chargement C++ abusant de BITS (Background Intelligent Transfer Service) pour C2 - une approche peu commune favorisée par certaines menaces.

L'exemple suivant est une liste qui correspond à l'option --Force-PreloadModules-Networking trouvée dans un exemple de chargement de LUMMA.

Cette fonction(disponible dans Shellter Pro Plus v10.x) exploite la capacité d'évasion de la pile d'appels pour dissimuler la source de l'appel LoadLibraryExW pendant le chargement des bibliothèques liées au réseau et à la cryptographie.

Vous trouverez ci-dessous un exemple de trace de procmon lors du chargement de wininet.dll, montrant une pile d'appels tronquée :

Dans le même échantillon où l'indicateur --Force-PreloadModules-Basic est activé, nous avons observé que les dépendances des modules préchargés étaient également sujettes à la corruption de la pile d'appels. Par exemple, urlmon.dll dissimule également la source de l'appel LoadLibraryExW pour ses dépendances iertutil.dll, srvcli.dll et netutils.dll.

Déconnexion des modules AV/EDR

SHELLTER comprend une fonctionnalité permettant de dissocier les modules DLL leurres qui sont placés dans le bloc d'environnement de processus(PEB). Ces modules leurres sont utilisés par certains fournisseurs de sécurité comme canaris pour surveiller les tentatives de shellcode d'énumérer manuellement la liste PEB LDR. PEB LDR est une structure de Windows qui contient des informations sur les modules chargés d'un processus.

Nous n'avons observé qu'un seul nom de module unique basé sur son hachage (différent pour chaque échantillon), qui se résout en kern3l32.dll [sic].

Obfuscation du hachage de l'API

Les échantillons observés utilisent un ensemencement basé sur le temps pour obscurcir les adresses API. Le logiciel malveillant lit d'abord la valeur SystemTime dans la structure KUSER_SHARED_DATA à l'adresse 0x7FFE0014 pour obtenir une clé XOR dynamique.

Il utilise ensuite un algorithme de hachage seeded-ROR13 sur les noms d'API pour résoudre les adresses des fonctions au moment de l'exécution.

Une fois résolus, ces pointeurs sont éventuellement obscurcis par une opération XOR avec la clé temporelle et par une rotation bit à bit avant d'être stockés dans une table de recherche. Cette tactique est appliquée à l'ensemble du binaire pour dissimuler diverses données telles que d'autres pointeurs de fonctions, des stubs syscall et des handles de modules chargés.

Contrôle du permis de conduire et autodestruction

Pour chaque charge utile SHELLTER, trois structures FILETIME sont intégrées. Dans un exemple d'échantillon, il s'est avéré qu'il s'agissait des éléments suivants :

• Date d'expiration de la licence (2026-04-17 19:17:24.055000)
• Date d'autodestruction (2026-05-21 19:44:43.724952)
• Date de début de l'infection (2025-05-21 19:44:43.724952)

Le contrôle de l'expiration de la licence compare l'heure actuelle à la date d'expiration de la licence et active l'indicateur license_valid dans la structure contextuelle. Il existe 28 sites d'appel uniques (probablement des fonctionnalités sous licence 28 ) pour le contrôle de validité de la licence, où l'indicateur license_valid détermine si la logique du code principal est ignorée, ce qui confirme que la date d'expiration de la licence agit comme un interrupteur d'arrêt.

Par défaut, la date d'autodésarmement est fixée exactement un an après la date de début de l'infection. Lorsque le drapeau d'autodésarmement est déclenché, plusieurs routines de nettoyage sont exécutées. L'une de ces routines consiste à annuler le mappage du module ntdll chargé manuellement (le cas échéant) et à effacer la table de recherche NTAPI, qui fait référence soit au module ntdll mappé manuellement, soit à celui qui a été chargé lors de l'initialisation du processus.

Alors que les dates de début de l'autodestruction et de l'infection diffèrent d'un échantillon à l'autre, nous constatons que la date d'expiration de la licence (2026-04-17 19:17:24.055000) reste constante.

Il est possible que cette heure soit générée de manière unique pour chaque licence délivrée par le projet Shellter. Si c'est le cas, cela confirmerait l'hypothèse selon laquelle une seule copie de Shellter Elite a été acquise à des fins malveillantes. Cette valeur n'apparaît pas dans l'analyse statique, mais elle apparaît dans la première étape décompressée.

Vous trouverez ci-dessous une règle YARA qui peut être utilisée pour identifier cette valeur d'expiration de licence codée en dur dans les échantillons illicites de SHELLTER que nous avons examinés :

rule SHELLTER_ILLICIT_LICENSE {  
    meta:  
        author = "Elastic Security"  
        last_modified = "2025-07-01"  
        os = "Windows"  
        family = "SHELLTER"  
        threat_name = "SHELLTER_ILLICIT_LICENSE"

    strings:

        // 2026-04-17 19:17:24.055000  
        $license_server = { c7 84 24 70 07 00 00 70 5e 2c d2 c7 84 24 74 07 00 00 9e ce dc 01}

    condition:  
        any of them  
}

Évasion du balayage de la mémoire

Les échantillons protégés par SHELLTER ont mis en œuvre diverses techniques, y compris des évasions au niveau de l'exécution, pour éviter d'être détectés. Ces types de techniques sont les suivants :

• Décodage et réencodage des instructions au moment de l'exécution
• Suppression des autorisations d'exécution sur les pages de mémoire inactives
• Réduction de l'empreinte, impact des signatures en mémoire avec YARA
• Utilisation des structures internes de Windows, telles que PEB, comme points d'ancrage temporaires pour les données.

SHELLTER génère un stub de type trampoline basé sur la version du système d'exploitation. Une page de 4 KB contient ce stub, où les permissions de mémoire fluctuent en utilisant NtQueryVirtualMemory et NtProtectVirtualMemory.

Une fois la page active, les octets codés peuvent être observés à cette adresse, 0x7FF5FFCE0000.

SHELLTER décode cette page lorsqu'elle est active au moyen d'une boucle XOR utilisant la clé SystemTime dérivée de la structure KUSER_SHARED_DATA.

Vous trouverez ci-dessous cette même page mémoire (0x7FF5FFCE0000), montrant le stub trampoline décodé pour le syscall (ntdll_NtOpenFile).

Lorsque la fonctionnalité est nécessaire, les autorisations de la page de mémoire sont définies avec des autorisations de lecture/exécution (RX). Après l'exécution, les pages sont désactivées.

La protection continue des fonctionnalités clés pendant l'exécution complique les efforts d'analyse et de détection. Ce niveau de protection est rare dans les échantillons de logiciels malveillants en général.

Appels Syscall indirects / Corruption de la pile d'appels

Comme le montre la section précédente, SHELLTER contourne les crochets du mode utilisateur en utilisant des appels syscall indirects basés sur le trampoline. Au lieu d'invoquer directement syscall, il prépare la pile avec l'adresse d'une instruction syscall propre provenant de ntdll.dll. Une instruction ret insère ensuite cette adresse dans le registre RIP, détournant ainsi furtivement l'exécution vers l'instruction syscall.

Vous trouverez ci-dessous un exemple d'événements Elastic Defend VirtualProtect, montrant la combinaison des deux évasions (syscall indirect et call stack truncation). Cette technique permet de contourner ou de perturber divers mécanismes de détection de sécurité.

Détection avancée de VM/Sandbox

La documentation de SHELLTER fait référence à une fonction de détection de l'hyperviseur. Une capacité similaire est observée dans nos échantillons malveillants après un appel à ZwQuerySystemInformationEx à l'aide des instructions CPUID et _bittest. Cette fonctionnalité renvoie diverses informations sur le processeur ainsi que le drapeau de la technologie Hyper-Threading (HTT).

Détection du débogueur (UM/KM)

SHELLTER utilise la détection de débogage en mode utilisateur et en mode noyau en utilisant les drapeaux du tas de processus et en vérifiant le drapeau KdDebuggerEnabled via la structure _KUSER_SHARED_DATA.

Dérivation AMSI

Il existe deux méthodes de contournement de l'AMSI. La première méthode consiste à patcher en mémoire les fonctions AMSI. Cette technique consiste à rechercher dans les fonctions des motifs d'octets spécifiques et à les modifier afin d'altérer la logique de la fonction. Par exemple, il écrase une chaîne de 4 octets "AMSI" avec des octets nuls et effectue des sauts conditionnels vers son opposé.

La seconde méthode est légèrement plus sophistiquée. Tout d'abord, il tente éventuellement de saboter la recherche de l'interface COM (Component Object Model) en trouvant la constante GUID CLSID_Antimalware {fdb00e52-a214-4aa1-8fba-4357bb0072ec} dans amsi.dll, en plaçant un pointeur sur cette constante dans une section de données accessible en écriture et en corrompant ce pointeur pour qu'il pointe sur 8 octets avant le GUID proprement dit.

Le pointeur ciblé est le pointeur CLSID dans l'entrée de la carte d'objets ATL (Active Template Library) du module AMSI, une structure utilisée par la fonction DllGetClassObject pour trouver et créer des classes COM enregistrées. En corrompant le pointeur dans cette carte, la recherche du fournisseur de logiciels anti-malware échouera, ce qui empêchera sa création, provoquant ainsi l'échec de AmsiInitialize et l'apparition d'une exception CLASS_E_CLASSNOTAVAILABLE.

Il appelle ensuite AmsiInitialize - Si le correctif précédent n'a pas eu lieu et que l'appel à l'API est réussi, il effectue un correctif de table virtuelle en guise de mécanisme de secours. Le HAMSICONTEXT obtenu à partir du AmsiInitialize contient un pointeur vers un objet COM IAntimalware, qui contient à son tour un pointeur vers sa table de fonctions virtuelles. La dérivation vise la fonction IAntimalware::Scan dans ce tableau. Pour la neutraliser, le code recherche une instruction ret dans la page de mémoire contenant la fonction IAntimalware::Scan.

Après avoir trouvé un gadget approprié, il écrase le pointeur de fonction Scan avec l'adresse du gadget ret. Il en résulte que tout appel ultérieur à AmsiScanBuffer ou AmsiScanString invoquera la table virtuelle modifiée, sautera directement à une instruction ret et reviendra immédiatement.

Proxy API de gestionnaire d'exception vectoriel

Il existe un mécanisme sophistiqué de proxy d'API qui est réalisé en redirigeant les appels aux API résolues et aux stubs syscall élaborés par le biais d'un gestionnaire d'exception personnalisé, qui agit comme un proxy de flux de contrôle. Elle peut être décomposée en deux phases : la mise en place et l'exécution.

La phase 1 consiste à allouer deux pages de mémoire spéciales qui serviront de "déclencheurs" pour le gestionnaire d'exception. La protection de ces pages est réglée sur PAGE_READONLY, et toute tentative d'exécution du code à cet endroit provoquera une exception STATUS_ACCESS_VIOLATION, ce qui est prévu. Les adresses de ces pages de déclenchement sont stockées dans la structure du contexte :

• api_call_trigger_page - La page qui sera appelée pour initier le proxy.
• api_return_trigger_page - La page à laquelle l'API réelle renverra.

Un modèle de gestionnaire d'exception du binaire est copié dans une région allouée et enregistré comme gestionnaire principal pour le processus à l'aide de RtlAddVectoredExceptionHandler. Une valeur magique codée en dur (0xe1e2e3e4e5e6e7e8) dans le gestionnaire est alors remplacée par un pointeur vers la structure de contexte elle-même.

Si l'on examine un exemple de site d'appel, si le proxy VEH doit être utilisé, l'adresse de GetCurrentDirectoryA sera stockée dans ctx_struct->target_API_function et le pointeur de la fonction API sera remplacé par l'adresse de la page de déclenchement de l'appel. Cette page de déclenchement est ensuite appelée, ce qui déclenche une exception STATUS_ACCESS_VIOLATION.

Le flux de contrôle est redirigé vers le gestionnaire d'exception. L'adresse d'erreur du contexte d'exception est vérifiée et, si elle correspond à la page de déclenchement de l'appel, elle sait qu'il s'agit d'un appel proxy API entrant et effectue les opérations suivantes :

• Conservez l'adresse de retour originale
• Remplacer l'adresse de retour sur la pile par l'adresse de la page de déclenchement du retour
• Définit le registre RIP à l'adresse API réelle sauvegardée précédemment dans ctx_struct->target_API_function.

L'appel GetCurrentDirectoryA est ensuite exécuté. Lorsqu'il a terminé, il passe à la page de déclenchement du retour, ce qui provoque une deuxième exception STATUS_ACCESS_VIOLATION et redirige le flux de contrôle vers le gestionnaire d'exception. L'adresse d'erreur est vérifiée pour voir si elle correspond à la page de déclenchement du retour ; si c'est le cas, RIP est mis à l'adresse de retour d'origine et le flux de contrôle retourne au site d'appel d'origine.

Campagnes

En juin, Elastic Security Labs a identifié plusieurs campagnes déployant divers voleurs d'informations protégés par Shellter Elite, comme en témoignent les informations de licence présentes dans chaque binaire. En tirant parti de l'outil susmentionné, nous avons observé des acteurs de la menace dans différentes campagnes intégrer rapidement ce chargeur très évasif dans leurs propres flux de travail.

LUMMA

LUMMA infostealer a été distribué avec SHELLTER à partir de la fin avril, comme en témoignent les métadonnées contenues dans les fichiers binaires. Bien que le vecteur d'infection initial ne soit pas clair, nous avons pu vérifier (à l'aide de ANY.RUN) que les fichiers concernés étaient hébergés sur la plateforme d'hébergement de fichiers MediaFire.

Vouloir vendre

Le 16 mai, l'utilisateur de Twitter/X @darkwebinformer a posté une capture d'écran avec la légende :

🚨Shellter Elite v11.0 à vendre sur un forum populaire

Dans ce cas, "Exploit Garant" fait référence à une tierce partie de type "escrow" qui sert de médiateur à la transaction.

ARECHCLIENT2

À partir du mois de mai, nous avons observé des campagnes ciblant les créateurs de contenu avec des appâts centrés sur les possibilités de parrainage. Il s'agit de courriels d'hameçonnage envoyés à des personnes ayant une chaîne YouTube et se faisant passer pour des marques telles que Udemy, Skillshare, Pinnacle Studio et Duolingo. Les courriels contiennent des liens de téléchargement vers des fichiers d'archive (.rar), qui contiennent un contenu promotionnel légitime emballé avec un exécutable protégé par SHELLTER.

Cet exécutable sous-jacent présente des caractéristiques et des comportements communs avec notre analyse précédente de SHELLTER. À l'heure où nous écrivons ces lignes, nous pouvons encore voir des échantillons avec des taux de détection très bas dans VirusTotal. Cela est dû à de multiples facteurs associés à des fonctions personnalisées permettant d'éviter l'analyse statique, notamment le code polymorphe, l'insertion de code dans des applications légitimes et l'application de certificats de signature de code.

La charge utile intégrée observée dans ce fichier déploie l'infostealer ARECHCLIENT2, également connu sous le nom de SECTOP RAT. Le C2 de ce voleur pointe vers 185.156.72[.]80:15847, qui a déjà été identifié par notre équipe le 17 juin lorsque nous avons discuté de cette menace en association avec le chargeur GHOSTPULSE.

RHADAMANTHYS

Ces infections commencent par des vidéos YouTube traitant de sujets tels que le piratage de jeux et les mods de jeux, dont les commentaires renvoient à des fichiers malveillants hébergés sur MediaFire.

L'un des fichiers distribués précédemment selon cette méthode a été soumis 126 fois par différentes personnes à la date de la présente publication.

Ce fichier présente les mêmes caractéristiques comportementales que le code sous-jacent des sections précédentes de l'analyse SHELLTER. La charge utile intégrée à cet échantillon déploie l'infostealer RHADAMANTHYS.

Dévidoir SHELLTER

Elastic Security Labs publie un décompresseur dynamique pour les binaires protégés par SHELLTER. Cet outil s'appuie sur une combinaison de techniques d'analyse dynamique et statique pour extraire automatiquement plusieurs étapes de la charge utile d'un binaire protégé par SHELLTER.

Comme SHELLTER offre une large gamme de fonctions optionnelles, ce déballeur n'est pas totalement complet, bien qu'il traite avec succès une grande majorité des échantillons testés. Même avec des binaires non pris en charge, il est généralement en mesure d'extraire au moins un étage de charge utile.

Pour des raisons de sécurité, cet outil ne doit être exécuté que dans une machine virtuelle isolée. Au cours du processus de décompactage, un code exécutable potentiellement malveillant est placé dans la mémoire. Bien que certaines garanties de base aient été mises en place, elles ne sont pas infaillibles.

Conclusion

Malgré les efforts de la communauté commerciale des OST pour conserver leurs outils à des fins légitimes, les méthodes d'atténuation sont imparfaites. Comme beaucoup de nos clients, ils sont confrontés à des attaquants persistants et motivés. Bien que le projet Shellter soit victime dans cette affaire de la perte de propriété intellectuelle et du temps de développement futur, d'autres participants à l'espace de sécurité doivent maintenant faire face à des menaces réelles utilisant des outils plus performants.

Nous attendons :

• Cette version illicite de SHELLTER continuera à circuler au sein de la communauté criminelle et pourra éventuellement être transmise à des acteurs alignés sur les États-nations.
• Le projet Shellter mettra à jour et publiera une version qui atténuera les possibilités de détection identifiées dans cette analyse.
  • Tout nouvel outil restera une cible pour les acteurs malveillants.
• Les menaces plus avancées analyseront ces échantillons et intégreront des fonctionnalités dans leurs outils.

Notre objectif est que cette analyse aide les défenseurs à détecter rapidement ces campagnes de vol d'informations et les prépare à une éventuelle extension de ces techniques à d'autres domaines du paysage offensif.

Logiciels malveillants et MITRE ATT&CK

Elastic utilise le cadre MITRE ATT& CK pour documenter les tactiques, techniques et procédures communes que les menaces utilisent contre les réseaux d'entreprise.

Tactiques

Les tactiques représentent le pourquoi d'une technique ou d'une sous-technique. Il s'agit de l'objectif tactique de l'adversaire : la raison pour laquelle il effectue une action.

• Commande et contrôle
• Collecte
• Évasion par la défense
• Exécution
• Accès initial
• Développement de ressources

Techniques

Les techniques représentent la manière dont un adversaire atteint un objectif tactique en effectuant une action.

• Protocole de la couche application
• Données du système local
• Injection de processus : Détournement de l'exécution d'un thread
• Fichiers ou informations obfusqués : Insertion de code indésirable
• Injection de contenu
• Obtenir des capacités

Atténuation de l'effet SHELLTER

La prévention

• Shellcode provenant d'un module inhabituel signé par Microsoft
• Shellcode non sauvegardé provenant d'un module non signé
• Exécution d'un shellcode à partir d'un module à faible réputation
• Evasion potentielle via une signature de code invalide
• Suspension du fil de la mémoire non sauvegardée
• Mappage suspect de la mémoire d'un exécutable

YARA

Elastic Security a créé des règles YARA pour identifier cette activité.

rule Windows_Trojan_Shellter {  
    meta:  
        author = "Elastic Security"  
        creation_date = "2025-06-30"  
        last_modified = "2025-06-30"  
        os = "Windows"  
        arch = "x86"  
        category_type = "Trojan"  
        family = "Shellter"  
        threat_name = "Windows.Trojan.Shellter"  
        reference_sample = "c865f24e4b9b0855b8b559fc3769239b0aa6e8d680406616a13d9a36fbbc2d30"

    strings:  
        $seq_api_hashing = { 48 8B 44 24 ?? 0F BE 00 85 C0 74 ?? 48 8B 44 24 ?? 0F BE 00 89 44 24 ?? 48 8B 44 24 ?? 48 FF C0 48 89 44 24 ?? 8B 04 24 C1 E8 ?? 8B 0C 24 C1 E1 ?? 0B C1 }  
        $seq_debug = { 48 8B 49 30 8B 49 70 8B 40 74 0B C1 25 70 00 00 40 85 C0 75 22 B8 D4 02 00 00 48 05 00 00 FE 7F }  
        $seq_mem_marker = { 44 89 44 24 ?? 89 54 24 ?? 48 89 4C 24 ?? 33 C0 83 F8 ?? 74 ?? 48 8B 44 24 ?? 8B 4C 24 ?? 39 08 75 ?? EB ?? 48 63 44 24 ?? 48 8B 4C 24 }  
        $seq_check_jmp_rcx = { 48 89 4C 24 ?? B8 01 00 00 00 48 6B C0 00 48 8B 4C 24 ?? 0F B6 04 01 3D FF 00 00 00 75 ?? B8 01 00 00 00 48 6B C0 01 48 8B 4C 24 ?? 0F B6 04 01 3D E1 00 00 00 75 ?? B8 01 00 00 00 }  
        $seq_syscall_stub = { C6 84 24 98 00 00 00 4C C6 84 24 99 00 00 00 8B C6 84 24 9A 00 00 00 D1 C6 84 24 9B 00 00 00 B8 C6 84 24 9C 00 00 00 00 C6 84 24 9D 00 00 00 00 C6 84 24 9E 00 00 00 00 }  
        $seq_mem_xor = { 48 8B 4C 24 ?? 0F B6 04 01 0F B6 4C 24 ?? 3B C1 74 ?? 8B 44 24 ?? 0F B6 4C 24 ?? 48 8B 54 24 ?? 0F B6 04 02 33 C1 8B 4C 24 ?? 48 8B 54 24 ?? 88 04 0A }  
        $seq_excep_handler = { 48 89 4C 24 08 48 83 EC 18 48 B8 E8 E7 E6 E5 E4 E3 E2 E1 48 89 04 24 48 8B 44 24 20 48 8B 00 81 38 05 00 00 C0 }  
    condition:  
        3 of them  
}

Observations

Toutes les observables sont également disponibles au téléchargement dans les formats ECS et STIX.

Les observables suivants ont été examinés dans le cadre de cette recherche.

Références

Les éléments suivants ont été référencés tout au long de la recherche ci-dessus :

• https://x.com/DarkWebInformer/status/1923472392157790700
• https://www.shellterproject.com/shellter-editions-feature-comparison-table/
• https://www.shellterproject.com/Downloads/ShellterElite/Shellter_Elite_Exclusive_Features.pdf
• https://github.com/elastic/labs-releases/tree/main/tools/shellter