Attaque Download More RAM : contournement de VBS, HVCI et désactivation de Microsoft Defender

Introduction

En août 2026, une nouvelle technique d’attaque nommée Download More RAM a été dévoilée lors de la conférence USENIX Security 2026. Identifiée sous la référence CVE-2026-23670, cette méthode innovante cible une faiblesse matérielle des modules mémoire DDR4 et DDR5 pour contourner les mécanismes de sécurité les plus avancés de Windows, notamment Virtualization-Based Security (VBS) et Hypervisor-Protected Code Integrity (HVCI). Pire encore, elle permet de désactiver Microsoft Defender et d’autres solutions EDR. Dans cet article, nous analysons le fonctionnement de cette attaque, ses implications pour la sécurité des systèmes Windows et les mesures de protection que les organisations doivent déployer.

Qu’est-ce que l’attaque Download More RAM ?

Une vulnérabilité matérielle inédite

Contrairement aux exploits classiques du noyau Windows, l’attaque Download More RAM exploite une faiblesse au niveau du matériel : le bus Serial Presence Detect (SPD) des modules mémoire. Le SPD est une puce EEPROM présente sur chaque barrette de mémoire vive (DIMM) qui contient les informations de configuration essentielles : capacité, organisation des banques, timings, tension, etc. Au démarrage, le firmware de la carte mère lit ces données pour configurer correctement le contrôleur mémoire.

Sur certains modules grand public, l’EEPROM SPD n’est pas protégée en écriture. Un attaquant disposant déjà de privilèges administrateur local peut alors modifier ces données de configuration. En altérant la géométrie mémoire rapportée (nombre de rangs, de banques, etc.), il fait croire au système que le module contient davantage de RAM qu’il n’en possède physiquement. Dans les démonstrations, les chercheurs ont ainsi fait passer un module de 16 Go pour un module de 32 Go.

Le principe du memory aliasing

Cette manipulation entraîne un phénomène dit de memory aliasing : le système d’exploitation traite plusieurs adresses physiques comme distinctes alors qu’elles pointent en réalité vers les mêmes cellules DRAM. En pratique, une même zone mémoire devient accessible via deux adresses différentes, ce qui brise une hypothèse fondamentale du système d’exploitation, du processeur et de l’hyperviseur.

« L’attaque Download More RAM démontre que la sécurité logicielle, aussi robuste soit-elle, peut être compromise par une faiblesse matérielle sous-jacente. » - Extrait du papier de recherche présenté à USENIX Security 2026.

L’équipe de recherche a réussi à stabiliser Windows malgré cette configuration mémoire anormale, en utilisant un mécanisme de démarrage Secure Boot-compatible nommé removememory. Ce dernier permet de réserver des plages mémoire pour exclure les zones conflictuelles, rendant le système exploitable pour la suite de l’attaque.

Comment l’attaque contourne-t-elle VBS et HVCI ?

VBS et les Virtual Trust Levels

Virtualization-Based Security (VBS) utilise Hyper-V pour isoler des composants sensibles du noyau Windows ordinaire. Ces composants s’exécutent dans un environnement sécurisé appelé Virtual Trust Level 1 (VTL1), tandis que le noyau classique et les pilotes restent en VTL0. Parmi les éléments protégés figurent le Secure Kernel, Credential Guard, les processus en mode isolé et certaines bibliothèques de sécurité.

L’isolation offerte par VBS repose sur l’intégrité de la mémoire physique : les pages mémoire assignées à VTL1 ne doivent pas être accessibles depuis VTL0, même par un administrateur système. L’attaque Download More RAM brise cette séparation en créant des alias mémoire.

Accès aux régions protégées

Grâce au memory aliasing, les chercheurs ont pu lire et écrire dans des pages mémoire censées être réservées au Secure Kernel. Ils ont 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. La cible principale était skci.dll, la bibliothèque du Secure Kernel Code Integrity, chargée de vérifier la liste noire des pilotes vulnérables (driver blocklist).

En patchant skci.dll, les chercheurs ont désactivé les vérifications qui empêchent le chargement de pilotes signés mais vulnérables. Une fois ces pilotes chargés, ils disposaient de primitives de lecture/écriture directes sur la mémoire physique, annulant complètement les barrières de VBS et HVCI.

Chaîne d’attaque complète

1. Reconnaissance : identifier un module mémoire avec SPD non protégé en écriture.
2. Manipulation SPD : modifier les paramètres de géométrie pour créer un alias mémoire.
3. Stabilisation : utiliser removememory pour exclure les zones conflictuelles et démarrer Windows.
4. Inspection mémoire : grâce aux alias, cartographier les pages du Secure Kernel.
5. Patch de skci.dll : altérer la bibliothèque de vérification d’intégrité du noyau sécurisé.
6. Chargement d’un pilote vulnérable : utiliser un pilote signé mais blacklisté pour obtenir un accès complet à la mémoire physique.
7. Désactivation des protections : neutraliser Microsoft Defender, l’EDR, ou toute autre sécurité reposant sur VBS/HVCI.

Les conséquences : désactivation d’EDR et de Microsoft Defender

Impact sur les solutions de sécurité

Une fois l’attaque menée à son terme, l’attaquant peut désactiver ou contourner les produits de sécurité qui s’appuient sur VBS et HVCI pour leur intégrité. Lors des démonstrations, les chercheurs ont réussi à :

• Désactiver Microsoft Defender (antivirus et EDR) ;
• Modifier la configuration de Sophos Intercept X ;
• Altérer le code d’une enclave protégée par VBS ;
• Interférer avec des produits anti-triche au niveau noyau.

Ces scénarios montrent que l’attaque ne se limite pas à un simple contournement : elle offre un contrôle étendu sur les mécanismes de sécurité de la plateforme Windows.

Exemple concret : neutralisation de Microsoft Defender

« En pratique, nous avons pu charger un pilote non autorisé après avoir désactivé les vérifications de skci.dll. Microsoft Defender, qui s’appuie sur l’intégrité du noyau pour ses propres détections, est devenu aveugle à notre activité. » - Extrait de la présentation USENIX Security 2026.

Ce cas illustre la confiance que placent les EDR dans l’isolation offerte par VBS : une fois celle-ci compromise, toute la chaîne de sécurité s’effondre.

Quels modules mémoire sont concernés ?

Modules testés par les chercheurs

L’étude n’a pas été exhaustive, mais les chercheurs ont identifié des modules avec SPD non protégé chez plusieurs fabricants grand public :

Il est important de noter que la protection peut varier au sein d’une même marque, selon le modèle, la révision du firmware SPD et la date de fabrication. Les modules équipés d’une protection en écriture correcte sur l’EEPROM SPD ne sont pas vulnérables à cette attaque logicielle.

Comment vérifier la vulnérabilité ?

Pour les responsables sécurité, il est possible de vérifier si un module est protégé en utilisant des outils comme RWEverything ou spd-tools sous Linux. Voici un exemple de commande pour lire l’EEPROM SPD sous Linux :

# Installer i2c-tools
sudo apt-get install i2c-tools
# Détecter les bus I2C
i2cdetect -l
# Lire le SPD sur le bus 0, adresse 0x50 (premier emplacement)
sudo i2cdump -y 0 0x50

Si l’écriture est possible, le module est potentiellement vulnérable. Toutefois, cette vérification nécessite un accès physique ou des privilèges élevés.

Correctif et recommandations de Microsoft

Mise à jour de sécurité d’avril 2026

Microsoft a publié un correctif pour CVE-2026-23670 dans ses mises à jour de sécurité d’avril 2026. Ce correctif désactive le mécanisme removememory utilisé par les chercheurs pour stabiliser le système après la manipulation SPD. Sur les systèmes à jour avec Secure Boot activé, la chaîne d’attaque publiée n’est plus fonctionnelle.

Recommandations immédiates :

• Déployer sans délai les dernières mises à jour de sécurité Windows.
• Vérifier que Secure Boot est activé sur tous les postes.
• Surveiller les modifications inattendues de la configuration de démarrage (BCD).
• Mettre en place une détection des tentatives de chargement de pilotes vulnérables (ex : via les règles de blocage WDAC ou AppLocker).

Limites du correctif

Microsoft a choisi de corriger la méthode d’exploitation plutôt que la vulnérabilité matérielle elle-même. En effet, le SPD non protégé reste un problème physique. Un attaquant motivé pourrait trouver une autre voie pour exploiter le memory aliasing, par exemple en utilisant un accès physique pour flasher l’EEPROM ou en développant une technique de stabilisation alternative.

Ainsi, le correctif Microsoft est une mesure de mitigation indispensable, mais elle ne doit pas être considérée comme une solution définitive. La protection des SPD doit être traitée comme un contrôle de défense en profondeur.

Mesures de protection pour les organisations

Audit des modules mémoire

Les équipes sécurité doivent identifier les postes équipés de modules mémoire potentiellement vulnérables. Priorité aux postes à risque : développeurs, administrateurs, utilisateurs à privilèges. Contacter les fabricants pour connaître l’état de la protection SPD de leurs produits.

Renforcement de la configuration UEFI

De nombreuses cartes mères récentes offrent une option de protection en écriture du SPD dans les paramètres UEFI/BIOS. Activer cette option si disponible. Consulter le manuel du fabricant de la carte mère ou du module.

Surveillance et détection

• Surveiller les événements de chargement de pilotes : les tentatives de chargement de pilotes blacklistés (ex : ceux figurant dans la liste de Microsoft) doivent déclencher une alerte.
• Détecter les modifications du BCD : l’utilisation de removememory ou d’autres paramètres de démarrage inhabituels peut être un indicateur.
• Analyser les accès mémoire anormaux : les solutions EDR avancées peuvent détecter des patterns d’accès mémoire suspects.

Recommandations de l’ANSSI

Dans le cadre de la défense en profondeur, l’ANSSI recommande de :

1. Maintenir les systèmes à jour (correctifs Microsoft, firmware UEFI).
2. Activer Secure Boot et les fonctionnalités de sécurité du noyau (VBS, HVCI, Credential Guard).
3. Restreindre les privilèges administrateur local au strict nécessaire.
4. Utiliser des solutions de blocage d’applications (AppLocker, WDAC).
5. Réaliser des audits matériels réguliers, notamment sur les postes sensibles.

Conclusion

L’attaque Download More RAM (CVE-2026-23670) illustre une nouvelle génération de menaces qui exploitent les faiblesses matérielles pour contourner des mécanismes de sécurité logicielle pourtant réputés robustes. En ciblant le SPD des modules mémoire, elle parvient à neutraliser VBS, HVCI et les EDR comme Microsoft Defender. Si le correctif de Microsoft bloque la méthode actuelle, la vulnérabilité sous-jacente demeure.

Pour les organisations, l’urgence est double : appliquer les mises à jour de sécurité et engager une réflexion plus large sur la sécurité de la chaîne matérielle. La protection des SPD, l’audit des modules et une surveillance renforcée sont désormais des éléments incontournables de la stratégie de défense. La leçon de cette attaque est claire : la sécurité ne peut plus se limiter au logiciel ; le matériel doit être intégré au périmètre de confiance.