ToolShell sur SharePoint : l’IA pour détecter l’invisible

Le 25/07/2025, des chercheurs ont documenté l’exploitation active de deux failles zero-day visant Microsoft SharePoint on‑premises : CVE-2025-53770 et CVE-2025-53771, regroupées sous le nom ToolShell. Les attaques ont touché des organisations partout dans le monde, et les États‑Unis ont concentré 13,3 % des tentatives observées.

Ce chiffre ne raconte qu’une partie de l’histoire. L’autre partie, c’est la mécanique : une vulnérabilité critique sur une brique très répandue, des groupes cybercriminels et des APT qui s’y engouffrent, et des équipes IT qui découvrent que “patcher vite” ne suffit plus quand l’exploitation s’automatise. C’est précisément là que l’intelligence artificielle en cybersécurité devient utile — pas comme un slogan, mais comme un moyen concret de détecter des signaux faibles en temps réel avant que l’attaque ne prenne de l’ampleur.

Dans cette publication de notre série « Intelligence artificielle dans la cybersécurité », on prend ToolShell comme étude de cas : ce que ces attaques disent de l’état actuel de la menace, pourquoi SharePoint on‑prem est une cible si rentable, et comment l’IA peut réduire le délai entre premiers signes et confinement.

ToolShell : pourquoi SharePoint on‑prem attire autant

Réponse directe : SharePoint on‑prem concentre des données sensibles, des workflows métiers, et des intégrations internes — c’est une “porte” idéale vers l’Active Directory et le SI.

SharePoint n’est pas qu’un site intranet. Dans beaucoup d’organisations, c’est le point de passage des documents RH, des contrats, des demandes d’achats, de la documentation projet, parfois même de dépôts utilisés comme “mini GED” sans gouvernance stricte. Quand un serveur SharePoint on‑prem est compromis, l’attaquant ne gagne pas seulement un serveur : il gagne un accélérateur d’accès.

La valeur opérationnelle d’un serveur compromis

Ce qui rend ToolShell particulièrement préoccupant, ce n’est pas juste le label zero-day. C’est l’économie de l’attaque :

• Cible massivement déployée : SharePoint on‑prem existe encore partout (contraintes réglementaires, héritage, intégrations).
• Contexte privilégié : comptes de service, accès à des partages, tokens, connexions à d’autres applications.
• Discrétion : une exploitation réussie ressemble souvent à une suite de requêtes web “bizarres”, pas à un malware bruyant.

Cybercriminels et APT sur le même buffet

Le fait que ToolShell soit exploité à la fois par des cybercriminels (monétisation rapide) et des groupes APT (intrusion longue, espionnage, prépositionnement) doit changer la façon de prioriser. Quand deux mondes partagent la même faille, la fenêtre de risque se réduit : la menace se propage vite, puis se spécialise.

Ce que ToolShell révèle : le problème n’est plus “avoir un patch”

Réponse directe : sur une exploitation active, le vrai enjeu est le délai de réaction bout‑en‑bout : détection, qualification, confinement, éradication.

Une équipe IT peut appliquer un correctif rapidement et rester quand même vulnérable opérationnellement :

1. Parce que l’exploitation peut avoir eu lieu avant le patch.
2. Parce que l’attaquant peut établir une persistance (comptes, tâches, webshell, secrets récupérés).
3. Parce que les indicateurs sont dispersés (logs web, événements Windows, AD, proxy, EDR).

En période de fêtes (décembre), ce risque augmente : effectifs réduits, changements gelés, cycles d’astreinte. Les attaquants le savent. Ils adorent les week‑ends et les congés.

Le mythe du “on est couvert, on a patché”

Patcher répond à la question “comment empêcher la prochaine exploitation”. Ça ne répond pas à “est‑ce que quelqu’un est déjà entré”. ToolShell, comme beaucoup de failles web exploitées en masse, impose une discipline : patch + chasse + surveillance renforcée.

Une faille critique exploitée activement transforme chaque serveur exposé en incident potentiel, même si la DSI n’a encore rien vu.

Là où l’IA aide vraiment : détecter la chaîne d’attaque, pas un seul signal

Réponse directe : l’IA est efficace quand elle corrèle des signaux faibles (web + identité + endpoints + réseau) pour repérer une séquence anormale, en minutes plutôt qu’en jours.

Les attaques type ToolShell ne se résument pas à “un IOC” qu’on bloque. Elles ressemblent davantage à une chaîne : requêtes inhabituelles vers SharePoint, création de processus inattendus, mouvements latéraux, accès à des fichiers sensibles, connexions à des heures atypiques.

Détection comportementale : l’avantage sur les règles statiques

Les règles (signatures, patterns) restent utiles, mais elles souffrent quand :

• l’exploit évolue,
• le trafic est chiffré et les traces sont partielles,
• les attaquants imitent des actions légitimes.

Une approche IA/ML bien mise en œuvre apporte autre chose : des modèles de comportement. Par exemple :

• Un serveur SharePoint qui lance soudain des commandes système qu’il ne lance jamais.
• Un compte de service qui s’authentifie sur des ressources qu’il n’utilise pas d’habitude.
• Un volume de requêtes avec des paramètres rares, sur un intervalle court.

L’IA ne “devine” pas. Elle mesure des écarts, et surtout elle les met en contexte.

Corrélation multi‑sources : l’IA comme analyste junior infatigable

Dans la vraie vie, les signaux sont éparpillés :

• Logs IIS / journaux SharePoint
• Journaux Windows (création de processus, services)
• EDR (arborescences de processus, injection)
• AD/Azure AD (authentifications, anomalies)
• Proxy/DNS (résolutions étranges, domaines nouveaux)

Une plateforme augmentée par IA peut faire gagner du temps sur deux points :

1. Regroupement d’événements : “ces 27 alertes appartiennent au même incident”.
2. Priorisation : “ce pattern ressemble à une exploitation serveur suivie d’un accès aux secrets”.

Le résultat attendu est concret : moins de fatigue d’alertes, et un temps de décision réduit quand ça compte.

Exemple réaliste (et fréquent) de scénario ToolShell

Voici un scénario typique qui illustre ce que l’IA peut repérer plus tôt qu’une surveillance manuelle :

1. Pic de requêtes atypiques vers des endpoints SharePoint
2. Dans les 5 minutes, création d’un processus inhabituel sous le compte applicatif
3. Puis, connexions SMB/LDAP depuis le serveur SharePoint vers d’autres serveurs
4. Enfin, accès massif à des répertoires documents sensibles

Pris séparément, chaque point peut avoir une explication. Ensemble, c’est un signal fort. L’IA est justement bonne pour évaluer ce “ensemble”.

Mesures prioritaires pour se protéger (et où placer l’IA)

Réponse directe : combinez durcissement SharePoint, visibilité, détection IA et playbooks d’intervention. Les quatre sont nécessaires.

1) Réduire l’exposition et durcir SharePoint

• Inventorier précisément les fermes SharePoint on‑prem (versions, rôles, exposition Internet).
• Appliquer les correctifs sécurité dès disponibilité, avec un processus d’urgence.
• Réduire les privilèges des comptes de service (principe du moindre privilège).
• Segmenter le réseau : un serveur SharePoint ne devrait pas “parler” librement à tout le SI.

2) Améliorer la télémétrie (sans logs, pas de détection)

• Centraliser les logs web et systèmes dans un SIEM.
• S’assurer que les événements critiques (process creation, PowerShell, WMI) sont collectés.
• Conserver les journaux suffisamment longtemps (les APT jouent la durée).

3) Déployer une détection basée sur l’IA, orientée cas d’usage

Si je devais choisir trois capacités IA “rentables” pour un cas ToolShell/SharePoint :

1. Détection d’anomalies sur serveurs exposés (web + OS)
2. UEBA (User and Entity Behavior Analytics) sur comptes à privilèges et comptes de service
3. Corrélation automatique avec scoring de risque et regroupement d’incidents

L’erreur classique est d’acheter “de l’IA” sans cas d’usage ni métriques. À la place, fixez des objectifs :

• MTTD (temps de détection) < 30 minutes sur serveurs critiques
• MTTR (temps de confinement) < 4 heures en heures ouvrées
• Diminution du bruit d’alertes de 30–50 % via regroupement intelligent

4) Préparer l’intervention : playbooks et automatisation raisonnée

Quand l’exploitation est active, chaque minute compte. Un bon playbook (et une automatisation limitée mais fiable) doit permettre :

• l’isolement réseau du serveur SharePoint suspect,
• la rotation des secrets (comptes de service, certificats, tokens),
• la recherche d’artefacts de persistance,
• la revue des authentifications et mouvements latéraux.

L’IA peut déclencher des actions recommandées, mais je reste pragmatique : gardez un humain dans la boucle pour les actions destructrices (coupure globale, suppression de comptes), surtout dans les environnements sensibles.

Questions fréquentes que les équipes se posent (et réponses nettes)

« Si on est sur Microsoft 365, on est concerné ? »

Réponse : ToolShell vise explicitement SharePoint on‑premises. En revanche, les attaques qui commencent on‑prem finissent souvent par toucher des identités et des données hybrides. Donc même en environnement mixte, vous êtes dans le rayon d’impact.

« Est-ce que l’IA remplace un SOC ? »

Réponse : non. Elle réduit le temps perdu et aide à voir des patterns que l’humain rate sous charge. Un SOC sans IA est lent ; une IA sans SOC est aveugle au contexte métier.

« Quel est le meilleur signal de compromis à surveiller ? »

Réponse : il n’y en a pas un. Sur ToolShell et autres exploits web, la meilleure stratégie est la corrélation : requêtes anormales + comportements OS + activités d’identité.

Ce que ToolShell change pour 2026 : l’IA comme première ligne sur les applis d’entreprise

Les attaques ToolShell montrent une réalité simple : les applications “banales” du quotidien (portails, GED, collaboration) sont devenues des cibles de premier choix. Elles ont des données, des droits, et elles sont exposées.

Pour les organisations publiques et privées, la trajectoire la plus saine n’est pas “plus d’outils”. C’est plus de visibilité, plus d’automatisation utile, et une détection IA centrée sur les comportements. L’objectif est clair : repérer l’exploitation pendant qu’elle se déroule, pas lors d’un audit post‑incident.

Si vous deviez agir dès cette semaine, je choisirais ceci : inventorier les serveurs SharePoint on‑prem, vérifier le niveau de patch, renforcer la collecte de logs, et tester un scénario de détection/corrélation sur une simulation d’incident. Ensuite seulement, vous saurez où l’IA vous fait gagner du temps — et où elle doit être encadrée.

La question qui reste, et qui mérite d’être posée en comité de direction : si une exploitation de type ToolShell démarre un samedi à 02h00, votre organisation la voit-elle avant 08h00 ?