EdgeStepper : l’attaque réseau que l’IA peut débusquer

Un détail suffit parfois à faire tomber tout un château de cartes : un simple détournement DNS peut transformer un “banal” téléchargement de mise à jour en installation de malware. C’est précisément le scénario documenté autour de PlushDaemon, un acteur d’espionnage actif depuis au moins 2018, qui a industrialisé une technique redoutable : compromettre des équipements réseau (routeurs, passerelles) pour se placer entre l’utilisateur et l’infrastructure légitime.

Ce qui me frappe dans ce cas, c’est la discrétion de l’attaque. La machine cible fait “tout bien” : elle cherche une mise à jour logicielle normale. Et pourtant, le réseau lui ment, en silence. Pour les équipes cybersécurité, c’est un rappel un peu brutal : si votre surveillance se limite aux postes et aux serveurs, vous ratez parfois l’essentiel.

Dans cette édition de notre série « Intelligence artificielle dans la cybersécurité », on va décortiquer la mécanique EdgeStepper/SlowStepper et, surtout, expliquer comment une détection pilotée par l’IA (NDR, UEBA, corrélation TI, détection d’anomalies) permet d’identifier ces attaques réseau avant qu’elles ne deviennent une compromission à grande échelle.

PlushDaemon : un espionnage qui commence… dans votre routeur

Point clé : PlushDaemon montre que l’attaque la plus rentable n’est pas toujours sur l’endpoint. Elle se joue souvent sur l’infrastructure intermédiaire.

PlushDaemon est décrit comme un groupe aligné Chine, opérant des campagnes d’espionnage sur plusieurs zones (Asie et au-delà). Son approche est cohérente avec une logique d’APT : accès initial opportuniste, maintien discret, charge utile modulaire, et surtout exploitation de la confiance (mises à jour, domaines légitimes, chemins attendus).

Leur recette observée :

• Compromission d’un équipement réseau (routeur/passerelle) via vulnérabilité, identifiants faibles ou défaut.
• Déploiement d’un implant réseau (EdgeStepper) qui détourne la résolution DNS.
• Redirection vers une infrastructure de détournement (hijacking node) servant de fausses mises à jour.
• Chaîne de charge utile côté Windows : LittleDaemon → DaemonicLogistics → backdoor SlowStepper.

Ce schéma a un avantage décisif pour l’attaquant : il fonctionne même si la cible est prudente. Mettre à jour un logiciel est un comportement normal. Ici, c’est l’itinéraire réseau qui est piégé.

Pourquoi ces attaques sont si difficiles à voir

Réponse directe : parce qu’elles exploitent des signaux “normaux” (DNS, HTTP, domaines connus) et se cachent dans la couche réseau.

Dans l’attaque observée, les requêtes DNS sont redirigées vers un nœud malveillant qui répond différemment uniquement quand le domaine semble lié à une mise à jour logicielle. Résultat : l’utilisateur ne voit rien, l’application non plus. Et si l’environnement ne force pas des contrôles forts (DNS sécurisé, signatures, TLS strict), le piège se referme.

EdgeStepper : l’implant qui détourne tout le DNS (en UDP/53)

Point clé : EdgeStepper transforme un routeur compromis en proxy DNS contrôlé par l’attaquant.

EdgeStepper (nom interne observé : dns_cheat_v2) est un binaire ELF compilé pour processeurs MIPS32, typique de nombreux équipements réseau. Il met en place un mécanisme simple, mais très efficace :

1. Redirection locale du trafic DNS : tout l’UDP sur le port 53 est redirigé vers un port interne (ex. 1090).
2. EdgeStepper agit comme proxy : il reçoit la requête DNS du client, la transmet à un DNS malveillant, puis renvoie la réponse.
3. Le DNS malveillant décide : répondre normalement, ou renvoyer l’IP du nœud de détournement si la requête concerne des domaines de mise à jour.

Techniquement, l’implant s’appuie sur des règles iptables côté routeur pour imposer cette redirection. On est face à un détournement “propre” du point de vue réseau : rien n’empêche la résolution, elle est simplement manipulée.

Ce que l’attaque change concrètement sur votre réseau

Réponse directe : les clients continuent d’émettre des requêtes DNS, mais les réponses sont forgées pour certains domaines.

Les impacts typiques :

• Résolution d’un domaine légitime vers une adresse IP non attendue.
• Mise à jour applicative qui passe en HTTP (ou TLS non vérifié) vers l’infrastructure de l’attaquant.
• Téléchargement d’une DLL/EXE “qui ressemble à” une ressource normale, mais sert de charge utile.

C’est là que l’IA devient utile : l’humain ne peut pas “regarder” toutes les résolutions DNS d’un SI. Un modèle d’anomalie, lui, peut repérer un écart statistique et le remonter en incident.

LittleDaemon et DaemonicLogistics : une chaîne de livraison pensée pour durer

Point clé : la charge utile est livrée par étapes, avec des contrôles simples pour éviter certains environnements.

Une fois la mise à jour détournée, la première brique côté poste est LittleDaemon (observée en DLL et en exécutable 32 bits). Son rôle est limité : vérifier si la backdoor finale (SlowStepper) tourne déjà, sinon récupérer un downloader.

Le downloader en question, DaemonicLogistics, est exécuté en mémoire (position-independent code). Sa logique de commande est atypique mais efficace : le serveur répond avec un code HTTP (200, 207, etc.) que le malware interprète comme un ordre.

Deux détails opérationnels comptent vraiment pour les défenseurs :

• DaemonicLogistics collecte un identifiant dérivé de l’OS et une valeur de type identifiant machine (MAC ou valeur générée).
• Il vérifie la présence d’un processus lié à une solution de sécurité (ex. 360tray.exe) avant certains téléchargements.

Autrement dit : l’adversaire adapte son comportement. C’est exactement le genre de dynamique où la détection basée sur signatures s’essouffle vite.

“Fichiers GIF/ZIP” : le camouflage qui piège les contrôles naïfs

Réponse directe : des payloads sont stockés sous des extensions et en-têtes trompeurs, puis déchiffrés localement.

Les éléments téléchargés peuvent masquer leur type (par exemple se présenter comme un GIF ou un ZIP via des octets magiques) tout en contenant des composants chiffrés/obfusqués. Ce n’est pas nouveau, mais c’est redoutable contre des contrôles qui se limitent à l’extension ou à des règles trop simples.

Côté défense, ça pousse à investir dans :

• l’analyse de contenu (MIME, magic bytes, sandbox),
• la corrélation réseau-endpoint,
• et des modèles qui détectent des séquences d’événements anormales (mise à jour → DLL téléchargée → exécution → connexions sortantes).

Où l’IA fait la différence : détection réseau, corrélation, réponse

Point clé : l’IA n’est pas “magique”, mais elle excelle sur trois tâches que l’humain fait mal à l’échelle : repérer les anomalies, relier des signaux faibles, prioriser.

Dans une attaque adversary-in-the-middle (AitM) via DNS, le défi est la volumétrie : des milliers/millions d’événements DNS et HTTP par jour. Une approche IA bien intégrée (NDR + SIEM + EDR) permet de sortir du bruit.

1) Détection d’anomalies DNS (NDR/UEBA)

Réponse directe : un modèle peut signaler quand un domaine “stable” change soudainement de résolution ou de géographie réseau.

Signaux très concrets à apprendre et surveiller :

• Changement d’IP pour un domaine de mise à jour habituellement constant.
• Apparition de réponses DNS pointant vers des hébergeurs/ASN inhabituels pour l’organisation.
• Pics de requêtes vers des sous-domaines rares, corrélés à des mises à jour.
• Écarts de TTL, patterns de réponses, ou serveurs DNS “intermédiaires” inattendus.

L’IA est utile car elle peut construire une baseline (comportement normal) et alerter sur des écarts même quand aucun IoC connu n’est présent.

2) Corrélation threat intelligence + signaux internes

Réponse directe : l’IA aide à regrouper ce qui, autrement, resterait une suite d’événements isolés.

Exemple de chaîne corrélable :

1. Nouvel équipement réseau qui commence à manipuler le DNS.
2. Plusieurs postes résolvent un domaine de mise à jour vers une IP “nouvelle”.
3. Téléchargements HTTP de DLL/EXE depuis des chemins qui ressemblent à une mise à jour.
4. Exécution d’un binaire en mémoire + création de fichiers dans des emplacements peu cohérents.

Pris séparément, chaque élément peut sembler “acceptable”. Pris ensemble, ça ressemble à un scénario d’infection.

3) Réponse guidée (SOAR) : isoler vite, sans sur-réagir

Réponse directe : on gagne du temps en automatisant les actions sûres, et en gardant l’humain sur les décisions à risque.

Playbooks utiles dans ce type de cas :

• Basculer les clients vers un DNS de confiance (interne, DoT/DoH contrôlé, ou résolveur sécurisé) quand un détournement est suspecté.
• Quarantaine réseau de l’équipement edge soupçonné (VLAN d’isolement, coupure WAN, ACL temporaires).
• Recherche automatisée des endpoints ayant contacté les IP/domaines suspects (EDR).
• Vérification de l’intégrité des mécanismes de mise à jour (certificats, signatures, hash, politiques proxy).

Le bon objectif n’est pas “tout bloquer”. C’est casser la chaîne au plus tôt.

Mesures concrètes pour réduire le risque (sans tout refaire)

Point clé : la majorité des organisations peuvent réduire drastiquement l’exposition avec 6 chantiers réalistes.

1. Durcissement des équipements réseau

   • Changer les identifiants par défaut, MFA si possible, désactiver l’administration depuis Internet.
   • Mettre à jour firmwares et vérifier la surface (services inutiles, ports exposés).

2. Contrôles DNS

   • Forcer la résolution via des résolveurs maîtrisés, bloquer le DNS sortant direct.
   • Mettre en place des politiques de filtrage DNS et alertes sur domaines de mise à jour.

3. Visibilité NDR

   • Capturer et analyser les flux DNS/HTTP à un niveau agrégé.
   • Déployer une détection d’anomalies (IA) sur les patterns réseau.

4. Hygiène des mises à jour

   • Privilégier des mises à jour signées et vérifiées.
   • Éviter les canaux HTTP non authentifiés quand c’est encore possible.

5. Segmentation

   • Séparer postes, serveurs, OT/IoT, et équipements réseau d’administration.

6. Exercices et tests

   • Simuler un détournement DNS en environnement de test.
   • Vérifier que l’équipe sait isoler un routeur compromis en moins de 30 minutes.

Phrase à retenir : si votre DNS ment, votre SI exécute. La question est de savoir combien de temps vous mettez à le voir.

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

PlushDaemon n’invente pas le DNS. Il l’exploite. Et c’est précisément pour ça que le sujet est si actuel en décembre 2025 : les environnements hybrides, le travail nomade, et la multiplication des équipements edge rendent le réseau plus “poreux” qu’on ne l’admet.

L’IA apporte un avantage concret : détecter l’attaque là où elle est la plus discrète, au niveau des comportements réseau et des corrélations multi-sources. Mon avis est assez tranché : une organisation qui n’investit pas dans une visibilité NDR pilotée par l’IA laisse un angle mort que des groupes d’espionnage savent très bien exploiter.

Si vous deviez choisir une prochaine étape simple : cartographiez vos chemins DNS, mesurez votre baseline, puis demandez-vous si vous sauriez repérer, en une heure, qu’une mise à jour légitime vient d’être servie par un serveur qui ne devrait pas exister. Vous seriez surpris du résultat.