IA & cyberespionnage : quand deux APT unissent leurs outils

76% des organisations ont subi au moins un incident de sécurité lié à une identité au cours des 24 derniers mois (Identity Defined Security Alliance, 2024). Ce chiffre revient souvent dans mes échanges avec des RSSI : les attaques « classiques » explosent, mais le vrai danger, ce sont les opérations discrètes qui ne cherchent pas le bruit — elles cherchent la bonne machine.

C’est exactement ce que révèle un fait marquant observé en Ukraine début 2025 : Gamaredon (très actif, très « industriel ») et Turla (beaucoup plus sélectif, orienté renseignement) ont été vus en co-compromission, avec une chaîne où les outils de Gamaredon servent à relancer ou déposer la porte dérobée Kazuar de Turla. Pour une équipe SOC, ce genre de coopération est un cauchemar : les signaux sont morcelés, les responsabilités se superposent, et le scénario ressemble à une simple « infection PowerShell de plus »… jusqu’au moment où l’exfiltration commence.

Dans cette note (série Intelligence artificielle dans la cybersécurité), je prends cette affaire comme un cas d’école : qu’est-ce que la collaboration entre groupes APT change concrètement, et pourquoi l’IA en cybersécurité devient indispensable pour détecter ces attaques coordonnées et state-sponsored.

Ce que change une collaboration APT (et pourquoi ça pique)

Point clé : quand deux groupes se partagent le travail, la défense voit deux demi-histoires au lieu d’un récit complet. Le premier groupe obtient l’accès initial et déploie des scripts/outils. Le second arrive plus tard, sur une poignée de machines, et exécute l’objectif stratégique.

Dans le cas observé en 2025 :

• Gamaredon déploie plusieurs implants/outils (famille “Ptero…”) et compromise un très grand volume de postes.
• Turla n’apparaît que sur un nombre très réduit de machines (7 détectées sur 18 mois dans le périmètre décrit), ce qui suggère un tri : les machines les plus intéressantes d’abord.

La conséquence opérationnelle est simple :

• Les IoC « bruyants » (phishing, scripts, fichiers LNK, USB) peuvent être attribués à Gamaredon.
• Les signaux faibles (side-loading DLL, communications C2 plus rares, charge utile C# sophistiquée) renvoient à Turla.

Si votre détection est trop « silo » (EDR d’un côté, proxy de l’autre, analystes séparés, règles statiques), vous risquez de traiter chaque morceau comme un incident distinct. Or ici, c’est une même campagne, avec une logique de chaîne.

Le mythe à oublier : “un poste = un attaquant”

La réalité des attaques modernes, surtout étatiques, c’est l’assemblage : infrastructures partagées, outils réutilisés, accès revendus ou transmis, et parfois coopération intra-agence. Résultat : l’attribution devient moins utile que la compréhension de la chaîne d’attaque.

Et c’est précisément là que l’IA peut aider : pas pour « deviner » un acteur, mais pour reconstruire les liens entre événements dispersés.

Ce que l’enquête 2025 montre, en clair

Point clé : des outils Gamaredon ont été utilisés pour relancer et déployer Kazuar (Turla). Trois chaînes observées illustrent une relation plus forte qu’un simple hasard.

Chaîne 1 : relance de Kazuar v3 via un downloader Gamaredon

Sur une machine en Ukraine, un outil PowerShell attribué à Gamaredon (PteroGraphin) sert de canal de distribution (pages d’un service web public) et déclenche l’exécution d’un autre downloader (PteroOdd). Ensuite, un binaire légitime est utilisé pour side-loader une DLL et charger Kazuar v3 en mémoire.

Deux éléments sont très parlants :

• L’utilisation de services web légitimes comme support de commande (moins d’infrastructure “à eux”, plus de camouflage).
• Le redémarrage de l’implant : c’est un comportement typique d’un opérateur qui veut récupérer une persistance ou confirmer que sa porte dérobée tourne encore.

Chaînes 2 et 3 : déploiement direct de Kazuar v2 via d’autres outils Gamaredon

Plus tard (avril et juin 2025), d’autres outils de la même galaxie Gamaredon (PteroOdd puis PteroPaste) sont observés en train de télécharger et exécuter des scripts installateurs qui déposent Kazuar v2.

Côté défense, c’est le détail qui fait mal : Kazuar v2 et v3 coexistent, avec une logique d’outillage évolutif. Pour un SOC, cela implique :

• Des signatures qui ratent une variante.
• Des modèles de communication C2 qui changent.
• Des charges utiles en C# (et leurs artefacts) qui ressemblent à de la “télémétrie applicative” si la visibilité n’est pas bonne.

Pourquoi Turla reste “rare” dans les logs

Turla vise peu de machines, mais des machines à haute valeur. Quand vous voyez une infection massive côté Gamaredon, il faut envisager une hypothèse : le gros volume sert de couverture à un ciblage ultra-sélectif.

Une phrase à garder : “Le bruit sert souvent de rideau.”

L’IA en cybersécurité : ce qu’elle apporte vraiment face à ces chaînes

Point clé : l’IA est utile quand la détection doit relier des événements hétérogènes (scripts, side-loading, C2, exfiltration) en un seul scénario. Les règles seules atteignent vite leurs limites.

1) Détection multi-étapes : corréler PowerShell, réseau et mémoire

Dans une coopération APT, l’attaque ressemble à une succession de “petits” événements :

• powershell -EncodedCommand
• téléchargement depuis un service web légitime
• exécution d’un binaire “clean” dans un répertoire plausible
• chargement d’une DLL inattendue (side-loading)
• beacon HTTPS vers un C2 masqué (souvent sur sites compromis)

Une approche IA (ou au minimum ML + corrélation) permet de :

• lier ces signaux sur une même timeline machine/utilisateur,
• détecter des séquences plutôt que des événements isolés,
• attribuer un score de risque cohérent malgré des artefacts “banals”.

Concrètement, un modèle peut apprendre qu’un Start-Process vers un chemin étrange + chargement DLL + nouveau domaine WordPress compromis = beaucoup plus suspect que chaque élément pris séparément.

2) Détection d’infrastructures “camouflées” : WordPress compromis, DNS dynamique, services cloud

Les campagnes décrites utilisent :

• des sites WordPress compromis comme C2,
• du DNS dynamique,
• des services cloud (workers, pages web) pour livrer des commandes.

Là encore, l’IA aide surtout sur deux points :

• regroupement : repérer que plusieurs endpoints “sans lien” parlent à des domaines qui partagent des caractéristiques (patterns d’URL, chemins WordPress, temporalité, certificats, ASN, etc.).
• détection d’anomalies : un poste bureautique qui contacte soudain des chemins wp-includes/.../index.php avec une périodicité régulière mérite une investigation — même si le domaine a l’air “normal”.

3) Chasse aux menaces : découvrir les liens faibles entre acteurs

Le plus intéressant dans ce type de dossier, ce sont les connexions faibles : un token réutilisé, un même endpoint de collecte, une structure identique de script, une manière récurrente d’exfiltrer des infos système.

L’IA (notamment via recherche sémantique sur logs + détection de similarités) permet aux équipes threat hunting de :

• retrouver des scripts quasi identiques (même si obfusqués différemment),
• identifier des chaînes récurrentes par forme plutôt que par signature,
• remonter d’un incident isolé à une campagne.

Check-list défense : quoi faire lundi matin (sans tout reconstruire)

Point clé : vous n’avez pas besoin de “tout faire”, mais vous devez couvrir la chaîne. Voici ce qui donne le plus de rendement quand des APT coopèrent.

Priorité 1 : rendre PowerShell vraiment observable

• Activer une journalisation adaptée (Script Block Logging, Module Logging) et centraliser.
• Détecter -EncodedCommand, IEX, téléchargements via WebClient/Invoke-WebRequest.
• Surveiller les exécutions depuis %APPDATA%, %TEMP% et chemins utilisateurs “bizarres”.

Priorité 2 : traquer le side-loading DLL (c’est un classique APT)

• Détecter les binaires qui chargent des DLL depuis des répertoires inattendus.
• Mettre des règles sur les applications “légitimes” lancées depuis des dossiers non standards.
• Corréler : nouveau process + DLL non signée + connexion réseau sortante.

Priorité 3 : traiter les domaines « plausibles » comme suspects par contexte

• Les C2 sur WordPress compromis ont l’air normaux. C’est le contexte qui ne l’est pas.
• Construire une base de comportements : qui contacte quoi, à quel rythme, avec quel user-agent.

Priorité 4 : intégrer l’IA là où elle fait gagner du temps

Si vous cherchez un point d’entrée pragmatique pour l’IA en cybersécurité :

• scoring de risque sur séquences d’événements endpoint,
• clustering d’alertes (réduction du bruit),
• recherche sémantique dans les logs et tickets SOC,
• détection d’anomalies réseau orientée postes “à haute valeur”.

Le bon objectif n’est pas “100% automatique”. C’est 30 à 50% de triage en moins, et une meilleure capacité à voir les chaînes.

Ce que cette affaire dit de 2026 (et pourquoi l’IA devient non négociable)

Point clé : les menaces state-sponsored fonctionnent de plus en plus en écosystèmes, pas en équipes isolées. Quand un acteur très bruyant ouvre la voie à un acteur très discret, la défense doit être capable de relier les points.

J’ai vu trop d’organisations mesurer leur maturité à la quantité de règles écrites. C’est une impasse. La valeur est dans la capacité à comprendre un scénario complet : accès initial → exécution → persistance → C2 → collecte → exfiltration. L’IA aide précisément à ça : transformer des millions d’événements en une histoire exploitable.

Si vous deviez choisir un prochain pas, choisissez celui-ci : évaluer votre capacité à détecter une attaque “à deux étages” (un premier acteur qui infecte large, un second qui cible fin). Si vous ne pouvez pas la rejouer en simulation et la détecter, vous êtes en retard.

Et vous, dans vos environnements, combien de “petites alertes PowerShell” pourraient en réalité être la première marche d’une opération d’espionnage ?