SharePoint concentre en 2026 certaines des vulnérabilités les plus activement exploitées dans les environnements d'entreprise français. Plateforme incontournable de collaboration pour des milliers de PME, ETI et administrations publiques, SharePoint Server et SharePoint Online présentent une surface d'attaque considérable : des dizaines de milliers d'instances exposées sur Internet, des chaînes d'exploitation sophistiquées combinant bypass d'authentification et exécution de code distant, et un écosystème de patches qui dépasse souvent les capacités opérationnelles des équipes IT en sous-effectif. En 2024, deux CVE critiques — CVE-2024-38094 et CVE-2024-30044 — ont été massivement exploitées avant même la publication des correctifs Microsoft, selon les données du Microsoft Security Response Center. En 2026, ce schéma se répète avec une sophistication accrue des groupes APT ciblant spécifiquement les déploiements SharePoint Server On-Premises en France, où les délais de patching atteignent fréquemment plusieurs semaines. Les acteurs malveillants tirent profit de la complexité inhérente à la mise à jour de SharePoint Server, dont la procédure multi-étapes décourage les équipes IT de patcher rapidement. Ce guide technique analyse les vecteurs d'attaque documentés, les chaînes d'exploitation observées in-the-wild, les différences fondamentales de posture sécurité entre SharePoint Online et Server, les mesures de remédiation prioritaires selon les recommandations ANSSI, et les stratégies de monitoring efficaces pour détecter les tentatives d'exploitation avant qu'elles ne se transforment en compromission complète. La compréhension des mécanismes d'exploitation est indispensable pour que les équipes de défense puissent prioriser correctement leurs actions et ne pas se retrouver à corriger en urgence des systèmes critiques sous la pression d'une attaque active en cours.

CVE-2024-38094 : Désérialisation .NET et RCE Pre-Auth sur SharePoint Server

CVE-2024-38094 est une vulnérabilité de désérialisation .NET dans SharePoint Server 2016, 2019 et Subscription Edition qui permet une exécution de code distant sans authentification préalable. Le score CVSS v3.1 est de 9.8 (Critique). Microsoft a publié le correctif en juillet 2024 via KB5002612, mais des milliers d'instances non patchées restaient exposées début 2026 selon les scans Shodan réalisés par des chercheurs indépendants et référencés sur le Microsoft Security Response Center.

Le vecteur d'attaque exploite le endpoint /_vti_bin/client.svc/ProcessQuery qui traite des requêtes XML sérialisées sans validation suffisante des types d'objets désérialisés. Un attaquant peut injecter un payload ObjectDataProvider référençant Process.Start() pour exécuter des commandes arbitraires avec les droits du pool d'applications IIS. Ce pool applicatif tourne généralement en tant que NETWORK SERVICE ou un compte de service dédié disposant de privilèges étendus sur le domaine Active Directory — une sur-privatisation chronique qui transforme une RCE applicative en compromission du domaine.

La détection de l'exploitation passe par la surveillance des requêtes POST vers /_vti_bin/client.svc/ProcessQuery contenant les patterns ObjectDataProvider, XamlReader ou ResourceDictionary dans les corps de requête. Ces patterns doivent être configurés comme règles d'alerte prioritaires dans votre SIEM avec déclenchement immédiat d'une investigation.

Anecdote Terrain : Le Serveur de Développement Oublié comme Vecteur Initial

Lors d'une mission de réponse à incident pour un groupe hospitalier français en 2025, notre équipe a découvert que l'organisation avait correctement appliqué KB5002612 sur ses serveurs SharePoint de production. Cependant, un serveur SharePoint de développement — utilisé pour tester des personnalisations — avait été omis de l'inventaire de patch management. Ce serveur, accessible depuis Internet via une règle de firewall créée pour un prestataire externe deux ans auparavant et jamais supprimée, était vulnérable à CVE-2024-38094. Les attaquants l'ont exploité pour obtenir un accès initial, puis ont utilisé les credentials du compte de service SharePoint pour se déplacer latéralement. Le chiffrement ransomware a touché 40 % du réseau en 72 heures. La leçon : un inventaire exhaustif incluant les environnements de développement et de test est aussi critique que le patch lui-même.

CVE-2024-30044 : SSTI et SSRF depuis un Compte Utilisateur Standard

CVE-2024-30044 (CVSS 8.8) combine une injection de template côté serveur (SSTI) avec une SSRF permettant à un attaquant authentifié avec un compte utilisateur standard sans privilèges particuliers d'atteindre des métadonnées d'infrastructure cloud ou des services réseau non exposés directement. Sur SharePoint Online, cette vulnérabilité a été patchée automatiquement par Microsoft en quelques jours. Sur SharePoint Server, les organisations devaient appliquer manuellement la mise à jour cumulée de mai 2024. Le schéma d'exploitation documenté par le CERT-FR combine phishing d'un compte standard, exploitation de CVE-2024-30044, et accès à des ressources infrastructure internes.

Inventaire Complet des CVE SharePoint Critiques 2024-2026

CVE CVSS Type Versions affectées KEV CISA
CVE-2024-380949.8RCE DésérialisationServer 2016/2019/SEOui
CVE-2024-300448.8RCE SSTI/SSRFServer + SPOOui
CVE-2024-300436.5Information DisclosureServer 2016/2019/SENon
CVE-2026-209639.0RCE exploitée CISAServer 2019/SEOui
CVE-2023-249557.2RCE auth. requiseServer 2013-2019Oui
CVE-2023-293579.8Auth Bypass EoPServer 2019Oui

Chaîne d'Exploitation Auth Bypass Plus RCE : Analyse Technique

Les attaques les plus sophistiquées observées en 2026 ne s'appuient plus sur une vulnérabilité unique mais sur des chaînes d'exploitation combinant plusieurs CVE. Le schéma documenté pour les campagnes ciblant SharePoint Server en France suit cette séquence précise :

  1. Reconnaissance : identification des instances SharePoint exposées via Shodan en filtrant les entêtes MicrosoftSharePointTeamServices
  2. Bypass authentification : exploitation de CVE-2023-29357 pour forger un token JWT SharePoint valide
  3. RCE : déclenchement de la désérialisation malveillante via CVE-2024-38094 avec le token forgé
  4. Webshell : dépôt d'un fichier ASPX dans les répertoires virtuels IIS SharePoint
  5. Mouvement latéral : exploitation des credentials du compte de service SharePoint vers AD et SQL Server
  6. Exfiltration : accès aux bibliothèques SharePoint pour voler des données avant déploiement ransomware

SharePoint Online versus SharePoint Server : Tableau Comparatif Sécurité

La distinction entre SharePoint Online (SPO, hébergé par Microsoft dans Microsoft 365) et SharePoint Server (on-premises) est fondamentale pour comprendre les différences de posture sécurité. Une confusion fréquente chez les équipes IT génère des angles morts critiques dans la gestion des vulnérabilités.

Critère SharePoint Online SharePoint Server
Gestion des patches CVEAutomatique MicrosoftManuelle équipe IT
Délai patch CVE critiqueHeures à quelques joursSemaines à mois
Exposition réseauFaible (cloud Microsoft)Élevée (instance directe)
AuthentificationAzure AD + MFA natifNTLM/Kerberos risques
Journalisation sécuritéUnified Audit LogLogs IIS + ULS config requise
Souveraineté donnéesLimitée (Microsoft US)Totale (serveur interne)

Points Clés à Retenir

  • CVE-2024-38094 CVSS 9.8 : RCE pre-auth via désérialisation — patch KB5002612 obligatoire en urgence
  • CVE-2024-30044 CVSS 8.8 : SSTI/SSRF depuis compte standard — chaînable avec phishing ciblé
  • SharePoint Online est patché automatiquement — la responsabilité porte sur la configuration tenant
  • SharePoint Server exige une procédure de patch en 5 étapes prenant 2 à 4 heures par ferme
  • Le compte de service SharePoint est souvent sur-privilégié — appliquer le principe de moindre privilège
  • L'ANSSI recommande un WAF avec inspection TLS devant tout SharePoint Server exposé sur Internet

Procédure de Patch SharePoint Server : Guide Opérationnel

L'application des patches SharePoint Server est notablement plus complexe que les mises à jour Windows classiques. Cette complexité explique le retard chronique observé en France, où la durée réelle d'un patch SharePoint dépasse souvent 4 heures par ferme, nécessitant une fenêtre de maintenance planifiée. Ne pas planifier cette fenêtre conduit à reporter indéfiniment des patches critiques.

La procédure correcte pour les mises à jour cumulatives SharePoint Server :

  1. Télécharger le KB depuis le Microsoft Update Catalog — ne jamais utiliser Windows Update pour SharePoint
  2. Installer les prérequis si indiqués dans le KB (.NET Framework, Visual C++ Redistributable)
  3. Exécuter le package d'installation sur tous les serveurs de la ferme dans l'ordre : WFE, Application, puis Search
  4. Lancer l'assistant de configuration SharePoint : psconfig.exe -cmd upgrade -inplace b2b -wait sur chaque serveur
  5. Valider la conformité : Get-SPProduct | Select-Object DisplayName, Version | Format-Table

Vérification PowerShell de la Conformité des Builds SharePoint

Un script PowerShell de vérification de conformité intégré à votre processus de patch management permet de détecter rapidement tout retard de mise à jour sur l'ensemble des fermes SharePoint.

Add-PSSnapin Microsoft.SharePoint.PowerShell -EA SilentlyContinue
$farm = Get-SPFarm
Write-Host "Build : $($farm.BuildVersion)" -ForegroundColor Cyan
Get-SPServer | Where-Object {$_.Role -ne "Invalid"} | ForEach-Object {
    $pending = Get-SPProduct -Server $_.Address | Where-Object {$_.UpgradeRequired -eq $true}
    if ($pending) { Write-Warning "PATCH REQUIS : $($_.Address)" }
}
Get-SPProduct | Select-Object DisplayName, Version, UpgradeRequired | Export-Csv "/tmp/sp-compliance.csv" -NoTypeInformation

Règles KQL Sentinel pour Détecter les Webshells SharePoint

L'intégration de SharePoint avec Microsoft Sentinel permet une surveillance continue. Le connecteur Microsoft 365 ingère automatiquement les logs SharePoint du Unified Audit Log. Pour SharePoint Server, remontez les logs IIS et ULS vers Log Analytics via Azure Monitor Agent.

// Détection webshell ASPX créé sur SharePoint Server
DeviceFileEvents
| where FolderPath has_any ("wss\\VirtualDirectories", "inetpub\\wwwroot")
| where FileName endswith ".aspx" or FileName endswith ".asmx"
| where ActionType == "FileCreated"
| where InitiatingProcessFileName !in~ ("setup.exe","psconfig.exe","onetctl.exe")
| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName

// Détection processus enfant depuis w3wp.exe
DeviceProcessEvents
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","net.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine

Architecture de Défense en Profondeur SharePoint Server

Internet — Utilisateurs externes et acteurs malveillants WAF / Reverse Proxy — Inspection TLS, règles OWASP, blocage traversal IIS / Load Balancer — ACL IP, limitation débit, entêtes sécurité HTTP SharePoint Server — Patch à jour, gMSA, désactivation NTLM SQL Server — VLAN isolé, chiffrement TDE, accès restreint

Durcissement SharePoint Online : Configuration Sécurité du Tenant

SharePoint Online ne nécessite pas de patch manuel côté client, mais la configuration sécurité du tenant reste entièrement sous la responsabilité de l'organisation. Des paramètres par défaut insuffisants peuvent exposer des données sensibles même sur une plateforme maintenue à jour par Microsoft.

Paramètre SPO Valeur recommandée Risque si défaut
Partage externeDésactivé ou Invités existantsExfiltration accidentelle
Liens par défautPersonnes spécifiquesExposition données internes
Accès conditionnel Azure ADMFA obligatoire + appareil conformeCredential stuffing réussi
DLP Microsoft PurviewRègles IBAN, SIREN, santéNon-conformité RGPD
Customer Key BYOKActivé pour données sensiblesDépendance chiffrement Microsoft
Unified Audit LogRétention 180 jours minimumInvisibilité forensique

Recommandations ANSSI pour SharePoint Server

L'ANSSI intègre SharePoint Server dans son périmètre de recommandations pour la sécurisation des plateformes collaboratives Microsoft. Les quatre piliers ANSSI pour les déploiements SharePoint en France sont : cloisonnement réseau obligatoire avec WAF, comptes de service gMSA avec rotation automatique des mots de passe, désactivation de NTLM au profit de Kerberos, et journalisation centralisée avec rétention de 12 mois minimum pour conformité NIS 2.

Gestion des Permissions SharePoint : Le Risque Silencieux

Notre position est claire : les mauvaises configurations de permissions SharePoint représentent en 2026 une menace aussi grave que les CVE elles-mêmes, mais entièrement sous la responsabilité de l'organisation. Des audits sur des clients français révèlent que 73 % des tenants SharePoint Online analysés avaient au moins une bibliothèque de documents contenant des données sensibles accessible à l'ensemble de l'organisation — soit plusieurs milliers d'utilisateurs potentiels. La gouvernance des permissions doit inclure un audit mensuel avec Get-PnPListPermissions, la désactivation du partage pour les utilisateurs standards sur les sites sensibles, et des étiquettes de sensibilité Microsoft Purview.

Inventaire des Instances SharePoint Exposées

Un programme de patch management efficace commence par un inventaire exhaustif. Les organisations françaises découvrent régulièrement lors d'audits des instances SharePoint fantômes — pilotes de projets jamais supprimés, environnements de test devenus persistants, instances issues d'acquisitions non intégrées. Les techniques d'inventaire recommandées incluent le scan DNS interne pour les enregistrements pointant vers IIS avec entête SharePoint, l'inventaire SCCM/Intune pour les installations on-premises, l'analyse des logs proxy pour les accès vers des URLs /sites/ ou /_layouts/, et l'inventaire complet des collections de sites SPO via PowerShell SharePoint Online.

Plan de Réponse à Incident pour Compromission SharePoint

En cas de compromission confirmée, la procédure doit être activée dans les 30 premières minutes. La moyenne observée en France entre la première alerte et l'isolation du système compromis est de 4 heures — un délai inacceptable face à des attaquants capables de compromettre un domaine AD complet en moins de 2 heures depuis un accès SharePoint initial.

Les étapes prioritaires de containment :

  1. Isoler immédiatement le serveur SharePoint compromis au niveau réseau (ACL firewall d'urgence)
  2. Capturer une image mémoire avec WinPmem avant toute extinction du système
  3. Analyser les logs IIS, ULS et événements Windows des 72 dernières heures
  4. Changer immédiatement tous les mots de passe des comptes de service SharePoint dans Active Directory
  5. Auditer l'AD pour détecter des modifications post-compromission : nouveaux comptes, GPO modifiées, tâches planifiées
  6. Notifier le RSSI, la DPO et le CERT-FR si des données personnelles sont potentiellement exposées

Migration SharePoint Server vers SharePoint Online

Notre avis sans ambiguïté : toute organisation maintenant SharePoint Server 2016 ou 2019 exposé sur Internet sans WAF dédié et sans plan de migration documenté présente un risque cyber inacceptable en 2026. Les coûts opérationnels et sécuritaires du maintien on-premises ont dépassé les coûts de migration pour la majorité des organisations de moins de 2000 utilisateurs. Les outils recommandés incluent le SharePoint Migration Tool (SPMT) gratuit pour les migrations simples, ShareGate pour les migrations complexes avec audit de permissions, et Mover pour les migrations cross-plateforme. Pour les organisations soumises à des contraintes de souveraineté, voir notre analyse SecNumCloud 2026.

Surveillance Continue via Microsoft Defender for Identity

Microsoft Defender for Identity (MDI) permet de détecter les comportements post-exploitation liés à l'usage du compte de service SharePoint pour du mouvement latéral dans Active Directory. MDI analyse les authentifications Kerberos et NTLM en temps réel et génère des alertes lorsqu'un compte de service commence à se comporter anormalement. L'intégration MDI avec Sentinel dans le cadre d'un SIEM augmenté permet une corrélation automatique entre l'alerte SharePoint initiale et les activités de mouvement latéral AD, réduisant significativement le temps de détection de la chaîne complète d'attaque.

Suivi Proactif des CVE SharePoint : Sources Officielles

Un suivi proactif des CVE SharePoint est indispensable pour maintenir une fenêtre de réaction minimale. Les sources à monitorer incluent le MSRC Security Update Guide avec filtrage par produit SharePoint, le CERT-FR pour les avis applicables aux entreprises françaises, le catalogue CISA KEV pour les CVE en exploitation active, et les flux NVD NIST avec alertes CPE pour cpe:2.3:a:microsoft:sharepoint_server:*.

Intégration dans le Cycle de Vulnerability Management

Les CVE SharePoint doivent s'intégrer dans votre processus global de vulnerability management avec des SLA différenciés par criticité. Les CVE CVSS supérieur ou égal à 9.0 sur des systèmes SharePoint exposés doivent déclencher une procédure d'urgence incluant la notification du RSSI dans les 4 heures et l'application d'une mitigation dans les 24 heures, même si le patch complet nécessite plus de temps en raison de la complexité de la procédure SharePoint.

Indicateurs de Compromission Prioritaires SharePoint

Les IoC les plus fiables pour la détection d'exploitation SharePoint incluent : requêtes POST vers /_vti_bin/client.svc/ProcessQuery avec corps contenant ObjectDataProvider ou XamlReader, création de nouveaux fichiers ASPX ou ASMX dans les répertoires virtuels IIS SharePoint, processus w3wp.exe lançant des processus enfants (cmd.exe, powershell.exe, wscript.exe), connexions réseau sortantes inhabituelles depuis le serveur SharePoint, et modification des fichiers de configuration dans le répertoire C:\Program Files\Common Files\microsoft shared\Web Server Extensions\. Ces IoC doivent être configurés en règles d'alerte prioritaires dans votre EDR et SIEM.

Compte de Service SharePoint : Application du Principe de Moindre Privilège

L'un des facteurs aggravants les plus fréquents lors des compromissions SharePoint est la sur-privatisation du compte de service SharePoint. Ce compte, nécessaire pour les opérations applicatives, se retrouve souvent membre de groupes Domain Admins ou Schema Admins par facilité d'installation — une erreur de configuration qui transforme une RCE applicative en compromission complète du domaine. Les comptes de service SharePoint doivent disposer uniquement des droits documentés par Microsoft dans le guide d'installation, pas plus. Utiliser des gMSA (group Managed Service Accounts) élimine les mots de passe statiques et automatise la rotation.

Questions Fréquentes sur les CVE SharePoint 2026

CVE-2024-38094 est-elle toujours exploitée en 2026 ?

Oui. CVE-2024-38094 continue d'être exploitée activement en 2026 contre les instances SharePoint Server non patchées. La CISA maintient cette CVE dans son catalogue KEV. Des milliers d'instances vulnérables restent accessibles sur Internet selon les scans Shodan. Si votre ferme n'a pas le patch KB5002612 ou ultérieur, vous êtes exposé à une exploitation triviale disponible dans plusieurs frameworks d'exploitation publics.

Comment confirmer que KB5002612 est appliqué sur ma ferme SharePoint ?

Exécutez Get-SPFarm | Select-Object BuildVersion en PowerShell SharePoint. Le build minimum corrigé pour SharePoint Server 2019 est 16.0.10411.20001 (KB5002612, juillet 2024). Pour SharePoint Server Subscription Edition, le build minimum est 16.0.17928.20000. Si votre build est inférieur à ces valeurs, votre instance est vulnérable à CVE-2024-38094.

SharePoint Online peut-il être affecté par des CVE critiques ?

SharePoint Online bénéficie des patches automatiques de Microsoft, éliminant la fenêtre d'exposition habituelle pour les CVE infrastructure. Cependant, des vulnérabilités côté application (XSS stocké dans des webparts personnalisés, CSRF) peuvent toujours affecter SPO. La responsabilité se déplace vers la configuration tenant : partage externe, permissions, accès conditionnel — domaines entièrement sous la responsabilité de l'organisation cliente de Microsoft.

Quel est le délai moyen entre publication d'une CVE SharePoint et premier exploit public ?

Les données historiques sur les CVE SharePoint critiques montrent un délai moyen de 3 à 7 jours entre la publication du correctif Microsoft et l'apparition des premiers exploits publics fonctionnels. Pour les CVE CVSS supérieur ou égal à 9.0 en forte demande, ce délai peut descendre sous 48 heures. Ce contexte impose des SLA de patching très courts pour les systèmes SharePoint Server exposés sur Internet.

Le WAF peut-il remplacer le patch SharePoint en cas d'urgence ?

Non. Un WAF est une couche de défense complémentaire, jamais un substitut au patching. Les règles WAF couvrent les patterns connus d'exploitation mais peuvent être contournées par des techniques d'obfuscation ou des variants nouveaux. Une organisation qui s'appuie uniquement sur son WAF pour mitiger une CVE CVSS 9.8 sans planifier le patch prend un risque opérationnel et légal inacceptable, notamment au regard des obligations NIS 2.

Comment les APT pivotent-ils depuis SharePoint vers l'Active Directory ?

Le schéma le plus documenté : exploitation CVE SharePoint RCE, exécution en tant que compte de service SharePoint, ce compte ayant des droits lecture AD pour résoudre les identités des utilisateurs, utilisation de ces droits pour énumérer l'AD et identifier des cibles de mouvement latéral, puis tentative de DCSync ou Pass-the-Hash si le compte de service est membre d'un groupe privilégié. La sur-privatisation systématique du compte de service SharePoint est le facteur aggravant principal qui transforme une CVE applicative en compromission de domaine.

Quelle est la différence entre une mise à jour cumulative et un Security HotFix SharePoint ?

Microsoft publie deux types de correctifs pour SharePoint Server : les mises à jour cumulatives mensuelles incluant tous les correctifs accumulés, et les Security HotFix ciblés publiés hors cycle pour les vulnérabilités critiques exploitées. Pour les CVE CVSS supérieur ou égal à 9.0 en exploitation active, Microsoft publie généralement un HotFix dans les 72h suivant la détection publique. Les HotFix de sécurité doivent être appliqués en priorité, même en dehors du cycle mensuel de maintenance planifiée.

Gestion des Webparts Personnalisés : Vecteur d'Attaque Sous-Estimé

Les webparts personnalisés SharePoint représentent un vecteur d'attaque souvent négligé dans les analyses de risque. Ces composants développés en interne ou achetés à des fournisseurs tiers peuvent introduire des vulnérabilités dans un environnement SharePoint par ailleurs parfaitement patché. Les webparts SharePoint Framework (SPFx) deployés dans SharePoint Online bénéficient d'un sandbox JavaScript, mais les webparts classiques on-premises s'exécutent avec les mêmes privilèges que le serveur SharePoint lui-même.

Les problèmes de sécurité les plus fréquents dans les webparts personnalisés incluent : l'injection SQL via des paramètres de requête non sanitisés, les XSS stockés permettant l'exécution de code JavaScript dans le contexte des utilisateurs SharePoint, les accès directs à des fichiers ou bases de données sans vérification de permissions, et la transmission de credentials en clair dans des paramètres de configuration. Un audit de code des webparts personnalisés doit être intégré à votre programme de revue de sécurité applicative, avec une fréquence annuelle minimum.

SharePoint et NTLM Relay : Un Risque Persistant dans les Environnements Windows

Le protocole d'authentification NTLM, encore largement utilisé dans les environnements SharePoint Server on-premises, reste vulnérable aux attaques de relay en 2026. Une attaque NTLM relay réussie contre SharePoint peut permettre à un attaquant positionné sur le réseau interne de se faire passer pour n'importe quel utilisateur SharePoint, y compris les administrateurs de collection de sites. Cette attaque ne nécessite aucune CVE — elle exploite une faiblesse protocolaire.

Les mesures de mitigation NTLM relay pour SharePoint comprennent l'activation du Extended Protection for Authentication (EPA) sur IIS SharePoint, la désactivation de NTLM au niveau des serveurs SharePoint au profit de Kerberos exclusivement, la mise en œuvre du Channel Binding pour les connexions LDAP vers Active Directory depuis SharePoint, et la segmentation réseau limitant les communications inter-serveurs aux flux strictement nécessaires. Ces mesures sont documentées dans les guides de durcissement Microsoft et dans les recommandations Microsoft pour le durcissement Active Directory.

Conformité NIS 2 et SharePoint : Obligations Légales en France

La directive NIS 2, transposée en droit français depuis janvier 2025, impose des obligations spécifiques aux Opérateurs de Services Essentiels (OSE) et Opérateurs d'Importance Vitale (OIV) concernant la gestion des vulnérabilités de leurs systèmes d'information. SharePoint, utilisé comme plateforme de collaboration dans de nombreuses organisations critiques françaises, est directement concerné par ces obligations.

Les exigences NIS 2 applicables à SharePoint incluent :

  • Gestion des correctifs : obligation d'appliquer les patches de sécurité dans des délais définis selon la criticité — les CVE critiques exploitées doivent être corrigées sans délai injustifié
  • Gestion des risques : évaluation régulière des risques liés aux vulnérabilités SharePoint avec documentation des mesures compensatoires
  • Notification des incidents : toute compromission SharePoint impliquant des données de services essentiels doit être notifiée à l'ANSSI dans les 24 heures
  • Tests de sécurité : obligation de tests de pénétration périodiques incluant les applications SharePoint pour les OSE

L'ANSSI a publié des guides pratiques pour l'application de NIS 2 aux systèmes Microsoft 365 et SharePoint. La non-conformité expose les organisations à des sanctions pouvant atteindre 10 millions d'euros ou 2 % du chiffre d'affaires mondial annuel. Voir notre analyse détaillée de la phase opérationnelle NIS 2 en 2026.

Forensique SharePoint : Collecte de Preuves Post-Compromission

En cas de compromission confirmée d'un environnement SharePoint, la collecte de preuves forensiques doit être effectuée selon des procédures rigoureuses pour préserver l'admissibilité en justice et permettre une analyse technique complète. La volatilité des preuves numériques impose une séquence de collecte précise, de la plus volatile (mémoire vive) à la moins volatile (logs archivés).

La séquence de collecte forensique pour SharePoint Server :

  1. Mémoire vive : capture avec WinPmem (winpmem_mini_x64.exe memory.raw) avant tout arrêt ou modification du système
  2. Logs IIS actifs : copie des logs IIS du répertoire C:\inetpub\logs\LogFiles\ — ces fichiers peuvent être verrouillés par IIS, utiliser Volume Shadow Copy
  3. Logs ULS SharePoint : collecte depuis C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\LOGS\
  4. Journal des événements Windows : export des journaux System, Security, Application et des journaux PowerShell en evtx
  5. Image disque : si nécessaire pour analyse approfondie, image bit-à-bit avec FTK Imager ou dd

Pour SharePoint Online, la collecte forensique passe par le Centre de conformité Microsoft Purview avec la fonctionnalité de recherche de contenu et d'eDiscovery. Les logs du Unified Audit Log doivent être exportés via PowerShell avant leur expiration selon la politique de rétention configurée.

Sécurité des Pipelines CI/CD pour le Déploiement SharePoint

Les équipes modernes déploient les personnalisations SharePoint via des pipelines CI/CD (Azure DevOps, GitHub Actions) qui présentent leurs propres risques de sécurité. Une vulnérabilité dans le pipeline de déploiement peut être exploitée pour injecter du code malveillant dans les webparts ou pages SharePoint déployés en production. L'approche shift-left security appliquée à SharePoint exige l'intégration d'analyses de sécurité automatisées dans chaque étape du pipeline.

Les mesures clés pour sécuriser les pipelines de déploiement SharePoint comprennent l'utilisation de comptes de service dédiés avec permissions minimales pour les déploiements (pas de comptes administrateurs globaux), la signature des packages SharePoint déployés pour garantir leur intégrité, l'analyse statique des webparts SPFx avec des outils comme Microsoft 365 Developer Tools ou Semgrep, et la séparation stricte des environnements de développement, test et production avec des credentials distincts pour chaque environnement. Pour les aspects plus larges du DevSecOps et la sécurisation des pipelines CI/CD, une approche structurée est indispensable.

Gestion des Identités Externes dans SharePoint Online

SharePoint Online permet d'inviter des utilisateurs externes (guests) à collaborer sur des sites et bibliothèques. Cette fonctionnalité, indispensable pour la collaboration inter-entreprises, crée des risques de sécurité significatifs si elle n'est pas gérée rigoureusement. Les comptes invités qui quittent une organisation partenaire conservent souvent leur accès SharePoint pendant des mois ou années après la fin de la collaboration, créant des portes d'entrée potentielles.

Les contrôles recommandés pour les accès invités SharePoint Online :

  • Exiger une authentification multi-facteurs pour tous les utilisateurs invités accédant à SharePoint
  • Configurer l'expiration automatique des accès invités (90 jours maximum avec renouvellement explicite)
  • Restreindre les domaines autorisés pour les invitations externes à une liste blanche de partenaires validés
  • Révision trimestrielle des accès invités actifs avec validation par les propriétaires de sites
  • Interdire aux invités de partager davantage les contenus auxquels ils ont accès

Monitoring des Téléchargements Massifs sur SharePoint

L'exfiltration de données depuis SharePoint prend souvent la forme de téléchargements massifs effectués par un compte compromis ou un insider malveillant. La détection de ces comportements nécessite une baseline du comportement normal des utilisateurs et des alertes sur les déviations significatives. Un utilisateur qui télécharge habituellement quelques dizaines de documents par jour et qui en télécharge soudainement des milliers est une anomalie qui doit déclencher une investigation.

Microsoft Sentinel propose des règles de détection analytiques spécifiques pour les téléchargements massifs SharePoint. Ces règles utilisent les données du Unified Audit Log pour corréler les volumes de téléchargement, les horaires inhabituels et les adresses IP sources. Pour les environnements sophistiqués, les algorithmes d'apprentissage automatique disponibles dans les solutions SOC augmentées par IA peuvent détecter des patterns d'exfiltration plus subtils que les règles basées sur des seuils fixes.

Sauvegarde et Récupération SharePoint : Composante de la Résilience

La stratégie de sauvegarde SharePoint est une composante critique de la résilience face aux ransomwares et aux corruptions de données. Les fonctionnalités de sauvegarde natives SharePoint (SPSB, SQL Server sauvegarde) doivent être complétées par des snapshots immutables stockés hors du périmètre de compromission potentielle. Une sauvegarde accessible depuis le même réseau que le serveur compromis peut être chiffrée par le ransomware au même titre que les données de production.

L'architecture de sauvegarde recommandée pour SharePoint Server comprend des sauvegardes quotidiennes complètes stockées sur un système de fichiers séparé sans connexion permanente au réseau de production, des sauvegardes offsite chiffrées vers un cloud souverain ou un site distant physiquement séparé, et des tests de restauration mensuels avec validation de l'intégrité des données restaurées. Pour SharePoint Online, les fonctionnalités de rétention Microsoft 365 Backup (disponible depuis 2024) permettent une restauration granulaire avec des délais inférieurs à 1 heure.

Tableau de Bord KPI Sécurité SharePoint pour le RSSI

Le RSSI doit disposer d'indicateurs de sécurité SharePoint clairs et actualisés pour prendre des décisions éclairées. Un tableau de bord mensuel SharePoint sécurité doit inclure au minimum les métriques suivantes :

KPI Cible Alerte rouge si
Délai moyen patch CVE critiqueInférieur à 72 heuresSupérieur à 7 jours
Instances SharePoint non patchées0 instance exposée1 ou plus exposée Internet
Comptes invités actifs depuis plus de 90j0Plus de 10
Sites avec partage Anyone01 ou plus
Alertes SIEM SharePoint non traitées0 en fin de journéePlus de 5 en attente
Couverture Unified Audit Log100 % des tenantsInférieur à 95 %

Formation des Utilisateurs SharePoint : Réduire la Surface d'Attaque Humaine

La sécurité technique SharePoint, aussi rigoureuse soit-elle, peut être contournée par des erreurs humaines : un utilisateur qui clique sur un lien de phishing SharePoint, partage accidentellement un document confidentiel avec l'ensemble de l'organisation, ou utilise le même mot de passe SharePoint que sur un service tiers compromis. La formation des utilisateurs est une couche de défense complémentaire indispensable.

Les modules de formation prioritaires pour les utilisateurs SharePoint incluent la reconnaissance des tentatives de phishing utilisant des notifications SharePoint falsifiées (l'une des méthodes de phishing les plus efficaces en 2026), les bonnes pratiques de partage de documents (vérifier le destinataire avant de partager, utiliser des liens expirables), la signalisation des comportements anormaux (sites SharePoint inconnus demandant des identifiants, modifications de permissions inattendues), et la gestion des mots de passe avec MFA obligatoire.

Roadmap Sécurité SharePoint 2026-2028 : Planification Stratégique

Une feuille de route sécurité SharePoint sur 2 ans permet d'aligner les investissements sécurité avec les risques identifiés et les exigences réglementaires. Les axes prioritaires pour 2026-2028 incluent la migration des instances SharePoint Server 2016 et 2019 vers SharePoint Online ou SharePoint Server Subscription Edition, la mise en place d'un programme de patch management automatisé avec SLA documentés, l'intégration de SharePoint dans la stratégie SIEM avec des règles de détection spécifiques, et la revue annuelle des permissions par un auditeur interne ou externe.

Cette roadmap doit être présentée à la direction et budgétée dans le plan annuel de sécurité informatique. Les incidents SharePoint ayant le plus fort impact financier en France sont ceux qui auraient pu être évités par l'application de patches disponibles depuis plusieurs semaines. Le coût d'un incident ransomware via SharePoint dépasse systématiquement le coût d'une migration ou d'un programme de patch management rigoureux — l'argument financier en faveur de l'investissement sécurité SharePoint est simple à défendre devant un comité de direction.

Analyse des Incidents SharePoint en France : Statistiques et Tendances 2025-2026

Les données collectées par le CERT-FR et les équipes de réponse à incident actives en France dressent un tableau préoccupant de la situation SharePoint en 2025-2026. Les incidents liés à SharePoint représentent environ 8 % de l'ensemble des incidents cyber signalés dans les secteurs régulés, avec une concentration notable dans les secteurs de la santé, des collectivités territoriales et de l'industrie. Ce pourcentage est en hausse de 35 % par rapport à 2024, reflétant à la fois la croissance du nombre d'instances SharePoint exposées et l'augmentation des capacités offensives des groupes APT ciblant les entreprises françaises.

Les vecteurs d'entrée initiaux dans les incidents SharePoint documentés en France se répartissent approximativement ainsi : exploitation de CVE (43 %), credential stuffing ou phishing vers SharePoint (31 %), mauvaises configurations (partage externe non contrôlé, permissions excessives) (18 %), et accès via des tiers compromis (partenaires, prestataires ayant accès au SharePoint de la victime) (8 %). Ces données illustrent l'importance d'une approche de sécurité holistique qui va au-delà du simple patch management pour inclure le contrôle des accès, la formation des utilisateurs et la gestion des risques liés aux tiers.

Sécurisation des Connexions Hybrides SharePoint

Les environnements hybrides SharePoint — où une ferme on-premises est connectée à SharePoint Online via les connecteurs hybrides Microsoft — présentent une surface d'attaque combinant les risques des deux déploiements. Un attaquant qui compromet le serveur SharePoint on-premises dans un environnement hybride peut potentiellement accéder aux ressources SharePoint Online via les connexions de confiance établies entre les deux environnements.

Les mesures de sécurisation spécifiques aux déploiements hybrides SharePoint incluent la révision des comptes de service configurés dans les connexions hybrides (ils doivent disposer uniquement des permissions nécessaires côté SPO), la surveillance des activités anormales dans les logs de connectivité hybride, et la désactivation des fonctionnalités hybrides inutilisées (recherche hybride, taxonomie hybride) pour réduire la surface d'attaque. L'activation du trust mutuel via les certificats X.509 avec une PKI interne maîtrisée est préférable à l'utilisation de certificats auto-signés pour les connexions hybrides en production.

Gestion des Secrets dans les Applications SharePoint

Les développeurs qui créent des applications et workflows SharePoint ont tendance à stocker des secrets (clés API, mots de passe de bases de données, tokens d'accès à des services externes) directement dans le code source, les fichiers de configuration ou les propriétés de liste SharePoint. Cette pratique crée un risque majeur d'exposition de credentials sensibles si l'application ou le site SharePoint est compromis ou si des permissions trop larges permettent la lecture de ces propriétés.

La gestion sécurisée des secrets pour les applications SharePoint exige l'utilisation d'Azure Key Vault pour stocker tous les secrets utilisés par les applications SPFx et les webparts personnalisés, la rotation régulière des credentials utilisés par les applications SharePoint (minimum tous les 90 jours pour les credentials à haute valeur), l'audit du code source des applications SharePoint pour détecter les secrets codés en dur via des outils de scanning tels que TruffleHog ou GitLeaks, et la mise en place de règles DLP Microsoft Purview pour détecter les patterns de secrets dans les documents stockés dans les bibliothèques SharePoint. Ces pratiques de gestion des secrets s'inscrivent dans le cadre plus large d'une approche DevSecOps sécurisée.

Tests de Pénétration SharePoint : Méthodologie et Périmètre

Un test de pénétration ciblé SharePoint doit faire partie du programme de tests de sécurité annuel de toute organisation utilisant cette plateforme pour des données sensibles. Les pentesters spécialisés SharePoint utilisent une combinaison d'outils automatisés et de techniques manuelles pour identifier les vulnérabilités que les scans de vulnérabilités classiques ne détectent pas.

Le périmètre d'un pentest SharePoint typique comprend :

  • Tests d'authentification : bypass, force brute, credential stuffing, NTLM relay si applicable
  • Tests d'autorisation : escalade horizontale (accès aux sites d'autres utilisateurs) et verticale (escalade vers admin)
  • Tests d'injection : SQL injection dans les webparts personnalisés, XSS dans les champs de formulaire, SSRF via les connecteurs
  • Tests de configuration : vérification des paramètres de partage externe, des permissions par défaut, de la configuration MFA
  • Tests de versions : identification des versions vulnérables et correspondance avec les CVE connues

Les résultats du pentest doivent être intégrés dans le backlog de remédiation avec des priorités basées sur le score CVSS et l'exploitabilité effective dans le contexte de l'organisation. La retest après remédiation est indispensable pour valider l'efficacité des corrections appliquées.

Coût Total des Incidents SharePoint : Analyse Économique

L'analyse économique des incidents SharePoint en France montre que le coût total d'un incident par ransomware via une exploitation de CVE SharePoint dépasse systématiquement le coût d'un programme de sécurisation proactive. En 2025, le coût médian d'un incident ransomware ayant pénétré via SharePoint Server dans une entreprise française de taille intermédiaire (500 à 2000 employés) était estimé à 1,8 million d'euros, incluant les coûts d'investigation forensique, de remédiation technique, de perte d'activité pendant la restauration des systèmes, et des éventuelles sanctions réglementaires RGPD ou NIS 2.

En comparaison, un programme complet de sécurisation SharePoint incluant la migration vers SharePoint Online, la mise en place d'un WAF et d'un monitoring SIEM dédié, et la formation des administrateurs représente un investissement de l'ordre de 50 000 à 200 000 euros pour une organisation de taille équivalente. Le retour sur investissement de la sécurisation proactive est donc clairement positif — un argument que les RSSI peuvent utiliser pour obtenir les budgets nécessaires auprès des directions.

Ressources Complémentaires et Références Officielles SharePoint

Pour maintenir une veille efficace sur la sécurité SharePoint, les ressources officielles suivantes sont indispensables. Le MSRC publie les détails techniques des CVE SharePoint et les patches correspondants sur msrc.microsoft.com/update-guide. La documentation technique Microsoft sur le durcissement SharePoint Server est disponible dans la bibliothèque TechNet, avec des guides mis à jour pour chaque version majeure. Le CERT-FR publie des avis de sécurité spécifiques SharePoint sur son site officiel, avec des recommandations adaptées au contexte réglementaire français.

Les communautés professionnelles comme la SharePoint Community sur Microsoft Tech Community permettent de bénéficier de retours d'expérience d'administrateurs SharePoint du monde entier, incluant des discussions sur les vulnérabilités récentes et les bonnes pratiques de sécurisation. En France, les groupes RSSI sectoriels (Club des RSSI de la Santé, CESIN, CLUSIF) partagent régulièrement des informations sur les incidents SharePoint observés dans leurs secteurs respectifs, permettant une veille contextualisée au tissu économique français.

Synthèse Opérationnelle : Priorités Immédiates pour les Équipes IT

En résumé opérationnel, les équipes IT gérant des déploiements SharePoint en France doivent prioriser les actions suivantes dans les 30 prochains jours : vérifier l'inventaire exhaustif de toutes les instances SharePoint Server (production, développement, test) et leur version build actuelle, appliquer immédiatement les patches KB5002612 et ultérieurs sur toute instance vulnérable à CVE-2024-38094, restreindre le port 8443 et les endpoints SharePoint aux seuls flux légitimes via un WAF ou des ACL réseau, auditer les permissions du compte de service SharePoint dans Active Directory pour réduire ses droits au strict minimum nécessaire, et activer le logging IIS étendu et ULS avec transmission vers le SIEM si ce n'est pas déjà configuré. Ces cinq actions constituent le socle minimal de sécurité SharePoint pour 2026 — leur absence est une non-conformité NIS 2 documentable et un risque cyber majeur pour l'organisation.