Comme tous les acteurs du cyber, nous avons assisté le week-end dernier à une vague de prise de conscience chez les administrateurs SharePoint du monde entier, confrontés à une série de vulnérabilités permettant l’exécution de code à distance sans authentification (CVE-2025-53770, CVE-2025-53771, …). Cela faisait longtemps que les administrateurs SharePoint n’avaient pas connu ce sentiment, celui que les administrateurs de passerelles VPN doivent malheureusement affronter régulièrement.
Quelles vulnérabilités devons-nous détecter ?
Pour rappel, chez ONYPHE, nous visons à déployer une capacité de détection avant même qu’une exploitation massive d’une vulnérabilité ne soit observée, ou dès que possible quand s’il s’agit d’une vulnérabilité zero-day. Nous utilisons les critères suivants pour déterminer si une vulnérabilité sera ajoutée à notre catégorie ulnscan :
- Fiabilité de l’exploitation : la vulnérabilité peut être exploitée de manière fiable en dehors du laboratoire
- Nous ignorons le CVSS (nous n’évaluons jamais la gravité d’une vulnérabilité par son score CVSS, même si nous pouvons parfois l’afficher)
- Non authentifié : l’exploitation se produit avant l’authentification ou permet de contourner l’authentification
- Accès à distance : l’exploitation directe ou indirecte de la vulnérabilité permet l’exécution de code à distance (RCE)
- Massivement déployé : le nombre de systèmes potentiellement vulnérables exposés sur Internet est important
- Identifiable : les systèmes potentiellement vulnérables peuvent être identifiés avant toute tentative d’exploitation
- Utilisée par les entreprises ou les gouvernements : la technologie est utilisée par les entreprises et sur les réseaux du secteur public (c’est-à-dire généralement pas sur les appareils des TPE/PME)
Il s’agit essentiellement des mêmes critères de sélection qu’un cybercriminel ou un autre acteur malveillant à faible pouvoir discrétionnaire utiliserait pour déterminer s’il convient d’exploiter une vulnérabilité.
ToolShell, ou CVE-2025-53770/53771
Ainsi, après avoir lu l’excellent article d’Eye Security, nous avons rapidement compris que cette série de vulnérabilités répondait à tous nos critères et qu’il était nécessaire de mettre en place une méthode de détection au plus vite.
Comme de nombreux fournisseurs d’analyse Internet similaires, nous sommes capables d’identifier les systèmes SharePoint Server grâce aux en-têtes que Microsoft ajoute judicieusement aux réponses HTTP. Cependant, nos précédentes investigations nous ont appris que les numéros de version de SharePoint ne sont pas mis à jour systématiquement ; autrement dit, il est possible d’avoir plusieurs composants .NET liés à SharePoint portant des numéros de version différents sur un même système, et qu’il était donc impossible d’utiliser une détection basée sur la version pour ces CVE.
Nous disposons d’une autre méthode de détection : la détection par vérification (check-based). Autrement dit, nous pouvons tenter de déterminer si un système est vulnérable en lui adressant une ou plusieurs requêtes non intrusives. Par « non intrusif », nous entendons que nous utilisons les fonctionnalités existantes du système, normalement exposées à Internet, et que nos actions ne compliqueront pas la tâche des cyber défenseurs qui œuvrent pour la protection des organisations. Notre priorité est de protéger l’écosystème et, lorsque cela est possible, nous informons les organisations concernées, qu’elles soient clientes ou non.
La méthode de détection
Extrait de payload en provenance de hazcod
Pour ToolShell, nous avons rapidement ajouté une détection pour l’URL webshell connue, comme décrit par Eye Security, puis nous avons recherché par l’intermédiaire de contacts privés afin d’identifier une preuve de concept (POC) concernant la vulnérabilité. Mardi matin (22/08 CEST), un code d’exploitation circulait sur Internet et plusieurs personnes avaient examiné ces attaques et publié du code. Cependant, le code le plus clair et le plus utile, selon nous, était celui de hazcod (Niels Hofmans) https://github.com/hazcod/CVE-2025-53770/.
Le code Go soigné de Niels, sa charge utile non intrusive et son fichier Readme utile illustrent comment la recherche en sécurité peut et doit être menée. Nous avons adapté son approche à notre propre pile technologique.
- Tout d’abord, nous avons besoin d’une liste de tous les serveurs SharePoint connus. Nous n’analysons pas les vulnérabilités de 0.0.0.0/0 ; nous devons donc utiliser notre jeu de données datascan et extraire toutes les adresses IP et tous les hôtes virtuels connus exécutant SharePoint. Nous procédons de la même manière que nos clients, avec une requête OQL : category:datascan app.http.component.product:”sharepoint server” !tag:honeypot
- Comme pour le POC original, notre code tente d’exploiter la vulnérabilité en injectant un marqueur inoffensif dans le widget SharePoint ToolBox. Si la réponse du serveur SharePoint contient ce marqueur, l’hôte est marqué comme vulnérable. Ce marqueur reste en mémoire pendant le rendu de la page par le serveur, mais n’est pas écrit sur le serveur SharePoint ni dans la base de données.
- Nos premières tentatives de décodage de la réponse du serveur ont échoué, car le marqueur est d’abord compressé, puis encodé en base64 avant d’être rendu par le serveur sous forme d’entité HTML. Nous avons dû effectuer quelques substitutions de caractères à ce stade pour reconstituer une chaîne base64 valide avant de poursuivre la décompression et de vérifier la présence de notre marqueur.
- Comme pour toutes nos analyses de vulnérabilités, nous effectuons des analyses depuis les États-Unis et la France, avec des serveurs identifiables comme infrastructure ONYPHE, tous deux dotés d’une entrée DNS inverse et d’un serveur web exécuté sur chaque analyseur. Nos plages d’adresses IP sont publiées et nous traitons les demandes de désinscription légitimes sans poser de questions (à part, bien sûr, quelle est votre plage d’adresses IP ?).
Exemple de réponse pour une système vulnérable
Scan results
| Résultats | Description | Nombre d’IP uniques |
| Total | Systèmes testés pour les failles SharePoint CVE-2025-53770 et CVE-2025-53771 | 11612 |
| Non vulnérable | Testés avec une requête POST inoffensive avec le marqueur présent dans la réponse | 11149 |
| Vulnérable | Testés avec une requête POST inoffensive avec le marqueur absent dans la réponse | 463 |
| Compromis | Testés la présence du webshell connu et identifié comme présent | 141* |
* au moment de l’écriture, seules 71 machines répondaient encore à l’URL du webshell. Nombres d’entre elles sont offline.
Requêtage de vulnscan
Les clients ONYPHE Entreprise peuvent utiliser les requêtes OQL suivantes dans notre catégorie vulnscan pour accéder aux données de vulnérabilité. Les clients de l’édition ASM verront tous les systèmes vulnérables de leurs domaines dans l’onglet « Vulnérabilités ».
- Pour les serveurs vulnérables :
category:vulnscan cve:cve-2025-53770 tag:vulnerable domain:example.com - Pour les serveurs compromis :
category:vulnscan cve:cve-2025-53770 tag:compromised domain:example.com
Comme toujours, si votre système est considéré comme vulnérable, vous devez appliquer un correctif dès que possible et effectuer des vérifications d’intégrité supplémentaires, comme la présence de nouveaux fichiers .aspx. Si votre système est considéré comme compromis, nous vous recommandons de le déconnecter du réseau (sans l’éteindre) et de contacter un service compétent en matière de réponse aux incidents de cybersécurité.
À propos de ONYPHE :
ONYPHE est une solution de gestion de la surface d’attaque, surveillant l’exposition des équipements vulnérables sur internet en analysant les adresses IP, les services accessibles, les URL et les indicateurs d’exploitation active.
Grâce à une collecte de données en temps réel sur plus de 370 millions de domaines et près de 500 millions d’adresses IP actives (IPv4 et IPv6 confondues), ONYPHE permet d’identifier les systèmes affectés, d’évaluer les risques portés par ces actifs et de suivre l’évolution des vulnérabilités exploitées.
Pour en savoir plus, découvrez-nous à l’adresse : https://www.onyphe.io/
- Nous n’appliquerons pas de procédure de bug bounty, alors facilitez-nous la tâche pour vous aider. Nous ne recherchons pas de récompense financière et nous ne souhaitons pas remplir de formulaires justifiant nos découvertes. Fournissez-nous une adresse e-mail et nous vous enverrons les détails, via PGP si vous préférez. Mieux encore, implémentez securitytxt, car nous les explorons également et disposons d’un inventaire de ces contacts. ↩︎
