Durcir Windows Defender contre CVE-2026-33825 BlueHammer en entreprise : le guide en 8 étapes

La divulgation simultanée le 8 avril 2026 des trois zero-days Windows Defender — BlueHammer (CVE-2026-33825), RedSun et UnDefend — change la donne pour tous les RSSI d'entreprises dont le parc Windows s'appuie sur Defender, intégralement ou en couche. Huntress Labs a confirmé l'exploitation active dès le 10 avril. Microsoft a publié le correctif KB5055XX le 14 avril pour BlueHammer uniquement ; RedSun et UnDefend restent sans patch public au 21 avril 2026.

Ce guide détaille les 8 étapes opérationnelles pour durcir Microsoft Defender en entreprise et absorber ce choc. Il est conçu pour être applicable directement par une équipe IT ou SOC disposant de droits d'administration du domaine Active Directory et d'une console Intune, SCCM ou WSUS. Pour le contexte complet sur les trois failles, consultez notre analyse Windows Defender BlueHammer, RedSun et UnDefend.

— Étape 1 — Auditer la version actuelle de Defender sur tout le parc

Impossible de durcir ce qu'on ne cartographie pas. La première étape consiste à obtenir une photographie précise de l'état Defender sur chaque endpoint : version du moteur antivirus, version des signatures, état de la protection en temps réel, présence du dernier cumulatif Windows. L'outil de référence est la cmdlet PowerShell Get-MpComputerStatus, disponible par défaut sur toutes les versions supportées de Windows 10 et Windows 11.

Pour un parc au-delà de quelques dizaines de machines, l'exécution locale ne suffit pas : il faut remonter les résultats de façon centralisée. Trois options pragmatiques : via Intune et un script remediation, via SCCM avec un Configuration Item, ou via une tâche planifiée GPO qui écrit le résultat dans un partage SMB sécurisé.

# Script d'audit à exécuter en session administrateur local
$status = Get-MpComputerStatus
[PSCustomObject]@{
  Host             = $env:COMPUTERNAME
  AMEngineVersion  = $status.AMEngineVersion
  AMProductVersion = $status.AMProductVersion
  AMServiceVersion = $status.AMServiceVersion
  AntivirusEnabled = $status.AntivirusEnabled
  RealTimeProtection = $status.RealTimeProtectionEnabled
  OSBuild          = (Get-CimInstance Win32_OperatingSystem).BuildNumber
  LastHotfix       = (Get-HotFix | Sort-Object -Property InstalledOn -Descending | Select-Object -First 1).HotFixID
  Date             = (Get-Date).ToString('s')
} | ConvertTo-Json

L'objectif : identifier en moins de 24h les endpoints qui ne reportent pas, ceux qui n'ont pas le KB d'avril 2026 installé, et ceux dont la protection en temps réel est désactivée ou en échec. Ces trois catégories doivent être traitées en priorité avant de passer aux étapes suivantes.

— Étape 2 — Déployer le Patch Tuesday d'avril KB5055XX

Le correctif KB5055XX publié le 14 avril 2026 corrige spécifiquement CVE-2026-33825 (BlueHammer) en durcissant la gestion des liens symboliques dans le processus MsMpEng.exe. Son déploiement est la mesure la plus immédiate et la plus efficace contre la faille la mieux documentée des trois zero-days.

Les SLA de déploiement recommandés, alignés sur les pratiques de patch management pour vulnérabilités activement exploitées :

• Endpoints privilégiés (administrateurs DSI, finance, juridique, direction, serveurs de rebond) : déploiement sous 24h avec redémarrage forcé.
• Parc standard (postes utilisateurs) : déploiement sous 72h avec redémarrage planifié en heures creuses.
• Postes hors réseau (nomades, BYOD supervisé) : déploiement sous 7 jours maximum avec rappel automatisé.

Pour les infrastructures Intune, un deployment ring avec groupe pilote → cadres → large déploiement permet de valider la stabilité sans sacrifier la vitesse. Pour SCCM, une collection dynamique basée sur la version OS et l'absence du KB cible les machines non conformes. Dans tous les cas, un tableau de bord journalier de couverture est indispensable jusqu'à atteindre 100 %.

— Étape 3 — Activer les règles Attack Surface Reduction (ASR)

Les règles ASR constituent le mécanisme de durcissement le plus efficace offert nativement par Windows. Elles bloquent des comportements d'attaque typiques au niveau du système, indépendamment de la détection de signature. Face à la chaîne BlueHammer/RedSun/UnDefend, plusieurs règles sont particulièrement pertinentes.

Règles à activer en mode bloquant en priorité :

• 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 — Block credential stealing from LSASS.
• d1e49aac-8f56-4280-b9ba-993a6d77406c — Block process creations from PSExec and WMI commands.
• 01443614-cd74-433a-b99e-2ecdc07bfc25 — Block executable files unless they meet prevalence, age, or trusted list.
• 5beb7efe-fd9a-4556-801d-275e5ffc04cc — Block execution of potentially obfuscated scripts.

# Activer les règles ASR en mode bloquant (1 = Block, 2 = Audit, 0 = Off)
$rules = @(
  '9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2',
  'd1e49aac-8f56-4280-b9ba-993a6d77406c',
  '01443614-cd74-433a-b99e-2ecdc07bfc25',
  '5beb7efe-fd9a-4556-801d-275e5ffc04cc'
)
Set-MpPreference -AttackSurfaceReductionRules_Ids $rules `
  -AttackSurfaceReductionRules_Actions ([byte[]](1,1,1,1))

Conseil opérationnel : activer d'abord ces règles en mode audit (valeur 2) pendant 5 à 7 jours pour identifier les faux positifs propres à votre SI, puis basculer en mode bloquant (valeur 1) après ajustement des exclusions. Un passage en mode bloquant brutal sur un parc de 500+ postes expose à un risque opérationnel non négligeable.

— Étape 4 — Restreindre la portée de remédiation Defender via GPO

BlueHammer exploite spécifiquement la fenêtre de remédiation automatique de Defender. Réduire cette fenêtre et contraindre le comportement par défaut via Group Policy constitue une mesure d'atténuation structurelle qui reste efficace même si RedSun et UnDefend restent non patchées.

Les réglages GPO clés à appliquer via le modèle administratif Windows Defender Antivirus (Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus) :

• Configure default action for high severity threats : forcer la valeur Quarantine et documenter le workflow de release manuelle.
• Turn on behavior monitoring : activer sur tous les endpoints, y compris les serveurs.
• Configure local administrator merge behavior for lists : désactiver la fusion des exclusions locales avec les exclusions GPO (limite les abus via UnDefend).
• Allow anti-malware service to startup with normal priority : activer pour éviter les courses de démarrage.

Complémentairement, il est fortement recommandé de désactiver la possibilité pour un utilisateur non administrateur de modifier les préférences Defender via WMI. Ceci se fait en appliquant le réglage Tamper Protection via Intune ou le portail Microsoft Defender for Business, qui verrouille les API MSFT_MpPreference exploitées par UnDefend.

— Étape 5 — Surveiller l'Event ID 5007 Defender et corréler au SIEM

Huntress Labs a mis en évidence une signature comportementale caractéristique de l'exploitation BlueHammer : un Event ID 5007 (modification de configuration Defender) suivi à moins de 60 secondes d'un Event ID 1116 (détection d'un malware). Cette séquence est rare dans un fonctionnement nominal et constitue une règle de corrélation SIEM à très fort signal.

Les journaux Defender se trouvent dans Microsoft-Windows-Windows Defender/Operational. Ils doivent être routés vers votre SIEM (Splunk, Sentinel, Elastic Security, LogPoint, etc.) via Winlogbeat, l'agent Sentinel, ou un collecteur Syslog-NG selon votre architecture.

Exemple de règle KQL Microsoft Sentinel :

DeviceEvents
| where TimeGenerated > ago(24h)
| where ActionType in ("AntivirusConfigurationChanged","AntivirusDetection")
| summarize events = make_list(ActionType), times = make_list(TimeGenerated)
    by DeviceId, bin(TimeGenerated, 1m)
| where array_length(events) >= 2
| where events has "AntivirusConfigurationChanged" and events has "AntivirusDetection"
| project DeviceId, TimeGenerated, events, times

Complémentairement, il est judicieux de remonter les créations de fichiers ou de liens symboliques dans C:\ProgramData\Microsoft\Windows Defender\Quarantine\ via Sysmon Event ID 11 et 15. Une alerte de niveau élevé doit partir dès qu'un processus non système y écrit.

— Étape 6 — Ajouter une couche EDR (CrowdStrike, SentinelOne, autre)

Tant que RedSun et UnDefend ne sont pas patchées, la défense en profondeur impose de ne pas reposer uniquement sur Defender. Une couche EDR tierce apporte une détection comportementale indépendante du moteur Microsoft, capable de repérer la chaîne d'exploitation même lorsque Defender lui-même est compromis.

Les principales options reconnues pour un déploiement français :

• CrowdStrike Falcon : détection comportementale mature, couverture complète de la chaîne MITRE ATT&CK, coût élevé mais fort ROI pour les environnements critiques.
• SentinelOne Singularity : capacité de rollback autonome, bonne intégration on-premise, option souveraine européenne via datacenters UE.
• Microsoft Defender for Endpoint Plan 2 : si vous êtes déjà sur une licence E5, cette extension apporte une télémétrie cloud et des capacités EDR complémentaires sans déployer un second agent.
• HarfangLab : acteur français, certification ANSSI CSPN, pertinent pour les OIV et les environnements sensibles exigeant la souveraineté.

Pour les PME et ETI qui ne peuvent pas déployer un EDR sur l'ensemble du parc, la recommandation minimale est de couvrir les endpoints privilégiés : comptes d'administration, serveurs d'identité (contrôleurs de domaine, serveurs ADFS, serveurs Entra ID Connect), postes des équipes finance, juridique, direction générale et RH.

— Étape 7 — Segmenter et isoler les endpoints privilégiés

Même avec la meilleure protection endpoint, la compromission d'un poste administrateur reste possible. La contre-mesure structurelle est la segmentation réseau et le principe du moindre privilège. Un attaquant qui exploite BlueHammer sur un poste utilisateur ne doit pas pouvoir atteindre directement un contrôleur de domaine ou une base de données financière.

Les mesures de segmentation prioritaires :

• VLAN dédié aux postes d'administration avec règles firewall restrictives : seuls les flux vers les serveurs de management (SCCM, AD, bastions) sont autorisés.
• Tiered Administration Model (Microsoft) : séparer les comptes d'administration Tier 0 (contrôleurs de domaine), Tier 1 (serveurs) et Tier 2 (postes) avec interdiction d'utilisation croisée.
• Just-In-Time Privilege (PAM) : via CyberArk, Delinea, BeyondTrust ou équivalent, les droits d'administration ne sont accordés que pour une durée limitée et journalisée.
• Micro-segmentation : pour les environnements matures, outils comme Illumio, Guardicore ou Cisco Secure Workload permettent d'appliquer le principe de moindre privilège au niveau applicatif.

Cette segmentation doit être cohérente avec votre périmètre de conformité. Un audit de périmètre NIS2 formalise les zones critiques à protéger en priorité, et notre guide d'audit des headers HTTP complète la couche applicative exposée à l'extérieur.

— Étape 8 — Plan de réponse à incident et KPIs

La dernière étape consiste à formaliser un playbook spécifique BlueHammer/RedSun/UnDefend et à piloter la posture de sécurité via des indicateurs mesurables. Un plan non documenté n'existe pas ; un plan non mesuré ne s'améliore pas.

Le playbook minimal doit couvrir :

1. A
   Détection et triage

   Qui reçoit l'alerte SIEM BlueHammer ? Quels sont les délais de prise en charge (15 min hors heures ouvrées, 5 min en heures ouvrées) ? Quelle est la procédure de validation du faux positif ?

2. B
   Confinement

   Isolation réseau du poste compromis via l'EDR ou le NAC. Désactivation des comptes concernés dans AD. Capture forensique mémoire et disque.

3. C
   Analyse et éradication

   Recherche d'IoC sur les autres endpoints, rotation des secrets exposés, reconstruction des machines touchées à partir d'une image saine.

4. D
   Notification réglementaire

   Si l'entité est OIV, OES ou NIS2 : notification précoce sous 24h au CERT-FR, rapport initial sous 72h, rapport final sous un mois. Information CNIL si données personnelles compromises (72h).

5. E
   Retour d'expérience (REX)

   Sous 30 jours après l'incident : analyse de la chaîne de défense, identification des angles morts, mise à jour du playbook et des règles SIEM.

Les KPIs à suivre en comité sécurité mensuel :

— Aller plus loin : gouvernance et écosystème

Durcir Defender en 8 étapes est un projet tactique, mais il s'inscrit dans une démarche plus large de gouvernance cyber. Les équipes de D-Open ont publié plusieurs ressources sur l'articulation entre durcissement technique et gouvernance NIS2/DORA qui permettent de structurer votre plan triennal. Côté architecture, les retours d'expérience partagés par Plug-Tech sur la diversification des moteurs de détection offrent un benchmark utile pour justifier l'investissement EDR tiers auprès de votre COMEX.

Les huit étapes de ce guide forment une boucle d'amélioration continue : l'audit initial (étape 1) doit être réexécuté trimestriellement, les règles ASR affinées en fonction des faux positifs, les KPIs challengés à chaque REX. Un durcissement qui n'évolue pas devient, en quelques mois, un durcissement dépassé.

Conclusion

La séquence BlueHammer, RedSun, UnDefend oblige à repenser la posture endpoint de toute entreprise reposant sur Microsoft Defender. Le KB5055XX neutralise la faille la mieux documentée, mais deux zero-days restent ouverts au 21 avril 2026. Les 8 étapes de ce guide — audit, patch, ASR, GPO, surveillance, EDR, segmentation, plan d'incident — constituent une réponse complète, opérationnelle, et alignée sur les exigences NIS2.

Un dernier principe : la vitesse prime sur la perfection. Mieux vaut déployer les huit étapes en 10 jours avec des ajustements à prévoir, que viser une mise en œuvre parfaite en 6 semaines pendant que l'exploitation active continue. Les RSSI qui ont déjà traversé WannaCry, NotPetya ou les campagnes SolarWinds connaissent cette règle : le premier à patcher gagne.