XSS et espionnage : détecter Sednit avec l’IA

Le 15/05/2025, des chercheurs ont mis en lumière une opération d’espionnage (baptisée RoundPress) visant des comptes e-mail d’organisations gouvernementales ukrainiennes et d’entreprises de défense européennes. Le détail qui pique : l’attaque s’appuie sur des failles XSS dans des webmails (Roundcube, Horde, MDaemon, Zimbra) et, dans certains cas, parvient même à contourner la 2FA.

Most companies get this wrong : elles traitent encore les vulnérabilités web comme un sujet “applicatif” isolé, alors que, dans la vraie vie, une XSS sur un webmail devient un incident de sécurité stratégique. Quand l’e-mail est le centre nerveux (achats, contrats, échanges diplomatiques, pièces jointes sensibles), une XSS n’est pas une “petite” faille front. C’est une porte d’entrée vers des secrets.

Dans cette édition de notre série « Intelligence artificielle dans la cybersécurité », je prends RoundPress comme cas d’école : ce que ce type d’attaque révèle sur les limites des approches classiques, et comment des dispositifs IA/ML (détection comportementale, corrélation, UEBA, NLP sur signaux de messagerie) peuvent repérer l’attaque avant que des boîtes mail ne soient vidées.

Ce que RoundPress nous apprend (et pourquoi la XSS reste rentable)

Une opération comme RoundPress montre une réalité simple : l’attaque la plus efficace est souvent celle qui n’a pas besoin de malware sur le poste. En ciblant le webmail, l’attaquant se place au plus près des données, avec un bruit opérationnel réduit.

Les grandes lignes (sans entrer dans des détails exploitables) sont typiques des campagnes APT :

• Ciblage précis : officiels, équipes projets, fonctions support proches des dossiers sensibles.
• Point d’entrée “web” : une faille XSS dans une interface accessible via navigateur.
• Objectif : accéder au contenu des e-mails et exfiltrer informations, pièces jointes, fils de discussion, carnets d’adresses.
• Persistance “douce” : le compte e-mail devient le pivot (plutôt que le poste), ce qui complique l’investigation.

Pourquoi la XSS fonctionne encore en 2025

Parce qu’elle exploite un mélange explosif : complexité des front-ends, plugins, templates, et usage massif d’HTML dans les interfaces webmail. La XSS n’a pas besoin d’être “bruyante” : un script injecté au bon endroit peut suffire à lire des données affichées, à déclencher des actions côté utilisateur, ou à voler des éléments de session si les garde-fous sont insuffisants.

Et surtout : beaucoup d’organisations patchent vite les systèmes critiques… mais les webmails on-prem ou hybrides traînent, faute de fenêtre de maintenance, de dépendances internes, ou parce que “ça marche”. Les attaquants adorent ce genre de dettes.

Comment une XSS sur un webmail mène au vol d’e-mails (et à la 2FA contournée)

Une XSS, dans un webmail, sert rarement à “défigurer” quoi que ce soit. Elle sert à agir au nom de l’utilisateur dans sa session légitime.

Le schéma opérationnel le plus fréquent ressemble à ceci :

1. L’utilisateur ouvre un message ou une vue du webmail contenant du contenu piégé.
2. Le navigateur exécute du code dans le contexte du webmail.
3. Le code accède à des éléments visibles (contenus, métadonnées) et peut déclencher des requêtes applicatives déjà autorisées.

“Contourner la 2FA” : ce que ça signifie réellement

Quand une campagne annonce un contournement 2FA, on imagine un piratage de l’OTP. En pratique, le plus souvent, l’attaquant ne casse pas la 2FA :

• il s’appuie sur une session déjà authentifiée (l’utilisateur a passé la 2FA plus tôt),
• ou il exploite des flux applicatifs où l’authentification forte ne se réapplique pas à certaines actions,
• ou il profite d’un “pas de côté” (jetons, cookies, endpoints internes, logique d’UI).

La nuance est capitale : cela signifie que renforcer la 2FA est nécessaire… mais pas suffisant. Le cœur du problème devient la détection de comportements anormaux dans la messagerie.

Là où l’IA fait la différence : détecter le “mauvais usage” plutôt que la signature

Pour les organisations publiques et la défense, la question n’est plus “comment bloquer toutes les XSS”. Il faut évidemment réduire la surface (patch, durcissement), mais la protection réelle vient d’une capacité à repérer une exploitation en cours, même si la vulnérabilité est inconnue (zero-day) ou si l’attaque est très ciblée.

L’IA est particulièrement utile ici pour une raison : elle excelle à modéliser le normal, puis à signaler l’écart.

Détection comportementale sur la messagerie (UEBA)

Les signaux exploitables sont nombreux et souvent sous-utilisés :

• Taux de lecture/extraction inhabituel (ex. consultation rapide de nombreux messages, navigation automatisée).
• Accès à des dossiers rarement utilisés (archives, dossiers projets anciens).
• Téléchargements en rafale de pièces jointes.
• Création/modification de règles (forwarding, tri, suppression) peu cohérentes avec l’historique.
• Connexions depuis des environnements atypiques (navigateur/empreinte, localisation, horaires).

Un modèle UEBA (User and Entity Behavior Analytics) peut attribuer un score de risque à une session : plus il y a de déviations corrélées, plus on se rapproche d’un scénario “XSS en action” ou “compte utilisé comme robot”.

Une phrase que j’aime bien utiliser en comité de pilotage : « L’attaque n’est pas invisible, elle est juste noyée dans le quotidien. » L’IA sert à faire remonter ce signal.

IA côté applicatif : repérer l’exploitation au niveau HTTP

Sur des webmails, l’exploitation laisse des traces côté serveur et proxy : patterns de requêtes, séquences, erreurs, variations de paramètres. Des approches ML peuvent aider à :

• identifier des séquences anormales de requêtes (ex. enchaînements non humains),
• repérer des charges inhabituelles (payloads) et encodages,
• corréler des anomalies entre WAF, reverse proxy, logs applicatifs et SIEM.

Ce n’est pas magique : l’IA a besoin d’instrumentation (journaux de qualité, horodatage cohérent, champs utiles) et d’un processus de réponse derrière.

NLP et sécurité e-mail : utile, mais à bon escient

Les modèles de langage (NLP) peuvent aider à :

• repérer des campagnes très ciblées où le contenu ressemble à des échanges internes,
• détecter des fils de conversation falsifiés (style, vocabulaire, incohérences),
• classifier des messages par criticité (dossiers sensibles, entités nommées : contrats, programmes, références).

L’idée n’est pas de “lire” tous les e-mails (sujet délicat, surtout dans le public), mais de travailler sur des métadonnées, des indicateurs de similarité et des signaux de risque compatibles avec la conformité.

Mesures concrètes à mettre en place (sans attendre la prochaine crise)

Pour transformer ces enseignements en plan d’action, je conseille une approche en trois couches : réduction de surface, détection, réponse.

1) Réduire la surface d’attaque XSS sur les webmails

• Patching prioritaire des composants webmail et de leurs dépendances (plugins, moteurs de templates).
• Durcissement navigateur/headers lorsque possible : CSP (Content Security Policy), restrictions de scripts, isolation.
• Revue de configuration : cookies HttpOnly/Secure, politiques de session, durées, invalidation.
• Moins d’exposition : limiter l’accès webmail à des plages IP, VPN, ZTNA, ou au minimum par politiques d’accès conditionnel.

2) Détecter : les 10 alertes qui valent de l’or

Si je devais choisir 10 alertes “must have” (SIEM/SOAR + UEBA) pour un webmail sensible :

1. Création de règles de transfert vers un domaine externe.
2. Création de règles de suppression/archivage automatique sur des dossiers critiques.
3. Téléchargement de pièces jointes en volume sur une fenêtre courte.
4. Consultation d’un grand nombre de messages anciens.
5. Connexion réussie + changement d’agent utilisateur inhabituel.
6. Session longue et active à un horaire atypique pour l’utilisateur.
7. Multiples requêtes répétitives à cadence régulière (signature d’automatisation).
8. Accès simultané au même compte depuis deux environnements éloignés.
9. Spike d’erreurs applicatives corrélé à une session unique.
10. Modification de paramètres de sécurité du compte (si applicable).

3) Répondre vite : playbooks orientés messagerie

Le point faible de beaucoup d’équipes SOC : elles savent isoler un poste, mais hésitent sur les comptes e-mail. Les playbooks doivent être prêts, testés, et validés juridiquement :

• Révocation de session immédiate (tous tokens) et réauthentification.
• Rotation des secrets liés (mots de passe, jetons d’apps, OAuth, accès IMAP/SMTP).
• Audit des règles (forwarding, délégations, boîtes partagées).
• Recherche de messages liés (mêmes objets, mêmes expéditeurs, mêmes fils).
• Notification ciblée des utilisateurs concernés avec consignes simples.

FAQ terrain (celles qu’on me pose vraiment)

“On a déjà un WAF, ça ne suffit pas contre les XSS ?”

Non. Un WAF aide, mais une campagne APT peut contourner des règles génériques, surtout si la vulnérabilité est inconnue ou si l’attaque joue sur le contexte applicatif. Le WAF est une barrière, pas un filet de sécurité complet.

“Pourquoi l’IA plutôt que des règles statiques ?”

Parce que l’attaque est ciblée et évolutive. Les règles statiques attrapent ce qu’on connaît déjà. L’IA est utile pour attraper ce qui ressemble à une rupture de comportement, même si la technique exacte change.

“Qu’est-ce qu’on déploie en premier si on manque de temps ?”

Je priorise : (1) patch + réduction d’exposition, (2) alertes sur règles de messagerie et exfiltration, (3) playbooks de réponse. L’IA/UEBA vient ensuite pour industrialiser et réduire le bruit.

Ce que je retiens pour 2026 : l’e-mail redevient une cible “premium”

L’affaire RoundPress rappelle que les acteurs d’espionnage investissent là où la valeur est maximale : la messagerie. Et quand la porte d’entrée est une XSS sur un webmail, l’attaque peut rester longtemps sous les radars si l’on se limite à la prévention “signature + patch quand on peut”.

Dans notre série « Intelligence artificielle dans la cybersécurité », c’est un exemple net : l’IA n’est pas un gadget. Bien utilisée, elle sert à détecter des séquences anormales, à prioriser les alertes et à déclencher une réponse avant que des documents sensibles ne sortent.

Si vous deviez choisir un chantier dès ce trimestre : équipez-vous pour voir ce qui se passe dans vos webmails (journaux exploitables, corrélation, comportements), puis automatisez une réponse proportionnée. La question qui reste, fin 2025, est simple : quand la prochaine campagne frappera, est-ce que vous la verrez en minutes… ou en semaines ?