TOLLBOOTH : Quel est le vôtre, IIS le mien ?

Introduction

En septembre 2025, Texas A& M University System (TAMUS) Cybersecurity, un fournisseur de services de détection et de réponse en collaboration avec Elastic Security Labs, a découvert une activité post-exploitation par un acteur de menace parlant chinois qui a installé un module IIS malveillant, que nous appelons TOLLBOOTH. Au cours de cette période, nous avons observé un cadre webshell Godzilla-forked, l'utilisation de l'outil de surveillance et de gestion à distance (RMM) GotoHTTP, ainsi qu'un pilote malveillant utilisé pour dissimuler leur activité. L'auteur de la menace a exploité un serveur web IIS mal configuré qui utilisait des clés machine ASP.NET trouvées dans des ressources publiques, telles que la documentation de Microsoft ou les pages d'assistance StackOverflow.

Une série d'événements similaires a été signalée pour la première fois par Microsoft en février, au début de cette année. Notre équipe pense qu'il s'agit de la poursuite de la même activité de menace que celle décrite par AhnLab en avril, sur la base de logiciels malveillants et de comportements similaires. Au cours de cet événement, nous avons pu tirer parti de notre partenariat avec Texas A&M System Cybersecurity pour recueillir des informations sur l'activité. En outre, grâce à notre collaboration avec Validin, qui s'appuie sur son infrastructure de numérisation mondiale, nous avons déterminé que des organisations du monde entier ont été touchées par cette campagne. Le rapport suivant détaille les événements et l'outillage utilisés dans ce groupe d'activités, connu sous le nom de REF3927. Nous espérons sensibiliser davantage les défenseurs et les organisations à cette activité, qui fait l'objet d'abus à l'échelle mondiale.

Principaux points abordés dans cet article

• Les acteurs de la menace abusent de serveurs IIS mal configurés en utilisant des clés de machine exposées publiquement.
• Les comportements post-compromission comprennent l'utilisation d'un pilote malveillant, d'outils de surveillance à distance, de vidage de données d'identification, de déploiement de webshell et de logiciels malveillants IIS.
• Les acteurs de la menace ont adapté le projet de rootkit open source "Hidden" pour dissimuler leur présence.
• L'objectif principal semble être d'installer une porte dérobée IIS, appelée TOLLBOOTH, qui comprend des capacités de masquage SEO et de webshell.
• Cette campagne comprenait une exploitation à grande échelle dans toutes les zones géographiques et tous les secteurs d'activité.

Aperçu de la campagne

Vecteur d'attaque

Le mois dernier, Elastic Security Labs et Texas A&M System Cybersecurity ont enquêté sur une intrusion impliquant un serveur Windows IIS mal configuré. Ce problème était directement lié à un serveur configuré avec des clés de machine ASP.NET qui avaient été publiées sur l'internet. Les clés machine utilisées dans les applications ASP.NET font référence aux clés cryptographiques utilisées pour chiffrer et valider les données. Ces clés sont composées de deux parties, ValidationKey et DecryptionKey, qui sont utilisées pour sécuriser les fonctions ASP.NET telles que ViewState et les cookies d'authentification.

ViewState est un mécanisme utilisé par les applications web ASP.NET pour préserver l'état d'une page et de ses contrôles à travers les requêtes HTTP. Comme HTTP est un protocole sans état, ViewState permet de collecter des données lorsque la page est soumise et rendue à nouveau. Ces données sont stockées dans un champ caché (__VIEWSTATE) sur la page qui est sérialisé et encodé en Base64. Ce champ ViewState est susceptible de faire l'objet d'attaques par désérialisation, ce qui permet à un pirate de falsifier des charges utiles en utilisant les clés de machine de l'application. Nous avons des raisons de penser qu'il s'agit d'une campagne opportuniste visant les serveurs web Windows qui utilisent des clés de machine exposées publiquement.

Vous trouverez ci-dessous un exemple de ce type d'attaque par désérialisation, démontré par une requête POST dans un environnement virtuel à l'aide d'un générateur de charge utile de désérialisation .NET à source ouverte. Le champ __VIEWSTATE contient une charge utile codée en URL et en Base64 qui effectuera un whoami et écrira un fichier dans un répertoire. Si la demande d'exploitation aboutit, le serveur répondra par un message HTTP/1.1 500 Internal Server Error.

Activité post-compromis

Après l'accès initial par injection de ViewState, REF3927 a été observé en train de déployer des webshells, y compris un cadre de shell Godzilla, pour faciliter l'accès persistant. Ils ont ensuite énuméré les privilèges et tenté (en vain) de créer leurs propres comptes d'utilisateur. Lorsque les tentatives de création de compte ont échoué, l'acteur a ensuite téléchargé et exécuté l'outil de surveillance et de gestion à distance (RMM) GotoHTTP. L'acteur de la menace a créé un compte d'administrateur et a tenté de déverser des informations d'identification à l'aide de Mimikatz, mais Elastic Defend l'en a empêché.

Les tentatives d'extension de la portée de l'intrusion ayant été bloquées, l'acteur de la menace a déployé son module IIS de détournement de trafic, TOLLBOOTH, afin de monétiser son accès. L'acteur a également tenté de déployer une version modifiée du rootkit open-source Hidden afin d'obscurcir son logiciel malveillant. Dans l'intrusion observée, Elastic Defend a empêché l'exécution de TOLLBOOTH et du rootkit.

Analyse EKP de Godzilla

L'un des principaux outils utilisés par ce groupe est un framework Godzilla-forked appelé Z-Godzilla_ekp écrit par ekkoo-z. Cet outil se greffe sur le projet Godzilla précédent en ajoutant de nouvelles fonctionnalités telles qu'un plugin de contournement AMSI et en masquant son trafic réseau pour paraître plus légitime. Cette boîte à outils permet aux opérateurs de générer des charges utiles ASP.NET, Java, C# et PHP, de se connecter à des cibles et offre différentes options de cryptage pour dissimuler le trafic réseau. Ce cadre utilise un système de plugins piloté par une interface graphique dotée de nombreuses fonctionnalités, notamment

• Capacités de découverte et d'énumération
• Techniques d'escalade des privilèges
• Exécution de commandes/de fichiers
• Chargeur de shellcode, meterpreter, exécution PE en mémoire
• Gestion de fichiers, utilitaire de zippage
• Plugin de vol de données (lemon) - Récupère les données d'identification de FileZilla, Navicat, WinSCP et Xmanager.
• Récupération de mots de passe dans les navigateurs
• Balayage des ports, configuration du proxy HTTP, prise de notes

Vous trouverez ci-dessous un exemple de trafic réseau montrant le trafic de l'opérateur vers le webshell (error.aspx) à l'aide de Z-Godzilla_ekp. Le webshell récupère les données AES codées en Base64 de la requête HTTP POST, puis exécute l'assemblage .NET en mémoire. Ces demandes sont déguisées en intégrant les données chiffrées dans les paramètres HTTP POST afin de se fondre dans le trafic normal du réseau.

Analyse des rootkits

L'attaquant a dissimulé sa présence sur la machine infectée en déployant un rootkit de noyau. Ce rootkit fonctionne en conjonction avec une application userland nommée HijackDriverManager, dont les chaînes d'interface sont écrites en chinois, afin d'interagir avec le pilote. Pour cette analyse, nous avons examiné à la fois le rootkit malveillant et le code du projet open-source original "Hidden" dont il est dérivé. En interne, nous appelons le rootkit HIDDENDRIVER et l'application userland HIDDENCLI.

Ce logiciel malveillant est une version modifiée du rootkit open source Hidden, disponible sur GitHub depuis des années. L'auteur du logiciel malveillant a apporté des modifications mineures avant la compilation. Par exemple, le rootkit utilise la manipulation directe d'objets du noyau (Direct Kernel Object Manipulation - DKOM) pour dissimuler sa présence et maintenir sa persistance sur le système compromis. Le pilote compilé contient toujours "hidden" dans la chaîne du chemin de compilation, ce qui indique qu'ils ont utilisé le projet de rootkit "Hidden".

Lors du chargement initial dans le noyau, le pilote donne la priorité à une série d'étapes d'initialisation critiques. Il invoque d'abord sept fonctions d'initialisation :

• InitializeConfigs
• InitializeKernelAnalyzer
• InitializePsMonitor
• InitializeFSMiniFilter
• InitializeRegistryFilter
• InitializeDevice
• InitializeStealthMode

Préparer ses composants internes avant de remplir son objet pilote et les champs associés, tels que les fonctions principales.

Les sections suivantes décrivent en détail chacune de ces sept fonctions d'initialisation essentielles, en précisant leur objectif.

InitializeConfigs

La première action du rootkit consiste à exécuter la fonction InitializeConfigs. Cette fonction a pour seul but de lire la configuration du rootkit à partir de la clé de service du pilote dans le registre Windows, qui est alimenté par l'application userland. Ces valeurs sont extraites et placées dans des variables de configuration globales qui seront utilisées ultérieurement par le rootkit.

Le tableau suivant résume les paramètres de configuration que le rootkit extrait du registre :

InitializeKernelAnalyzer

Son but est de parcourir dynamiquement la mémoire du noyau pour trouver les adresses de PspCidTable et ActiveProcessLinks qui sont nécessaires.

Le PspCidTable est la structure du noyau qui sert de table pour les identifiants des processus et des threads, tandis que la structure ActiveProcessLinks sous la structure _EPROCESS sert de liste doublement liée reliant tous les processus en cours d'exécution. Il permet au système de suivre et de parcourir tous les processus actifs. En supprimant des entrées de cette liste, il est possible de cacher des processus à des outils d'énumération tels que Process Explorer.

LookForPspCidTable

Il recherche l'adresse PspCidTable en désassemblant la fonction à l'aide de la bibliothèque Zydis et en l'analysant. PsLookupProcessByProcessIdavec la bibliothèque Zydis et en l'analysant.

Recherche de liens de processus actifs

Cette fonction détermine le décalage du champ ActiveProcessLinks dans la structure _EPROCESS. Il utilise des valeurs d'offset codées en dur, spécifiques aux différentes versions de Windows. Il dispose d'un processus de balayage rapide qui s'appuie sur ces valeurs codées en dur pour trouver le champ ActiveProcessLinks, qui sera validé par une autre fonction. S'il ne le trouve pas avec les valeurs codées en dur, il adopte une approche de force brute en commençant par un décalage relatif codé en dur jusqu'au décalage maximal possible.

InitializePsMonitor

InitializePsMonitor met en place le moteur de surveillance et de manipulation des processus du rootkit. C'est le cœur de sa capacité à dissimuler des processus.

Il initialise d'abord trois structures arborescentes AVL qui contiennent des informations (règles) sur l'exclusion, la protection et le masquage des processus. Il utilise RtlInitializeGenericTableAvl pour les recherches à grande vitesse et les remplit avec les données de la configuration. Il met ensuite en place différents rappels du noyau pour surveiller le système à l'aide de l'ensemble des règles.

Enregistrement du rappel du gestionnaire d'objets avec (ObRegisterCallbacks)

Ce crochet enregistre les fonctions ProcessPreCallback et ThreadPreCallback. Le gestionnaire d'objets du noyau exécute ce code avant de terminer toute demande de création ou de duplication d'un handle vers un processus ou un thread.

Lorsqu'un processus tente d'obtenir un handle sur un autre processus, la fonction de rappel ProcessPreCallback est appelée. Il vérifie d'abord si le processus de destination est un processus protégé (dans la liste). Si c'est le cas, au lieu de ne pas accorder l'accès, il rétrogradera simplement ses droits sur le processus protégé dont l'accès est fixé à SYNCHRONIZE | PROCESS_QUERY_LIMITED_INFORMATION.

Cela garantit que les processus ne peuvent pas interagir avec le processus protégé, ni l'inspecter ou le tuer.

Le même mécanisme s'applique aux fils.

Rappel de création de processus (PsSetCreateProcessNotifyRoutineEx)

Le rootkit enregistre un rappel auprès de l'API PsSetCreateProcessNotifyRoutineEx lors de la création d'un processus. Lorsqu'un nouveau processus est lancé, ce rappel exécute une fonction CheckProcessFlags qui vérifie l'image du processus par rapport à la liste configurée des chemins d'accès aux images. Il crée ensuite une entrée pour ce nouveau processus dans son tableau de suivi interne, en paramétrant ses drapeaux excluded, protected et hidden en conséquence.

Comportement basé sur les drapeaux :

• Exclus
  • Le rootkit ignorera le processus et le laissera s'exécuter comme prévu.
• Protégé
  • Le rootkit ne permet à aucun autre processus d'obtenir un accès privilégié, comme c'est le cas dans ProcessPreCallback.
• Caché
  • Le rootkit dissimule le processus par manipulation directe d'objets du noyau (DKOM). La manipulation directe des structures du noyau d'un processus au moment même de sa création peut être instable. Dans le rappel de création du processus, si un processus doit être caché, il est supprimé de la liste ActiveProcessLinks. Cependant, il active un drapeau postponeHiding qui sera expliqué plus loin.

Le rappel de chargement d'image (PsSetLoadImageNotifyRoutine)

Cela permet d'enregistrer l'adresse LoadProcessImageNotifyCallback à l'aide de PsSetLoadImageNotifyRoutineque le noyau appelle chaque fois qu'une image exécutable ( .exe ou .dll) est chargée dans la mémoire d'un processus.

Lorsque l'image est chargée, le callback vérifie l'indicateur postponeHiding; s'il est activé, il appelle UnlinkProcessFromCidTable pour le supprimer de la table d'identification du processus maître (PspCidTable).

InitializeFSMiniFilter

La fonction définit ses capacités dans l'élément FilterRegistration structure(FLT_REGISTRATION). Cette structure indique au système d'exploitation les fonctions à appeler pour les différents types d'opérations du système de fichiers. Il enregistre des rappels pour les demandes suivantes :

• IRP_MJ_CREATE: Intercepte toute tentative d'ouverture ou de création d'un fichier ou d'un répertoire.
• IRP_MJ_DIRECTORY_CONTROL: Intercepte toute tentative d'énumérer le contenu d'un répertoire.

FltCreatePreOperation(IRP_MJ_CREATE)

Il s'agit d'un rappel de pré-opération, lorsqu'un processus tente de créer/ouvrir un fichier, cette fonction est déclenchée. Il vérifiera le chemin d'accès par rapport à sa liste de fichiers à masquer. Si une correspondance est trouvée, le résultat de l'opération de la requête IRP devient STATUS_NO_SUCH_FILE, indiquant au processus demandeur que le fichier n'existe pas, sauf si le processus est inclus dans la liste des exclusions.

FltDirCtrlPostOperation(IRP_MJ_DIRECTORY_CONTROL)

Il s'agit d'un rappel après l'opération ; le crochet mis en œuvre intercepte essentiellement l'écoute du répertoire générée par le système et la modifie en supprimant tous les fichiers répertoriés comme étant cachés.

InitializeRegistryFilter

Après avoir dissimulé ses processus et ses fichiers, l'étape suivante du rootkit consiste à effacer les entrées du registre Windows. La fonction InitializeRegistryFilter accomplit cette tâche en installant un rappel de filtrage du registre pour intercepter et modifier les opérations du registre.

Il enregistre un rappel à l'aide de l'API CmRegisterCallbackEx en utilisant le même principe que pour les fichiers. Si la clé ou la valeur de registre se trouve dans la liste des registres cachés, la fonction de rappel renvoie l'état STATUS_NOT_FOUND.

Initialiser l'appareil

La fonction InitializeDevice effectue l'initialisation du pilote nécessaire et met en place une interface de communication avec le pilote. IOCTL communication afin que l'application userland puisse communiquer directement avec elle

Le tableau suivant décrit chaque commande IOCTL gérée par le pilote.

Initialiser le mode furtif

Après avoir configuré avec succès sa configuration, ses rappels de processus et ses filtres de système de fichiers, le rootkit exécute sa routine d'initialisation finale : InitializeStealthMode. Si l'option de configuration Kbj_YinshenMode est activée, elle masquera tous les artefacts associés au rootkit, y compris les clés de registre, le fichier .sys et d'autres composants connexes, en utilisant les mêmes techniques que celles décrites ci-dessus.

Variations du code

Bien que le logiciel malveillant soit largement basé sur le code source de HIDDENDRIVER, notre analyse a permis d'identifier plusieurs modifications mineures. La section suivante présente les différences de code notables que nous avons observées.

Le code original de la fonction IsProcessExcluded exclut systématiquement le processus système (PID 4) des opérations du rootkit. Cependant, le rootkit malveillant dispose d'une liste d'exclusion pour d'autres noms de processus, comme le montre la capture d'écran ci-contre.

Le rappel du code original pour filtrer les informations système (y compris les fichiers, les répertoires et les registres) utilisait la fonction IsDriverEnabled pour vérifier si les fonctionnalités du pilote étaient activées. Cependant, le rootkit observé a introduit une vérification supplémentaire et automatique de la liste blanche pour les processus avec le détournement du nom de l'image, qui correspond à l'application userland.

Utilisation de RMM

L'outil GotoHTTP est une application légitime de surveillance et de gestion à distance (RMM), déployée par l'auteur de la menace pour faciliter l'accès au serveur IIS compromis. Son architecture "navigateur-client" permet à l'attaquant de contrôler le serveur à partir de n'importe quel navigateur web standard sur les ports web courants (80/443) en acheminant l'ensemble du trafic via la plate-forme de GotoHTTP, ce qui empêche toute connexion réseau directe avec l'infrastructure de l'attaquant.

La popularité des RMM ne cesse de croître, car ils sont utilisés à de multiples endroits de la chaîne de destruction cybernétique et par divers acteurs de la menace. La plupart des éditeurs de logiciels anti-malveillants ne les considèrent pas comme malveillants en soi et ne les bloquent donc pas d'emblée. Le RMM C2 ne circule également que vers les sites web légitimes des fournisseurs de RMM, et présente donc la même dynamique pour les protections et la surveillance basées sur le réseau.

Le mécanisme de protection optimal consisterait à bloquer la masse des RMM actuellement actifs et à n'autoriser que le RMM préféré de l'entreprise. Toutefois, ce paradigme n'est accessible qu'aux entreprises disposant des connaissances techniques adéquates, d'outils défensifs, de politiques organisationnelles mûres et d'une coordination entre les départements.

Analyse du module IIS

L'acteur de la menace a été observé en train de déployer des versions 32 bits et 64 bits de TOLLBOOTH, un module IIS malveillant. TOLLBOOTH a été discuté précédemment par Ahnlab et le chercheur en sécurité, @Azaka. Parmi les principales fonctionnalités de ce logiciel malveillant, citons le masquage SEO, un canal de gestion et un webshell accessible au public. Nous avons découvert que des versions natives et des versions gérées par .NET étaient déployées dans la nature.

Structure de configuration des logiciels malveillants

TOLLBOOTH récupère sa configuration de manière dynamique sur hxxps://c[.]cseo99[.]com/config/<victim_HTTP_host_value>.json, et la création du fichier de configuration JSON de chaque victime est gérée par l'infrastructure de l'acteur de la menace. Cependant, hxxps://c[.]cseo99[.]com/config/127.0.0.1.json a répondu, montrant un manque de contrôles anti-analyse - ce qui nous a permis de récupérer une copie d'un fichier de configuration pour l'analyser. Elle peut être consultée dans cette Gist GitHub, et nous ferons référence à la manière dont certains des champs sont utilisés, le cas échéant.

Pour les modules natifs, les fichiers de configuration et autres fichiers de cache temporaires sont compressés par Gzip et stockés localement dans un chemin codé en dur C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\. Pour le module géré, ces données sont cryptées en AES avec la clé YourSecretKey123 et l'IV 0123456789ABCDEF, compressées en Gzip et stockées à l'adresse C:\\Windows\\Temp\\AcpLogs\\.

Webshell

TOLLBOOTH expose un webshell au chemin d'accès /mywebdll, nécessitant un mot de passe hack123456! pour le téléchargement de fichiers et l'exécution de commandes. La soumission d'un formulaire envoie une demande POST au point de terminaison /scjg.

Le mot de passe est codé en dur dans le fichier binaire, et cette fonction webshell est présente à la fois dans v1.6.0 et v1.6.1 de la version native de TOLLBOOTH.

La fonctionnalité de téléchargement de fichiers contient un bogue qui provient de l'analyse séquentielle et dépendante de l'ordre des champs multipart/form-data. Le formulaire HTML standard est structuré de manière à ce que le champ de saisie du fichier apparaisse avant les champs de saisie du répertoire. Le serveur qui traite les parties de la demande tente de traiter les données du fichier avant le répertoire de destination, ce qui crée un conflit de dépendance qui entraîne l'échec des téléchargements standard. En réorganisant manuellement les parties du site multipart/form-data, il est possible de déclencher le téléchargement d'un fichier.

Canal de gestion

TOLLBOOTH expose quelques points d'extrémité supplémentaires à des fins de gestion/débogage pour les opérateurs C2. Ils ne sont accessibles qu'en paramétrant l'agent utilisateur sur l'un des éléments suivants (bien qu'il soit configurable) :

Hijackbot
gooqlebot
Googlebot/2.;
Googlébot
Googlêbot
Googlebót;
Googlebôt;
Googlebõt;
Googlèbot;
Googlëbot;
Binqbot
bingbot/2.;
Bíngbot
Bìngbot
Bîngbot
Bïngbot
Bingbót;
Bingbôt;
Bingbõt;

Le point d'accès /health permet d'évaluer rapidement l'état de santé du module. Il renvoie le nom du fichier permettant d'accéder à la configuration stockée à l'adresse c[.]cseo99[.]com, des informations sur l'espace disque, le chemin d'installation du module et la version de TOLLBOOTH.

Le point d'accès /debug fournit plus de détails, notamment un résumé de la configuration, le répertoire du cache, des informations sur les requêtes HTTP, etc.

La configuration analysée est accessible à l'adresse /conf.

Le point de terminaison /clean permet à l'opérateur d'effacer la configuration actuelle en supprimant les fichiers de configuration stockés localement (clean?type=conf) afin de les mettre à jour sur le serveur victime, d'effacer tout autre cache temporaire utilisé par le logiciel malveillant (clean?type=conf), ou d'effacer les deux - tout ce qui se trouve dans le chemin d'accès C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\ (clean?type=all).

L'occultation des moteurs de recherche

L'objectif principal de TOLLBOOTH est l'occultation SEO, un processus qui consiste à présenter un contenu optimisé pour les mots-clés aux robots des moteurs de recherche, tout en le dissimulant aux utilisateurs occasionnels, afin d'obtenir un meilleur classement de la page dans les moteurs de recherche. Lorsqu'un visiteur humain clique sur le lien figurant dans les résultats de recherche optimisés, le logiciel malveillant le redirige vers une page malveillante ou frauduleuse. Cette tactique est un moyen efficace d'augmenter le trafic vers des pages malveillantes par rapport à d'autres solutions comme l'hameçonnage direct, car les utilisateurs font davantage confiance aux résultats des moteurs de recherche qu'ils demandent qu'aux courriels non sollicités.

TOLLBOOTH fait la différence entre les robots et les visiteurs en vérifiant les en-têtes User Agent et Referer pour les valeurs définies dans la configuration.

Les modules natifs et les modules gérés sont mis en œuvre de manière presque identique. La seule différence est que les modules natifs v1.6.0 et v1.6.1 vérifient à la fois l'agent utilisateur et le référent par rapport à la liste seoGroupRefererMatchRules, tandis que le module .NET v1.6.1 vérifie l'agent utilisateur par rapport à la liste seoGroupUaMatchRules et le référent par rapport à la liste seoGroupRefererMatchRules.

Sur la base de la configuration actuelle, les valeurs pour seoGroupUaMatchRules et seoGroupRefererMatchRules sont respectivement googlebot et google. Un robot GoogleBot aurait une correspondance avec l'agent utilisateur mais pas avec le référent, tandis qu'un visiteur humain aurait une correspondance avec le référent mais pas avec l'agent utilisateur. L'examen de la liste de remplacement contenant à la fois bing et yahoo suggère que ces moteurs de recherche ont également été ciblés par le passé.

L'extrait de code ci-dessous est responsable de la construction d'une page remplie de liens bourrés de mots-clés que les robots d'indexation des moteurs de recherche verront.

Le module construit une ferme de liens en deux phases. Tout d'abord, pour établir la densité des liens internes, il récupère une liste de mots-clés aléatoires à partir des URI de ressources définies dans le champ de configuration affLinkMainWordSeoResArr. Pour chaque mot-clé, il génère un lien local "" pointant vers une autre page SEO du même site web compromis. Ensuite, il construit le réseau externe en récupérant les ressources du lien d'affiliation "" dans le champ affLinkSeoResArr. Ces ressources sont une liste d'URI pointant vers des pages SEO sur d'autres domaines externes également infectés par TOLLBOOTH. Les URI ressemblent à hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> dans la configuration. Le module crée ensuite des hyperliens du site actuel vers ces autres victimes. Cette technique, connue sous le nom de " link farming", est conçue pour gonfler artificiellement le classement des moteurs de recherche dans l'ensemble du réseau de sites compromis.

Vous trouverez ci-dessous un exemple de ce qu'un robot d'exploration verrait lorsqu'il visiterait la page d'accueil d'un serveur web infecté par TOLLBOOTH.

Les préfixes des chemins d'accès aux pages SEO contiennent des mots ou des phrases provenant du champ de configuration seoGroupUrlMatchRules. Il est également mentionné dans la logique de redirection du site ciblant les visiteurs. Il s'agit actuellement de

• stock
• invest
• summary
• datamining
• market-outlook
• bullish-on
• news-overview
• news-volatility
• video/
• app/
• blank/

Les modèles et le contenu des pages SEO sont également récupérés en externe à partir d'URI qui ressemblent à hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> dans la configuration. Voici un exemple de ce à quoi ressemble l'une des pages de référencement :

Pour la logique de redirection de l'utilisateur, le module recueille d'abord une empreinte digitale du visiteur, comprenant son adresse IP, son agent utilisateur, son référent et le mot-clé cible de la page de référencement. Il envoie ensuite ces informations via une requête POST à hxxps://api[.]aseo99[.]com/client/landpage. Si la demande aboutit, le serveur répond par un objet JSON contenant une adresse spécifique landpageUrl, qui devient la destination de la redirection.

Si la communication échoue pour quelque raison que ce soit, TOLLBOOTH construit une nouvelle URL pointant vers le même point d'arrivée C2, mais encode les informations du visiteur directement dans l'URL sous forme de paramètres GET. Enfin, l'URL choisie - qu'elle provienne de la réponse C2 réussie ou de la solution de repli - est intégrée dans un extrait de JavaScript (window.location.href) et envoyée au navigateur de la victime, forçant ainsi une redirection immédiate.

Page Hijacker

Pour les modules natifs, si le chemin URI contient xlb, TOLLBOOTH répond par une page de chargement personnalisée contenant une balise de script. L'attribut src de ce script pointe vers une URL générée dynamiquement, mlxya[.]oss-accelerate[.]aliyuncs[.]com/<12_random_alphanumeric_characters>, qui est utilisée pour récupérer une charge utile JavaScript obfusquée à l'étape suivante.

La charge utile désobfusquée semble être un outil de remplacement de page qui s'exécute sur la base de mots-clés déclencheurs spécifiques (par exemple, xlbh, mxlb) trouvés dans l'URL. Une fois déclenché, il contacte l'un des points de terminaison contrôlés par l'attaquant à l'adresse asf-sikkeiyjga[.]cn-shenzhen[.]fcapp[.]run/index/index?href= ou ask-bdtj-selohjszlw[.]cn-shenzhen[.]fcapp[.]run/index/index?key=, en ajoutant l'URL de la page actuelle en tant que paramètre codé en Base64 pour identifier le site compromis. Le script utilise ensuite document.write() pour effacer complètement le DOM de la page actuelle et le remplacer par la réponse du serveur. Bien que la charge utile finale n'ait pas pu être récupérée au moment de la rédaction de ce document, cette technique est conçue pour injecter un contenu contrôlé par l'attaquant, le plus souvent une page HTML malveillante ou une redirection JS vers un autre site malveillant.

Ciblage des campagnes

Lors de l'analyse de TOLLBOOTH et de son webshell associé, nous avons identifié de nombreux mécanismes permettant d'identifier d'autres victimes par le biais de méthodes de collecte actives et semi-passives.

Nous nous sommes ensuite associés à @SreekarMad de Validin pour tirer parti de son expertise et de leur infrastructure d'analyse afin de dresser une liste plus complète des victimes.

Au moment de la publication, 571 victimes de serveurs IIS ont été identifiées avec des infections actives par TOLLBOOTH.

Ces serveurs sont répartis dans le monde entier (à une exception près, décrite ci-dessous) et ne correspondent pas à des secteurs verticaux bien définis. Pour ces raisons, ainsi que pour l'ampleur de l'opération, nous sommes amenés à penser que la sélection des victimes n'est pas ciblée et qu'elle s'appuie sur un balayage automatique pour identifier les serveurs IIS réutilisant des clés de machine répertoriées publiquement.

La collaboration avec Validin et Texas A&M System Cybersecurity a permis d'obtenir une grande quantité de métadonnées sur les autres victimes infectées par TOLLBOOTH.

L'exploitation automatisée peut également être employée, mais TAMUS Cybersecurity a noté que l'activité post-exploitation semblait être interactive.

Validin a découvert d'autres domaines potentiellement infectés liés par les configurations de liens d'élevage SEO, mais a constaté que l'interface webshell était inaccessible sur certains d'entre eux. Après avoir mené une enquête manuelle plus approfondie sur ces serveurs, nous avons déterminé qu'ils avaient en fait été infectés par TOLLBOOTH, mais que les propriétaires avaient remédié au problème ou que les attaquants s'étaient retirés d'eux-mêmes.

Une analyse ultérieure a révélé qu'un grand nombre des mêmes serveurs étaient réinfectés. Nous en avons déduit que la remédiation était incomplète. Une explication plausible est que le simple fait d'éliminer la menace ne supprime pas la vulnérabilité laissée ouverte par la réutilisation de la clé de la machine. Ainsi, les victimes qui omettent cette dernière étape sont susceptibles d'être réinfectées par le même mécanisme. Voir la section "Remédier à REF3927" ci-dessous pour plus de détails.

Géographie

La répartition géographique des victimes exclut notamment tout serveur situé à l'intérieur des frontières de la Chine. Un serveur a été identifié à Hong Kong, mais il hébergeait un domaine .co.uk. Ce geofencing probable s'aligne sur les modèles de comportement d'autres menaces criminelles, qui mettent en œuvre des mécanismes pour s'assurer qu'ils ne ciblent pas les systèmes de leur pays d'origine. Cela réduit le risque de poursuites, car les gouvernements de ces pays ont tendance à fermer les yeux sur les activités criminelles visant les étrangers, quand ils ne les approuvent pas carrément.

Modèle diamant

Elastic Security Labs utilise le modèle du diamant pour décrire les relations de haut niveau entre les adversaires, les capacités, l'infrastructure et les victimes d'intrusions. Alors que le modèle en diamant est le plus souvent utilisé avec des intrusions uniques et qu'il s'appuie sur le filtrage des activités (section 8) pour créer des relations entre les incidents, un modèle centré sur l'adversaire (section 7.1.4) peut également être utilisé. permet d'obtenir un seul diamant.

Remédier à REF3927

La remédiation de l'infection elle-même peut être réalisée grâce aux meilleures pratiques de l'industrie, telles que le retour à un état propre et le traitement des logiciels malveillants et des mécanismes de persistance. Cependant, face à une éventuelle analyse et exploitation automatisées, la vulnérabilité de la clé machine réutilisée demeure pour tout acteur malveillant qui souhaite prendre le contrôle du serveur.

Par conséquent, la remédiation doit inclure la rotation des clés de machine vers une nouvelle clé correctement générée.

Conclusion

La campagne REF3927 montre comment une simple erreur de configuration, telle que l'utilisation d'une clé de machine exposée publiquement, peut conduire à une compromission importante. Dans ce cas, la cybersécurité du système universitaire Texas A&M et le client concerné ont pris des mesures rapides pour remédier au problème du serveur, mais d'après nos recherches, d'autres victimes continuent d'être ciblées en utilisant les mêmes techniques.

L'intégration par l'acteur de la menace d'un outil open-source, d'un logiciel RMM et d'un pilote malveillant est une combinaison efficace de techniques qui ont fait leurs preuves dans leurs opérations. Les administrateurs d'environnements IIS exposés au public devraient vérifier leurs configurations de clés de machine, assurer une journalisation solide de la sécurité et utiliser des solutions de détection de points finaux telles qu'Elastic Defend en cas d'incidents potentiels.

Logique de détection

Règles de détection

• Détection du Web Shell : Processus de script enfant des processus Web courants

Règles de prévention

• Exécution suspecte via les services Windows
• Injection potentielle de Shellcode via un WebShell
• Exécution à partir d'un répertoire suspect

Signatures de YARA

Elastic Security a créé les règles YARA suivantes pour empêcher les logiciels malveillants observés dans REF3927 :

• Windows.Trojan.Tollbooth
• Windows.Trojan.HiddenCli
• Windows.Trojan.HiddenDriver

REF3927 par 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.

• Accès initial
• Exécution
• Évasion par la défense
• Accès aux identifiants
• Collecte
• Exfiltration

Techniques

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

• Exploit Public-Facing Application
• Composant logiciel du serveur : Composants IIS
• Récupération des identifiants sur les SE
• Hide Artifacts: Hidden Files and Directories
• Données du système local
• Rootkit
• Comptes valides

Observations

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://www.microsoft.com/en-us/security/blog/2025/02/06/code-injection-attacks-using-publicly-disclosed-asp-net-machine-keys/
• https://asec.ahnlab.com/en/87804/
• https://unit42.paloaltonetworks.com/initial-access-broker-exploits-leaked-machine-keys/
• https://blog.blacklanternsecurity.com/p/aspnet-cryptography-for-pentesters
• https://github.com/ekkoo-z/Z-Godzilla_ekp
• https://x.com/AzakaSekai_/status/1969294757978652947

Addendum

HarfangLab a publié son projet de recherche sur cette menace le jour même de la publication de ce billet. Il contient des informations complémentaires :

• https://x.com/securechicken/status/1980715257791193420
• https://harfanglab.io/insidethelab/rudepanda-owns-iis-servers-like-2003/