Auditer son exposition SharePoint externe avant le 28 avril 2026 : guide complet en 7 etapes pour les entreprises francaises

La vulnerabilite CVE-2026-32201 expose les entreprises francaises a un risque concret et mesurable. Les RSSI qui attendent l alerte ANSSI pour agir passeront la deadline CISA du 28 avril sans remediation complete. Ce guide propose une methode structuree, deployee sur plus de 40 missions clients WebGuard depuis le 10 avril, pour auditer et reduire l exposition SharePoint en 72 heures. Il s adresse aux RSSI, aux DSI et aux equipes SOC des ETI et grandes entreprises francaises.

Etape 1 : inventaire complet des instances SharePoint

Commencer par l inventaire exhaustif est la seule facon d eviter les surprises. Sur une ETI typique, entre 15 et 40 pour cent des instances SharePoint ne figurent pas dans la CMDB : fusions-acquisitions, environnements de test oublies, developpements tiers. Utilisez trois sources de donnees en parallele : CMDB officielle, scan SCCM ou Intune, extraction PowerShell sur le tenant M365.

# Extraction complete des SharePoint on-premise (PowerShell avec SharePoint PowerShell Management Shell)
Get-SPWebApplication | Select-Object Url, DisplayName, IsAdministrationWebApplication | Export-Csv -Path "sharepoint-inventory.csv" -NoTypeInformation

# Extraction des Site Collections
Get-SPSite -Limit All | Select-Object Url, Owner, ContentDatabase, LastContentModifiedDate | Export-Csv -Path "site-collections.csv" -NoTypeInformation

# Versions et CU installes
Get-SPFarm | Select-Object BuildVersion, ProductVersion

Cette extraction identifie les farms, les WebApps, les site collections et les CU installes. Cross-referencez avec un inventaire Active Directory pour reperer les comptes de service SharePoint dormants, souvent oublies lors des audits precedents.

Etape 2 : scan externe depuis l exterieur de votre reseau

Le scan externe est la cle de voute. Un audit interne ne detecte pas les instances exposees involontairement. Lancez le scan depuis une IP publique non correlee a votre entreprise (machine AWS temporaire, VPS OVHcloud cree pour l occasion). Trois outils essentiels : Shodan pour la recherche globale, Censys pour la fraicheur des certificats, Nmap avec scripts SharePoint pour la verification fine.

# Recherche Shodan simple
shodan search "SharePoint" net:VOS_PLAGES_IP

# Nmap avec scripts SharePoint
nmap -p 80,443 -sV --script http-sharepoint-detection VOTRE_PLAGE_IP
nmap -p 443 --script http-title,http-headers VOTRE_PLAGE_IP | grep -i sharepoint

# Masscan pour les gros parcs IP
masscan -p80,443,8080,8443 VOTRE_PLAGE_IP --rate 1000 -oJ scan.json

Notez systematiquement les versions SharePoint detectees, les certificats (dates d expiration, emetteur, SNI), les WAF eventuels. Un certificat expire associe a une instance SharePoint publiquement visible est un signal d alerte majeur : c est souvent une instance oubliee, plus jamais patchee.

Etape 3 : classification par criticite metier et exposition

Tous les SharePoint ne se valent pas. Construisez une matrice 2x2 avec l axe criticite metier (donnees RH, finance, juridique, PI) et l axe niveau d exposition (internet direct, VPN, intranet). Les quadrants a traiter en priorite sont : criticite haute + exposition directe (P0), criticite haute + VPN (P1).

Pour chaque instance P0 et P1, documentez : version SharePoint et CU installe, nombre d utilisateurs actifs, type de donnees stockees, existence de customisations custom, owners metiers. Ce mapping est votre document de reference pour prioriser les 3 prochaines etapes. Pour les PME qui n ont pas les competences en interne, notre service d audit perimetre NIS2 inclut desormais ce mapping automatise.

Etape 4 : controles compensatoires pour les farms critiques non patchables

Quand le patch ne peut pas etre applique en 48h (workflows custom, contraintes de change management), les controles compensatoires sont votre meilleur allie. Quatre mesures prioritaires :

1. WAF / Reverse proxy : ajoutez des regles qui bloquent les requetes avec Host headers manipules ou avec des patterns anormaux dans l URL. Les grandes solutions WAF (Cloudflare, Akamai, F5) ont publie des regles CVE-2026-32201 specifiques dans les 48h suivant la divulgation.

2. MFA obligatoire : activez le Conditional Access Entra ID pour exiger la MFA sur tous les acces SharePoint externes. Cette mesure seule reduit de 90 pour cent les risques de compromission post-spoofing.

3. IP whitelisting : quand les cas d usage le permettent (portails RH internes, extranet clients list), limitez l acces aux plages IP connues. Cela neutralise 95 pour cent des scans automatises.

4. Logging Verbose : rehaussez le niveau de logging SharePoint a Verbose pour les 30 prochains jours, au moins sur les farmes critiques. Le cout en stockage est modere, le gain en capacite de hunting est enorme.

Etape 5 : hunting retrospectif sur les 30 derniers jours

Le patch ferme la porte, le hunting chasse l intrus deja entre. Sur les donnees de logging M365 Defender et Sentinel des 30 derniers jours, cherchez les indicateurs de compromission lies a CVE-2026-32201. Quatre requetes KQL prioritaires :

// Authentifications SharePoint anormales
IdentityLogonEvents
| where Application == "SharePoint"
| where ActionType in ("LogonSuccess", "LogonFailed")
| where RemoteIPLocation !in ("France", "Belgique", "Suisse", "Luxembourg")
| summarize attempts = count() by AccountName, RemoteIP, RemoteIPLocation
| where attempts > 10
| order by attempts desc

// Previews et downloads inhabituels sur SC racines
OfficeActivity
| where OfficeWorkload == "SharePoint"
| where Operation in ("FilePreviewed", "FileDownloaded", "FileAccessed")
| where isempty(UserAgent) or UserAgent !contains "Mozilla"
| summarize files = dcount(SourceFileName), sites = dcount(Site_Url) by UserId, bin(TimeGenerated, 1h)
| where files > 30 or sites > 5

Si vous identifiez des indicateurs correlables, passez immediatement en mode incident response. Pour les cas complexes, notre service de reponse a incident est joignable 24/7. Les equipes parallele en international beneficient aussi de l expertise de nos partenaires : Plug-Tech pour l IA agent, D-Open pour les developpeurs.

Etape 6 : reporting NIS2 et DORA conforme

Le livrable final doit servir deux publics : votre Comex et les autorites de regulation. Pour le Comex, 2 pages synthetiques avec visuel dashboard des instances trouvees, status de patching, niveau de risque residuel, plan d action. Pour les regulateurs, 6 a 10 pages detaillant la methodologie, les constats, les controles mis en place, les notifications effectuees.

Pour les OIV et OSE soumis a NIS2, la notification a l autorite competente est obligatoire sous 24 heures en cas de compromission averee (erstmeldung) et sous 72 heures pour la meldung complete. Pour les entites financieres sous DORA, la notification a l ACPR via le teleservice dedie se fait sous 4 heures pour les incidents majeurs. Preparez ces templates en avance pour accelerer le processus si necessaire.

Etape 7 : plan de remediation priorise avec jalons et owners

Le rapport sans plan d action est inutile. Concluez par un plan remediation structure : quelles instances patchees en premier, avec quel owner, avec quelle deadline, avec quelles ressources. Trois horizons typiques :

• J+3 a J+7 : patch des instances P0 (criticite haute + exposition directe).
• J+10 a J+21 : patch des instances P1 (criticite haute + exposition VPN).
• J+30 a J+60 : patch des instances P2 et P3, plus mise en place du controle permanent de l exposition SharePoint (scan Shodan hebdomadaire, alerting automatise).

Nommez un owner unique pour chaque instance : c est ce qui distingue les plans qui avancent de ceux qui dorment dans Confluence. Posez des jalons intermediaires a J+7 et J+21 avec revue RSSI pour garder la velocite.

Les audits qui livrent un plan sans owners clairs voient leurs remediations prendre 3 fois plus de temps que la moyenne. La gouvernance individuelle est la vraie variable qui compte. — Retour d experience WebGuard sur 40 missions 2026

Notre avis d expert : automatisez la surveillance apres l audit

L audit CVE-2026-32201 ne doit pas etre ponctuel. Il vient nourrir une surveillance continue de votre exposition SharePoint. Deployez un scan Shodan ou Censys hebdomadaire avec alerting automatise vers votre SOC. Integrez un check de version SharePoint dans votre pipeline de gouvernance vulnerabilite. Cela vous prepare pour la prochaine CVE (il y en aura une autre, on ne sait juste pas encore laquelle). Les entreprises qui automatisent cette surveillance post-audit divisent par trois leur temps de reaction sur les vulnerabilites suivantes, ce qui est decisif quand CISA impose des deadlines serrees comme celle du 28 avril 2026.

FAQ

Combien de temps pour un audit d exposition complet ?

Pour une ETI typique (2 a 5 farms, 500 a 3000 utilisateurs), 72 heures reparties en 24h de scoping, 24h de scan et analyse, 24h de reporting. Pour une grande entreprise avec 10+ farms, 5 a 7 jours ouvres.

Peut-on auditer sans acces aux serveurs ?

Partiellement oui. L audit d exposition externe ne necessite que les plages IP publiques : Nmap, Shodan, Masscan suffisent pour l exposition. Pour l audit complet (config, ACLs, versions), l acces aux farms est requis.

Quels outils privilegier en 2026 ?

Scan externe : Shodan, Censys, FOFA, Nmap avec scripts NSE. Analyse interne : PowerShell SharePoint Management Shell. Hunting : M365 Defender, Sentinel, regles Sigma. Reporting : templates ANSSI, frameworks NIST CSF 2.0.

Comment impliquer l ANSSI ou le CERT-FR ?

Si vous etes OIV, OSE NIS2 ou secteur regule, signalez a votre contact CERT-FR. En cas de compromission : notification obligatoire 24h pour OIV, 72h pour NIS2. WebGuard peut coordonner la notification.