GhostRedirector : quand le SEO masque une intrusion IIS

65 serveurs Windows compromis en juin 2025. Pas pour chiffrer des données, ni pour voler des secrets industriels à la une des journaux, mais pour installer une porte dérobée et… truquer le référencement Google.

C’est exactement ce que montre l’affaire GhostRedirector, documentée par des chercheurs : un acteur malveillant a combiné une backdoor C++ (Rungan), un module IIS natif (Gamshen) et des techniques d’élévation de privilèges de type Potato pour garder la main sur des serveurs web. Le détail qui dérange : la fraude SEO ne touche souvent pas les visiteurs, seulement les robots d’indexation. Autrement dit, votre site peut « aller bien » en apparence tout en servant d’infrastructure à une opération clandestine.

Dans cette édition de notre série « Intelligence artificielle dans la cybersécurité », je prends ce cas comme exemple concret d’un point que beaucoup d’équipes IT sous-estiment : les attaques modernes se cachent dans les “zones grises” (anomalies faibles, comportements contextuels, signaux dispersés). Et c’est précisément là que la détection pilotée par l’IA peut faire la différence.

GhostRedirector, en clair : intrusion serveur + fraude SEO ciblée Googlebot

Réponse directe : GhostRedirector compromet des serveurs Windows (souvent IIS), installe des mécanismes d’accès à distance et détourne la réputation SEO des sites hébergés pour pousser des sites tiers (probablement liés au jeu).

Les chercheurs ont observé :

• Au moins 65 serveurs Windows compromis (détection et scan à grande échelle en 2025).
• Une concentration géographique notable : Brésil, Thaïlande, Vietnam, avec des cas dans d’autres pays.
• Des secteurs variés : santé, assurance, retail, transport, éducation, technologie… signe d’une exploitation opportuniste.

Le cœur de l’arsenal se joue en deux « couches » :

1. Contrôle du serveur : via une backdoor et des comptes admin persistants.
2. Monétisation discrète : via un module IIS qui modifie les réponses… mais seulement pour les crawlers.

Et c’est là que l’histoire devient intéressante pour les équipes SOC : si vous ne surveillez que les symptômes “visibles” (plainte utilisateurs, pages cassées), vous passez à côté.

Rungan : une porte dérobée HTTP hors d’IIS

Réponse directe : Rungan ouvre un point d’entrée HTTP et exécute des commandes à distance, sans passer par le pipeline IIS.

Rungan s’installe sous forme de DLL et enregistre une URL d’écoute (ex. un chemin spécifique sur le port 80) en s’appuyant sur l’API HTTP de Windows. Une fois activée par des paramètres attendus, la backdoor peut :

• exécuter des commandes système,
• créer des utilisateurs,
• gérer des URL additionnelles,
• effectuer un début de découverte de répertoires.

Un élément marquant opérationnellement : le protocole de commande n’est pas forcément sophistiqué. Ce qui compte, c’est le positionnement (hors IIS) et la persistance.

Gamshen : le module IIS qui “ment” à Google

Réponse directe : Gamshen modifie la réponse HTTP uniquement quand la requête ressemble à Googlebot, afin d’injecter du contenu SEO et des backlinks vers une cible.

Gamshen est un module IIS natif (C/C++) qui s’accroche aux événements du pipeline web. Il filtre les requêtes selon :

• un User-Agent ou un referer évoquant Googlebot,
• des méthodes (évite POST),
• des extensions (évite images/CSS/JS),
• des motifs d’URL « plausibles ».

Ensuite, il récupère du contenu depuis une infrastructure de commande et l’injecte dans la réponse renvoyée au crawler. Un visiteur humain ne verra rien. Résultat : le site compromis devient une usine à signaux SEO artificiels.

Ce type d’abus a deux impacts concrets pour l’entreprise :

1. Risque réputationnel : association à du spam/black-hat SEO, déclassement potentiel.
2. Risque sécurité : si un acteur sait installer un module IIS natif, il sait aussi installer autre chose (webshell, redirection malveillante, collecte).

Les “Potatoes” : pourquoi l’élévation de privilèges change tout

Réponse directe : GhostRedirector utilise des exploits publics de type BadPotato/EfsPotato pour créer des comptes administrateurs et renforcer sa résilience.

Une fois un premier accès obtenu (les signaux pointent vers une vulnérabilité applicative, probablement de type injection SQL), l’attaquant télécharge des outils (souvent via PowerShell) et déclenche une élévation de privilèges locale.

Ce que j’observe souvent en incident response : beaucoup d’équipes pensent qu’une compromission web = “juste” un problème applicatif. En réalité, le passage en admin est le moment où l’incident change de catégorie :

• installation de backdoors “système”,
• création de comptes,
• modification de services,
• déploiement de webshells,
• persistance robuste.

Dans ce cas, plusieurs noms de comptes ont été observés (ex. variantes autour de MysqlServiceEx), typiques des comptes « qui ne font pas tache » dans une liste.

Le détail qui piège : le serveur continue de “fonctionner”

Gamshen est conçu pour ne pas casser le site. Les webshells peuvent être déposés dans des répertoires qui contiennent déjà des contenus dynamiques, et certains timestamps sont ajustés pour ressembler à des fichiers légitimes.

C’est une stratégie pragmatique : un site cassé déclenche une alerte. Un site “OK” mais qui empoisonne Google en silence peut rester compromis longtemps.

Ce que l’IA détecte mieux (et plus tôt) que les règles seules

Réponse directe : l’IA est particulièrement efficace sur les attaques discrètes où les signaux sont faibles, distribués et contextuels (anomalies comportementales, corrélations multi-sources, séquences).

Les règles statiques (IOC, signatures) restent utiles, mais elles ont deux limites dans un cas comme GhostRedirector :

• les outils sont custom (Rungan, Gamshen), donc peu signés au départ,
• l’attaque est “calme” : peu de bruit côté utilisateurs, et des déclenchements conditionnels (Googlebot).

L’intérêt de l’IA en cybersécurité, c’est d’apprendre ce qui est normal pour votre environnement et de repérer ce qui s’en écarte.

1) Détection d’anomalies sur la chaîne applicative → système

Exemple concret : voir sqlserver.exe à l’origine d’exécutions PowerShell (via xp_cmdshell) n’est pas un “bug”, c’est un scénario d’attaque classique.

Un modèle comportemental peut remonter des alertes du type :

• processus inattendu → interpréteur de commandes (SQL Server → cmd → PowerShell),
• téléchargements répétés vers C:\ProgramData\,
• exécutions d’outils inhabituels (certutil, binaires signés étrangement, etc.).

Le point clé : le modèle ne se limite pas à un hash. Il reconnaît une séquence.

2) Détection d’artefacts IIS “hors routine”

Un module IIS natif installé n’est pas forcément malveillant. Mais dans beaucoup d’organisations, c’est rare et encadré.

Avec de la télémétrie et un peu d’IA, vous pouvez surveiller :

• modifications de la configuration IIS,
• chargement de DLL non standard par w3wp.exe,
• nouveaux fichiers dans des chemins atypiques (ex. répertoires qui imitent des composants Microsoft).

3) Détection réseau orientée “intention”

Gamshen va chercher du contenu externe pour l’injection. Même si les domaines changent, le comportement reste similaire :

• requêtes sortantes depuis un serveur web vers des hôtes non attendus,
• réponses encodées (ex. base64),
• pics corrélés à des passages de crawlers.

Une approche IA aide à prioriser ce qui est rare sur un serveur IIS par rapport à une station utilisateur.

Phrase à retenir : Quand un attaquant ne déclenche pas d’erreur visible, la détection doit se faire sur le comportement, pas sur les symptômes.

Mesures concrètes : quoi vérifier lundi matin sur vos serveurs IIS

Réponse directe : vous réduisez fortement le risque GhostRedirector en durcissant l’exécution, en surveillant IIS et en chassant les comptes admin anormaux.

Voici une checklist pragmatique (sans se raconter d’histoires : elle prend du temps, mais elle évite des mois de compromission silencieuse).

Durcissement et hygiène

1. Désactivez xp_cmdshell si vous n’en avez pas un besoin strict et documenté.
2. Appliquez un processus de patching serré sur les applis exposées (les compromissions opportunistes vivent des retards).
3. Restreignez PowerShell (modes contraints, journalisation renforcée, contrôle applicatif).

Surveillance orientée attaque

• Surveillez les créations/modifications de comptes et l’ajout au groupe Administrateurs.
• Alertez sur l’exécution de powershell.exe ou cmd.exe depuis des processus serveurs (SQL Server, w3wp, services applicatifs).
• Inventoriez et contrôlez les modules IIS réellement nécessaires (baseline + alertes sur dérive).

Chasse (threat hunting) ciblée SEO-fraud

• Comparez le contenu servi à :
  • un navigateur classique,
  • un user-agent “crawler” (dans un environnement de test).
• Analysez les logs pour des patterns “bizarres” : URL aux motifs artificiels, accès sélectifs, réponses modifiées.

Où l’IA s’insère dans votre stratégie SOC (sans promesses irréalistes)

Réponse directe : l’IA apporte de la valeur quand elle corrèle vos signaux (endpoint, serveur, identité, réseau) et produit des alertes exploitables, pas quand elle remplace vos fondamentaux.

Je prends position : l’IA ne compense pas une mauvaise visibilité. Si vous n’avez pas de logs serveurs, pas d’audit comptes, pas de télémétrie sur les processus, aucun modèle ne “devinera” l’attaque.

En revanche, avec une collecte minimale, l’IA peut :

• prioriser les événements rares (ceux qu’un SOC ignore faute de temps),
• regrouper des signaux épars en un incident cohérent,
• accélérer le triage et réduire la fenêtre d’exposition.

C’est exactement le type d’attaque qui justifie une approche détection + réponse pilotée par données : backdoor personnalisée, module IIS discret, fraude SEO ciblant Googlebot, persistance par comptes admin.

Et maintenant : transformer ce cas en avantage opérationnel

GhostRedirector rappelle une réalité simple : un serveur web compromis n’est pas toujours bruyant. Parfois, il sert à une activité “business” pour l’attaquant (SEO, affiliation, trafic) et il restera stable pour éviter de se faire remarquer.

La prochaine étape logique, surtout pour les organisations qui gèrent des environnements IIS/Windows exposés, c’est de passer d’une défense par listes (hash, IP) à une défense par comportements. C’est là que l’intelligence artificielle dans la cybersécurité devient un outil concret : elle aide à repérer l’anormal avant que l’impact (réputation, compromission étendue, nouveaux payloads) ne s’installe.

Si votre SOC devait détecter une fraude SEO “invisible” demain, sur quels signaux s’appuierait-il : contenu web, modules IIS, séquences de processus, identités… ou seulement des IOC ?