📌 Au programme Focus sur :

🗂️ Microsoft SharePoint – Exploitation active par ToolShell
Chaîne d’exploitation documentée par la CISA : CVE‑2025‑49704, CVE‑2025‑49706, CVE‑2025‑53770, CVE‑2025‑53771. Exécution de code, contournement d’authentification, webshells ASPX, DLL, et artefacts identifiés.
🔗 https://www.cisa.gov/news-events/alerts/2025/08/06/cisa-releases-malware-analysis-report-associated-microsoft-sharepoint-vulnerabilities
🔗 https://www.cisa.gov/news-events/analysis-reports/ar25-218a

📞 Partagez vos retours :
📱 Répondeur : 07 68 72 20 09
📧 Email : radiocsirt@gmail.com

🎧 Disponible sur :
Apple Podcasts • Deezer • Spotify • YouTube • Amazon Music
🌐 Site : https://www.radiocsirt.org
📰 Newsletter : https://radiocsirt.substack.com

🛡️ On ne réfléchit pas. On patch !™

Vous trouverez ci-dessous la transcription technique de l’épisode pour vous permettre de retrouver les IOC

Depuis Le 18 juillet 2025, une campagne d’exploitation d’envergure ciblant des serveurs Microsoft SharePoint sur site a été observée par plusieurs chercheurs en cybersécurité. Cette attaque s’appuie sur une chaîne de vulnérabilités critiques, connue sous le nom de « ToolShell », permettant à un attaquant non authentifié d’obtenir une exécution de code à distance sur les serveurs SharePoint vulnérables. 

D’après Eye Security, qui a été le premier à alerter sur ce phénomène, plus de 400 serveurs SharePoint dans le monde ont été compromis en quelques jours, sur un total de 23 000 instances examinées, au travers de quatre vagues d’attaques successives entre le 17 et le 21 juillet 2025. 

Ces attaques ont visé des organismes variés, notamment des institutions gouvernementales, des établissements scolaires, le secteur de la santé (hôpitaux) et de grandes entreprises, en particulier celles maintenant leurs propres serveurs SharePoint (« on-premises ») exposés sur internet. Les instances cloud SharePoint Online associées à Microsoft 365 n’ont pas été affectées, seuls les déploiements sur site étant vulnérables.

Microsoft et la CISA (agence américaine de cybersécurité) ont rapidement réagi en publiant des alertes et correctifs. 

La CISA a notamment intégré les failles exploitées dans son catalogue des vulnérabilités activement exploitées (Known Exploited Vulnerabilities) – la CVE-2025-53770 y a été ajoutée le 20 juillet 2025, et les CVE-2025-49704/49706 le 22 juillet. Le 6 août 2025, la CISA a diffusé un rapport d’analyse malware (MAR 25-1132) concernant cette campagne, avec des indicateurs de compromission et des règles de détection associées. Microsoft a également publié des mises à jour de sécurité d’urgence et un blog MSRC détaillant l’attaque le 22 juillet 2025. 

Ces sources confirment que la chaîne ToolShell a été utilisée par plusieurs groupes d’attaque liés à la Chine, identifiés par Microsoft sous les appellations Linen Typhoon, Violet Typhoon ainsi qu’un acteur suivi en tant que Storm-2603. Des indices montrent que l’activité d’un de ces acteurs (cluster CL-CRI-1040 suivi par Palo Alto) recoupe celle de Storm-2603 signalée par Microsoft. 

Par ailleurs, au-delà de la prise de contrôle initiale des serveurs SharePoint, les assaillants ont été observés déployant ensuite un ransomware surnommé “Warlock” (une variante de l’open-source Mauri870) sur certaines des infrastructures compromises.

Quand on regarde les Vulnérabilités exploitées au niveau des CVE, du scores CVSS et de l’impact)

Cette chaîne ToolShell exploite en combinaison plusieurs failles critiques de SharePoint, dont certaines étaient des jours zéro (zero-days) au moment de leur découverte. Quatre CVE majeures sont à considérer :

• CVE-2025-49704 – Injection de code (« Improper control of generation of code ») dans Microsoft SharePoint. Elle permet à un attaquant authentifié d’exécuter du code arbitraire à distance sur le serveur via un vecteur réseau. Microsoft l’a initialement évaluée avec un score de sévérité CVSS 8,8 (haute). Cette faille, dévoilée et corrigée le 8 juillet 2025, était l’une des deux composantes originelles de la chaîne ToolShell.
  
• CVE-2025-49706 – Vulnérabilité d’authentification (« Improper Authentication ») dans Microsoft SharePoint, permettant à un attaquant non authentifié d’usurper une identité ou de contourner des mécanismes d’authentification sur le réseau. Son score CVSS est de 6,5 (niveau modéré). En pratique, cette faille de type spoofing réseau a servi de point d’entrée pour lancer l’exploitation de la CVE-2025-49704, en contournant les contrôles d’accès. Elle a également été corrigée dans les mises à jour de sécurité du 8 juillet 2025.
  
• CVE-2025-53770 – Désérialisation de données non fiables (« Deserialization of untrusted data ») dans SharePoint Server sur site. Il s’agit de la plus critique : elle permet à un attaquant non authentifié d’exécuter du code arbitraire à distance (RCE) sur un serveur SharePoint vulnérable, sans nécessiter de compte valide. Microsoft lui a attribué un score CVSS 9,8 (critique). Cette faille a été découverte en juillet 2025 alors que les acteurs menaçants l’exploitaient déjà activement dans la nature. Elle représente en réalité une variante contournant les correctifs de CVE-2025-49704 – c’est pourquoi Microsoft l’a qualifiée de « ToolShell Auth Bypass and RCE » (bypass d’authentification menant à RCE). La CVE-2025-53770 a été assignée et corrigée d’urgence le 19 juillet 2025 par Microsoft (patch hors cycle), dès la prise de conscience de son exploitation active.
  
• CVE-2025-53771 – Vulnérabilité de chemin non sécurisé (« Improper limitation of pathname to a restricted directory (path traversal) ») dans Microsoft SharePoint. Elle permet à un attaquant non authentifié d’obtenir indûment des privilèges ou de réaliser des actions via un contournement de restrictions de chemin, pouvant faciliter une usurpation (spoofing). Son score CVSS est de 6,5. Cette faille a été identifiée comme un contournement de patch pour la CVE-2025-49706 (dont elle reprend le principe d’authentification insuffisante). Bien que Microsoft n’ait pas confirmé d’exploitation active de CVE-2025-53771 au moment de l’alerte, la CISA estime qu’elle pourrait être utilisée en conjonction avec CVE-2025-53770 pour bypasser les protections introduites par les premiers correctifs. CVE-2025-53771 a été corrigée simultanément avec CVE-2025-53770 dans l’update hors bande du 19 juillet 2025.
  

Selon Microsoft, seules les éditions sur site de SharePoint (versions 2016, 2019 et Subscription Edition) sont affectées par ces failles. Les services SharePoint Online (cloud) ne sont pas touchés et les instances à jour de SharePoint 2013 ou antérieures, bien que potentiellement vulnérables, sont en fin de vie (EOL) et ne reçoivent plus de correctifs, ce qui pose un risque majeur si elles sont exposées en ligne.

Mode opératoire de l’exploitation « ToolShell »

Les acteurs malveillants tirent parti de ces vulnérabilités en les enchaînant pour compromettre complètement les serveurs cibles sans avoir besoin de comptes légitimes. D’après la CISA et Microsoft, le schéma d’attaque est le suivant :

1. Point d’entrée – Spoofing & RCE initiale : L’attaquant envoie une requête spécialement construite vers une page SharePoint accessible anonymement (par exemple /_layouts/15/ToolPane.aspx?DisplayMode=Edit), en exploitant la faille d’usurpation CVE-2025-49706 pour se faire passer pour un utilisateur ou un contexte autorisé. Un en-tête ou référant particulier – la page _layouts/SignOut.aspx – est notamment utilisé dans ces requêtes, ce qui est inhabituel (une requête émise juste après une déconnexion) et a mis la puce à l’oreille des analystes. Cette première étape permet de contourner l’authentification et de déclencher, via la page légitime ToolPane.aspx, l’exécution de code à distance sur le serveur en exploitant la faille CVE-2025-49704 (injection de code). Concrètement, les chercheurs indiquent que la chaîne ToolShell peut aboutir à un RCE « in-memory » sans écritures de fichiers, grâce à des requêtes POST malveillantes bien formées, même si dans de nombreux cas observés les attaquants ont ensuite déposé des webshells sur disque pour maintenir l’accès persistant.
   
2. Extraction des Machine Keys : Une fois un accès code obtenu, la première action des attaquants est généralement de récupérer les clés de sécurité ASP.NET du serveur compromis. Ces clés, appelées Machine Key dans la configuration ASP.NET, sont cruciales car elles servent à chiffrer et signer divers éléments (cookies d’authentification, vues ViewState, tokens, etc.) sur le serveur SharePoint. En les obtenant, un adversaire peut par exemple générer de faux cookies d’authentification valides ou usurper des sessions, assurant une persistance discrète même si les failles sont corrigées par la suite. Dans le cas de ToolShell, l’extraction de ces clés a été réalisée via l’installation d’une charge webshell ASPX légère (dénommée SharpyShell par les analystes) dont le rôle est précisément de dumper les secrets cryptographiques du serveur. Par exemple, les journaux montrent qu’immédiatement après la requête initiale sur ToolPane.aspx, les attaquants ont invoqué en GET une page nommée spinstall0.aspx, qui n’existait pas sur un serveur sain et correspond à un webshell implanté : celle-ci a répondu en HTTP 200 en renvoyant le contenu des clés privées du serveur dans la réponse. La CISA confirme qu’en analyse, le premier fichier ASPX malveillant (spinstall0.aspx) sert spécifiquement à lire et afficher la section machineKey de la configuration de l’application web SharePoint.
   
3. Déploiement d’un webshell persistant : Forts de cet accès initial, les attaquants déploient ensuite un webshell plus complet sur le serveur pour disposer d’une porte dérobée persistante. L’analyse montre qu’une seconde charge (un script baptisé stage3.txt dans les échantillons recueillis) contient une commande PowerShell encodée en Base64. Lorsqu’elle est exécutée sur le serveur, cette commande décodera et écrira un fichier ASPX malveillant sur le disque du serveur SharePoint. D’après les indicateurs, ce fichier webshell est souvent nommé info3.aspx et placé dans le répertoire standard des layouts SharePoint (…/15/Template/Layouts/), ce qui le rend accessible via une URL web habituelle. Ce webshell ASP.NET implanté offre une interface cachée à l’attaquant : il inclut par exemple un formulaire HTML pour soumettre un mot de passe d’accès (stocké ensuite dans un cookie côté client à durée de vie 4 jours), un champ pour saisir et exécuter des commandes système sur le serveur (via cmd.exe), ainsi qu’un module d’upload de fichiers vers le serveur. En somme, l’attaquant dispose alors d’un contrôle à distance complet de la machine compromise par le biais de ce webshell persistant.
   
4. Mouvements post-exploitation et impact : Une fois le serveur SharePoint compromis et équipé de porte dérobée, les assaillants peuvent explorer son contenu et l’utiliser comme tremplin. SharePoint contient souvent des informations internes sensibles ; de plus, parce qu’il est intégré à l’environnement Windows/Active Directory, le contrôle d’un serveur SharePoint peut ouvrir l’accès à d’autres services de l’entreprise. Les clés volées (Machine Keys) permettent potentiellement de forger des tickets d’authentification ou des tokens OAuth si le SharePoint est fédéré, facilitant une mobilité latérale vers d’autres applications reliées. Microsoft signale que ces tactiques ont été observées concordantes avec les modes opératoires de groupes affiliés à l’État chinois déjà connus. Dans plusieurs cas, les attaquants ont profité de l’accès pour déployer un ransomware (famille Warlock), chiffrant les fichiers sur le serveur SharePoint lui-même ou sur des machines connectées. D’autres charges malveillantes sous forme de modules .DLL ont également été vues, par exemple pour agir en mémoire et subtiliser d’autres informations sensibles. L’ensemble de ces activités fait de cette chaîne ToolShell une menace particulièrement grave, « donnant aux acteurs la maîtrise complète du serveur SharePoint, y compris son système de fichiers, ses configurations internes, et la possibilité d’exécuter du code arbitraire sur le réseau ».
   

La chronologie de l’attaque initiale en juillet 2025 montre une progression rapide. Eye Security indique une première reconnaissance active le 17 juillet au matin (scan/test d’exploitation depuis une IP suspecte), suivie d’une première vague massive le 18 juillet vers 18h UTC (depuis une autre adresse IP, ayant compromis de nombreux serveurs). Une deuxième vague a eu lieu le 19 juillet vers 07h30 UTC, puis d’autres tentatives les jours suivants. Plusieurs adresses IP d’origine ont été identifiées, notamment 96.9.125[.]147, 107.191.58[.]76 et 104.238.159[.]149, correspondant aux premières vagues. Ces IP, tout comme un user-agent HTTP particulier (un faux navigateur Firefox/120.0 sur Windows 10) présent dans les requêtes malveillantes, servent d’indicateurs de compromission pour détecter cette activité dans les journaux. Des outils publics d’exploitation (Proof of Concept) ont également émergé peu après la divulgation des failles, facilitant possiblement d’autres attaques par des acteurs opportunistes.

Analyse des fichiers malveillants par la CISA

Le rapport d’analyse de la CISA (MAR-251132 du 06/08/2025) détaille les six fichiers malveillants récupérés sur des serveurs compromis par ToolShell. Il s’agit de deux bibliothèques DLL .NET et de quatre fichiers ASPX (pages web) liés à l’exploitation :

• Modules .NET (.dll) : Les deux DLL malveillantes, initialement encodées en Base64 sur le serveur pour échapper à la détection, ont été décodées par la CISA. La première, identifiée par le hash SHA-256 bee94b93c1… (nom interne bjcloiyq.dll), contient une classe nommée “E” conçue pour accéder par réflexion aux paramètres de configuration MachineKey de l’application web ASP.NET. Ce module extrait la clé de validation (ValidationKey), le type de validation utilisé, la clé de déchiffrement (DecryptionKey), l’algorithme de chiffrement, etc., puis concatène ces valeurs en une chaîne qu’il ajoute en clair dans un en-tête HTTP personnalisé (X-TXT-NET) des réponses du serveur. Cela signifie que lorsqu’il est chargé dans le processus IIS/SharePoint, cette DLL agit comme un voleur de secrets : à chaque requête traitée, elle peut divulguer les clés cryptographiques sensibles au client attaquant via la réponse HTTP. La deuxième DLL (osvmhdfl.dll, SHA-256 3461da3a2d…) est une variante 32-bit qui, en plus de récupérer également la section MachineKey, collecte des informations d’inventaire sur le système hôte. En effet, d’après l’analyse, cette DLL recense les lecteurs logiques présents et leurs lettres, le nom de la machine, le chemin du répertoire système et le répertoire courant, le nombre de processeurs, le temps de fonctionnement du système, le nom d’utilisateur du processus, la version de l’OS Windows et la version du framework .NET. Ces informations, combinées aux clés MachineKey, sont formatées puis insérées dans la réponse HTTP renvoyée à l’attaquant (via l’objet HttpResponse) – suggérant que ce module sert à profiler le serveur compromis tout en exfiltrant ses secrets cryptographiques, le tout de manière furtive (via les canaux HTTP normaux). Notons qu’aucun de ces fichiers DLL n’a été détecté par les antivirus lors de l’analyse (ils étaient inconnus des bases de signatures à ce moment).
  
• Webshells ASPX : Quatre fichiers ASPX ont été identifiés, correspondant à des webshells déposés par les attaquants à divers stades de l’intrusion. Le premier, nommé spinstall0.aspx (SHA-256 92bb4ddb98…), est celui évoqué précédemment pour l’extraction des MachineKeys. Son contenu, une fois décompilé, confirme qu’il charge dynamiquement l’assembly système System.Web et utilise les classes de configuration (System.Web.Configuration) pour obtenir la section MachineKeySection active, puis écrire ses propriétés (clés de validation et de déchiffrement, mode de compatibilité, etc.) dans la réponse HTTP via Response.Write(). C’est un outil simple d’exfiltration de ces secrets, déclenché à la demande par l’attaquant via une requête HTTP GET. 

• Le deuxième fichier ASPX (info3.aspx dans sa version script d’installation, hash 9340bf7378…) contient principalement une commande PowerShell encodée. 

• Cette commande, lors de son exécution sur le serveur, va décoder une charge en Base64 et l’écrire dans un fichier ASPX distinct sur le disque. Ce fichier résultant – le troisième ASPX malveillant, également nommé info3.aspx mais de taille différente (SHA-256 675a10e87c…) – constitue le webshell principal installé par ToolShell pour persister sur le serveur. Son code source révèle des fonctionnalités étendues : il s’interface avec la requête HTTP courante (HttpRequest) pour lire soit des champs de formulaire, soit des cookies, selon plusieurs modes de fonctionnement. Il implémente une porte dérobée multifonction :
  
  • Un mode authentification : il attend un mot de passe transmis via un champ de formulaire spécifique (nYOmkVTYH2). Si présent, il stocke ce mot de passe dans un cookie HTTP nommé wY1DC6wH4u retourné au client, avec une expiration dans 4 jours, servant ainsi de clé de session pour l’attaquant. À chaque requête suivante, le webshell vérifie l’existence de ce cookie et calcule un haché SHA-512 combinant la valeur du cookie et une longue constante cachée dans son code. Il compare ce SHA-512 (après encodage Base64) avec une valeur attendue en dur, afin de valider que l’utilisateur est bien le détenteur du mot de passe correct. Ce mécanisme implémente une porte d’accès rudimentaire pour empêcher qu’un tiers non autorisé n’exploite la webshell s’il la découvre.
    
  • Un mode commande distante : si un paramètre de formulaire nommé GTaRkhJ9wz est reçu (contenant une commande), le webshell va lancer un processus cmd.exe sur le serveur et rediriger son entrée/sortie. Il écrit la commande reçue dans l’entrée standard, exécute ainsi la commande système, puis capture la sortie du programme. Cette sortie est renvoyée au client (via Response.Write) après exécution, permettant à l’attaquant d’obtenir le résultat de la commande comme réponse HTTP. Le code insère aussi un exit pour fermer correctement le processus cmd.exe après chaque commande. Ce fonctionnement donne à l’attaquant un shell distant interactif via le simple envoi de formulaires web.
    
  • Un mode upload de fichier : le webshell comporte un formulaire multipart avec un champ de fichier (type= »file », nommé 0z3H8H8ato) et un champ texte 7KAjlfecWF (destiné à indiquer le chemin/nom de destination). Si une requête contenant un fichier uploadé est reçue, le code va sauvegarder le fichier fourni sur le serveur à l’emplacement indiqué (via Request.Files[« 0z3H8H8ato »]) et retourner la chaîne « uploaded » dans la page en cas de succès. En cas d’échec, il capture l’exception et la renvoie dans la réponse pour informer l’attaquant de l’erreur. Ce mécanisme permet d’transférer aisément des outils ou données vers le serveur compromis.
    
• Globalement, ce webshell principal offre à l’attaquant une interface web complète pour piloter le serveur à distance, protégée par mot de passe, et combinant exécution de commandes arbitraires et transfert de fichiers – de quoi explorer le système et préparer d’autres actions malveillantes.
  
• Enfin, la CISA décrit deux autres webshells ASPX (spinstallb.aspx – SHA-256 d9c4dd5a83… – et spinstallp.aspx – SHA-256 d0c4d6a4be…), de taille plus réduite, qui semblent avoir été utilisées pour exécuter des commandes PowerShell de façon plus discrète. Le code de ces pages reçoit un paramètre (par ex. p dans la requête) contenant une chaîne chiffrée, qu’il déchiffre via un XOR avec une clé codée en dur (une longue suite hexadécimale), obtenant ainsi une commande PowerShell en clair. 
• Il lance alors un processus powershell.exe sur le serveur avec l’argument -EncodedCommand suivi de la commande (re-chiffrée en Base64) ; pour l’un des deux fichiers, la sortie de la commande PowerShell est capturée, re-chiffrée par XOR avec la même clé, puis encodée en Base64 et renvoyée dans la réponse HTTP. Ces deux webshells agissent donc comme des portes dérobées temporaires pour exécuter du code de manière chiffrée, probablement afin d’éviter une détection par des solutions de sécurité (en masquant le contenu exact des commandes). Elles démontrent le niveau de sophistication et les mesures d’évasion employées par les attaquants pour pérenniser leur présence sur les serveurs SharePoint infectés.
  

L’analyse technique fournie par la CISA inclut également des règles de détection YARA et SIGMA pour identifier ces fichiers ou comportements. Par exemple, une règle Sigma publiée cible explicitement l’exploitation ToolShell (CVE-2025-53770) et ses indicateurs, notant que « CVE-2025-53770 correspond à un nouveau webshell furtif appelé SharpyShell, conçu pour extraire et exfiltrer les secrets cryptographiques du serveur via de simples requêtes GET ». 

Les hashes SHA-256 de chaque composant malveillant, les motifs de code caractéristiques (extraits de chaînes Base64, signatures de commandes, etc.) et des patterns de logs IIS (appels à ToolPane.aspx, User-Agent inhabituel, etc.) sont fournis pour aider les défenseurs à traquer la présence de ces artefacts sur leurs systèmes.

Correctifs et recommandations de sécurité

Microsoft a publié des correctifs pour l’ensemble de ces vulnérabilités. Il est impératif d’appliquer les mises à jour de sécurité de juillet 2025 sur tous les serveurs SharePoint on-premise vulnérables. Les failles CVE-2025-49704 et 49706 ont été corrigées dans les patchs du 11 juillet 2025 (Patch Tuesday), tandis que les CVE-2025-53770 et 53771 ont fait l’objet d’un correctif hors cycle le 19 juillet 2025 pour colmater la chaîne ToolShell. 

Dans son alerte, la CISA insiste pour que les organisations appliquent immédiatement ces mises à jour sur les instances SharePoint concernées. À noter que toute version obsolète de SharePoint (telle que SharePoint 2013, arrivée en fin de vie) devrait être déconnectée d’internet ou mise à jour vers une version supportée, car aucune rustine ne viendra combler ces failles sur des produits hors support.

Au-delà des correctifs, il est recommandé de procéder à une inspection approfondie des serveurs SharePoint pour détecter tout signe de compromission passée. 

En particulier, il convient de rechercher la présence des fichiers malveillants mentionnés (ex.: spinstall0.aspx, info3.aspx, etc., dans les répertoires Layouts), des DLL suspectes chargées dans les processus IIS, ou des logs révélant des accès étranges (référents inhabituels comme SignOut.aspx, requêtes vers ToolPane.aspx avec DisplayMode=Edit, ou provenant des adresses IP signalées). 

La CISA fournit pour cela une liste d’indicateurs de compromission (IOC) dans un fichier STIX, ainsi que des règles Sigma que les analystes SOC peuvent déployer dans leurs SIEM pour identifier des schémas d’attaque ToolShell dans les journaux.

En termes de durcissement, Microsoft recommande d’activer l’AMSI (Antimalware Scan Interface) sur SharePoint. AMSI permet aux antivirus/EDR d’inspecter les scripts et charges dynamiques exécutées dans SharePoint (par exemple les commandes PowerShell encodées pourraient être interceptées). Il est aussi préconisé d’installer des solutions EDR sur les serveurs SharePoint eux-mêmes – ces serveurs étant souvent négligés en termes d’outils de sécurité – afin de détecter des comportements suspects en mémoire, comme le chargement de modules non signés ou l’exécution de cmd.exe par le processus w3wp.exe (IIS). Si l’AMSI ne peut être activé immédiatement, la CISA suggère en dernier recours de couper temporairement l’accès internet aux serveurs SharePoint vulnérables jusqu’à application des patchs, afin d’éviter leur compromis.

Dans le cas où une machine a été compromise, rotations des secrets sont conseillées. En effet, comme les attaquants ont pu voler les Machine Keys ASP.NET, il est nécessaire de générer de nouvelles clés une fois le serveur nettoyé et patché, pour invalider les accès persistants qu’ils auraient pu conserver. 

La CISA recommande une procédure en trois temps : rotation initiale des clés, application des correctifs Microsoft, puis rotation à nouveau des clés avant de remettre en service, accompagnée d’un redémarrage du service IIS. Cette double rotation garantit que même si les attaquants avaient implanté un module malveillant surveillant les clés (comme c’était le cas ici), ce module soit neutralisé par le patch et ses clés volées rendues obsolètes par la seconde rotation. Il est par ailleurs souligné qu’un redémarrage complet d’IIS (commande iisreset.exe) est requis après nettoyage, car un simple redémarrage applicatif pourrait recharger des modules malveillants encore référencés dans la configuration si ceux-ci n’ont pas été manuellement retirés des fichiers applicationHost.config ou web.config.

Enfin, de façon générale, les bonnes pratiques de sécurité doivent être renforcées autour des services SharePoint : appliquer le principe du moindre privilège (limiter les comptes disposant de privilèges Admin sur la ferme SharePoint, et restreindre l’accès aux pages _layouts aux seuls utilisateurs autorisés), maintenir un journalage détaillé des actions (logs d’accès web, journaux Windows) et intégrer ces sources à une solution de détection d’intrusion, déployer des règles de filtrage WAF pour bloquer les motifs de requêtes suspectes connus (par ex., bloquer les accès externes à ToolPane.aspx ou aux chemins contenant /_/layouts/ si non nécessaires depuis Internet). La CISA oriente également vers son guide “Best Practices for Event Logging” pour améliorer la surveillance, ainsi que vers le guide #StopRansomware pour se préparer et réagir aux éventuelles attaques de ransomware qui pourraient découler de telles intrusions.

Il est vivement conseillé à toute organisation utilisant SharePoint sur site de vérifier en urgence si ses serveurs ont été mis à jour avec les patchs de juillet 2025 et d’examiner les signes d’intrusion indiqués dans les rapports de Microsoft, CISA, Eye Security et autres. La chaîne d’exploitation ToolShell représente une menace critique combinant exploitation ciblée d’une infrastructure collaborative répandue et techniques avancées de post-exploitation (vol de clés de confiance, webshell furtif, usage de ransomware). Les retours d’expérience de cette campagne soulignent l’importance de tenir à jour les systèmes exposés, de surveiller activement les applications web d’entreprise, et de partager rapidement les informations sur les attaques en cours au sein de la communauté de cybersécurité. Les indicateurs et signatures publiés sont à disposition pour aider à détecter et neutraliser ce type de menace le plus tôt possible.