Quand deux APT coopèrent : l’IA voit ce que l’humain rate

Le 02/2025, des analystes ont observé quelque chose de rare et très instructif : un acteur “bruyant” qui compromise en masse a servi de rampe de lancement à un acteur “chirurgical” pour viser quelques machines seulement. Dans des environnements déjà sous pression (administrations, défense, opérateurs critiques), ce type de coopération change la donne parce qu’il brouille les repères habituels : on n’a plus “une intrusion”, mais une chaîne multi-acteurs, avec des outils différents, des infrastructures différentes et des objectifs différents.

Ce cas — une collaboration documentée entre Gamaredon et Turla, deux groupes affiliés au FSB — raconte surtout une chose : les défenses centrées sur des signatures, des listes d’IoC statiques et des investigations “à la main” arrivent trop tard quand l’attaque se fragmente en micro-événements. Dans cette série « Intelligence artificielle dans la cybersécurité », c’est précisément le genre de scénario où l’IA devient utile, non pas par effet de mode, mais parce qu’elle sait relier des signaux faibles à grande échelle.

Gamaredon + Turla : la coopération qui complique tout

La leçon principale est simple : quand deux APT se partagent le travail, la surface d’observation explose.

D’après les éléments techniques rendus publics, Gamaredon a utilisé plusieurs outils PowerShell et chaînes de téléchargement (notamment via des services web légitimes) et, dans plusieurs cas en 2025, ces mêmes mécanismes ont servi à (re)lancer ou déployer la porte dérobée Kazuar de Turla. On voit une logique très “opérationnelle” : Gamaredon ouvre des portes à grande vitesse, et Turla ne garde que celles qui mènent aux pièces les plus intéressantes.

Le modèle “bruit + précision”

• Gamaredon : volume, fréquence, compromissions nombreuses, méthodes d’accès initial connues (ex. spearphishing, supports amovibles, raccourcis malveillants).
• Turla : faible nombre de victimes, sélection forte, outillage d’espionnage, persistance et discrétion.

Dans ce cas, le ratio victimes/compromissions est révélateur : Turla apparaît sur très peu de machines comparé à l’ampleur des intrusions Gamaredon, ce qui suggère un tri sévère. Pour un SOC, c’est un cauchemar : l’activité “de masse” peut masquer l’activité “premium”.

Un détail qui compte : relancer plutôt que réinfecter

Un point particulièrement parlant : sur une machine, un outil Gamaredon a servi à redémarrer Kazuar (Turla), possiblement parce que l’implant avait cessé de fonctionner ou n’était pas lancé automatiquement.

Phrase à retenir : l’attaquant qui “revient” n’a pas forcément besoin de repasser par l’accès initial — il a juste besoin d’un mécanisme de récupération.

C’est exactement le type d’événement que les équipes sous pression négligent : “juste un script PowerShell”, “juste un téléchargement”, “juste un process qui démarre”. Sauf que mis bout à bout, ça reconstitue une opération d’espionnage.

Ce que cette campagne dit sur l’évolution des attaques (et pourquoi ça vise aussi le privé)

Le message n’est pas “c’est en Ukraine donc ça ne nous concerne pas”. Le message, c’est : la méthode est transférable.

Techniques observées : la normalisation de l’abus de services légitimes

Une partie de la chaîne de commande et contrôle s’appuie sur des services web grand public (publication de pages, scripts PowerShell téléchargés, infrastructures intermédiaires). Ce schéma a deux avantages côté attaquant :

1. Baisser la friction (pas besoin d’infrastructure lourde au départ).
2. Augmenter l’ambiguïté (trafic HTTPS vers des domaines “normaux”, difficile à bloquer sans casser du métier).

Ce n’est pas nouveau, mais la nouveauté, c’est la combinaison : services légitimes + multi-acteurs + sélection de cibles.

“Deux équipes, une mission” : un scénario réaliste en 2026

J’ai trouvé que ce cas illustre très bien la trajectoire actuelle : les attaquants ne cherchent pas seulement à être furtifs. Ils cherchent à être modulaires.

• Un groupe maximise l’accès initial.
• Un autre maximise la valeur renseignement.
• Et l’infrastructure peut être réutilisée, détournée, ou partagée.

Pour les organisations françaises et européennes, le risque se traduit ainsi : même si votre secteur n’est pas la cible principale, vous pouvez devenir un relais (fournisseur, intégrateur, prestataire IT, sous-traitant défense), et donc être “pré-filtré” par un acteur de masse avant d’être “sélectionné” par un acteur d’élite.

Pourquoi l’IA aide vraiment : relier des signaux faibles multi-acteurs

L’IA est utile ici pour une raison précise : les indicateurs importants sont relationnels, pas isolés.

Un EDR traditionnel voit :

• un powershell encodé,
• un script qui télécharge un autre script,
• des connexions HTTPS,
• un process qui démarre,
• un binaire dans un chemin qui “ressemble” à du logiciel légitime.

Pris séparément, chaque signal est banal. Pris ensemble, dans le bon ordre, sur le bon périmètre, ça devient une histoire cohérente.

Détection comportementale et corrélation : l’avantage décisif

Une approche IA (ou “AI-assisted”, soyons concrets) apporte trois capacités :

1. Détection de séquences : repérer un enchaînement (téléchargement → exécution → side-loading DLL → beaconing) même si chaque étape change légèrement.
2. Regroupement (clustering) d’événements : lier des campagnes proches sans dépendre d’un hash unique.
3. Scoring de risque contextualisé : un PowerShell encodé sur un serveur d’admin n’a pas le même poids que sur un poste bureautique.

L’enjeu n°1 : identifier la “sélection” dans le bruit

Dans une opération du type Gamaredon/Turla, votre SOC va voir beaucoup de bruit (activité Gamaredon) et très peu de signaux Turla. L’IA sert à détecter le moment où l’attaque change de phase : quand on passe d’un outillage opportuniste à un outillage d’espionnage.

Concrètement, cela ressemble à :

• un poste déjà “sale” qui déclenche soudain des comportements de persistance plus sophistiqués,
• l’apparition d’un exécutable lancé via un mécanisme de side-loading,
• des communications vers une infrastructure atypique (ex. sites compromis servant de relais).

Mesures concrètes à mettre en place (et comment l’IA les renforce)

Le bon réflexe est de viser la réduction du temps entre “signal faible” et “décision de réponse”.

1) Faire de PowerShell un terrain observé, pas un angle mort

Réglez votre posture comme si PowerShell était un “protocole d’attaque” (ce qui est souvent vrai).

• Activer une journalisation adaptée (script block logging, transcription, etc.).
• Alerter sur EncodedCommand, sur les téléchargements de scripts et l’exécution en chaîne.
• Mesurer le “PowerShell normal” de vos équipes IT, puis détecter les écarts.

Apport IA : modèles de baselines par équipe/machine, réduction des faux positifs, priorisation.

2) Traquer les chaînes de téléchargement et les “stagers”

Dans ce cas, plusieurs étapes servent de relais (téléchargeur → téléchargeur → payload). Ce pattern est un classique des APT.

• Détecter les successions de processus : powershell → création de fichier → exécution → nouvelle connexion sortante.
• Corréler endpoint + proxy + DNS (ou équivalent) pour reconstruire la chronologie.

Apport IA : reconstruction automatique de chaînes d’attaque, corrélation multi-sources en temps quasi réel.

3) Mettre le focus sur le side-loading DLL

Le side-loading reste une technique très efficace parce qu’elle exploite la confiance implicite dans un exécutable “légitime”.

• Surveiller les exécutions depuis des répertoires utilisateur ou des chemins “trop beaux pour être vrais”.
• Détecter les chargements de DLL inattendus par un binaire qui ne devrait pas en charger à cet endroit.

Apport IA : détection d’anomalies de chargement par graphe de dépendances (process/dll) et réputation comportementale.

4) Penser “chasse” : la question qui déclenche les bonnes recherches

Dans un contexte multi-acteurs, j’utilise une question simple en threat hunting :

“Qu’est-ce qui, dans notre environnement, ressemble à un mécanisme de reprise d’accès (recovery) ?”

Rechercher : tâches planifiées suspectes, scripts persistants, pages web utilisées comme boîtes aux lettres, communications périodiques, processus “vitrines” qui masquent un chargement anormal.

Apport IA : suggestion de pistes de chasse basées sur des patterns observés (et pas seulement sur des IoC).

FAQ rapide : ce que les équipes demandent vraiment

“Est-ce qu’on peut bloquer tout trafic vers des services web légitimes ?”

Non, et c’est souvent une mauvaise idée. La stratégie réaliste est d’observer finement (qui y va, quand, combien, depuis quel poste) et de réagir sur les séquences suspectes.

“Pourquoi l’IoC-based ne suffit pas ?”

Parce que les domaines, hashes et chemins changent vite. Ce qui reste, c’est la logique d’exécution : scripts encodés, téléchargement en cascade, side-loading, exfiltration discrète.

“Quel est le minimum viable si on n’a pas un SOC 24/7 ?”

• Un EDR bien configuré.
• Des règles fortes sur PowerShell.
• Une corrélation simple endpoint + sorties réseau.
• Un playbook d’isolement poste + collecte (mémoire/artefacts) dès qu’un pattern “stager” apparaît.

Ce que cette collaboration doit changer dans votre plan de défense

Ce cas Gamaredon/Turla illustre une réalité : les campagnes modernes ressemblent à des chaînes logistiques. Un acteur fournit l’accès, un autre exploite. Pour les défenseurs, la conséquence est directe : il faut détecter des enchaînements, pas des événements.

L’IA en cybersécurité est surtout là pour ça : mettre en relation ce qui paraît banal, et vous donner une alerte actionnable avant que l’attaquant n’ait le temps de sélectionner, d’installer et d’exfiltrer.

Si votre organisation devait durcir une seule capacité en 2026, je choisirais celle-ci : corréler automatiquement endpoint + identité + réseau pour repérer les bascules de phase (du bruit vers la précision). La question qui reste ouverte : dans votre SI, sauriez-vous distinguer une intrusion “de masse” d’une intrusion “sur mesure” avant qu’il ne soit trop tard ?