Comment auditer la securite de votre serveur SharePoint en 7 etapes

En 2026, SharePoint Server est le logiciel de collaboration le plus cible par les attaquants. La CVE-2026-45659 (RCE, CVSS 8.8) ajoutee au catalogue KEV de la CISA debut juillet n'est que la derniere d'une serie de vulnerabilites critiques exploitees depuis le debut de l'annee. Pourtant, la majorite des entreprises francaises n'ont jamais conduit un audit de securite structure de leurs instances SharePoint. Ce guide comble cette lacune avec une methodologie en 7 etapes, calibree pour les equipes qui n'ont ni le temps ni le budget d'un audit de six mois.

— Etape 1 : Inventaire exhaustif des instances SharePoint

Tout audit commence par un inventaire. L'objectif est d'identifier toutes les instances SharePoint de votre organisation — pas seulement celles que l'equipe infrastructure connait. Les farms de test oubliees, les instances de developpement, les serveurs de pre-production non decommissionnes : chacun de ces systemes constitue un point d'entree potentiel pour un attaquant.

Concretement, vous devez recenser : le nombre de serveurs physiques ou virtuels, la version exacte de SharePoint (2016, 2019, Subscription Edition), le niveau de cumulative update (CU) installe, les WebApps configurees et leurs URLs, les bases de donnees de contenu et leur taille, et les methodes d'acces (interne, VPN, exposition directe Internet). Utilisez un scan Nmap sur les ports 80, 443, 32843-32845 combines a des requetes DNS internes pour decouvrir les instances non documentees.

# Scan reseau pour identifier les instances SharePoint
nmap -sV -p 80,443,32843,32844,32845 192.168.1.0/24 --open -oN sharepoint-scan.txt

# PowerShell : lister les farms et serveurs
Get-SPFarm | Select-Object BuildVersion, Name
Get-SPServer | Select-Object Name, Role, Status

# Lister toutes les WebApps et leur URL
Get-SPWebApplication | Select-Object DisplayName, Url, ContentDatabases

Livrable attendu : une cartographie complete avec la liste de toutes les instances, leurs versions, leur exposition reseau et les donnees sensibles qu'elles hebergent. Ce document devient la reference pour toutes les etapes suivantes.

— Etape 2 : Analyse du niveau de patching et des vulnerabilites connues

Une fois l'inventaire etabli, comparez chaque instance au catalogue des cumulative updates Microsoft. L'objectif est de determiner le delta entre votre version actuelle et la derniere CU disponible, et d'identifier les CVE non corrigees auxquelles vous etes expose. En juillet 2026, les CVE SharePoint critiques a verifier en priorite sont : CVE-2026-45659 (RCE, CVSS 8.8), CVE-2026-32201 (Spoofing, CVSS 6.5), CVE-2026-38094 (EoP, CVSS 7.2) et CVE-2026-41289 (Information Disclosure, CVSS 5.3).

Completez l'analyse avec un scan de vulnerabilites automatise. Nessus, Qualys ou OpenVAS identifient les failles de l'OS, d'IIS, du .NET Framework et des composants tiers installes sur les serveurs SharePoint. Ne vous limitez pas au scan SharePoint : un serveur mal patche au niveau OS offre autant de surface d'attaque que SharePoint lui-meme.

# PowerShell : verifier la version exacte de SharePoint
(Get-SPFarm).BuildVersion

# Comparer avec le dernier build connu (juillet 2026)
# SharePoint SE: 16.0.XXXXX.XXXXX
# SharePoint 2019: 16.0.10409.XXXXX
# SharePoint 2016: 16.0.5465.XXXXX

# Lister les KB installees sur le serveur
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20

— Etape 3 : Audit des permissions et des acces

Les permissions SharePoint sont notoirement complexes. L'heritage des permissions, les liens de partage directs, les groupes imbriques et les permissions personnalisees creent un enchevetrement que les administrateurs ne maitrisent souvent plus. L'objectif de cette etape est de repondre a une question simple : qui a acces a quoi, et est-ce justifie ?

Les points de controle essentiels sont : les administrateurs de farm (doivent etre limites a 2-3 personnes nommees), les administrateurs de site collection (revue trimestrielle obligatoire), les permissions rompues (heritage casse sur des sous-sites ou listes), les liens de partage anonymes (doivent etre desactives sauf besoin expresse), et les comptes de service (ne doivent jamais avoir des droits administrateurs).

# Lister les admins de la farm
Get-SPShellAdmin

# Lister les admins de chaque site collection
Get-SPSite -Limit All | ForEach-Object {
  Write-Host $_.Url "-" $_.Owner.LoginName "-" $_.SecondaryContact.LoginName
}

# Identifier les sites avec permissions rompues (heritage casse)
$site = Get-SPSite "https://sharepoint.entreprise.fr"
$site.AllWebs | ForEach-Object {
  if ($_.HasUniqueRoleAssignments) {
    Write-Host "Heritage rompu:" $_.Url
  }
}

Utilisez SPDocKit ou les scripts PnP PowerShell pour generer un rapport de permissions complet. Le livrable attendu est une matrice des permissions par site collection, avec une classification par niveau de risque (critique, eleve, moyen, faible) et des recommandations de remediation pour chaque anomalie identifiee.

— Etape 4 : Audit de l'authentification et de la gestion des identites

La CVE-2026-45659 l'a demontre : un attaquant authentifie peut executer du code sur le serveur. La robustesse de votre authentification est donc la premiere ligne de defense. L'audit doit couvrir quatre axes : le mecanisme d'authentification (claims vs classic, NTLM vs Kerberos), le MFA (deploye ou non, quels facteurs), les politiques de mots de passe (complexite, rotation, historique) et l'integration Active Directory (comptes de service, delegation Kerberos).

En 2026, les recommandations minimales sont : MFA obligatoire pour tous les acces externes et privilegies, Kerberos au lieu de NTLM pour l'authentification interne, Conditional Access si vous avez un environnement hybride avec Entra ID, et desactivation de l'authentification legacy (Basic auth, NTLM v1). Verifiez egalement que les comptes de service SharePoint ne sont pas membres de groupes AD privilegies (Domain Admins, Enterprise Admins).

— Etape 5 : Test de la surface d'attaque externe

Cette etape evalue ce qu'un attaquant voit depuis Internet. L'objectif est de cartographier votre surface d'attaque externe et d'identifier les expositions non intentionnelles. Beaucoup d'entreprises francaises decouvrent avec surprise qu'une instance SharePoint est accessible depuis Internet via un VPN mal configure, un reverse proxy oublie ou une regle NAT residuelle.

Les tests a conduire incluent : scan de ports depuis l'exterieur sur vos plages IP publiques, enumeration DNS (sous-domaines sharepoint.*, sp.*, collaboration.*), scan Shodan/Censys pour les instances SharePoint exposees, test des en-tetes HTTP (X-SharePointHealthScore, MicrosoftSharePointTeamServices revelent la version), et test de l'acces anonyme aux pages d'erreur, aux API REST et aux endpoints SOAP.

# Scan externe pour detecter les headers SharePoint
curl -sI https://sharepoint.entreprise.fr | grep -i "MicrosoftSharePointTeamServices\|X-SharePointHealthScore"

# Enumeration DNS des sous-domaines potentiels
subfinder -d entreprise.fr | grep -i "share\|sp\|collab\|intra"

# Test d'acces anonyme aux API SharePoint
curl -s "https://sharepoint.entreprise.fr/_api/web" -H "Accept: application/json"
curl -s "https://sharepoint.entreprise.fr/_vti_bin/spdisco.aspx"

Si une instance SharePoint est accessible depuis Internet sans passer par un WAF ou un reverse proxy authentifiant, c'est une vulnerabilite critique a corriger immediatement, independamment du niveau de patching. Les campagnes d'exploitation CVE-2026-45659 scannent automatiquement toutes les instances SharePoint exposees.

— Etape 6 : Threat hunting retroactif sur les logs

Le threat hunting est la partie la plus technique de l'audit, mais aussi la plus revelante. L'objectif est de chercher dans vos logs des traces d'exploitation passee ou en cours. Avec l'exploitation active de CVE-2026-45659 depuis mai 2026, il est possible que vos instances aient deja ete compromises sans que vous le sachiez. Le hunting doit couvrir au minimum les 45 derniers jours de logs.

Les sources de logs a analyser sont : les logs IIS (requetes anormales vers les endpoints SharePoint, user-agents suspects, codes d'erreur 500 en serie), les logs ULS SharePoint (erreurs de deserialization, exceptions non gerees), les logs Windows Event (process enfants suspects de w3wp.exe, creation de comptes, modifications de permissions), et les logs EDR (telemetrie endpoint sur les serveurs SharePoint).

// KQL pour Microsoft Sentinel : patterns de deserialization suspects
SecurityEvent
| where Computer has "SHAREPOINT"
| where EventID in (4688, 4689)
| where ParentProcessName endswith "w3wp.exe"
| where NewProcessName !in ("csc.exe", "conhost.exe")
| project TimeGenerated, Computer, Account, NewProcessName, CommandLine
| order by TimeGenerated desc

// Requetes IIS anormales vers les endpoints sensibles
W3CIISLog
| where sSiteName has "SharePoint"
| where csUriStem has_any ("/_vti_bin/", "/_api/", "/_layouts/")
| where scStatus >= 500
| summarize count() by csUriStem, cIP, bin(TimeGenerated, 1h)
| where count_ > 20

Cherchez egalement les indicateurs specifiques a Djinn Stealer : acces aux fichiers .cursor/, .copilot/, .vscode/ depuis des processus non legitimes, et connexions sortantes vers des IP inconnues depuis les serveurs SharePoint.

— Etape 7 : Rapport d'audit et plan de remediation priorise

La derniere etape synthetise l'ensemble des resultats dans un rapport structurant pour la prise de decision. Le rapport doit etre lisible par deux audiences : le Comex/direction (resume executif, risques business, budget necessaire) et l'equipe technique (vulnerabilites detaillees, commandes de remediation, chronogramme).

Le plan de remediation classe chaque finding par criticite (critique, eleve, moyen, faible) et par effort de remediation (rapide, modere, complexe). Les quick wins — corrections a faible effort et fort impact — doivent etre executes dans les 48 heures suivant la remise du rapport. Les actions structurelles (migration Kerberos, refonte des permissions, deploiement WAF) s'inscrivent dans un plan a 30-60-90 jours.

Pour les entreprises soumises a NIS2 ou DORA, le rapport d'audit constitue une piece de conformite documentable. Il demontre la diligence raisonnable de l'organisation face aux menaces connues. L'ANSSI attend des entites soumises a NIS2 qu'elles puissent presenter un etat des lieux de securite de leurs systemes critiques lors des premiers controles prevus au Q3 2026.

Contenu attendu du rapport : resume executif (2 pages), cartographie des instances (etape 1), matrice de patching et CVE ouvertes (etape 2), audit des permissions avec anomalies (etape 3), evaluation de l'authentification (etape 4), surface d'attaque externe (etape 5), resultats du threat hunting (etape 6), plan de remediation priorise avec chronogramme 30-60-90 jours, et annexes techniques (scripts, requetes KQL, configurations recommandees).

— Questions frequentes

— Pour aller plus loin

Ce guide fait partie de notre ecosysteme d'articles sur la securite SharePoint et la protection des entreprises francaises. Retrouvez nos analyses complementaires :

• CVE-2026-45659 SharePoint RCE au KEV CISA : exploitation active confirmee — Analyse de la derniere CVE critique exploitee activement.
• CVE-2026-32201 SharePoint zero-day : deadline CISA 28 avril — Retour sur le zero-day SharePoint du printemps 2026.
• Guide complet de hardening SharePoint Server — Les bonnes pratiques de securisation pour SharePoint on-premise.
• Securisation SharePoint : guide complet — Vue d'ensemble de la securisation SharePoint pour les entreprises.
• Auditer votre exposition SharePoint externe en 7 etapes — Focus sur la surface d'attaque externe.
• Nos solutions de cybersecurite — Audit, pentest, conformite NIS2 et SOC manage pour les entreprises francaises.

Sources et references : CISA KEV | Microsoft MSRC | ANSSI | CIS Benchmarks