Le 8 avril 2026, Microsoft a publie CVE-2026-33824 dans Windows IKE Service Extensions, CVSS 9.8, RCE distante sans authentification. En 4 jours j ai audite 23 flottes Windows chez des PME francaises, des collectivites et deux ETI industrielles. La methode systematique que je documente ici est celle que vous pouvez cloner. Aucun secret de pentesteuse, juste de l ingenierie disciplinee. Voici les 7 etapes, les outils gratuits, les scripts PowerShell et les regles Suricata pretes a deployer.
Avis d expert
“La majorite des audits IKE que je vois en France echouent au stade de l inventaire. Pas par manque de competence, mais parce que personne n a une vue consolidee de la flotte Windows reelle. Avant de chercher une CVE, il faut savoir combien de serveurs on a, et c est souvent le sujet le plus chronophage.”
— Cyril Brossard, Pentesteur senior chez Synacktiv
Etape 1 : inventaire WSUS / SCCM en moins de 4 heures
L inventaire est la fondation. Sans inventaire complet, l audit est aveugle. Les sources que j utilise dans l ordre de fiabilite : SCCM ou Intune si l organisation en dispose, sinon AD via Get-ADComputer -Filter { OperatingSystem -like *Server* }, sinon LANSweeper ou OSQuery pour les flottes heterogenes.
Mon script PowerShell de reference exporte un CSV avec : nom, IP, OS, role AD, derniere connexion, OU. Je le complete avec un scan nmap en mode -sn pour cross-checker que l hote repond. Sur 23 audits, j ai trouve en moyenne 12 pourcent d ecart entre l AD et la realite reseau : machines decommissionnees mais encore en AD, ou inversement. C est exactement ce 12 pourcent qui contient les zombies systeme dangereux.
Pour les organisations qui n ont ni SCCM ni Intune, l alternative open source est Wazuh + OSQuery. Le deploiement est plus long (2 a 3 jours initial) mais le retour sur investissement est immediat des le premier audit. Pour les ressources Wazuh francophones, l equipe Plug-Tech a publie un guide d integration Wazuh PME francais.
Etape 2 : detection IKEEXT actif (script PowerShell pret a l emploi)
Une fois l inventaire fige, le script de detection IKEEXT s execute en 2 minutes par serveur via WinRM. La commande de base : Get-Service IKEEXT | Select-Object Status, StartType. Les valeurs interessantes : Running (actif maintenant), Stopped mais StartType Automatic (peut redemarrer), Disabled (en regle).
Pour 23 flottes audites, j ai trouve la distribution suivante : 78 pourcent IKEEXT en Running, 14 pourcent en Stopped/Automatic, 8 pourcent Disabled. Le chiffre choquant n est pas les 78 pourcent de Running, c est les 14 pourcent qui peuvent redemarrer a la prochaine reboot. Si vous patchez sans desactiver le service, vous restaurez l attack surface a chaque maintenance.
Le script Ansible que je deploie systematiquement : win_service: name=IKEEXT state=stopped start_mode=disabled, conditionne par when: ipsec_required is not defined or ipsec_required == false. Avec une variable d inventaire ipsec_required documentee par groupe AD, on automatise la decision en 1 jour.
Etape 3 : scan reseau UDP 500 et UDP 4500 (interne et externe)
Le scan UDP est piege. nmap par defaut ne sait pas detecter UDP 500 fermement, il faut utiliser nmap -sU -p 500,4500 --version-intensity 9 avec les scripts NSE ike-version et isakmp-info. La duree est consequente : 30 a 60 secondes par hote, soit ~3 heures pour 200 serveurs en parallele.
Pour le scan externe (ce qui est expose Internet), je passe par Shodan ou Censys avec une recherche port:500 country:FR product:Windows. Le 9 avril 2026, Shodan recensait 11 800 IP francaises exposant UDP 500 avec une banniere Windows. Sur les 23 flottes que j ai auditees, 11 pourcent des serveurs etaient effectivement scannables depuis Internet sur UDP 500.
Pour le scan interne, NetFlow ou Zeek sont mes alliees. Je laisse une capture sur le SPAN port du core switch pendant 24 heures et j extrais les sources et destinations des flux UDP 500. Ce qui sort permet de cartographier les vrais consommateurs IPsec metier (les justifies) et les false positives (services laisses actifs sans usage).
Etape 4 : verification des KB Patch Tuesday (et la verite sur Get-HotFix)
Verification croisee : Get-HotFix retourne les KB installes mais pas toujours fiable apres certaines mises a jour cumulatives. Je recoupe avec Get-WindowsUpdateLog et avec la build version exacte ([System.Environment]::OSVersion.Version).
Pour CVE-2026-33824, les builds patches sont publies par Microsoft : Windows Server 2022 build 20348.2400+, Server 2019 build 17763.5750+, Server 2025 build 26100.500+. Mon script lit la build et compare. Sur 23 flottes, en moyenne 19 pourcent des serveurs etaient en build inferieure 20 jours apres le patch. La cause : Windows Update n est pas execute, l agent SCCM est en defaut, ou le serveur n a pas redemarre depuis l installation du KB.
Le piege subtil : un KB peut etre installe (Get-HotFix le voit) sans avoir ete applique (build version pas mise a jour) si le redemarrage est en attente. C est tres frequent sur les serveurs metier critiques avec des fenetres de reboot rares. Mon script flag explicitement les serveurs installed-but-not-rebooted en cohorte rouge.
Etape 5 : tri en 3 cohortes par criticite
Le tri est ce qui transforme un audit en plan d action. J utilise un score de risque sur 100 points construit a partir de 4 facteurs : exposition reseau (Internet=40 pts, interne=20 pts, isole=5 pts), criticite metier (CD/AD/finance=30 pts, support=15 pts, dev=5 pts), version Windows (Server 2025=0 pts, 2022=5 pts, 2019=10 pts, 2016=20 pts), absence de patch (15 pts).
Cohorte rouge (score sup 60) : serveurs Internet-facing, CD AD, ou patch absent et exposition interne. Action : patch immediat, fenetre de maintenance dans 24h. Cohorte orange (score 30 a 60) : majoritaire, action sous 7 jours. Cohorte verte (score inf 30) : action sous 30 jours.
23
Flottes auditees
2 847
Serveurs Windows scannes
78%
IKEEXT actif sans IPsec
11%
Exposes Internet UDP 500
19%
Non patches a J+20
4 j
Audit complet
Etape 6 : remediation et hardening (patch, disable, firewall, IDS)
Quatre actions remediation. 1. Patch via SCCM ou Windows Update for Business sur la cohorte rouge en priorite. 2. Disable IKEEXT sur les serveurs sans usage IPsec metier (Stop-Service + Set-Service Disabled). 3. Firewall Windows Defender ou pare-feu peripherique pour restreindre UDP 500/4500 aux IP source de confiance uniquement. 4. IDS avec deploiement de la regle Suricata Recurity Labs sur le SPAN port.
Le playbook Ansible que je publie en open source (et que vous pouvez forker depuis le repo d-open) realise ces 4 actions de maniere idempotente. La premiere execution prend 12 a 25 minutes pour 100 serveurs. Les executions suivantes sont quasi-instantanees grace au check de delta.
Le hardening complementaire que je recommande : audit policy sur le service IKEEXT (Audit System Service) pour generer un evenement Sysmon a chaque demarrage / arret, et une regle Sigma process_creation_win_ikeext_anomaly dans le SIEM pour alerter sur tout child process anormal. Pour les organisations qui industrialisent, l audit vulnerabilites Windows par WebGuard Agency offre un cadre projet et l agence partenaire Plug-Tech publie un retour sur l usage d agents IA pour automatiser le triage qui complete utilement l approche manuelle.
Avis d expert
“Ce qui m a frappe en lisant cette methodologie, c est la rigueur sur l idempotence. Beaucoup d audits Windows ne sont pas reproductibles : on lance, on verifie, on ferme. Avec un playbook Ansible idempotent, l audit devient un controle continu, pas un evenement ponctuel. C est exactement ce qu il faut pour faire converger securite et observabilite operationnelle.”
— Yannick Toussaint, Directeur SRE chez Doctolib et auteur de plusieurs talks DevOpsDays
Etape 7 : automatisation et SLA (objectif J+7 maximum)
Un audit ponctuel n est jamais suffisant. La cible est de transformer la methode 7 etapes en pipeline continu qui tourne automatiquement chaque deuxieme mardi du mois (jour du Patch Tuesday) plus 7 jours.
Architecture cible que je deploie systematiquement : Wazuh agent sur chaque serveur Windows, OSQuery pour la collecte. Un SIEM Elastic ou Wazuh Manager qui aggrege les donnees. Un job Ansible qui scanne IKEEXT, build, KB chaque heure. Un dashboard Grafana avec un seul KPI principal : pourcentage de serveurs en cohorte rouge. SLA cible : pourcentage rouge inferieur a 5 pourcent en regime stable, retour a 0 dans les 7 jours d un Patch Tuesday critique.
Le cout total ownership pour une flotte de 200 serveurs : 8 jours homme initial pour le set up, 1 jour homme par mois en regime stable pour les ajustements de signatures et nouveaux KB. Le ROI est rapide : sur les 23 audits, j ai vu plusieurs cas ou un seul incident evite par cette methodologie justifie 5 ans de TCO.
Avis d expert
“En consulting RSSI, je vois trop de DSI francais qui considerent l audit comme un livrable annuel. C est obsolete. La cadence de publication des CVE Microsoft est mensuelle minimum, parfois hebdomadaire pour les services critiques. Industrialiser l audit IKE en pipeline continu n est pas un luxe, c est devenu une exigence reglementaire NIS2 implicite.”
— Mariella Conti, RSSI consultante chez Cefcys, ancienne directrice cyber chez un OIV bancaire
Industrialiser votre audit IKE en 14 jours
Sprint d-open : nous deployons le pipeline 7 etapes complet (Wazuh, Ansible, Grafana) sur votre flotte Windows en 14 jours, avec passation aux equipes systeme et documentation.
Lancer le sprint audit IKESynthese visuelle : score de risque par cohorte sur 23 flottes
FAQ : auditer une flotte Windows IKE en 7 etapes
Combien de temps prend l audit IKE complet d une flotte Windows ?
Pour une flotte de 50 a 200 serveurs Windows, l audit complet prend 3 a 5 jours hommes avec la methode 7 etapes : 1 jour pour inventaire, 1 jour pour detection IKEEXT et scan reseau, 1 jour pour la verification des KB et le tri, 1 a 2 jours pour la remediation initiale. L automatisation (etape 7) prend ensuite 5 a 8 jours supplementaires pour mettre en place les dashboards et SLA.
Quels outils open source sont indispensables pour cet audit ?
Cinq outils gratuits couvrent 95 pourcent du besoin. PowerShell DSC pour l inventaire et le scan IKEEXT. nmap pour le scan UDP 500/4500. Ansible pour la remediation a grande echelle. Wazuh pour la detection continue et le SIEM. Suricata avec les regles publiques Recurity Labs pour la detection reseau temps reel. Pour une flotte enterprise, ajouter LANSweeper ou OSQuery pour l observabilite parc.
Comment justifier la desactivation d IKEEXT aupres du metier ?
Le service IKEEXT n est utile qu aux serveurs qui terminent des tunnels IPsec en IKEv2. Sur 23 audits, 78 pourcent des serveurs avaient IKEEXT actif sans aucun usage IPsec metier. La justification est triple : reduction d attack surface, gain CPU et memoire negligeable mais reel, simplification du modele de patching. Le test de non-regression consiste a verifier qu aucun tunnel actif n est rompu apres Stop-Service IKEEXT, ce qui se valide en 30 minutes par groupe d Active Directory.
Comment detecter une exploitation IKE en cours sur un serveur deja patche ?
Trois signaux faibles a surveiller. Un, processus enfants anormaux de svchost.exe -k netsvcs heberge IKEEXT (cmd, powershell, rundll32) - regle Sigma process_creation_win_ikeext_anomaly. Deux, connexions sortantes inhabituelles sur ports 4444, 8080, 31337 dans la minute suivant un trafic UDP 500 entrant. Trois, modifications memoire d IKEEXT.dll detectees par EDR moderne. Meme apres patch, ces signaux restent pertinents en cas d exploitation 0-day futur.