Dans ses bulletins d’alerte, Microsoft précise que deux failles zero day, CVE‑2025‑53770 (exécution de code à distance) et CVE‑2025‑53771 (usurpation d’identité), touchent uniquement les éditions locales de SharePoint 2016, 2019 et Subscription Edition, tandis que SharePoint Online n’est pas concerné. Ces vulnérabilités, variante de correctifs déjà publiés en juillet, ont été activement exploitées dès le 17 juillet et permettent à un attaquant non authentifié de prendre le contrôle complet d’un serveur et de contourner la double authentification et l’authentification unique.
La chaîne ToolShell tire son nom de la page ToolPane.aspx, composant interne de SharePoint, utilisée pour administrer des composants Web. Des chercheurs ont découvert qu’en envoyant une requête POST vers le répertoire
/_layouts/ — qui contient les pages ASP.NET utilisées pour gérer l’interface d’administration — avec un en‑tête HTTP « Referrer » usurpé pointant vers la page de déconnexion, il est possible de franchir la phase de PostAuthenticateRequest et d’exécuter du code sans authentification. Cette première faille (CVE‑2025‑49706) permet d’atteindre le gestionnaire d’événements. La seconde (CVE‑2025‑49704), un défaut de désérialisation dans SharePoint, ouvre la voie à l’injection de code.
Les correctifs de Microsoft se sont révélés insuffisants : des chercheurs ont démontré qu’une simple modification d’un octet dans la requête suffisait à contourner la protection, ce qui a conduit à la publication des nouveaux correctifs CVE‑2025‑53770 et CVE‑2025‑53771.
Livraison de la charge utile
Une fois cette porte d’entrée franchie, les attaquants livrent différents maliciels. Dans les premières vagues, ils déposent un fichier ASPX baptisé spinstall0.aspx qui, loin d’être un simple webshell, extrait les clés cryptographiques (MachineKey) nécessaires à la validation et au déchiffrement des jetons d’authentification. SentinelOne a constaté deux vagues distinctes les 18 et 19 juillet, provenant d’adresses IP différentes, avec des scripts PowerShell encodés en Base64 écrivant ce fichier dans des répertoires spécifiques du serveur. Une version dite « no shell » exécute le module .NET directement en mémoire sans laisser de trace sur disque, ce qui complique la détection.D’autres campagnes utilisent un webshell plus sophistiqué, GhostWebShell, intégré dans une page ASP.NET encodée en Base64. Ce shell dispose d’une interface en HTTP avec un paramètre « ? cmd= » qui exécute des commandes via
cmd.exe et renvoie la sortie standard et d’erreur. Pour rester furtif, il modifie temporairement le gestionnaire BuildManager, injecte la page depuis la mémoire ou un emplacement non standard et la publie sous un chemin légitime avant de restaurer les paramètres du système. Certains groupes déposent également des shells personnalisés — par exemple xxx.aspx, détecté le 18 juillet — dotés de fonctions d’authentification par cookie, d’exécution de commandes et de téléversement de fichiers.
Organiser la persistance furtive
Après l’accès initial, les acteurs malveillants mènent des actions de reconnaissance et de persistance. Microsoft a observé que le processus w3wp.exe, responsable du traitement des requêtes SharePoint, est utilisé pour exécuter des commandes commewhoami, déterminer le contexte utilisateur et désactiver les protections Microsoft Defender via des modifications de registre. Le groupe Storm 2603, attribué par Microsoft à un acteur chinois, crée des tâches planifiées et manipule Internet Information Services pour charger des assemblages .NET suspicieux, assurant une présence même après la suppression du webshell. Des outils comme Mimikatz servent ensuite à extraire des identifiants dans la mémoire LSASS, puis les assaillants se déplacent latéralement, allant jusqu’à modifier des objets de stratégie de groupe pour propager des rançongiciels de type Warlock.
Le module KeySiphon observé par Fortinet illustre le niveau d’informations collectées : il récupère l’objet HttpContext, nettoie les erreurs, recense les disques logiques, le nom de machine, le système d’exploitation, le nombre de cœurs CPU et la version du CLR. Surtout, il invoque la méthode privée
MachineKeySection.GetApplicationConfig() pour lire les clés de validation et de déchiffrement ainsi que les modes cryptographiques. La possession de ces clés permet de falsifier des jetons d’authentification ou de manipuler la ViewState pour exécuter du code, et de déchiffrer des données protégées. Une fois l’ensemble des informations collecté, le module écrit le rapport en texte clair dans la réponse HTTP et met fin au traitement. L’objectif final est donc l’exfiltration de secrets cryptographiques plutôt que l’exécution systématique de charges utiles destructives.
Chronologie d’une propagation « épidémique »
Selon ESET, la campagne s’est déclenchée le 17 juillet 2025 avec des tentatives initiales repérées en Allemagne et la livraison du premier webshell sur un serveur italien le lendemain. La télémétrie montre ensuite une propagation mondiale, les États‑Unis concentrant 13,3 % des attaques. L’éditeur note également que des groupes étatiques alignés sur la Chine ont saisi l’opportunité, notamment LuckyMouse et d’autres groupes APT, en visant des administrations et des organisations internationales. Microsoft confirme l’implication des groupes Linen Typhoon, Violet Typhoon et Storm 2603 et observe que ce dernier déploie des rançongiciels Warlock dans certaines intrusions.SentinelOne a identifié trois clusters d’attaque distincts : des vagues utilisant spinstall0.aspx, des shells personnalisés et une variante fileless ; les premières cibles appartenaient au conseil en technologie, à la fabrication, aux infrastructures critiques et aux services professionnels avec un impact stratégique. Kaspersky a détecté des serveurs compromis dans des pays aussi variés que l’Égypte, la Jordanie, la Russie, le Viêt Nam ou la Zambie, touchant des entités publiques, financières, manufacturières et même agricoles. Recorded Future estime qu’au 23 juillet, plus de quatre cents organisations avaient été victimes de la campagne et que près de 5 % des entreprises surveillées restaient vulnérables.
Enjeux pour les entreprises et réponses de Microsoft
L’exécution de la chaîne ToolShell est facilitée par la présence massive de SharePoint dans les entreprises. En 2022, plus de 400 000 organisations en étaient équipées et environ 80 % des entreprises du Fortune 500 l’utilisent. Si l’essor de SharePoint Online est notable, près de 60 % des installations y seraient désormais migrées, de nombreux environnements hybrides conservent un serveur local, notamment pour des raisons de conformité ou de performance. Cette exposition rappelle les précédentes attaques ProxyLogon ou ProxyShell sur Exchange, soulignant la vulnérabilité des services de collaboration hébergés en interne face à des acteurs étatiques et cybercriminels.Face à la crise, Microsoft a publié un correctif d’urgence le 19 juillet 2025 puis des recommandations détaillées. L’éditeur conseille d’utiliser uniquement les versions supportées de SharePoint Server, d’appliquer immédiatement les mises à jour cumulatives, d’activer l’interface de scan Antimalware (AMSI) et Microsoft Defender Antivirus en mode complet, de renouveler les clés MachineKey et de redémarrer Internet Information Services.
Dans son billet du 22 juillet, l’éditeur de Redmond insiste sur la rotation des clés ASP.NET et la mise à jour des serveurs avant de reconnecter l’instance au réseau. Palo Alto Networks et d’autres éditeurs de cybersécurité recommandent en outre de déconnecter temporairement d’Internet les serveurs exposés, de faire appel à des équipes de réponse à incident et de ne pas se contenter d’installer les correctifs, mais de rechercher des signes de compromission en profondeur. L’Agence américaine de cybersécurité CISA a classé ces failles parmi les vulnérabilités activement exploitées et a exigé des administrations fédérales qu’elles appliquent les correctifs avant le 1er août.
Adaptation stratégique et perspectives
Pour Microsoft, cette crise illustre le dilemme entre la maintenance de produits sur site et la transition vers le cloud. L’éditeur a réagi rapidement avec un correctif hors cycle et une communication coordonnée via MSRC, mais il est également mis en cause pour la fragilité de ses correctifs initiaux. En forçant la rotation des clés et l’activation de modules de sécurité avancés, Microsoft encourage implicitement les clients à renforcer leur hygiène de sécurité.L’épisode constitue aussi un argument en faveur de la migration vers SharePoint Online, où Microsoft peut appliquer des corrections côté serveur et mutualiser les défenses. D’un point de vue commercial, la dépendance des entreprises à l’égard de SharePoint, service générant plus de deux milliards de dollars de chiffre d’affaires annuel, rend la sécurisation de cette plateforme stratégique pour Microsoft.
ToolShell, ce n’est qu’un début
Pour les entreprises utilisatrices, cette attaque souligne l’importance d’une gestion de configuration rigoureuse, de la surveillance de l’exposition des services et de la rapidité d’application des correctifs. Les secteurs très dépendants de la collaboration documentaire doivent revoir leur stratégie de maintien des systèmes sur site et envisager des solutions hybrides sécurisées.Les attaquants, quant à eux, montrent une capacité d’adaptation remarquable : l’apparition de charges en mémoire sans fichiers (fileless), l’exploitation de clés cryptographiques pour persister malgré les correctifs et la diversification des outils (GhostWebShell, KeySiphon) indiquent une stratégie orientée vers la furtivité et l’exploitation à long terme plutôt que la simple exécution de rançongiciels.
L’histoire de ToolShell ne fait que commencer. Alors que les correctifs sont diffusés et que les premières vagues d’attaques sont identifiées, les acteurs malveillants pourraient recycler ces techniques pour d’autres plateformes ASP.NET. À court terme, la priorité pour les directions informatiques est d’appliquer les mises à jour, d’effectuer une chasse aux maliciels et de renouveler les secrets de leurs applications. À plus long terme, ce cas met en évidence la nécessité d’investir dans des solutions de détection en mémoire et de renforcer les pratiques de développement sécurisé pour les applications Web internes afin d’anticiper les futures chaînes d’exploits.
