Whisper & PrimeCache : détecter les APT avec l’IA

En 2024, des chercheurs ont mis la main sur une campagne d’espionnage visant des responsables gouvernementaux kurdes et irakiens, avec un détail qui devrait faire tiquer n’importe quel RSSI : une porte dérobée qui “parle” via des pièces jointes email sur Microsoft Exchange. Pas de trafic C2 évident, pas de domaine louche qui crie « malware ». Juste des comportements qui ressemblent à… du quotidien.

C’est précisément pour ça que cette affaire BladedFeline est un excellent cas d’école pour notre série « Intelligence artificielle dans la cybersécurité » : quand les attaquants se camouflent dans les outils légitimes (Exchange, IIS, SSH, PowerShell), la détection par signatures et règles statiques finit souvent par arriver trop tard. La bonne réponse, c’est une défense capable d’assembler des signaux faibles, de repérer des anomalies et d’accélérer l’investigation — et c’est là que l’IA appliquée à la détection a une vraie valeur opérationnelle.

Ce que BladedFeline nous apprend sur les APT en 2025

Point clé : les APT modernes jouent la durée, pas le bruit. Le groupe BladedFeline est actif au moins depuis 2017 et semble spécialisé dans le maintien d’accès et l’extension progressive de son empreinte. On ne parle pas d’un ransomware “one shot”. On parle d’une présence qui s’installe, s’adapte, et change d’outils quand il le faut.

Dans ce dossier, on voit une évolution claire : des implants et reverse shells plus “classiques” au départ, puis l’introduction d’outils plus discrets et modulaires. Deux éléments ressortent :

• Whisper, une backdoor qui utilise Exchange Web Services (EWS) et des règles de boîte de réception pour piloter la machine infectée via email.
• PrimeCache, un module IIS natif malveillant, qui se comporte comme une backdoor “passive”, déclenchée par des requêtes HTTP spécifiques.

Ce duo illustre une tendance qui s’est renforcée en 2024–2025 : les canaux C2 se confondent de plus en plus avec le trafic métier (messagerie, cloud, API, proxies, web services), et les attaquants privilégient des mécanismes d’accès qui survivent aux nettoyages partiels.

Pourquoi les défenses traditionnelles décrochent

La réalité ? Beaucoup d’organisations protègent encore très bien les endpoints… mais laissent des angles morts côté identités, messagerie et serveurs web.

• Une signature AV repère un binaire connu ; ici, les composants sont variés, parfois custom, parfois “timestompés” (horodatages falsifiés), et souvent livrés en chaîne.
• Une règle réseau cherche des domaines ou patterns connus ; ici, Whisper passe par Exchange, PrimeCache s’active via cookies et chiffre ses échanges.
• Une supervision classique alerte sur les pics ; ici, tout est fait pour ressembler à une activité normale, mais légèrement “tordue”.

C’est exactement le terrain où l’IA (et plus largement l’analytique comportementale) devient utile : corréler des micro-indicateurs qui, pris isolément, ne déclenchent rien.

Whisper : quand la messagerie devient un canal de commande

Whisper montre un principe simple : si votre SOC ne surveille pas Exchange comme un système critique, vous jouez à l’aveugle.

Le fonctionnement, résumé de façon opérationnelle :

1. L’implant se connecte à un compte webmail compromis via EWS.
2. Il vérifie (ou crée) une règle de boîte mail spécifique, avec un marqueur (ex. chaîne dans l’objet), et déplace des messages vers un dossier donné.
3. Il envoie périodiquement un “alive” toutes les 10 heures (dans l’échantillon décrit).
4. Il récupère des pièces jointes contenant des commandes chiffrées (AES), exécute (PowerShell, écriture/lecture de fichiers…), puis renvoie les résultats… en pièce jointe.

Ce qui rend Whisper pénible à détecter n’est pas la crypto. C’est le contexte : Exchange est légitime, EWS aussi, les emails et pièces jointes aussi.

Les signaux faibles que l’IA peut faire ressortir

Réponse directe : on détecte Whisper en surveillant les comportements “anormaux mais plausibles” autour des comptes et des règles.

Exemples de features (signaux exploitables) que j’ai vus bien fonctionner en détection assistée par IA :

• Création/édition de règles Inbox inhabituelles (nommage générique, déplacement systématique, conditions “bizarres”).
• Connexions EWS depuis des postes ou segments réseau atypiques, ou avec des patterns temporels mécaniques.
• Séquences répétitives : login → recherche emails avec PJ → exfil PJ → envoi de réponse, selon une cadence régulière.
• Corrélation identité + poste : un compte qui s’authentifie “normalement”, mais exécute ensuite des actions qui ne collent pas au profil métier.

Une approche IA utile ici n’est pas “un modèle magique”. C’est souvent :

• Profilage comportemental par utilisateur et service (UEBA),
• détection d’anomalies sur séries temporelles,
• et corrélation multi-sources (Exchange logs + EDR + proxy + IAM).

« Quand le C2 ressemble au métier, on ne cherche plus une signature : on cherche une histoire cohérente… qui sonne faux. »

PrimeCache : une backdoor IIS qui attend le bon cookie

PrimeCache rappelle que les serveurs web sont encore trop souvent traités comme des “briques techniques” au lieu d’actifs critiques. Ici, la backdoor est un module IIS natif (DLL C++), chargé par le worker process IIS, et qui filtre les requêtes entrantes.

Le mécanisme important, côté détection :

• Les commandes arrivent via un en-tête Cookie avec une structure du type F=<command_ID>,<param>;.
• Les actions se font en plusieurs requêtes : d’abord on “cache” des paramètres, puis on déclenche.
• Les échanges sont chiffrés (RSA pour la clé de session, AES-CBC pour le contenu), et les réponses repartent dans le body HTTP.

Ce n’est pas juste technique : c’est une stratégie de furtivité. En dissociant paramètres et exécution, l’attaquant réduit les requêtes “suspectes” complètes et complique les détections par pattern.

Ce que l’IA apporte côté serveur web

Réponse directe : l’IA aide à repérer des requêtes statistiquement rares, et surtout des enchaînements rares.

Sur IIS, quelques pistes concrètes :

• Détection d’entropie anormale dans les cookies (base64, blobs chiffrés) couplée à des URLs “normales”.
• Analyse de séquences (plusieurs hits rapprochés avec cookies structurés, puis exfil). Un modèle séquentiel simple (ou une détection de motifs) suffit souvent.
• Alertes sur chargement de modules IIS non standards, changements de DLL, ou exports suspects (RegisterModule).
• Corrélation avec l’EDR : w3wp.exe qui lance des commandes système, crée des fichiers, ou lit des chemins sensibles.

Et surtout : l’IA accélère le tri. Sur un serveur web exposé, il y a du bruit. Le but est de prioriser ce qui ressemble à une interaction opérateur (rare, structurée, répétable).

Reverse tunnels, webshells, PowerShell : l’arsenal “post-compromission”

Une campagne APT robuste ne repose pas sur un seul implant. BladedFeline combine plusieurs briques : reverse tunnels en .NET (configuration chiffrée/encodée), webshell ASP.NET, listener HTTP, services Windows de persistance, scripts PowerShell…

Le message pour les équipes défense : vous ne “nettoyez” pas un APT en supprimant un binaire. Vous cherchez une chaîne : accès initial → persistance → mouvement latéral → collecte → exfiltration.

Une check-list de détection pragmatique (sans promesse marketing)

Si vous devez prioriser en 2025, je ferais ceci :

1. Messagerie / Exchange

   • Monitoring des règles Inbox (création, modification, patterns).
   • Détection d’automations EWS atypiques.
   • Surveillez les comptes à privilèges et les boîtes “sensibles” (cabinet, juridique, direction, diplomatie, etc.).

2. Serveurs web (IIS)

   • Inventaire des modules chargés, contrôle d’intégrité.
   • Logs HTTP enrichis (cookies, user-agents, tailles de réponses) avec rétention suffisante.
   • Corrélation w3wp.exe ↔ exécutions système.

3. Endpoints & identité

   • Détection de dumps LSASS et comportements de vol d’identifiants.
   • Hunting sur persistance : services Windows, startup folder, LNK, tâches planifiées.

4. Capacité d’investigation

   • Centralisez : IAM + EDR + logs serveurs + messagerie.
   • Automatisez l’enrichissement (qui, quand, d’où, sur quel hôte, avec quel jeton/session).

Où l’IA fait vraiment gagner du temps (et où elle ne sert à rien)

Réponse directe : l’IA est utile quand elle réduit le temps entre “signal faible” et “décision actionnable”. Dans un cas comme BladedFeline, l’intérêt se mesure en heures gagnées sur :

• la corrélation multi-logs (Exchange + IIS + EDR),
• la détection d’anomalies sur des comportements “légitimes”,
• le regroupement automatique d’alertes en incidents cohérents,
• la génération de pistes de hunting (machines associées, comptes proches, périodes).

À l’inverse, l’IA ne vous sauvera pas si :

• vous n’avez pas de télémétrie fiable (logs absents ou non normalisés),
• vous n’avez pas de procédure de réponse (qui coupe quoi, qui valide quoi),
• vous ne traitez pas vos identités comme un périmètre critique.

L’IA n’est pas une “couche” de plus. C’est un accélérateur — à condition que le moteur (les données + le SOC) tourne déjà.

Actions immédiates pour réduire le risque face à ce type d’APT

Si vous ne faites que trois choses la semaine prochaine, faites celles-là :

1. Auditez vos règles de boîtes mail sur les populations sensibles et mettez une alerte sur créations/modifications inhabituelles.
2. Contrôlez l’intégrité de vos serveurs IIS (modules, DLL, changements non planifiés) et forcez la journalisation utile (dont cookies, tailles, statuts).
3. Mettez en place une corrélation comportementale (même simple) : compte ↔ hôte ↔ service ↔ séquence d’actions.

Et si votre organisation dépend fortement de Microsoft 365 / Exchange / IIS : c’est un excellent terrain pour une approche IA + Threat Intelligence + SOC centrée sur les identités et les services, pas uniquement sur le poste.

Vous voulez un plan d’évaluation concret (en 2 semaines) pour mesurer votre capacité à détecter une backdoor type Whisper/PrimeCache : collecte de logs, cas d’usage, règles + modèles, et scénarios de réponse ? Parlons-en.

La question qui reste, fin 2025, est simple : vos contrôles savent-ils repérer une intrusion quand l’attaquant utilise vos outils comme canal de commande ?