RedSun : une faille zero-day dans Microsoft Defender qui retourne la défense
La faille zero-day Microsoft Defender RedSun transforme un composant de sécurité en vecteur d’attaque direct. Exploitée sur des machines Windows entièrement à jour, cette nouvelle vulnérabilité, suivie sous l’identifiant CVE-2024-26234 dans le cadre du Patch Tuesday d’avril, permet une élévation de privilèges SYSTEM via le moteur antivirus Microsoft Defender, sans interaction utilisateur significative. Pour un DSI, cela signifie qu’un simple fichier malveillant peut suffire à obtenir des privilèges SYSTEM persistants sur un parc Windows Server et sur chaque machine Windows du poste de travail, comme le confirment les informations publiées dans le bulletin de sécurité Microsoft et dans la fiche CVE officielle.
Techniquement, la faille RedSun repose sur une chaîne d’exploitation qui abuse des privilèges système accordés au service antivirus pour analyser un fichier spécialement forgé. Le scénario type combine un vecteur d’accès initial classique, par exemple via un document bureautique ou un binaire déposé par un autre malware, puis une exploitation locale de la faille zero au sein du service de sécurité Microsoft Security pour obtenir des privilèges SYSTEM complets. Les chercheurs sécurité parlent d’une élévation de privilèges SYSTEM silencieuse, car l’attaque reste souvent invisible pour Windows Defender et pour les consoles de supervision traditionnelles, comme l’illustre l’analyse technique publiée par le chercheur Will Dormann et relayée dans le bulletin de sécurité Microsoft, qui détaillent le comportement du moteur antivirus lors du traitement du fichier piégé.
Les premiers éléments publiés par le chercheur en sécurité Will Dormann et par d’autres chercheurs sécurité indiquent que plusieurs versions de Microsoft Defender sont concernées, y compris sur Windows Server en environnement datacenter. La vulnérabilité a reçu un identifiant CVE dans le cadre du Patch Tuesday d’avril, au milieu de 167 failles corrigées dont deux zero day déjà exploitées, selon les données agrégées dans la base CVE. Pour les équipes SOC, le signal faible est d’autant plus difficile à capter que les événements proviennent d’un composant de confiance, classé comme défenseur officiel dans l’écosystème Microsoft Security et souvent exclu des règles de corrélation les plus strictes, alors même que les journaux Windows (Event ID 1116, 1117, 5007) et Sysmon peuvent contenir des indices d’exploitation, comme des analyses répétées suivies de modifications de configuration ou de créations de processus inattendues.
Surface d’attaque, exposition et mesures d’urgence avant le correctif
La surface d’attaque de la faille zero-day Microsoft Defender RedSun couvre tout système Windows où le service antivirus est actif, y compris les serveurs applicatifs critiques. Sur un poste client, un attaquant peut exploiter la faille via un fichier déposé dans un répertoire scanné automatiquement, alors que sur un serveur, l’exploitation peut viser des partages de fichiers ou des répertoires temporaires utilisés par des applications métiers connect. Dans les deux cas, l’élévation de privilèges SYSTEM transforme un accès standard en compromission totale du système, avec à la clé la possibilité de désactiver des contrôles, de déployer un second binaire et de se propager latéralement dans l’infrastructure Windows et le domaine Active Directory.
Les chercheurs sécurité évoquent plusieurs variantes, parfois regroupées sous des noms de campagnes comme BlueHammer RedSun ou Chaotic Eclipse, qui combinent la faille RedSun avec d’autres vulnérabilités CVE pour contourner les politiques de sécurité. Ces dénominations restent pour l’instant issues de travaux de recherche et de laboratoires, sans reconnaissance officielle par les éditeurs ni mention explicite dans les bulletins Microsoft, mais elles décrivent des chaînes d’attaque réalistes. Certaines chaînes d’exploitation utilisent des outils décrits comme RedSun Undefend ou Undefend RedSun, capables de désactiver partiellement Windows Defender après l’élévation de privilèges, puis de déployer un second fichier malveillant pour la persistance. Dans ce contexte, un simple retard sur le déploiement du Microsoft correctif transforme un incident isolé en compromission latérale de tout un domaine Active Directory, avec un risque de rebond vers d’autres environnements Windows Server interconnectés.
Avant même le déploiement complet du correctif, plusieurs mesures d’urgence s’imposent pour réduire le risque lié à cette nouvelle faille. D’abord, cartographier précisément les versions de Microsoft Defender et de Windows Defender présentes sur chaque machine Windows et chaque Windows Server, en identifiant les environnements les plus exposés comme les serveurs de fichiers et les bastions d’administration, par exemple via des commandes centralisées de type Get-MpComputerStatus ou des rapports d’inventaire. Ensuite, ajuster temporairement les politiques de sécurité pour limiter l’accès en écriture aux répertoires scannés automatiquement, en particulier pour les comptes à faibles privilèges système et pour les comptes de service applicatifs, en documentant les exceptions et en fixant un délai maximal de quelques jours pour revenir à la configuration nominale. Enfin, mettre en place des règles de détection spécifiques (par exemple via Sysmon Event ID 1, 7, 10 et 13) pour repérer la création ou la modification de fichiers exécutables et de clés de registre sensibles immédiatement après une analyse Defender, en s’appuyant sur des requêtes KQL ou des règles Sigma concrètes qui corrèlent ces événements dans un intervalle de temps inférieur à cinq minutes.
SOC, patching et gouvernance : quand le défenseur devient angle mort
Pour les SOC d’ETI françaises, déjà sous pression avec une pénurie mondiale de plusieurs millions de professionnels cyber, la faille zero-day Microsoft Defender RedSun ajoute une couche de complexité opérationnelle. Les journaux générés par Microsoft Security et par Windows Defender sont souvent considérés comme intrinsèquement fiables, ce qui crée un angle mort dans la détection d’une élévation de privilèges SYSTEM issue du composant de défense lui même. Les équipes doivent désormais intégrer des règles de corrélation spécifiques sur les événements liés au service Defender divulgués, notamment lors de la création ou modification inattendue de fichiers exécutables dans des répertoires système, ou de changements de configuration (Event ID 5007) juste après une analyse antivirus (Event ID 1116), en définissant des seuils clairs de déclenchement d’alerte.
Concrètement, un SOC mature va définir des indicateurs de compromission centrés sur l’exploitation de la faille zero, par exemple des séquences d’événements où un compte standard déclenche une analyse Defender suivie d’une modification de clés de registre sensibles. Les campagnes BlueHammer RedSun ou Chaotic Eclipse laissent souvent des traces dans les journaux de connect réseau, avec des connexions sortantes inhabituelles juste après l’élévation de privilèges, ce qui doit être intégré aux playbooks de réponse à incident. Une règle Sigma ou une requête KQL typique va corréler un événement Defender indiquant la détection ou l’analyse d’un fichier suspect avec, dans les cinq minutes, un événement de création de processus SYSTEM ou de modification de registre, puis une connexion sortante vers un domaine récemment enregistré, afin de repérer les IOCs associés à RedSun, par exemple via une requête KQL qui filtre sur EventID in (1116, 5007) et sur des processus enfants lancés par le service antivirus.
La politique de patching reste le point dur, comme le montrent encore les retours d’expérience du CESIN et de cabinets comme Wavestone ou Gartner sur le Patch Tuesday. Trop d’ETI traitent encore le Patch Tuesday comme une routine mensuelle, alors que la combinaison d’une nouvelle faille zero day et d’un composant critique comme Microsoft Defender impose un mode projet accéléré, avec tests ciblés et déploiement prioritaire sur les systèmes exposés. Pour les DSI et RSSI, la vraie métrique n’est pas le nombre de CVE corrigées, mais le délai entre la publication du Microsoft correctif et la fermeture effective de la faille zero-day sur chaque machine Windows en production, mesuré via un plan de déploiement en trois vagues (pilote, serveurs critiques, reste du parc) assorti de vérifications post-patch automatisées, incluant la vérification de la version du moteur Defender et la confirmation que la signature CVE-2024-26234 est bien prise en compte.
Statistiques clés sur la gestion des failles et la cybersécurité
- Part des vulnérabilités critiques exploitées dans les 7 jours suivant leur divulgation officielle, telle que mesurée par les rapports annuels de threat intelligence et les analyses de la base CVE.
- Pourcentage d’ETI françaises ayant industrialisé un processus de déploiement accéléré des correctifs de sécurité sur leurs environnements Windows Server, avec des indicateurs de performance suivis en comité de pilotage.
- Temps moyen de détection d’une élévation de privilèges SYSTEM par les SOC internes ou externalisés, comparé au temps moyen de remédiation après application du correctif Microsoft Defender.
- Écart entre le nombre de failles CVE publiées chaque mois et la capacité réelle de traitement par les équipes sécurité, mesuré en nombre de vulnérabilités effectivement corrigées dans les 30 jours.
Questions fréquentes des DSI sur la faille zero-day Microsoft Defender RedSun
Comment prioriser le déploiement du correctif RedSun dans un parc hétérogène Windows ?
La priorisation doit partir d’un inventaire précis des versions de Windows et de Microsoft Defender, en ciblant d’abord les serveurs exposés à Internet, les serveurs de fichiers et les postes à privilèges administrateur. Ensuite, il est pertinent de créer un lot pilote sur un échantillon représentatif, puis de basculer en déploiement massif dès validation fonctionnelle, en s’appuyant sur des outils de gestion de correctifs centralisés et sur la vérification de la version du moteur antivirus associée à CVE-2024-26234. Enfin, le suivi doit inclure des vérifications post déploiement pour s’assurer que la faille zero n’est plus exploitable sur les systèmes critiques, par exemple via des scans de vulnérabilités ciblés et la vérification de la version de moteur Defender sur chaque machine Windows, en fixant un objectif de fermeture complète de la faille en moins de deux cycles de Patch Tuesday.
Quels indicateurs de compromission spécifiques surveiller pour détecter une exploitation de RedSun ?
Les SOC doivent surveiller les événements d’élévation de privilèges SYSTEM anormaux, les modifications de fichiers exécutables dans les répertoires système et les changements inattendus de configuration de Windows Defender ou de Microsoft Security. Il est également utile de corréler ces signaux avec des connexions réseau sortantes inhabituelles juste après une analyse antivirus, en particulier vers des domaines récemment enregistrés. Enfin, toute désactivation partielle ou totale de l’antivirus, même temporaire, doit déclencher une investigation approfondie, en s’appuyant sur des règles Sysmon et des requêtes KQL ou Sigma qui lient les événements Defender, les créations de processus et les modifications de registre, par exemple en filtrant sur les Event ID 1, 7, 10, 13, 1116 et 5007 dans une fenêtre temporelle restreinte.
Faut il désactiver temporairement certaines fonctions de Microsoft Defender pour réduire la surface d’attaque ?
La désactivation complète de Microsoft Defender n’est pas recommandée, car elle ouvrirait d’autres vecteurs d’attaque plus immédiats. En revanche, il peut être pertinent de restreindre certaines fonctionnalités comme l’analyse automatique de répertoires partagés très exposés, le temps de déployer le correctif sur les serveurs concernés. Cette approche doit rester encadrée, documentée et limitée dans le temps, avec une validation conjointe DSI RSSI, et un plan de retour à la configuration nominale dès que le correctif RedSun est appliqué et vérifié sur l’ensemble des systèmes concernés, en s’assurant que les signatures et le moteur Defender sont bien à jour.
Comment intégrer la leçon RedSun dans la gouvernance globale de la sécurité ?
L’incident RedSun montre qu’un composant de défense peut devenir un vecteur d’attaque, ce qui impose de revoir les modèles de confiance implicite accordés aux outils de sécurité. Les DSI devraient intégrer ces scénarios dans leurs analyses de risques, leurs exercices de crise et leurs politiques de durcissement, en traitant les agents de sécurité comme tout autre logiciel à privilèges élevés. Cela passe aussi par une meilleure articulation entre gouvernance des correctifs, supervision SOC et audits réguliers de configuration des outils de défense, avec des tableaux de bord qui suivent explicitement les failles zero-day affectant les composants de sécurité et les délais de déploiement des correctifs Microsoft associés.
Quel rôle pour les audits externes face à des failles zero-day comme RedSun ?
Les audits externes menés par des cabinets spécialisés permettent de vérifier que les processus de patching, de supervision et de gestion des privilèges sont réellement appliqués sur le terrain, au delà des procédures. Ils peuvent aussi simuler des scénarios d’exploitation de faille zero-day pour tester la capacité de détection et de réaction des équipes internes. Pour un DSI, ces audits offrent un regard indépendant précieux pour arbitrer les investissements entre outils supplémentaires et renforcement des pratiques existantes, et pour s’assurer que les leçons tirées de RedSun sont bien intégrées dans la feuille de route de cybersécurité, en cohérence avec les recommandations issues des bulletins Microsoft et des analyses de la communauté de recherche.
