Attaque Download More RAM : contournement de VBS, HVCI et désactivation de Windows Defender
Aurélien Fontevive
Imaginez un instant qu’un simple fichier téléchargé puisse non seulement duper votre système d’exploitation en lui faisant croire qu’il dispose de plus de mémoire vive, mais aussi désarmer l’ensemble de ses défenses les plus critiques. Ce scénario, digne d’un film de science-fiction, est devenu une réalité tangible avec l’attaque Download More RAM. Présentée à l’USENIX Security 2026 et identifiée sous la référence CVE-2026-23670, cette technique inédite cible une vulnérabilité matérielle oubliée pour démanteler les piliers de la sécurité Windows moderne. Contrairement à un exploit de noyau classique qui cherche une faille dans le code, elle s’attaque aux fondations physiques de la gestion mémoire. Dans cet article, nous décortiquons le fonctionnement de cette menace, analysons ses impacts sur les infrastructures Virtualization-Based Security (VBS), Hypervisor-Protected Code Integrity (HVCI) et Microsoft Defender, et vous fournissons les étapes essentielles pour vous en prémunir.
Qu’est-ce que l’attaque Download More RAM ?
L’attaque ‘Download More RAM’, ou CVE-2026-23670, est une technique d’exploitation qui cible une faiblesse de configuration matérielle présente sur certains modules de mémoire DDR4 et DDR5 grand public. Pour bien comprendre la menace, il faut s’intéresser à un composant méconnu : le Serial Presence Detect (SPD).
Le SPD est une petite mémoire EEPROM située sur chaque barrette de mémoire DIMM. Son rôle est crucial : il stocke les informations de configuration essentielles que le BIOS/UEFI lit au démarrage pour configurer le contrôleur mémoire. Ces informations incluent la capacité du module, sa vitesse, ses timings, et sa tension de fonctionnement. Historiquement, le SPD est accessible en écriture pour permettre l’overclocking et les profils XMP/EXPO, ce qui en fait une surface d’attaque idéale.
“Ce qui rend cette attaque particulièrement redoutable, c’est qu’elle ne nécessite pas de démonter physiquement la machine, ni de flasher la mémoire. Un accès administrateur local suffit pour altérer les données SPD.”
En modifiant les informations de l’EEPROM SPD, un attaquant fait croire au système que la barrette de mémoire dispose d’une capacité supérieure à sa capacité physique réelle. Dans les démonstrations des chercheurs de l’USENIX, ils ont réussi à faire croire au système que le module avait une capacité doublée.
Cette manipulation crée un phénomène de memory aliasing (aliasing mémoire). Concrètement, Windows traite alors des adresses physiques distinctes comme des emplacements uniques, alors qu’elles pointent vers les mêmes cellules DRAM. Ce bris de postulat fondamental est la clé de voûte de l’attaque. Le nom ‘Download More RAM’ fait ironiquement référence à la possibilité d’augmenter la mémoire système par un simple artifice logiciel, sans ajout physique de mémoire.
Pourquoi VBS et HVCI sont-ils vulnérables ?
Windows Virtualization-Based Security (VBS) est l’un des piliers de la sécurité moderne de Microsoft. Il utilise l’hyperviseur Hyper-V pour créer et isoler des régions mémoire sécurisées, appelées Virtual Trust Levels (VTL). Le VTL0 héberge le noyau Windows standard, tandis que le VTL1 héberge le Secure Kernel et des composants sensibles comme Credential Guard.
Le rôle du Secure Kernel et des VTL
Hypervisor-Protected Code Integrity (HVCI) s’appuie sur cette isolation pour garantir que seuls des pilotes signés et intègres sont chargés dans le noyau. La séparation entre VTL0 et VTL1 est considérée comme une barrière infranchissable depuis le noyau normal.
L’exploitation de l’aliasing mémoire
L’aliasing mémoire créé par l’attaque Download More RAM brise cette isolation de manière élégante. En manipulant les données SPD, l’attaquant crée des correspondances d’adresses physiques qui, du point de vue du processeur et de l’hyperviseur, devraient être strictement séparées. Des régions mémoire censées être réservées au Secure Kernel (VTL1) deviennent accessibles depuis le noyau normal (VTL0).
Voici les piliers de sécurité directement compromis :
- Virtual Trust Levels (VTL) : La barrière fondamentale entre VTL0 et VTL1 est annulée. Un code s’exécutant dans le noyau normal peut lire et écrire dans la mémoire du Secure Kernel sans déclencher d’exception.
- Secure Kernel Code Integrity (skci.dll) : Ce module critique, qui maintient la liste des pilotes bloqués par Microsoft (la vulnerable driver blocklist), devient modifiable. Les chercheurs ont démontré sa modification pour désactiver cette liste.
- Credential Guard : Les secrets d’authentification (hashs NTLM, tickets Kerberos, clés) isolés dans le VTL1 deviennent potentiellement lisibles et modifiables.
- Microsoft Defender et EDR : Les processus de l’antivirus et des solutions de détection et réponse (EDR) tierces, qui s’appuient sur l’intégrité du noyau, peuvent être désactivés ou leurs signatures falsifiées.
En pratique, l’équipe de recherche a utilisé des outils signés légitimes pour inspecter la mémoire aliasée, puis un mécanisme de RAM-disk pour appliquer des modifications ciblées. Le maillon faible n’est pas un bug du noyau, mais l’architecture mémoire elle-même.
Les conséquences concrètes pour les entreprises
Les implications de CVE-2026-23670 sont vastes et touchent directement l’intégrité des postes de travail et des serveurs. Une fois l’isolation VBS contournée, l’attaquant dispose d’un accès privilégié à l’ensemble de la mémoire physique, ce qui ouvre la voie à des scénarios d’attaque avancés.
Tableau des impacts par couche de sécurité :
| Couche de Sécurité | Fonction Normale | Impact de Download More RAM |
|---|---|---|
| Virtualization-Based Security (VBS) | Isole le Secure Kernel et les données sensibles (Credential Guard). | L’isolation est compromise. Accès total à la mémoire VTL1. |
| Hypervisor-Protected Code Integrity (HVCI) | Empêche le chargement de pilotes non signés ou non conformes. | La vérification d’intégrité est contournée via la modification de skci.dll. Chargement de pilotes malveillants signés. |
| Microsoft Defender / EDR | Détecte et bloque les menaces au niveau noyau. | Les processus de l’EDR peuvent être désactivés ou rendus aveugles. |
| Anti-Cheat (jeux vidéo) | Protège l’intégrité des jeux. | Les mécanismes de détection de triche basés sur le noyau sont neutralisés. |
“L’équipe de recherche a démontré des scénarios impliquant la désactivation de Microsoft Defender, des impacts sur Sophos Intercept X, la modification de code exécuté dans des enclaves VBS, et l’interférence avec des produits anti-triche au niveau noyau.”
Dans la pratique, pour les équipes SOC, cela signifie qu’un attaquant disposant de droits administrateur local peut, via cette technique, désactiver les protections les plus avancées sans déclencher les alertes habituelles. La chaîne d’attaque typique implique le chargement d’un pilote signé mais vulnérable (comme un pilote de gestion de matériel obsolète), offrant des primitives de lecture/écriture mémoire physique complètes. Selon les chercheurs de l’USENIX, la stabilité du système est maintenue pendant l’exploitation, rendant la détection par l’utilisateur final extrêmement difficile.
Prenons l’exemple d’un cabinet d’avocats utilisant Windows Defender et Credential Guard pour protéger l’accès à son système de gestion de documents. Un attaquant compromet le poste d’un collaborateur via un hameçonnage et obtient des droits administrateur local. En exploitant CVE-2026-23670, il contourne Credential Guard, récupère les identifiants d’un administrateur de domaine, et désactive Windows Defender sur les autres postes pour déployer un rançongiciel. L’attaque Download More RAM a servi de catalyseur pour neutraliser l’ensemble des défenses de l’infrastructure.
Matériels concernés et configuration SPD
Tous les systèmes ne sont pas vulnérables. L’attaque cible spécifiquement les modules mémoire dont l’EEPROM SPD est accessible en écriture. L’étude de l’USENIX a identifié des configurations à risque sur des produits grand public de marques telles que Corsair, G.Skill et ADATA. Il est important de noter que cette enquête n’était pas exhaustive, et d’autres fabricants peuvent être concernés.
Il est crucial de comprendre que la protection SPD n’est pas uniforme. Elle peut varier selon le fabricant, la gamme de produit, et même la version du firmware de la mémoire. Un module haut de gamme destiné à l’overclocking sera plus susceptible d’avoir un SPD déverrouillé qu’un module de base pour PC de bureau.
Facteurs de risque matériels à évaluer :
- Type de mémoire : Les DDR4 et DDR5 grand public sont les plus exposées. Les modules serveurs (ECC Registered) intègrent souvent une protection SPD renforcée et verrouillée en usine.
- Protection SPD : Vérifiez si le fabricant de votre mémoire verrouille l’EEPROM SPD en écriture. Cette information est rarement publique et nécessite une requête directe au support technique ou une analyse approfondie du firmware du module.
- Configuration BIOS/UEFI : Certaines cartes mères offrent des options de protection SPD. Leur activation est une mesure de défense en profondeur immédiate et fortement recommandée.
- Firmware de la carte mère : Un firmware obsolète peut exposer des vulnérabilités supplémentaires ou ne pas exposer les options de protection nécessaires pour verrouiller le SPD.
Comment se protéger de CVE-2026-23670 ?
Microsoft a pris cette menace très au sérieux. Un correctif a été déployé dans le cadre des mises à jour de sécurité d’avril 2026 (Patch Tuesday). Ce correctif supprime la fonctionnalité removememory de la configuration de démarrage compatible Secure Boot, que les chercheurs utilisaient pour stabiliser le système après l’injection des fausses données SPD. Les systèmes à jour avec Secure Boot activé sont protégés contre la chaîne d’attaque actuellement documentée.
“La mise à jour de Microsoft désamorce l’exploitation logicielle, mais la cause racine matérielle (le SPD accessible en écriture) persiste. La protection doit donc être envisagée comme une couche de défense en profondeur, et non comme une solution miracle.”
Voici les vérifications essentielles à effectuer sur vos systèmes :
# Vérifier l'état de Secure Boot
Confirm-SecureBootUEFI
# Vérifier les paramètres de démarrage (bcdedit)
bcdedit /enum
# Vérifier l'état de VBS
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
# Vérifier les mises à jour installées (exemple pour le correctif d'avril 2026)
Get-HotFix -Id "KB5xxxxx" # Remplacer par l'ID du correctif
En complément du correctif Microsoft, il est impératif d’auditer votre parc matériel. Contactez les fabricants de vos modules mémoire pour connaître l’état de la protection SPD. La surveillance des tentatives de chargement de pilotes vulnérables, des modifications de la configuration de démarrage, et des accès mémoire anormaux doit être renforcée dans vos outils SIEM. L’activation de l’audit avancé pour les modifications de la configuration de démarrage est une piste à explorer.
Indicateurs de compromission (IoC) à surveiller :
- Modifications inattendues de la configuration de démarrage (BcdEdit).
- Tentatives de chargement de pilotes vulnérables connus (événements Code Integrity 3000/3001).
- Accès anormaux au bus I2C/SMBus depuis l’espace utilisateur.
- Redémarrages inexpliqués suivis de modifications de la mémoire système.
Mise en œuvre : plan d’action pour les RSSI
Face à cette menace, la réactivité est clé. Voici les étapes à suivre pour sécuriser votre infrastructure contre l’attaque Download More RAM :
- Déployer les correctifs en urgence : Traitez CVE-2026-23670 avec une priorité critique. Le correctif d’avril 2026 est indispensable. Utilisez vos outils de gestion de correctifs (WSUS, SCCM, Intune) pour un déploiement rapide.
- Vérifier Secure Boot : Assurez-vous que Secure Boot est activé et correctement configuré sur l’ensemble de vos postes et serveurs Windows. Un script de vérification automatisé peut être déployé via GPO.
- Auditer le parc matériel : Identifiez les machines équipées de modules DDR4/DDR5 grand public, spécifiquement ceux des marques identifiées (Corsair, G.Skill, ADATA). Évaluez leur exposition en consultant les spécifications techniques.
- Configurer les BIOS/UEFI : Activez toutes les options de protection SPD disponibles dans les paramètres du firmware de vos machines. Documentez ces paramètres et intégrez-les à votre politique de configuration de base (benchmark de sécurité).
- Renforcer la surveillance : Mettez en place des alertes sur les tentatives de chargement de pilotes vulnérables, les modifications de la configuration de démarrage, et les comportements mémoire anormaux via votre SIEM. Les règles de corrélation doivent se concentrer sur les événements Windows 5136 et les événements 3000/3001 de Code Integrity. La détection d’outils d’accès à la mémoire physique comme WinDbg ou PCILeech en dehors des contextes de développement doit également être une priorité.
- Appliquer le principe du moindre privilège : Limitez strictement les droits administrateur local. Un accès administrateur est un prérequis indispensable à la réalisation de l’attaque. Sa limitation est un frein majeur et une barrière de sécurité fondamentale. Envisagez l’utilisation de solutions de Privileged Access Management (PAM) pour élever temporairement les privilèges et les révoquer automatiquement, réduisant ainsi la fenêtre d’opportunité pour un attaquant.
Conclusion : un réveil brutal sur la sécurité matérielle
L’attaque Download More RAM (CVE-2026-23670) représente un changement de paradigme dans le paysage des menaces. En ciblant une faiblesse matérielle oubliée - l’EEPROM SPD - elle démantèle les défenses logicielles les plus avancées de Windows, que sont VBS et HVCI. Elle nous rappelle brutalement que la sécurité est une chaîne dont le maillon le plus faible peut se trouver dans un simple module mémoire.
La réactivité de Microsoft avec son correctif d’avril 2026 est salutaire, mais la responsabilité incombe désormais aux équipes IT de vérifier l’intégrité de leur parc matériel et d’appliquer une stratégie de défense en profondeur. En suivant ce plan d’action, vous renforcez votre résilience face aux attaques ciblant le matériel, une exigence croissante des référentiels comme l’ISO 27001 et les recommandations de l’ANSSI. Ne négligez pas cet avertissement : si un attaquant peut ’télécharger plus de RAM’, il peut aussi télécharger le contrôle total de votre système. Agissez dès aujourd’hui pour auditer vos configurations, déployer les correctifs, et appliquer les principes du moindre privilège. La sécurité de votre infrastructure en dépend.