IA et DNS hijacking : contrer l’attaque PlushDaemon

Un routeur compromis. Rien de spectaculaire à l’écran, pas de rançon, pas d’alerte bruyante. Et pourtant, c’est souvent là que tout se joue : une simple redirection DNS peut suffire à transformer une mise à jour logicielle « normale » en porte d’entrée pour un implant.

C’est exactement ce que montre l’opération attribuée à PlushDaemon, un acteur aligné sur la Chine actif depuis au moins 2018. Son approche est dérangeante parce qu’elle vise un angle mort encore fréquent en entreprise : la confiance implicite dans l’infrastructure réseau locale (routeurs, boîtiers edge, équipements SOHO, IoT), et la confiance implicite dans les mises à jour.

Dans cette série « Intelligence artificielle dans la cybersécurité », ce cas est précieux : il illustre pourquoi l’IA n’est pas un gadget de plus, mais un moyen concret de détecter des signaux faibles (anomalies DNS, redirections furtives, comportements d’update inhabituels) avant que l’incident ne devienne une compromission durable.

PlushDaemon : une attaque qui commence… avant le poste de travail

Réponse directe : PlushDaemon contourne l’endpoint en attaquant le réseau. L’idée n’est pas d’envoyer un phishing sophistiqué. L’idée est de prendre le contrôle d’un équipement réseau (par exemple un routeur), puis de manipuler le trafic de toute une organisation.

Le mode opératoire observé s’appuie sur un implant réseau baptisé EdgeStepper (un binaire ELF pour processeurs MIPS32, typiques de nombreux équipements réseau). Une fois présent sur l’équipement, EdgeStepper redirige le trafic DNS (port 53) vers un nœud DNS malveillant qui répond « intelligemment » : si la requête concerne un domaine lié aux mises à jour, il renvoie l’IP d’un serveur de détournement contrôlé par l’attaquant.

Ce point est crucial :

• L’utilisateur ne fait rien d’inhabituel.
• Le logiciel effectue une mise à jour « attendue ».
• L’attaque se déroule dans la plomberie du réseau.

Ce style d’attaque — souvent qualifié d’adversary-in-the-middle (AITM) — est particulièrement efficace dans des environnements où les équipements réseau sont peu supervisés et rarement durcis.

Comment le DNS hijacking transforme une mise à jour en infection

Réponse directe : l’attaquant détourne la résolution DNS pour servir une “fausse” mise à jour. Dans le scénario analysé, EdgeStepper agit comme un proxy DNS : il intercepte les requêtes DNS et les fait transiter par une infrastructure contrôlée par l’attaquant.

Le mécanisme AITM, en trois mouvements

1. Compromission d’un équipement réseau : via vulnérabilité logicielle, identifiants par défaut, ou mots de passe faibles.
2. Redirection DNS : tout ce qui passe en DNS peut être orienté vers un serveur malveillant.
3. Détournement des mises à jour : quand un logiciel cherche une mise à jour, il est dirigé vers un serveur de “hijacking” qui lui répond comme si c’était l’infrastructure légitime.

Dans l’exemple étudié, un logiciel de saisie (IM) populaire communique en HTTP avec ce qu’il croit être l’infrastructure d’update. Le serveur malveillant lui indique ensuite de télécharger une DLL présentée comme un composant normal… qui est en réalité LittleDaemon, un premier chargeur.

Pourquoi ça marche encore en 2025

Parce que beaucoup d’organisations ont encore :

• des segments où le DNS n’est pas surveillé finement,
• des mises à jour applicatives qui reposent sur HTTP ou sur des mécanismes insuffisamment vérifiés,
• une visibilité limitée sur les équipements edge (routeurs, passerelles, boîtiers opérateurs).

Le résultat : on peut avoir un EDR très coûteux sur les postes… et un routeur « oublié » qui décide silencieusement de la destination de vos mises à jour.

EdgeStepper, LittleDaemon, DaemonicLogistics : une chaîne pensée pour durer

Réponse directe : PlushDaemon empile des composants spécialisés pour rester discret et fiable. Ce n’est pas un malware monolithique : c’est une chaîne, avec des rôles bien séparés.

EdgeStepper : l’implant réseau qui tord le DNS

EdgeStepper configure des règles iptables pour rediriger l’UDP/53 vers un port local (ex. 1090), devenant ainsi un proxy DNS. Il récupère sa configuration dans un fichier local chiffré (ex. /etc/bioset.conf) et s’appuie sur un chiffrement AES-CBC.

Ce qu’il faut retenir côté défense :

• l’attaque modifie le comportement réseau, pas seulement l’endpoint ;
• les indicateurs peuvent être systémiques (plusieurs postes affectés sur un même segment).

LittleDaemon : le premier étage sur Windows

LittleDaemon est livré via la mise à jour détournée. Son rôle est simple : vérifier si l’implant final est déjà présent, sinon télécharger et exécuter un downloader en mémoire (DaemonicLogistics). Il ne cherche pas forcément la persistance : il cherche la fiabilité et la discrétion.

DaemonicLogistics : des commandes « cachées » dans les codes HTTP

DaemonicLogistics télécharge ensuite l’implant SlowStepper. Détail intéressant : il interprète des codes de statut HTTP (200, 207, etc.) comme des commandes.

Ce type de design complique la détection basée sur des signatures statiques : un flux HTTP « normal » peut transporter un protocole de commande implicite.

Une phrase utile à garder en tête : quand le protocole de commande se cache dans la normalité (HTTP/DNS), la détection doit se baser sur les comportements, pas sur les chaînes.

Là où l’IA fait une vraie différence (et où les règles seules peinent)

Réponse directe : l’IA est efficace quand il faut corréler des micro-anomalies distribuées dans le temps et l’infrastructure. Les règles de sécurité classiques (IOC, signatures, listes de domaines) ont deux faiblesses face à ce genre de campagne : elles arrivent souvent après la compromission, et elles cassent dès que l’attaquant change un domaine ou un chemin.

1) Détection d’anomalies DNS à l’échelle d’un réseau

L’IA (ou plus largement le machine learning appliqué au réseau) peut apprendre un profil normal de résolution DNS :

• quels postes résolvent quels domaines,
• à quelle fréquence,
• via quels résolveurs,
• avec quelles latences et taux d’échec.

Dans un scénario type EdgeStepper, on observe souvent :

• une centralisation anormale (beaucoup de postes reçoivent des réponses cohérentes mais « atypiques »),
• des résolutions de domaines d’update qui aboutissent à des IP/AS inattendus,
• une récurrence d’artefacts (TTL inhabituels, réponses identiques sur des segments différents).

Une bonne approche IA ici n’est pas de « classifier le malware », mais de détecter le détournement : le DNS dit une chose, l’infrastructure attendue en dit une autre.

2) Corrélation update → téléchargement → exécution

Sur les endpoints, l’IA aide à relier des événements qui, pris séparément, semblent légitimes :

• un processus d’update lance un téléchargement,
• le téléchargement vient d’un domaine connu,
• le fichier ressemble à une DLL attendue,
• puis une exécution en mémoire se produit.

La valeur vient de la corrélation temporelle : update + redirection réseau + payload déguisé = signal fort.

3) Détection de « masquage » par types de fichiers

La chaîne observée montre des techniques de masquage (ZIP/GIF, chemins trompeurs, sous-répertoires qui imitent des éditeurs). Les modèles orientés comportement peuvent repérer :

• des écritures dans des emplacements inhabituels (ex. sous ProgramData avec des noms qui ne collent pas au logiciel),
• des fichiers dont la structure interne ne correspond pas à leur extension annoncée,
• des séquences répétées XOR/déchiffrement suivies d’exécution.

4) Threat intelligence “augmentée” : regrouper les signaux faibles

Dans un SOC, le problème n’est pas d’avoir un IoC. Le problème est d’expliquer rapidement :

• « Est-ce un incident isolé ou une campagne ? »
• « Quels actifs partagent le même chemin d’attaque ? »
• « Quel est le next best action pour contenir ? »

L’IA appliquée à la threat intelligence (clustering d’événements, rapprochement d’infrastructures, similarité de TTP) accélère cette réponse, surtout quand l’attaquant réutilise des patterns (ex. redirection DNS + hijack d’update + loaders en chaîne).

Mesures concrètes à mettre en place (sans attendre le “grand projet”)

Réponse directe : sécuriser le DNS et l’edge donne un meilleur ROI que d’ajouter une couche de plus sur les postes. J’ai vu des organisations investir dans l’endpoint tout en laissant le réseau « implicite ». PlushDaemon montre pourquoi c’est un mauvais pari.

Priorité 1 : durcir et surveiller les équipements réseau

• Inventorier routeurs, firewalls, passerelles opérateur, boîtiers VPN, Wi‑Fi.
• Supprimer les identifiants par défaut, imposer des mots de passe uniques.
• Mettre à jour les firmwares, fermer l’administration distante non nécessaire.
• Journaliser les changements : règles NAT, iptables, DNS proxy, redirections.

Priorité 2 : rendre le DNS observable et contrôlé

• Forcer l’usage de résolveurs internes (bloquer DNS direct vers Internet).
• Déployer des alertes sur : pics de NXDOMAIN, changements d’IP pour domaines critiques, variations de TTL.
• Classer les domaines d’update « critiques » (OS, VPN, agents, navigateurs) et surveiller leurs résolutions.

Priorité 3 : sécuriser la chaîne de mise à jour

• Exiger des mises à jour avec validation cryptographique (signature, intégrité).
• Réduire les applications qui mettent à jour via HTTP non durci.
• Mettre en place une politique de proxy/inspection cohérente pour les flux d’update (sans tout casser).

Priorité 4 : utiliser l’IA là où elle est la plus rentable

• Détection d’anomalies DNS et egress (modèles de comportement).
• Corrélation automatisée réseau + endpoint + identité.
• Priorisation intelligente des alertes (réduire le bruit, augmenter le signal).

Si votre IA « détecte tout », elle ne sert à rien. Une IA utile en cybersécurité est celle qui réduit le temps entre anomalie et action de confinement.

Ce que PlushDaemon nous apprend sur l’IA en cybersécurité

Le point marquant, c’est la simplicité apparente : détourner le DNS et laisser le logiciel faire le reste. La sophistication est dans l’orchestration et la discrétion. Face à ça, une défense uniquement basée sur des listes (domaines, hash, signatures) finit toujours par courir derrière.

Une stratégie solide en 2025 combine :

• une hygiène de base (edge, DNS, mises à jour),
• et une couche d’IA focalisée sur la détection comportementale et la corrélation multi-sources.

Si vous deviez tester une seule chose dès cette semaine : comparez la résolution DNS réelle de vos domaines d’update critiques avec l’infrastructure attendue, segment par segment. La surprise est rarement agréable.

La question à se poser maintenant : votre organisation sait-elle détecter une mise à jour détournée avant que le poste installe la “bonne” DLL au “mauvais” endroit ?