ToolShell sur SharePoint : l’IA pour détecter avant l’impact

Le 25/07/2025, des chercheurs ont documenté l’exploitation active de deux vulnérabilités zero-day affectant Microsoft SharePoint on‑premises (CVE‑2025‑53770 et CVE‑2025‑53771), surnommées ToolShell. Les attaques ont touché des organisations dans le monde entier, avec les États‑Unis en tête (13,3 % des attaques observées). Ce chiffre est utile, mais le vrai message est ailleurs : quand une faille devient un “menu à volonté” pour cybercriminels et groupes APT, la vitesse de détection vaut souvent plus que n’importe quelle promesse de sécurité.

La fin d’année 2025 est un moment particulièrement délicat : équipes en effectif réduit, gel de changements, projets “à livrer avant les fêtes”… et en face, des attaquants qui savent très bien que les fenêtres de maintenance sont plus rares. Sur des briques collaboratives comme SharePoint (documents, workflows, portails internes), l’impact d’une compromission est rarement “local” : c’est un tremplin.

Dans cette publication de notre série « Intelligence artificielle dans la cybersécurité », je prends ToolShell comme cas concret pour répondre à une question opérationnelle : comment l’IA aide à détecter, contenir et réduire l’impact d’une exploitation zero-day sur SharePoint, même quand le correctif n’est pas encore partout.

ToolShell : ce que ces attaques disent de la réalité terrain

ToolShell n’est pas “juste” une paire de CVE. C’est un exemple typique d’un phénomène qui s’accélère : dès qu’une surface critique est exploitable à distance, plusieurs familles d’attaquants convergent (cybercriminalité opportuniste + APT) et l’exploitation se standardise.

Pourquoi SharePoint on‑premises est une cible si rentable

SharePoint on‑premises concentre trois choses que les attaquants adorent :

• Données sensibles (contrats, RH, finances, secrets industriels).
• Confiance (plateforme interne, souvent intégrée à l’authentification d’entreprise).
• Connectivité (liaisons avec Office, workflows, connecteurs, parfois exposé via reverse proxy).

Dans la pratique, une compromission SharePoint sert souvent à :

1. Voler des documents à forte valeur.
2. Déposer une porte dérobée (webshell, tâche planifiée, service).
3. Élargir l’accès (mouvement latéral, recherche d’identifiants, escalade de privilèges).

Le danger n’est pas uniquement la faille : c’est l’effet domino.

“Zero-day” : pourquoi les défenses classiques arrivent trop tard

Un zero-day crée un trou dans la raquette des approches purement “signatures et listes noires”. Même avec une bonne hygiène (WAF, EDR, durcissement), vous vous retrouvez avec une question très simple : comment détecter l’exploitation quand vous ne connaissez pas encore tous les indicateurs ?

C’est exactement là que l’IA (bien utilisée) devient pragmatique : elle ne “devine” pas la faille, elle repère des comportements anormaux et des chaînes d’événements improbables en temps normal.

L’IA ne remplace pas les correctifs : elle gagne du temps (et c’est énorme)

Le rôle le plus utile de l’IA dans ce type de crise n’est pas de faire du marketing. C’est de réduire le temps entre intrusion et détection, et d’aider à prioriser quand tout arrive en même temps.

Détection par anomalies : le bon réflexe quand les IOC manquent

Sur SharePoint, les signaux faibles existent :

• pics d’erreurs applicatives, appels inhabituels à certaines pages,
• variations soudaines dans les volumes de requêtes,
• création/modification de fichiers système ou web inattendus,
• comportements atypiques de comptes de service.

Les modèles d’IA (ou de machine learning) utilisés en SOC peuvent apprendre un “profil normal” et déclencher des alertes quand :

• un serveur SharePoint commence à se comporter comme un serveur d’upload,
• des endpoints “peu visités” deviennent soudainement très sollicités,
• une séquence de requêtes ressemble à un exploit chain (même sans signature).

Ce qui compte : le contexte. Une alerte isolée fatigue tout le monde. Une corrélation d’indices, c’est une piste exploitable.

Corrélation multi‑sources : la force de l’IA en environnement Microsoft

L’intérêt de l’IA en entreprise, c’est sa capacité à relier des signaux dispersés :

• logs IIS / SharePoint,
• événements Windows (création de processus, services, tâches),
• authentifications AD,
• télémétrie EDR,
• flux réseau (DNS, proxy, sorties Internet).

Un scénario typique “à attraper” ressemble à ceci :

1. Requêtes web anormales vers SharePoint.
2. Écriture d’un fichier inattendu dans un répertoire web.
3. Exécution de cmd.exe/powershell.exe par un processus serveur.
4. Connexion sortante vers une destination rare.

L’IA excelle à faire ressortir cette chaîne et à la transformer en incident prioritaire, plutôt que de laisser chaque signal mourir dans un tableau de bord.

Automatisation raisonnée : SOAR + IA pour contenir vite

Quand ToolShell (ou équivalent) se propage, l’enjeu est de contenir sans casser la prod. Une approche utile consiste à définir des paliers de réponse :

• Palier 1 (soupçon) : enrichissement automatique (réputation IP, fréquence, historique) + création de ticket.
• Palier 2 (probable) : isolement réseau du serveur (ou restriction egress) + collecte forensique.
• Palier 3 (confirmé) : rotation d’identifiants, blocage de comptes, recherche de persistance, éradication.

L’IA aide à décider plus vite quel palier appliquer, en s’appuyant sur score de risque, similarité avec incidents passés, et corrélation d’événements.

Plan d’action concret : sécuriser SharePoint face à ToolShell

Voici ce que je recommande aux équipes IT/Sécu qui gèrent du SharePoint on‑premises, surtout en période de fin d’année où les équipes sont sous tension.

1) Réduire l’exposition : moins d’attaque, moins d’urgence

Objectif : rendre l’exploitation plus difficile et limiter le “blast radius”.

• Revoir l’exposition Internet : publication minimale, filtrage IP si possible, durcissement du reverse proxy.
• Segmenter : SharePoint ne devrait pas parler librement à tout le SI.
• Limiter la sortie Internet (egress filtering) : un serveur collaboratif n’a pas besoin de communiquer partout.

Phrase à garder en tête : si un serveur SharePoint peut joindre n’importe quelle destination, il peut exfiltrer n’importe quel document.

2) Instrumenter les bons logs (sinon l’IA n’a rien à manger)

L’IA ne compense pas l’absence de données. Priorité aux sources utiles :

• journaux web (IIS) avec conservation suffisante,
• logs SharePoint et événements Windows,
• télémétrie EDR (processus, scripts, mémoire si possible),
• DNS/Proxy pour repérer les communications sortantes.

Si votre SOC “voit” seulement du réseau, il manquera la moitié de l’histoire. Si votre SOC “voit” seulement l’EDR, il manquera l’amorce web.

3) Déployer des détections comportementales dédiées SharePoint

Sans entrer dans des recettes exploitables, l’idée est de surveiller :

• exécution de shells ou d’outils d’administration par des processus serveur,
• écritures anormales dans des répertoires web,
• création de tâches/services depuis un serveur applicatif,
• accès atypiques à des ressources sensibles (bibliothèques, sites peu consultés).

Les systèmes de détection basés IA peuvent ensuite :

• regrouper ces signaux,
• identifier les serveurs “hors norme” par rapport à la flotte,
• réduire le bruit en comparant à l’historique.

4) Chasse proactive : chercher l’exploitation avant l’alerte

Une bonne stratégie fin 2025 consiste à planifier une session de threat hunting après toute annonce de zero-day majeur sur une brique Microsoft.

Concrètement, on cherche :

• des serveurs SharePoint qui ont vu une augmentation brutale d’erreurs ou de requêtes,
• des modifications inattendues de fichiers applicatifs,
• des comptes de service utilisés à des horaires ou depuis des hôtes inhabituels.

L’IA peut prioriser les “top 5 serveurs les plus atypiques” sur 30 jours. C’est extrêmement efficace quand on manque de temps.

5) Remédiation : patch + validation + retour d’expérience

Une fois les correctifs disponibles, l’ordre “propre” est :

1. Patch (en respectant les prérequis et tests).
2. Vérifier la compromission (avant et après) : patcher un serveur compromis ne le “nettoie” pas.
3. Réduire la dette : durcissement, segmentation, MFA là où applicable, rotation de secrets.
4. Capitaliser : transformer l’incident en règles de détection et playbooks.

Là encore, l’IA sert à une chose : valider qu’après remédiation, le comportement redevient normal (pas de connexions sortantes rares, pas de scripts, pas de nouveaux services).

FAQ opérationnelle (format SOC/DSI)

L’IA aurait-elle pu empêcher ToolShell ?

Elle n’empêche pas une vulnérabilité zero-day à elle seule. En revanche, elle peut réduire drastiquement le temps de détection et accélérer le confinement, ce qui change le résultat final (exfiltration vs incident contenu).

Faut-il abandonner SharePoint on‑premises ?

Pas forcément. Mais il faut être lucide : l’on‑premises demande une discipline d’exploitation (patching, segmentation, logs, supervision) que beaucoup d’organisations sous-estiment. Si vous ne pouvez pas tenir ce niveau, une stratégie de modernisation (ou d’hébergement mieux maîtrisé) mérite d’être étudiée.

Quel est le minimum à faire dès maintenant ?

Trois actions rapides, réalistes :

1. Vérifier l’exposition et réduire l’egress.
2. S’assurer que les logs critiques sont collectés et conservés.
3. Mettre en place des détections comportementales sur exécution de shells, écritures web, tâches/services.

Ce que ToolShell nous apprend sur l’IA en cybersécurité

ToolShell est un rappel assez brutal : les plateformes collaboratives sont des cibles de premier ordre, et les attaquants n’attendent pas que nos comités de changement se réunissent. L’IA, dans ce contexte, n’est ni magique ni optionnelle. C’est une façon concrète d’absorber le volume, de corréler vite, et de contenir avant que l’incident ne devienne une crise.

Si vous ne deviez retenir qu’une idée pour cette fin 2025 : le patching réduit le risque, l’IA réduit l’impact. Les deux sont nécessaires, et l’un sans l’autre laisse des angles morts.

Si votre organisation gère encore du SharePoint on‑premises exposé (même partiellement), quelle part de votre défense repose sur des règles statiques… et quelle part repose sur une détection comportementale capable d’absorber le prochain zero-day ?