Attaque « Download More RAM » : un contournement critique de VBS et HVCI sous Windows

Et si votre module de sécurité le plus avancé, censé isoler les processus critiques du noyau Windows, pouvait être neutralisé sans même toucher à votre disque dur ? Cette menace n’est plus théorique. Lors de l’USENIX Security 2026, une conférence de référence en cybersécurité, des chercheurs ont dévoilé une technique d’attaque inédite, baptisée « Download More RAM », qui permet de contourner la Virtualization-Based Security (VBS) et l’Hypervisor-Protected Code Integrity (HVCI) de Microsoft. Identifiée sous la référence CVE-2026-23670, cette vulnérabilité ne repose pas sur un pilote défaillant, mais sur une faiblesse matérielle insoupçonnée : la configuration des barrettes de mémoire vive. Elle cible spécifiquement les modules DDR4 et DDR5 dont le SPD (Serial Presence Detect) n’est pas protégé en écriture. Selon une estimation des chercheurs, des millions de machines dans le monde, dont une part importante en France, pourraient être concernées.

« Download More RAM » : une menace qui frappe à la racine du hardware

Contrairement à une exploitation classique du noyau Windows, l’attaque « Download More RAM » cible une configuration matérielle spécifique présente sur certains modules de mémoire DDR4 et DDR5 grand public. Le nom provocateur de l’attaque fait référence à la capacité du système à détecter plus de mémoire que physiquement installée, comme si celle-ci était « téléchargée ». Pourtant, ce n’est pas un bug logiciel classique. L’attaque exploite une faiblesse de conception au niveau de l’interface entre le système d’exploitation et le firmware de la mémoire.

Le rôle clé du SPD (Serial Presence Detect)

La clé de voûte de cette attaque réside dans le Serial Presence Detect (SPD). Il s’agit d’une puce EEPROM située sur chaque barrette de mémoire (DIMM) qui contient les informations de configuration essentielles : capacité, vitesse, timings, et fabricant. C’est cette puce que la carte mère interroge au démarrage pour configurer le contrôleur mémoire. Le SPD est normalement programmé en usine, mais de nombreux fabricants laissent une fenêtre d’écriture active pour permettre les profils XMP (eXtreme Memory Profile) ou EXPO (Extended Profiles for Overclocking), très prisés des gamers et des professionnels de la création.

Les chercheurs de l’USENIX ont découvert que de nombreux modules grand public, notamment de marques Corsair, G.Skill et ADATA, ne verrouillent pas l’EEPROM du SPD en écriture. Un attaquant disposant de privilèges administrateur locaux peut alors modifier ces données de configuration. L’attaque ne nécessite pas de démonter physiquement la machine ni d’utiliser un programmateur externe ; tout se fait par logiciel via l’interface SMBus.

L’exploitation de la mémoire fantôme (Memory Aliasing)

En modifiant les paramètres géométriques de la mémoire (nombre de banques, rangées, colonnes), l’attaquant force le système à croire que le module contient une capacité double, voire plus. Cette manipulation crée un état dangereux appelé memory aliasing : Windows traite plusieurs adresses physiques comme des emplacements distincts, alors qu’elles pointent vers les mêmes cellules DRAM. Imaginez un dictionnaire où deux mots différents auraient la même définition. Le système d’exploitation et l’hyperviseur se retrouvent avec une table de traduction d’adresses corrompue.

« Cette technique brise une hypothèse fondamentale du système d’exploitation, du processeur et de l’hyperviseur. » - Extrait du rapport USENIX Security 2026.

Cette confusion dans la table des adresses permet à l’attaquant d’accéder à des régions mémoire qui devraient être isolées, ouvrant la voie à des altérations profondes du système. Les chercheurs ont réussi à stabiliser Windows malgré cette altération, transformant ce qui aurait dû être un simple crash système en une vulnérabilité exploitable.

Pourquoi cette attaque est une menace critique pour VBS et HVCI ?

La Virtualization-Based Security (VBS) est un pilier de la sécurité moderne de Windows. Elle utilise Hyper-V pour créer des Virtual Trust Levels (VTL) : le VTL0 pour le système d’exploitation standard et le VTL1 pour le Secure Kernel et les composants sensibles comme Credential Guard et les enclaves protégées. L’Hypervisor-Protected Code Integrity (HVCI) s’appuie sur cette isolation pour vérifier l’intégrité du code en mode noyau, en s’assurant que seuls des drivers signés et approuvés peuvent s’exécuter.

La brèche dans l’isolation des VTL

En exploitant le memory aliasing, les chercheurs ont pu accéder à la mémoire physique appartenant au VTL1, un niveau d’accès qu’aucun administrateur Windows ne devrait posséder. Le proof-of-concept a démontré la possibilité de patcher skci.dll, la bibliothèque du Secure Kernel Code Integrity. skci.dll est le gardien de la blocklist des drivers vulnérables de Microsoft. En le patchant en mémoire, l’attaquant supprime cette protection sans toucher au disque dur, rendant la détection extrêmement difficile pour les solutions de sécurité traditionnelles.

En désactivant la liste noire des pilotes vulnérables de Microsoft (driver blocklist), l’attaquant ouvre la porte au BYOVD (Bring Your Own Vulnerable Driver). Il peut charger un pilote signé mais présentant une vulnérabilité connue, offrant des primitives de lecture/écriture en mémoire physique. Cette technique est particulièrement redoutée car elle permet de contourner les EDR en utilisant du code signé par Microsoft lui-même.

L’impact concret sur les solutions de sécurité (Defender, EDR)

Les conséquences de cette brèche sont considérables. Elle ne se limite pas à un simple déni de service ; elle permet une neutralisation complète des couches de sécurité logicielles. Le tableau suivant résume l’impact sur les principales solutions de sécurité :

Dans la pratique, un attaquant pourrait exécuter la chaîne d’exploitation suivante :

1. Obtenir des privilèges administrateur locaux (via phishing, credential theft).
2. Modifier le SPD de la mémoire pour créer un memory aliasing.
3. Utiliser un outil signé légitime pour inspecter la mémoire aliasée.
4. Patcher skci.dll pour désactiver la blocklist des drivers.
5. Charger un pilote vulnérable signé (BYOVD) pour obtenir un contrôle total.

« Nous avons observé que la chaîne d’exploitation ne nécessite pas de démonter physiquement la machine. Tout se fait par logiciel, à distance, une fois l’accès administrateur obtenu. » - Analyse des chercheurs.

Cette chaîne d’attaque est particulièrement insidieuse car elle n’écrit pas sur le disque dur et ne laisse que peu de traces dans les journaux Windows standard. Les outils de forensic traditionnels peinent à détecter ce type d’altération mémoire.

Quelles sont les configurations matérielles vulnérables et comment se protéger ?

L’étude menée par l’USENIX s’est concentrée sur des modules grand public. Il est important de noter que la protection du SPD varie énormément :

• Par fabricant : Corsair, G.Skill et ADATA ont été cités, mais l’étude n’est pas exhaustive. D’autres fabricants comme Kingston, Crucial ou Samsung peuvent également être concernés selon les gammes.
• Par gamme de produits : Les modules orientés gaming ou overclocking sont souvent plus exposés, car le SPD est déverrouillé pour permettre des profils XMP/EXPO personnalisés. Les modules pour serveurs et stations de travail professionnelles sont généralement verrouillés.
• Par firmware : Une simple mise à jour du firmware du module peut verrouiller le SPD. Il est impératif de vérifier auprès du fabricant si une mise à jour est disponible.

Les modules avec un SPD correctement protégé en écriture (write-protected) ne sont pas vulnérables à cette attaque logicielle. Il est donc crucial d’auditer son parc matériel.

Le correctif Microsoft d’avril 2026

Microsoft a publié un correctif pour CVE-2026-23670 lors de ses mises à jour de sécurité d’avril 2026. Ce correctif empêche l’utilisation du mécanisme removememory en environnement Secure Boot, mécanisme que les chercheurs utilisaient pour stabiliser Windows après la modification du SPD.

Il est impératif de déployer ce correctif sans délai sur l’ensemble du parc Windows. Sans ce correctif, toute machine dotée d’un module mémoire au SPD non protégé est potentiellement vulnérable.

Vérifier et activer Secure Boot

Le correctif de Microsoft ne fonctionne que si Secure Boot est activé. Les équipes sécurité doivent vérifier ce paramètre sur chaque poste. Une simple commande PowerShell permet de le faire :

# Vérifier l'état de Secure Boot
Confirm-SecureBootUEFI
# Vérifier l'état de VBS
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Verrouiller le SPD au niveau du BIOS/UEFI

La protection en écriture du SPD est la seule barrière matérielle contre cette classe d’attaque. Les équipes techniques doivent :

1. Consulter la documentation du fabricant de la carte mère pour activer l’option « SPD Write Protection ».
2. Vérifier les paramètres BIOS/UEFI après chaque mise à jour.
3. Contacter le fabricant des modules mémoire (Corsair, G.Skill, ADATA, etc.) pour connaître l’état de la protection SPD de leurs produits.

Surveiller les signes d’exploitation

Les équipes SOC doivent surveiller activement :

• Les tentatives de chargement de pilotes vulnérables connus (indicateurs de BYOVD).
• Les modifications inhabituelles de la configuration de démarrage (bcdedit).
• Les changements soudains dans la capacité mémoire rapportée par le système (alerte sur les postes de travail).

Conclusion : une leçon pour la défense en profondeur

L’attaque « Download More RAM » est un signal d’alarme puissant pour l’industrie. Elle démontre que la sécurité ne peut pas reposer uniquement sur des correctifs logiciels, même au niveau de l’hyperviseur. Le problème racine - le SPD non protégé en écriture - reste présent sur des millions de machines.

Bien que le correctif de Microsoft neutralise la chaîne d’exploitation actuelle, une nouvelle variante contournant cette protection logicielle est envisageable. La protection en écriture du SPD doit être traitée comme un contrôle de défense en profondeur, au même titre que le chiffrement des disques ou la segmentation réseau. En France, où l’ANSSI recommande l’activation de VBS, les RSSI doivent désormais intégrer cette dimension matérielle dans leur analyse de risques.

En conclusion, le contournement VBS et HVCI via l’attaque Download More RAM nous rappelle une vérité fondamentale : la cybersécurité ne s’arrête pas au système d’exploitation. Elle descend jusqu’au silicium. Les professionnels de la sécurité français doivent s’assurer que leur parc matériel est résilient face à ces menaces émergentes, en combinant correctifs logiciels, configuration Secure Boot et vérification de l’intégrité du SPD, tout en restant vigilants face aux menaces émergentes exploitant les failles d’API de raisonnement des IA.