GhostRedirector : quand l’IA traque les backdoors IIS

En juin 2025, au moins 65 serveurs Windows ont été compromis dans une campagne qui n’avait rien d’un braquage “classique”. Le but n’était pas uniquement de voler des données ou de chiffrer des systèmes, mais aussi de détourner la réputation des sites web hébergés sur ces serveurs pour manipuler Google. C’est précisément le genre d’attaque qui passe sous le radar des équipes IT quand elles se fient uniquement à des alertes “connues”.

Ce cas, baptisé GhostRedirector, illustre une réalité que je vois de plus en plus : la frontière entre cybercriminalité, fraude marketing et compromission serveur s’efface. Et face à des outils sur mesure (backdoor C++ + module IIS natif) qui ne déclenchent pas forcément d’alarme, l’IA appliquée à la cybersécurité n’est pas un gadget. C’est une façon pragmatique de détecter l’inhabituel, de prioriser, et de répondre avant que le dommage (technique et réputationnel) ne s’installe.

GhostRedirector en clair : une compromission “double usage”

GhostRedirector, tel qu’observé depuis fin 2024 (avec des artefacts remontant à août 2024), s’appuie sur une logique simple : compromettre des serveurs Windows exposés, obtenir des privilèges élevés, puis installer des composants qui assurent exécution de commandes, persistance et monétisation via fraude SEO.

Les éléments saillants (et utiles à retenir côté défense) :

• Victimes : au moins 65 serveurs, principalement au Brésil, en Thaïlande et au Vietnam (avec des cas ailleurs).
• Secteurs : variés (santé, assurance, retail, transport, éducation, IT), ce qui ressemble à de l’opportunisme.
• Chaîne d’attaque : exploitation initiale probable d’une appli exposée (souvent une logique de type injection), puis téléchargement d’outils via PowerShell/certutil.
• Deux charges finales majeures :
  • Rungan : backdoor passive en C/C++ capable d’exécuter des commandes.
  • Gamshen : module IIS natif conçu pour empoisonner l’indexation Google (fraude SEO “as-a-service”).

Phrase à garder en tête : une attaque peut viser votre SEO avant de viser vos données.

Pourquoi cette attaque est difficile à voir sans détection “intelligente”

La particularité la plus dérangeante de GhostRedirector, c’est sa composante Gamshen : elle ne modifie les réponses HTTP que pour Googlebot (ou des signaux associés), tout en laissant les visiteurs “normaux” voir un site parfaitement sain.

Gamshen : fraude SEO via module IIS natif

Un module IIS natif (DLL C++) s’insère dans le pipeline IIS et peut intercepter des événements comme :

• OnBeginRequest
• OnPreExecuteRequestHandler
• OnPostExecuteRequestHandler
• OnSendResponse

Concrètement, Gamshen filtre des requêtes (User-Agent, referer, type de ressource, patterns d’URL) et injecte du contenu récupéré depuis une infrastructure distante dans la réponse que recevra le crawler. Si la récupération échoue, il peut même rediriger le bot.

Résultat :

• Google indexe des pages “polluées” (backlinks artificiels, contenu sur-optimisé, redirections).
• Votre marque peut se retrouver associée à des pratiques douteuses.
• Votre domaine peut perdre de la confiance (voire subir des sanctions SEO), même si le site “semble normal”.

C’est une attaque asymétrique : le symptôme n’est pas un crash, c’est une réputation qui glisse.

Rungan : backdoor discrète hors IIS

Rungan, lui, prend une approche différente : il enregistre une URL d’écoute via l’API HTTP de Windows (sans passer par IIS) et attend des requêtes spécifiques, puis exécute des commandes. Ce type de mécanisme est pénible à surveiller avec des contrôles purement “web”, parce que l’attaquant peut contourner ce que vous regardez habituellement (logs IIS, règles WAF centrées sur l’application, etc.).

“Potatoes” et comptes admin : la persistance qui ruine les remédiations

GhostRedirector s’appuie sur des outils d’élévation de privilèges inspirés/exploités via EfsPotato et BadPotato. Le but observé est très concret : créer un utilisateur local privilégié (groupe Administrators) ou modifier un compte existant.

Ce point est essentiel en réponse à incident :

• Vous pouvez supprimer une webshell.
• Vous pouvez supprimer une DLL suspecte.
• Mais si un compte admin furtif reste présent (ou si des mécanismes de repli existent), l’attaquant revient.

Dans les compromissions serveur, la persistance la plus “rentable” reste souvent… un identifiant/mot de passe et un accès distant discret.

Là où l’IA en cybersécurité change vraiment la donne

GhostRedirector est un bon cas d’école pour comprendre l’intérêt des approches IA/ML dans la défense. Pas parce que “l’IA voit tout”, mais parce que le problème à résoudre n’est pas un manque de données : c’est un excès de signaux faibles.

1) Détecter l’anomalie comportementale sur les serveurs Windows

Les IOC (hash, domaines) sont utiles… jusqu’au jour où l’infrastructure change. En pratique, une défense robuste combine IOC et détection comportementale, par exemple :

• Exécutions PowerShell inhabituelles lancées depuis un binaire serveur (sqlserver.exe est un signal particulièrement parlant dans ce scénario).
• Téléchargements d’exécutables vers des répertoires atypiques (ex. C:\ProgramData\ et chemins “bizarres” liés à DRM/log).
• Création/modification de comptes locaux suivie d’ajout au groupe Administrators.
• Enregistrement d’URL d’écoute via l’API HTTP Windows (écart par rapport au fonctionnement normal du serveur web).

Des modèles de détection (ou une couche IA dans un EDR/XDR) sont très efficaces pour prioriser ces chaînes d’événements plutôt que de déclencher 20 alertes séparées.

2) Repérer une fraude SEO “invisible” aux utilisateurs

C’est le piège Gamshen : les visiteurs ne voient rien.

Les bonnes stratégies orientées IA consistent à :

• Comparer automatiquement le contenu servi à différents profils (navigateur standard vs. crawler simulé) et détecter les divergences.
• Surveiller les patterns d’URL et réponses 404/302 anormales quand l’agent ressemble à un bot.
• Corréler les modifications de ranking, l’apparition de pages “fantômes” dans l’indexation, et des signaux serveur.

Dit autrement : l’IA aide à industrialiser une vérification que personne ne fait manuellement à l’échelle.

3) Accélérer la réponse : du triage à l’éradication

Dans un incident GhostRedirector, la vitesse compte. L’IA est utile si elle vous aide à répondre à trois questions opérationnelles :

1. Quels serveurs sont réellement touchés ? (corrélation de télémétrie)
2. Quel est le mécanisme de persistance ? (comptes, modules IIS, tâches, services)
3. Qu’est-ce qu’on doit reconstruire vs. nettoyer ? (décision guidée par le niveau de compromission)

Les plateformes modernes (SIEM + SOAR + détection augmentée) permettent d’automatiser des actions sûres : isoler un hôte, désactiver un compte, collecter des artefacts, déclencher une enquête ciblée.

Mesures concrètes : ce que je ferais dès lundi matin

Si vous gérez des serveurs Windows exposés (IIS, SQL Server, applis métiers), voici une checklist réaliste, pensée pour limiter ce type de campagne.

1) Réduire la surface d’attaque côté application

• Traquer et corriger les vulnérabilités d’applications exposées (les injections restent un grand classique, surtout sur des apps héritées).
• Désactiver/encadrer les fonctions dangereuses côté SQL Server (ex. procédures permettant l’exécution de commandes) quand ce n’est pas strictement nécessaire.
• Mettre en place des règles WAF axées sur les patterns d’injection et sur les comportements, pas uniquement sur des signatures.

2) Verrouiller IIS contre les modules malveillants

• Inventorier régulièrement les modules IIS chargés (et alerter sur toute DLL non approuvée).
• Durcir les permissions d’écriture sur les répertoires système et applicatifs.
• Mettre en place une supervision de l’intégrité (hash/allowlist) sur les répertoires où un module IIS pourrait être déposé.

3) Protéger l’identité locale (le vrai “fallback” des attaquants)

• Auditer la création de comptes locaux et l’ajout à des groupes privilégiés.
• Mettre des alertes “haute priorité” sur : création d’utilisateur + ajout au groupe Administrators + connexion RDP/outil distant.
• Rotation des secrets et nettoyage post-incident : si un serveur est compromis, partez du principe que les identifiants le sont aussi.

4) Instrumenter la détection avec une logique IA (utile, pas décorative)

• Exiger de votre EDR/XDR des détections basées sur séquences d’événements (attaque chain) : exploitation → PowerShell → drop → élévation → persistance.
• Mettre en place des “canaris” : faux comptes admin, faux répertoires surveillés, règles de détection sur chemins anormaux.
• Créer une routine mensuelle “SEO sécurité” : échantillonnage automatisé du contenu servi à des crawlers simulés + comparaison.

Une idée simple qui marche : surveiller ce que Google voit, pas seulement ce que vos utilisateurs voient.

Pourquoi ce cas s’inscrit parfaitement dans une série “IA et cybersécurité”

GhostRedirector montre un angle souvent sous-estimé : la sécurité n’est pas seulement la confidentialité, c’est aussi l’intégrité de votre présence en ligne. Quand un serveur IIS est détourné pour faire de la fraude SEO, l’impact peut être commercial (trafic en baisse, marque dégradée) autant que technique (porte dérobée, webshells, comptes admin persistants).

L’IA appliquée à la cybersécurité est particulièrement pertinente ici, car elle aide à :

• détecter des malwares sur mesure (backdoors et modules IIS) via comportements,
• identifier des schémas d’abus “invisibles” (cloaking pour crawlers),
• orchestrer la réponse sur plusieurs signaux faibles.

Si votre organisation héberge des applications web sur Windows, la question n’est pas “est-ce qu’on aura une alerte antivirus”. La question c’est : est-ce qu’on saura repérer une altération subtile, conçue pour tromper les moteurs de recherche, avant qu’elle n’abîme durablement le domaine ?

Prochaine étape utile : cartographier vos serveurs IIS critiques, définir une baseline “normale”, puis ajouter une couche de détection augmentée (IA) sur les écarts. Le ROI se voit le jour où l’attaque ressemble à GhostRedirector.