ToolShell : sécuriser SharePoint avec l’IA, maintenant

Le 19/07/2025, Microsoft a confirmé l’exploitation « in the wild » d’un duo de failles zero-day visant SharePoint Server on‑premises : ToolShell. Et ce qui frappe, ce n’est pas seulement la gravité technique (exécution de code à distance + usurpation côté serveur), c’est la vitesse à laquelle l’écosystème criminel s’en est emparé. Entre le 17/07/2025 et le 22/07/2025, on a vu passer des tentatives d’exploitation à l’échelle mondiale, avec un pic d’opportunisme dès que « la recette » a circulé.

Cette affaire illustre parfaitement un point central de notre série « Intelligence artificielle dans la cybersécurité » : les correctifs restent indispensables, mais ils ne suffisent plus. Quand un zero-day touche une brique aussi transversale que SharePoint (connectée à Office, Teams, OneDrive, Outlook), la question n’est pas si vous serez ciblé, mais combien de temps vous resterez exposé. Et c’est précisément là que l’IA change la donne : non pas en remplaçant les équipes sécu, mais en réduisant le temps de détection, en corrélant les signaux faibles et en automatisant la réponse.

ToolShell : pourquoi ce zero-day fait si mal

ToolShell est dangereux parce qu’il combine impact élevé et surface d’attaque “par défaut”. Les serveurs SharePoint on‑premises (SharePoint Subscription Edition, 2019, 2016) sont souvent exposés, intégrés à l’authentification d’entreprise, et reliés à des dépôts documentaires sensibles. SharePoint Online (Microsoft 365) n’est pas concerné, mais beaucoup d’organisations gardent des instances on‑premises pour des raisons de souveraineté, d’héritage applicatif ou de contraintes métiers.

Dans les attaques observées, ToolShell n’est pas utilisé seul : les attaquants enchaînent plusieurs CVE (dont deux déjà corrigées auparavant) pour obtenir un chemin fiable vers la compromission. C’est un détail essentiel : les attaques modernes ressemblent rarement à “une faille = un incident”. Ce sont des chaînes.

Chaînes d’exploitation : le vrai défi côté défense

Quand un acteur malveillant « chaîne » des vulnérabilités, il profite d’une réalité terrain :

• les patchs ne sont pas appliqués partout, tout de suite ;
• certaines dépendances cassent en cas de mise à jour ;
• les fenêtres de maintenance sont limitées ;
• l’inventaire applicatif est parfois incomplet.

Résultat : même après publication de correctifs, l’exploitation continue. Et l’attaquant n’a pas besoin d’être un génie : dès que des preuves de concept circulent, l’industrialisation suit.

Un point qui inquiète : contournement MFA/SSO

Le volet le plus « business‑risque » est clair : l’exploitation permet de contourner MFA et SSO dans certains scénarios, ce qui casse un mythe répandu : « On a la MFA, donc on est tranquille. » Non.

La MFA protège l’identité. ToolShell vise l’application et le serveur. Si l’adversaire exécute du code sur SharePoint, il peut agir comme SharePoint — et donc franchir des frontières que vos contrôles d’accès n’avaient pas anticipées.

De la faille au webshell : ce que l’attaquant cherche vraiment

Le but opérationnel, c’est la persistance et l’accès aux données. Après exploitation, plusieurs campagnes ont déployé des webshells (petits scripts côté serveur) permettant d’exécuter des commandes via cmd.exe et d’exfiltrer des informations.

Un exemple très parlant : un webshell fréquemment observé s’appuie sur un fichier spinstall0.aspx, identifié comme malveillant. D’autres noms simples et jetables ont été utilisés (famille de fichiers ghostfile***.aspx). Ce choix n’est pas anodin :

• il se fond dans les conventions de nommage « à la SharePoint » ;
• il facilite l’automatisation (déployer, tester, remplacer) ;
• il rend la détection basée uniquement sur des signatures plus fragile.

APT + opportunistes : la même porte, des objectifs différents

Ce type de vulnérabilité attire deux mondes à la fois :

• les cybercriminels opportunistes, qui cherchent l’accès rapide (vol, rançonnage, revente d’accès) ;
• les groupes APT liés à des États, qui visent l’espionnage, la durée, et les organisations à forte valeur.

Dans le cas ToolShell, des signaux ont montré l’intérêt d’acteurs sophistiqués. Ce mélange est explosif : les mêmes techniques circulent, mais l’intention varie, et donc la réponse doit être capable de traiter à la fois le bruit de masse et les attaques discrètes.

Ce que l’IA apporte face à ToolShell (et aux prochains)

L’IA est utile quand le défenseur doit prendre une décision avant d’avoir toutes les certitudes. Un zero-day impose de travailler en conditions imparfaites : indicateurs incomplets, variantes qui évoluent, règles à écrire dans l’urgence.

Dans ce contexte, l’IA aide surtout sur quatre plans concrets.

1) Détection comportementale : repérer l’anomalie, pas la signature

Un webshell n’est pas « juste un fichier suspect ». C’est un comportement :

• un processus IIS/ASP.NET qui lance des commandes systèmes ;
• des accès fichiers inhabituels dans des répertoires applicatifs ;
• des requêtes anormales vers des pages .aspx récemment déposées ;
• des pics d’erreurs suivis d’une exécution réussie.

Les approches IA (et plus largement data-driven) sont pertinentes ici car elles peuvent apprendre le « normal » de votre SharePoint (volumétrie, endpoints, horaires, patterns) et alerter sur les ruptures. C’est exactement ce qu’il faut quand les noms de fichiers changent toutes les 30 minutes.

Une phrase que je répète souvent en audit : « Les attaquants adorent changer le décor, mais ils changent rarement la pièce. » L’IA aide à reconnaître la pièce.

2) Corrélation multi-signaux : reconstruire la chaîne d’attaque

ToolShell met en évidence un besoin : corréler plusieurs étapes.

Une défense efficace doit relier :

1. un événement d’exploitation sur une application exposée ;
2. une écriture de fichier côté serveur ;
3. une exécution de commande ;
4. un accès à des données sensibles ;
5. des connexions sortantes ou mouvements latéraux.

Un SOC humain peut le faire, mais à condition d’avoir le temps, les logs, et des outils bien intégrés. L’IA, intégrée dans un SIEM/XDR, est précieuse pour prioriser : elle réduit les faux positifs et met en avant les séquences « plausibles », au lieu d’une avalanche d’alertes isolées.

3) Réponse automatisée : gagner des heures quand chaque minute compte

Face à un zero-day activement exploité, la meilleure réponse n’est pas « analyser pendant 48h ». C’est contenir.

Des playbooks pilotés par l’IA (ou déclenchés par scoring) peuvent :

• isoler le serveur SharePoint au niveau réseau ;
• bloquer temporairement certaines routes ou méthodes HTTP ;
• déclencher une collecte forensic ciblée (fichiers .aspx récents, journaux IIS, événements PowerShell) ;
• créer un ticket prioritaire « P1 » avec chronologie automatique.

L’objectif n’est pas l’automatisation totale. L’objectif, c’est d’arrêter l’hémorragie avant l’enquête complète.

4) Gestion du risque patch : prioriser ce qui doit être corrigé en premier

Les équipes IT le savent : on ne peut pas tout patcher immédiatement, surtout en fin d’année (période de gel de changements, équipes réduites, contraintes métiers). Une approche IA aide à prioriser par risque réel :

• serveur exposé Internet vs interne ;
• présence de comptes à privilèges ;
• sensibilité des espaces documentaires ;
• historique d’alertes et de comportements anormaux.

C’est plus utile qu’une liste CVSS imprimée et oubliée.

Plan d’action SharePoint : ce que je ferais lundi matin

La réponse efficace mélange hygiène, vérifications et capacités de détection. Voici une checklist pragmatique, pensée pour des équipes qui doivent agir vite.

Mesures immédiates (0–24h)

1. Vérifier les versions SharePoint et confirmer si vous êtes dans le périmètre (Subscription Edition / 2019 / 2016 on‑premises).
2. Appliquer les mises à jour de sécurité disponibles dès que possible (en respectant vos processus de changement, mais sans attendre la prochaine fenêtre “confort”).
3. Activer et configurer AMSI (Antimalware Scan Interface) côté SharePoint, avec une solution de sécurité compatible.
4. Rechercher des webshells et fichiers .aspx récents ou atypiques sur les serveurs SharePoint (et pas seulement dans un répertoire).

Mesures de durcissement (48h–7 jours)

• Rotation des clés machine ASP.NET (machine keys) sur SharePoint Server.
• Réduction de l’exposition : limiter l’accès à l’interface d’administration, filtrer les IP si possible, segmenter.
• Journalisation renforcée : IIS logs, événements Windows, logs SharePoint, et centralisation dans SIEM.
• Détection orientée comportements : règles sur cmd.exe lancé par le worker process, créations de fichiers .aspx hors déploiements, anomalies de requêtes.

Contrôles IA “utiles” (pas décoratifs)

Si vous avez une brique IA/XDR/SIEM, imposez trois résultats mesurables :

• MTTD (temps moyen de détection) sur activités webshell < 15 minutes ;
• corrélation automatique exploitation → fichier → commande → accès données ;
• réponse guidée avec actions recommandées et collecte de preuves.

Si votre outil ne sait pas faire ça, ce n’est pas une stratégie IA : c’est un tableau de bord.

FAQ rapide : les questions qu’on me pose après ToolShell

« On est sur Microsoft 365, on est concernés ? »

Non, SharePoint Online n’est pas dans le périmètre. Mais si vous avez des connecteurs, des synchronisations ou des dépendances hybrides, une instance on‑premises compromise peut servir de tremplin vers d’autres ressources.

« Est-ce que la MFA suffit contre ce type d’attaque ? »

Non. La MFA limite le vol d’identifiants, mais un exploit applicatif peut offrir un accès serveur qui contourne le parcours d’authentification classique.

« L’IA remplace un patch ? »

Non. Un patch ferme la porte. L’IA aide à voir la porte forcée (ou la fenêtre cassée) plus vite, et à contenir avant que l’incident ne se propage.

Ce que ToolShell dit de 2026 : la défense doit devenir plus rapide que la rumeur

ToolShell montre une réalité : dès qu’une chaîne d’exploitation fonctionne, elle devient un produit. Elle se copie, se vend, se modifie. Et en quelques jours, on passe d’un incident de recherche à une vague mondiale.

Si vous gérez SharePoint on‑premises, votre meilleure trajectoire est claire : patch + durcissement + détection pilotée par l’IA. Pas par effet de mode, mais parce que les chaînes d’attaque exigent de corréler, prioriser et répondre à une vitesse que l’humain seul ne peut pas tenir durablement.

Vous voulez savoir si votre environnement SharePoint est capable de détecter un webshell en moins de 15 minutes, et de reconstruire automatiquement la chaîne ? C’est une bonne question à poser à votre SOC dès lundi. Et si la réponse est floue, c’est probablement là que votre feuille de route IA en cybersécurité doit commencer.