« Download More RAM » : l’attaque qui contourne Windows VBS et HVCI - Tout savoir sur CVE-2026-23670

L’USENIX Security 2026 a dévoilé une attaque qui repousse les limites de la compromission matérielle. Baptisée « Download More RAM », cette technique ne requiert ni rootkit ni exploit noyau traditionnel. Elle cible une faiblesse de configuration dans les modules mémoire DDR4 et DDR5 grand public. En modifiant les données de configuration SPD (Serial Presence Detect) non protégées en écriture, les chercheurs ont réussi à créer un aliasing mémoire, déjouant ainsi les mécanismes de sécurité les plus avancés de Windows : Virtualization-Based Security (VBS) et Hypervisor-Protected Code Integrity (HVCI). Pire encore, l’attaque peut désactiver Microsoft Defender et d’autres solutions EDR. Référencée CVE-2026-23670, cette vulnérabilité a reçu un correctif de Microsoft en avril 2026, mais les implications matérielles persistent. Plongeons dans les détails techniques et les parades à mettre en œuvre pour protéger votre infrastructure.

« Download More RAM » : un contournement inédit de la sécurité matérielle Windows

L’attaque « Download More RAM » exploite non pas une vulnérabilité du code de Windows, mais une faille dans la confiance accordée aux données de configuration des barrettes mémoire. Elle suppose que l’attaquant dispose déjà de droits d’administrateur local - une condition courante après une escalade de privilèges initiale. Dans la pratique, de nombreuses organisations peinent à restreindre ces droits sur l’ensemble de leur parc, comme le souligne régulièrement l’ANSSI. Une fois ces droits acquis, le chemin vers le cœur du système est étonnamment simple.

En altérant les données SPD, l’attaquant modifie la géométrie mémoire perçue par le système d’exploitation. Par exemple, un module de 8 Go peut être déclaré comme un module de 16 Go. Le système d’exploitation, le processeur et l’hyperviseur sont alors confrontés à une mémoire qui n’existe pas physiquement. Cette situation produit un aliasing : plusieurs adresses physiques pointent vers les mêmes cellules DRAM. Or, les mécanismes d’isolation comme VBS et HVCI reposent sur une séparation stricte des espaces d’adressage. En exploitant l’aliasing, les chercheurs ont pu accéder à des zones mémoire réservées au Secure Kernel, y compris les données protégées par Virtual Trust Level 1.

« L’attaque démontre que l’isolation offerte par VBS peut être brisée sans jamais toucher au microcode ou à l’hyperviseur lui-même. » - Communication USENIX.

Cette attaque diffère des classiques exploits du noyau car elle détourne des fonctionnalités légitimes comme le paramètre de démarrage removememory pour stabiliser l’aliasing. Elle illustre la difficulté de sécuriser un système dont le matériel lui-même peut mentir sur sa configuration.

Comment l’attaque exploite le SPD des barrettes mémoire

Qu’est-ce que le SPD et pourquoi sa protection est cruciale

Le SPD (Serial Presence Detect) est une mémoire EEPROM présente sur chaque barrette DIMM. Elle contient des informations essentielles pour le démarrage : capacité, vitesse, timings, organisation des banques, etc. Le firmware de la carte mère lit ces données pour configurer le contrôleur mémoire. Idéalement, après la phase de test en usine, le SPD doit être verrouillé en écriture. Mais de nombreux modules grand public, comme ceux de Corsair, G.Skill ou ADATA, ne verrouillent pas systématiquement cette zone. Les chercheurs de l’USENIX ont découvert que sur certains modules, il est possible de réécrire le SPD simplement en adressant le bus I2C/SMBus sur lequel l’EEPROM est connectée. Des outils comme RWEverything ou MmioTools permettent d’écrire sur ce bus depuis Windows sans matériel supplémentaire. Une fois le SPD modifié, le changement peut être activé par un cycle de redémarrage ou via un mécanisme de retrait et réinsertion de mémoire simulé.

La création d’un aliasing mémoire pour briser VBS

Avec un SPD falsifié, le système redémarre en voyant une capacité mémoire différente. Dans le cas de l’attaque, la capacité déclarée est supérieure à la capacité physique. Cela conduit à une incohérence dans la table des pages du noyau. L’hyperviseur Windows (Hyper-V) qui sert de base à VBS et HVCI suppose que chaque adresse physique correspond à une cellule DRAM unique. L’aliasing brise cette hypothèse.

Les chercheurs ont utilisé une technique de stabilisation du système. Ils ont employé le paramètre de démarrage removememory (supporté par le chargeur Secure Boot) pour exclure certaines plages d’adresses de la vue du noyau. En choisissant judicieusement les plages à retirer, ils ont pu aligner les adresses aliasées et les rendre accessibles sans planter le système. Une fois cet environnement stable, ils ont utilisé des outils de diagnostic mémoire signés (comme certains pilotes OEM) pour inspecter et écrire dans les zones aliasées.

« L’astuce la plus redoutable est l’utilisation de pilotes légitimes pour effectuer les opérations sensibles, rendant la détection extrêmement difficile. » - Un expert en sécurité des plateformes Windows.

Impact concret sur les défenses : Microsoft Defender, HVCI et EDR

Désactivation des antivirus et contournement de l’intégrité du code

Avec l’aliasing sous contrôle, l’étape suivante est de désactiver les protections du Secure Kernel. La bibliothèque skci.dll (Secure Kernel Code Integrity) maintient la liste noire des pilotes interdits. En patchant cette DLL dans la mémoire aliasée, les chercheurs ont pu ajouter des exceptions pour charger des pilotes signés mais vulnérables qui offrent un accès mémoire complet (lecture/écriture). Une fois ce pilote malveillant chargé, l’attaquant peut lire ou modifier n’importe quelle zone mémoire, y compris les structures de données des produits de sécurité.

Les démonstrations ont inclus :

• Désactivation de Microsoft Defender : modification des structures internes pour empêcher le démarrage du service.
• Contournement de Sophos Intercept X : altération des hooks noyau installés par l’EDR.
• Modification d’enclaves VBS : changement de code dans des enclaves de type Virtual Trust Level 1.
• Impact sur anti-cheat : les protections noyau des jeux en ligne ont pu être inhibées, démontrant la portée transverse de l’attaque.

Selon les chercheurs, l’attaque parvient à doubler la capacité de RAM perçue, créant un aliasing suffisamment large pour atteindre les zones critiques. Ce constat a été présenté avec des preuves de concept lors de la conférence USENIX Security 2026.

Utilisation d’outils légitimes pour la frappe finale

L’ensemble de la chaîne d’attaque repose sur des composants signés. Le paramètre removememory est une fonctionnalité légitime de démarrage. Les outils de diagnostic mémoire sont souvent signés par les fabricants. Les pilotes vulnérables mais signés font partie des vecteurs classiques déjà exploités dans la nature. En combinant ces éléments, l’attaque ne déclenche pas les alarmes habituelles. Ni l’intégrité du code (HVCI) ni Windows Defender Application Control (WDAC) n’ont bloqué ces composants puisqu’ils sont considérés comme de confiance. Cette capacité à rester sous le radar renforce la nécessité d’une défense en profondeur qui ne repose pas uniquement sur la signature des binaires.

Correctif Microsoft et bonnes pratiques de protection

Le correctif d’avril 2026 : ce qu’il fait et ce qu’il ne fait pas

Microsoft a réagi rapidement en publiant un correctif pour CVE-2026-23670 dans ses mises à jour de sécurité d’avril 2026. Ce correctif modifie le chargeur de démarrage pour bloquer l’utilisation du paramètre removememory lorsque Secure Boot est activé. Puisque la stabilisation de l’aliasing nécessite ce paramètre dans la démonstration, la chaîne d’attaque est coupée. Cependant, il est important de comprendre que le correctif ne résout pas le problème fondamental : des SPD non protégés en écriture. Si un autre moyen de stabiliser l’aliasing est trouvé (par exemple via un autre paramètre de démarrage ou un outil firmware), l’attaque pourrait redevenir viable.

Vérifier et renforcer la protection SPD de vos modules mémoire

Les équipes sécurité doivent désormais intégrer l’audit SPD dans leur check-list de sécurisation des postes de travail. Voici les étapes recommandées :

1. Identifier les modules vulnérables : utilisez un outil comme decode-dimms sous Linux ou, sous Windows, des scripts PowerShell qui interrogent le WMI pour lister les fabricants et modèles. Contactez le fabricant pour savoir si la protection SPD est active. Sur certaines cartes mères professionnelles, une option « SPD Write Protect » est disponible dans les paramètres avancés de l’UEFI.
2. Limiter l’accès administrateur local : réduisez le nombre d’utilisateurs disposant de droits administrateur sur les postes sensibles, car l’attaque nécessite ces privilèges. La gestion des privilèges via des solutions de type Privileged Access Management (PAM) peut limiter ce risque.
3. Déployer la mise à jour Microsoft : assurez-vous que le correctif d’avril 2026 est installé et que Secure Boot est activé. Un outil de gestion des correctifs comme WSUS ou SCCM peut aider. Vérifiez Secure Boot avec la commande PowerShell suivante :

Confirm-SecureBootUEFI

Si la commande retourne True, Secure Boot est actif.

4. Surveiller les événements de sécurité : activez l’audit des modifications de configuration de démarrage (Event ID 5139, 5140 liés au Secure Boot) et le chargement de pilotes. Les EDR peuvent être configurés pour détecter l’écriture dans les zones mémoire normalement inaccessibles.

Actions prioritaires pour les RSSI et administrateurs

• Mettre à jour : déployer la mise à jour de sécurité d’avril 2026 sur l’ensemble du parc Windows.
• Activer Secure Boot : vérifier que Secure Boot est activé dans tous les firmwares.
• Auditer les barrettes mémoire : compiler une liste des modèles utilisés et demander aux fabricants si le SPD est protégé en écriture. Envisager le remplacement des modules non protégés sur les postes critiques.
• Configurer WDAC : renforcer Windows Defender Application Control pour ne permettre que l’exécution de logiciels approuvés.
• Mettre en place des règles ASR : les règles de réduction de la surface d’attaque peuvent bloquer certains outils de diagnostic signés utilisés dans l’attaque.
• Surveiller l’activité mémoire : utilisez une solution EDR capable de détecter des accès anormaux à la mémoire du noyau.
• Former les administrateurs : sensibiliser aux risques liés à l’utilisation d’outils non vérifiés sur le bus SMBus.

Conclusion : le matériel devient une frontière de sécurité à part entière

L’attaque « Download More RAM » illustre parfaitement la complexification du paysage des menaces. Les protections logicielles, même les plus sophistiquées comme VBS et HVCI, ne suffisent plus si le socle matériel présente des failles de configuration. Le correctif Microsoft a colmaté une brèche spécifique, mais la cause racine - des SPD non verrouillés - reste une menace latente. Les administrateurs et RSSI doivent intégrer ce nouveau facteur de risque dans leur analyse : la mémoire vive n’est plus un simple composant passif, c’est une couche de confiance qui doit être auditée et protégée.

En attendant une normalisation de la protection SPD par les constructeurs (peut-être dans le cadre d’une certification comme Memory Protection Profile), la défense en profondeur reste la seule approche viable. Appliquez les correctifs sans délai, activez Secure Boot, limitez les privilèges administrateur et, surtout, n’oubliez pas de vérifier la sécurité de vos barrettes mémoire. La prochaine attaque matérielle pourrait être encore plus subtile, mais avec une veille continue et des audits réguliers, vous pouvez réduire significativement la surface d’exposition.

Cet article s’appuie sur des informations présentées à l’USENIX Security 2026, sur le bulletin de sécurité Microsoft relatif à CVE-2026-23670, ainsi que sur les recommandations de l’ANSSI concernant la sécurisation des postes Windows.