IA et APT : détecter MuddyWater avant l’exfiltration

En 2025, le vrai problème n’est plus « est-ce qu’on va être ciblé ? », mais combien de temps un attaquant peut rester discret avant qu’on s’en rende compte. Le cas MuddyWater illustre parfaitement ce basculement : une opération d’espionnage qui a commencé le 30/09/2024 et s’est étirée jusqu’au 18/03/2025, avec une évolution nette des techniques d’évasion et de persistance.

Ce qui m’intéresse ici, ce n’est pas seulement la sophistication technique. C’est le signal stratégique : les groupes APT industrialisent des tactiques “anti-analyse” (chargement en mémoire, délais d’exécution, tunnels inverses) et s’appuient sur des outils légitimes (RMM) pour brouiller la frontière entre administration et compromission. Face à ça, une approche centrée uniquement sur les signatures et les listes d’IoC se fait rattraper.

Dans cette publication de notre série « Intelligence artificielle dans la cybersécurité », on va prendre MuddyWater comme cas d’école : ce que l’attaque raconte, ce que les équipes sécurité ratent souvent, et surtout comment l’IA peut aider à détecter plus tôt—avant le vol d’identifiants et l’exfiltration.

Ce que la campagne MuddyWater change (vraiment)

Réponse directe : MuddyWater est passé d’un “bruyant mais efficace” à un modèle plus discipliné, pensé pour durer. Historiquement, ses opérations étaient souvent repérables (scripts PowerShell, activité interactive “hands-on-keyboard”, etc.). Dans la campagne observée fin 2024–début 2025, on voit au contraire une intention claire : réduire l’empreinte, améliorer la furtivité et sécuriser la chaîne d’accès.

Les points marquants :

• Ciblage : principalement des organisations en Israël (et un cas confirmé en Égypte), dans des verticaux variés (collectivités, universités, industrie, transports, utilities). Ce n’est pas du “spray and pray”.
• Tooling inédit : apparition d’un chargeur (loader) personnalisé, Fooder, et d’une nouvelle porte dérobée MuddyViper.
• Moins de sessions interactives : les opérateurs évitent volontairement les interventions manuelles longues, typiquement plus détectables (commandes mal tapées, outils d’administration lancés à répétition, etc.).

Ce raffinement a une conséquence opérationnelle : les signaux faibles deviennent la matière première de la détection. Et c’est précisément là où les modèles IA (détection d’anomalies, corrélation comportementale, scoring de risque) apportent une vraie valeur.

Une coopération qui ressemble à un “marché” de l’accès initial

Un autre point qui mérite d’être dit clairement : MuddyWater montre des signes d’intermédiaire d’accès (initial access broker) via un chevauchement opérationnel avec Lyceum (sous-groupe OilRig) début 2025. Concrètement : spearphishing, installation d’outils RMM, récupération d’identifiants, puis prise en main potentielle par une autre entité.

Pour une entreprise, ça change la donne : même si vous “gérez” un incident, vous pouvez en réalité être dans une chaîne, où l’accès est revendu, partagé ou transféré.

La chaîne d’attaque : là où l’IA peut repérer plus tôt

Réponse directe : l’IA devient utile quand elle modélise des comportements et non des artefacts. MuddyWater combine des outils légitimes, des composants sur mesure et des tactiques d’évasion. Le bon angle, c’est d’observer la séquence : comment ça commence, comment ça persiste, comment ça vole, comment ça sort.

1) Accès initial : spearphishing + outils RMM (le faux “support informatique”)

MuddyWater utilise des emails ciblés avec des liens menant à des installateurs d’outils de supervision/assistance (RMM). Sur le papier, c’est banal. Dans les logs, ça peut ressembler à une installation IT.

Là où l’IA aide vraiment :

• Détection d’anomalies d’installation : installation RMM sur des postes qui n’en ont jamais eu, à des horaires atypiques, par un utilisateur non-admin.
• Profilage du “normal” : quelles équipes installent quoi, sur quels segments, avec quels certificats/empreintes, à quelle fréquence.
• Corrélation email → endpoint : lien cliqué + téléchargement + exécution + nouveau service = enchaînement à haut risque.

Phrase “à citer” : Si un outil légitime est la première étape de l’attaque, la détection doit se baser sur le contexte, pas sur le nom du binaire.

2) Exécution furtive : Fooder charge en mémoire, et “Snake” sert d’écran de fumée

Fooder est un loader C/C++ 64 bits qui décrypte un payload et le charge directement en mémoire (techniques de reflective code loading). Certaines variantes se font passer pour un vieux jeu type Snake, et surtout, Fooder intègre une logique de délais d’exécution inspirée des boucles du jeu, combinée à des appels fréquents à Sleep.

Objectif : ralentir l’exécution et rendre l’analyse automatisée (sandbox, émulation) plus coûteuse ou moins concluante.

Là où l’IA aide :

• Détection comportementale de “time-based evasion” : processus inhabituels qui multiplient les pauses, enchaînent des patterns de temporisation, ou s’alignent sur des stratégies anti-sandbox.
• Analytique mémoire : repérer des charges utiles qui n’écrivent presque rien sur disque, mais créent des artefacts en RAM (mappage suspect, sections exécutables, threads anormaux).
• Scoring : un “jeu Snake” qui duplique un token et lance un autre processus, ce n’est pas un jeu. Même si le hash change.

3) Contrôle et persistance : MuddyViper et le retour des tâches planifiées

MuddyViper (C/C++) permet collecte système, exécution de commandes, transferts de fichiers, vol de données navigateur et exfiltration d’identifiants Windows. La persistance passe notamment par :

• Tâche planifiée nommée ManageOnDriveUpdater
• Détournement/usage de dossiers Startup via registres

Un détail technique intéressant : l’usage de CNG (Cryptography Next Generation) pour chiffrer les échanges, jugé atypique pour des groupes alignés Iran dans l’observation décrite. Pour un défenseur, ça signifie que l’analyse réseau ne verra souvent que du TLS + des requêtes HTTP GET avec des corps (body) non conventionnels.

Là où l’IA aide :

• Détection d’anomalies de persistance (tâches planifiées) : nom “updater” créé récemment + binaire non standard + exécution au démarrage = pattern à risque.
• Analyse des flux : même chiffré, un C2 laisse des signatures comportementales (cadence, taille, régularité, endpoints, erreurs/retry). Les modèles d’anomalies réseau sont faits pour ça.

4) Vol d’identifiants : le “faux Windows Security” qui marche encore

MuddyViper (commande 805) et LP-Notes affichent une fausse boîte de dialogue Windows Security pour inciter l’utilisateur à saisir son mot de passe. LP-Notes va jusqu’à valider l’identifiant/mot de passe via des API Windows, ce qui rend l’attaque très “propre” côté attaquant.

Là où l’IA aide :

• Détection d’UI frauduleuse via événements endpoint : appels anormaux à des API de collecte d’identifiants, depuis un processus non attendu.
• UEBA (User and Entity Behavior Analytics) : un utilisateur qui “réussit” une authentification locale via un binaire inconnu, puis un accès à des partages/ressources inhabituels.

5) Exfiltration et tunnels inverses : go-socks5 pour sortir sans faire de bruit

Le groupe utilise des variantes de go-socks5 (tunnels inverses) pour relayer la communication et contourner firewall/NAT. C’est une tactique simple, mais très efficace : le poste compromis devient un pivot réseau.

Là où l’IA aide :

• Détection de rôles réseau anormaux : un poste utilisateur qui se comporte soudain comme un proxy.
• Graphes de communication : nouveaux couples client-serveur, nouvelles destinations, protocoles inhabituels sur des ports “normaux”.

Plan d’action : 10 contrôles concrets à mettre en place (avec et sans IA)

Réponse directe : vous pouvez réduire le risque MuddyWater sans “tout refaire”, à condition d’aligner endpoint, identité, et réseau. Voici ce qui marche en pratique.

1. Politique RMM stricte : liste blanche d’outils autorisés, signatures éditeur, et canaux d’installation (MDM/Intune, dépôt interne).
2. Alertes sur création de tâches planifiées avec mots-clés “update/updater/drive/onedrive” + binaire inconnu.
3. Surveillance des modifications des clés Startup dans le registre utilisateur.
4. Détection “process injection / reflective loading” côté EDR (télémetrie mémoire et threads).
5. Détection de temporisations excessives (Sleep/boucles) couplées à actions réseau.
6. Corrélation email → endpoint : clic + téléchargement + exécution = incident potentiel, même si l’outil est “légitime”.
7. Contrôles navigateur : durcir la protection des secrets (gestionnaire, session, cookies), limiter l’accès aux profils sur machines partagées.
8. UEBA sur l’identité : authentifications locales anormales, mouvements latéraux, accès aux coffres/partages hors profil.
9. Egress filtering : postes utilisateurs ne devraient pas initier des connexions sortantes arbitraires vers Internet sur des patterns proxy.
10. Tabletop “APT silencieuse” : simuler une compromission où rien n’est “bloqué”, et mesurer le temps de détection.

Si vous avez déjà des capacités IA dans votre SOC, l’objectif n’est pas d’ajouter une couche “magique”. C’est de prioriser : l’IA doit faire remonter les séquences rares et cohérentes (RMM + persistance + collecte navigateur + tunnel), pas des alertes isolées.

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

Réponse directe : l’IA n’est pas un remplaçant d’EDR ou de SOC—c’est un accélérateur de décision quand l’attaque ressemble à du normal. MuddyWater s’appuie sur trois leviers qui piègent les approches classiques :

• Outils légitimes (RMM) pour réduire le “signal malware”.
• Exécution en mémoire et délais pour compliquer l’analyse.
• Vol d’identifiants et tunnels pour transformer un poste en point d’appui durable.

Là où l’IA devient décisive, c’est quand elle relie les points : un événement “acceptable” isolément (installer un RMM) devient critique quand il est suivi d’une tâche planifiée suspecte, d’un pattern réseau anormal, puis d’une collecte de secrets navigateur.

Pour la suite de notre série Intelligence artificielle dans la cybersécurité, la question à se poser est simple : votre détection est-elle construite pour reconnaître des attaques qui empruntent des chemins “légitimes” ? Si la réponse est “pas sûr”, vous avez déjà votre prochain chantier.

Prochaine étape (utile, pas théorique) : cartographiez vos outils d’administration autorisés, puis demandez à votre SOC de produire une règle (ou un modèle) qui détecte l’enchaînement « installation RMM → persistance → accès aux secrets navigateur → trafic proxy ». C’est exactement le type de scénario où l’IA fait gagner du temps.