Comment Secure les référentiels Server Secure Server

Lorsque les utilisateurs et administrateurs de SharePoint sur site téléchargent un fichier, celui-ci est analysé à l'aide d'un antivirus tiers ou de moteurs compatibles AMSI (tels que Microsoft Defender). Si le fichier passe cette analyse initiale, il est considéré comme traité. Une fois nettoyé, il reste propre pour toujours. C'est précisément ce principe qui permet aux charges utiles de logiciels malveillants et de rançongiciels de rester dans le référentiel sans être détectées, parfois pendant des années.

Microsoft l'affirme clairement: la protection contre les logiciels malveillants de SharePoint peut limiter les dégâts, mais ne constitue pas un rempart unique.

Dans les secteurs de la banque, des services financiers et de l'assurance (BFSI), de la santé, de l'administration publique, ainsi que dans les environnements de technologie opérationnelle (OT) ou d'infrastructures critiques, les données exposées à des risques comprennent les documents de conformité, les dossiers médicaux, les dossiers de cas et la documentation technique. Toutes ces données sont stockées dans une bibliothèque qui ne cesse de s'enrichir d'année en année, sans que personne ne revienne jamais examiner ce qu'elle contient déjà.

Ce qui suit se résume à trois points : comment fonctionne concrètement l'analyse antivirus dans SharePoint, ce qu'elle ne couvre pas, et à quoi devrait ressembler une sécurité efficace et à plusieurs niveaux pour un référentiel de fichiers SharePoint.

Les données d'Enlyft relatives à l'adoption des technologies portent sur 256 295 entreprises qui utilisent actuellement Microsoft SharePoint, dans des secteurs allant des services informatiques au secteur bancaire, en passant par la santé, le pétrole et le gaz, ainsi que le secteur public. Ces entreprises comptent généralement entre 50 et 200 salariés et réalisent un chiffre d'affaires compris entre 1 et 10 millions de dollars.

C'est précisément en raison de cette ampleur que les pirates s'y intéressent et considèrent les référentiels SharePoint comme des cibles de grande valeur.

Cela ne signifie en aucun cas que SharePoint ne sécurise pas ses serveurs ou néglige la sécurité des fichiers. Selon la documentation de Microsoft, SharePoint Server à deux interfaces d'analyse possibles:

• VSAPI (Virus Scanning API), une interface d'intégration antivirus pour SharePoint qui permet à des logiciels antivirus tiers compatibles d'analyser les documents lors d'opérations telles que le téléchargement et l'envoi de fichiers.

• AMSI (Antimalware Scan Interface), un cadre d'intégration anti-malware de Microsoft qui permet à SharePoint Server transmettre des fichiers à des moteurs antivirus compatibles AMSI (tels que Microsoft Defender) afin qu'ils soient analysés à la recherche de logiciels malveillants lors d'opérations de gestion de contenu prises en charge.

Le Server SharePointpeut être configuré pour utiliser VSAPI, AMSI ou le mode automatique. Quelle que soit l'option choisie, un seul moteur d'analyse évalue un fichier à la fois.

L'analyse s'effectue en fonction des événements et est déclenchée lorsque les utilisateurs téléchargent ou transfèrent des documents; elle n'est ni rétroactive ni périodique. Un seul moteur (le Microsoft Malware Protection Engine, communément appelé MpEngine.dll) analyse le fichier.

Point clé : les fichiers sont analysés à l'aide d'un seul moteur, lors du téléchargement ou de l'envoi, en utilisant les signatures et les capacités de détection actuelles de ce moteur.

Cette approche n'est pas conçue pour détecter une menace véhiculée par un fichier et spécialement conçue pour échapper à la logique de détection de ce moteur spécifique. Les menaces persistantes avancées, en particulier, exploitent souvent précisément cette limite, ce qui leur permet de passer inaperçues pendant de longues périodes.

Cette persistance permet aux attaquants d'exploiter à des fins malveillantes du contenu SharePoint de confiance. Des attaques ont déjà été recensées, au cours desquelles des acteurs malveillants ont utilisé des sites SharePoint compromis pour héberger des documents de hameçonnage et des liens malveillants.

Une faille « zero-day » passera l'analyse sans problème, tout comme un fichier sain, tout simplement parce qu'aucun moteur ne la détecte encore. Et comme SharePoint ne réanalyse pas le contenu existant par la suite, un fichier contenant une faille « zero-day » qui passe l'analyse le premier jour ne fera pas l'objet d'un nouveau contrôle le deux centième jour, même après que l'éditeur aura publié une mise à jour des signatures qui permettrait de le détecter.

Les menaces inconnues suivent la même logique. En l'absence de signature associée, l'analyse statique (celle effectuée par les moteurs antivirus) ne permet pas de détecter la menace.

Remarque : il s'agit là de lacunes dans le champ d'application plutôt que de défauts. L'antivirus natif Server SharePoint Server a été conçu pour effectuer des contrôles ponctuels à des points d'interaction spécifiques, et non pour revalider en continu un référentiel en constante expansion et dont les versions évoluent, face à un paysage de menaces en constante évolution.

En juillet 2025, Microsoft a révélé l'exploitation active d'une chaîne d'exécution de code à distance sans authentification affectant SharePoint Server sur site : CVE-2025-49706, CVE-2025-49704, auxquelles se sont ajoutées par la suite les vulnérabilités CVE-2025-53770 et CVE-2025-53771. L'exploitation ne nécessitait ni identifiants ni connexion pour fonctionner.

Microsoft a ensuite corrigé cette faille, et la chaîne d'exploitation a été baptisée « ToolShell ».

Selon l'analyse d'Eye Security, citée par Infosecurity Magazine, 396 systèmes compromis ont été recensés au sein de 145 organisations réparties dans 41 pays. Le secteur public a été le plus durement touché, représentant 30 % des infections confirmées, les États-Unis à eux seuls représentant 31 % du total. Par ailleurs, la Shadowserver Foundation a signalé que plus de 10 700 instances SharePoint restaient exposées, accessibles à toute personne exécutant la même chaîne d'exploitation, même après la divulgation publique de la vulnérabilité, qui avait compromis des centaines d'organisations. Storm-2603, l'un des groupes à l'origine de cette exploitation, a transformé cette faille en une charge utile du ransomware Warlock.

Une fois infiltrés, les membres de Storm-2603 ont utilisé des identifiants volés et des outils d’administration légitimes pour se déplacer latéralement d’un système à l’autre. Ces mouvements n’ont déclenché aucune alerte, car ils s’appuyaient sur des outils censés se trouver sur place. Storm-2603 a installé des shells web et exfiltré des données importantes. Les attaquants ont conservé leur accès même après la correction de la vulnérabilité, car ils avaient déjà volé les clés nécessaires pour falsifier des jetons d’authentification valides.

ToolShell a été conçu à partir de quatre vulnérabilités CVE enchaînées, avec des mécanismes de contournement des correctifs intégrés dès le départ. Les vulnérabilités CVE-2025-53770 et -53771 existent précisément parce qu’il était possible de contourner les correctifs initiaux des vulnérabilités CVE-2025-49704 et -49706.

Ce qui importe vraiment, c'est qu'un pirate ait su s'adapter plus rapidement que le cycle de correctifs, à deux reprises, sur la même cible, en l'espace de quelques semaines.

Les contrôles statiques, tels que les antivirus autonomes qui analysent un fichier une seule fois à l'aide des signatures d'un seul éditeur, n'ont jamais été conçus pour détecter une chaîne d'exploits côté serveur. De plus, ils ne peuvent pas protéger contre un attaquant qui revient après la publication du correctif avec un moyen de le contourner.

ToolShell illustre bien le niveau de sophistication des attaques qui visent désormais spécifiquement les serveurs SharePoint. Il n'y a aucune raison de penser que ce sera la dernière fois qu'une telle faille sera exploitée. Les données stockées sur ces serveurs sont-elles protégées par une solution capable de s'adapter à l'évolution des menaces, ou par un scan qui se contente d'une seule vérification avant de considérer que le travail est terminé ?

Pour être honnête, ToolShell n’était pas un document malveillant ayant échappé à un scan lors du téléchargement. Mais le web shell (spinstall0.aspx et ses variantes renommées) déposé par les attaquants ? C’est un fichier. Il se trouvait sur le serveur et le fait qu’il ait été signalé ou non dépendait des mêmes limites décrites précédemment : un seul moteur, une seule vérification, à un moment précis.

C'est ce mécanisme qui relie cet incident au débat plus général. L'application du correctif met fin spécifiquement à la chaîne d'exploitation de ToolShell. Elle n'a aucun effet sur le prochain fichier non analysé qui se trouve déjà dans un référentiel.

Tout ce qui précède n'a pas grande importance pour un contenu resté inchangé depuis 2023, à moins qu'il ne soit effectivement numérisé.

Il s'agit là d'un niveau que l'antivirus natif de SharePoint ne peut pas prendre en charge : l'analyse récurrente ou continue du contenu stocké, y compris les anciennes versions conservées dans l'historique des versions, plutôt que de se limiter au moment du téléchargement ou de l'envoi. Les analyses en temps réel, programmées et à la demande comblent cette lacune en inspectant périodiquement les fichiers à mesure que les bases de données sont mises à jour.

Pris individuellement, chacun de ces contrôles comble une lacune spécifique évoquée précédemment. Ensemble, ils constituent le type de défense multicouche auquel fait référence la documentation de Microsoft lorsqu’elle précise que l’antivirus intégré n’est pas conçu pour être le seul moyen de protection.

MetaDefender Storage Security peut être déployé selon différents modèles : serveurs physiques pour une installation matérielle directe, plateformes de virtualisation (compatibles avec VMware, Hyper-V et XenServer), IaaS (Infrastructure as a Service) auprès des principaux fournisseurs de cloud, ou encore via des déploiements conteneurisés dans des clusters Kubernetes.

Cette liste de contrôle s'appuie sur les recommandations de la CISA concernant l'exploit ToolShell.

1. Vérifier l'état du correctif.

Des mises à jour de sécurité sont disponibles pour toutes les vulnérabilités CVE exploitées, mais les serveurs non mis à jour restent exposés à ToolShell. Appliquez les mises à jour de sécurité de Microsoft pour toutes Server de SharePoint Server concernées.

2. Vérifiez que l'AMSI est bien configuré.

Un système AMSI déployé mais mal configuré présente la même faille que s’il n’existait pas du tout. Vérifiez que l’intégration AMSI est activée et qu’une solution antivirus est déployée sur chaque serveur SharePoint.

3. Renouveler les clés de machine ASP.NET

Les clés de machine volées permettent aux attaquants de créer de faux jetons d'authentification valides, même après l'application d'un correctif sur le serveur. L'application d'un correctif ne suffit pas à elle seule à invalider les clés déjà volées. Renouvelez les clés de machine, appliquez la mise à jour de sécurité, puis renouvelez à nouveau les clés de machine. Redémarrez IIS à l'aide de la commande iisreset.exe après chaque renouvellement afin de supprimer les entrées malveillantes des fichiers applicationHost.config et web.config.

4. Rechercher manuellement les signes d'une intrusion antérieure.

La CISA souligne que les charges utiles au format .dll utilisées dans le cadre de cette campagne peuvent servir à obtenir les clés système. L'application d'un correctif ne supprime pas la charge utile déjà déployée sur le serveur. Il convient d'inspecter les systèmes et certains fichiers à la recherche d' indicateurs de compromission ( IOC ), et pas uniquement de la vulnérabilité elle-même.

5. Vérifiez s'il existe des versions en fin de vie ou en fin de support.

Certaines instances SharePoint ont atteint leur fin de vie (EOL) et ne bénéficient plus d'aucune mise à jour de sécurité, quelle que soit l'activité d'exploitation. Vérifiez si les versions utilisées par votre entreprise sont toujours prises en charge. Si ce n'est pas le cas, prenez les mesures nécessaires.

6. Examiner les journaux à la recherche d'indicateurs connus

La CISA a identifié des schémas de requêtes spécifiques ainsi que des adresses IP liées à cette campagne. Recherchez dans les journaux les requêtes correspondant aux références fournies par la CISA.

7. Vérifier les droits d'administration et de mise en page.

Pour limiter l'ampleur des dommages, vérifiez qui dispose des droits de mise en page et d'administration sur SharePoint, puis supprimez les accès qui ne sont pas réellement nécessaires.

8. Évaluez ce qui est déjà stocké, et pas seulement ce qui est actuellement visible

Tout ce qui précède concerne la chaîne d'exploitation elle-même. Aucun de ces éléments n'évalue le contenu déjà présent dans les bibliothèques de documents, y compris les fichiers antérieurs à ces correctifs.

Déterminez si le contenu existant du référentiel a fait l'objet d'une nouvelle analyse depuis l'application des correctifs et des mises à jour de signatures concernés, ou s'il conserve toujours son verdict d'analyse d'origine, qui pourrait être obsolète.