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

Une nouvelle technique d’attaque, baptisée “Download More RAM”, bouleverse les paradigmes de la sécurité Windows. Présentée à l’USENIX Security 2026 et traquée par Microsoft sous la référence CVE-2026-23670, cette méthode ne cible pas une vulnérabilité logicielle classique du noyau, mais une faiblesse matérielle présente dans certaines barrettes de mémoire DDR4 et DDR5. En exploitant l’absence de protection en écriture des données de configuration SPD (Serial Presence Detect), un attaquant disposant de privilèges administrateur local peut tromper le système d’exploitation sur la quantité réelle de RAM installée. Cette manipulation engendre un phénomène d’aliasing mémoire (recouvrement d’adresses) qui permet de contourner les mécanismes de sécurité les plus avancés de Microsoft : Virtualization-Based Security (VBS), Hypervisor-Protected Code Integrity (HVCI), mais aussi de désactiver Microsoft Defender et d’autres solutions EDR. Cet article décrypte le fonctionnement de cette menace inédite, analyse son impact sur l’écosystème de sécurité Windows et détaille les mesures de remédiation urgentes pour les entreprises françaises.

L’attaque Download More RAM : un contournement matériel des sécurités Windows

L’attaque “Download More RAM” tire son nom de la capacité apparente du système à gagner de la mémoire sans ajout physique de barrettes. Derrière ce nom ironique se cache une technique sophistiquée qui s’attaque à un composant matériel souvent négligé : la puce EEPROM du SPD.

Le maillon faible : la puce SPD des barrettes DDR4 et DDR5

Chaque module de mémoire vive (DIMM) embarque une petite puce EEPROM qui contient les paramètres SPD (Serial Presence Detect). Ces données décrivent les caractéristiques techniques de la barrette : sa capacité (8 Go, 16 Go, 32 Go…), son organisation en banques, ses fréquences, ses timings et sa tension de fonctionnement. Lors du démarrage du PC, le firmware UEFI lit ces informations pour initialiser correctement le contrôleur mémoire.

Le problème fondamental est que, sur certains modules mémoire grand public, cette puce SPD n’est pas protégée en écriture. La fonctionnalité est souvent délibérément activée par les fabricants pour supporter les profils d’overclocking comme Intel XMP 3.0 et AMD EXPO, qui permettent aux utilisateurs de modifier les fréquences et les timings via une simple reprogrammation logicielle du SPD. Selon les recherches présentées à l’USENIX Security 2026, des produits des marques Corsair, G.Skill et ADATA présentent cette vulnérabilité. Un attaquant disposant de privilèges administrateur local peut, à l’aide d’outils parfaitement légitimes et signés par Microsoft, modifier les données du SPD via le bus SMBus (System Management Bus).

“Nous avons constaté que la protection en écriture du SPD est absente sur une sélection de modules grand public. Un attaquant n’a besoin d’aucun matériel spécialisé ; un simple outil logiciel signé suffit pour altérer la configuration mémoire de base.” - Extrait du rapport USENIX Security 2026

Le mécanisme de l’aliasing mémoire

En modifiant la géométrie mémoire déclarée, l’attaquant peut faire croire au système que la barrette possède une capacité largement supérieure à la réalité. Dans leurs démonstrations, les chercheurs ont réussi à faire croire au système que la capacité d’un module était doublée (par exemple, un module de 8 Go détecté comme 16 Go). Windows, le processeur et l’hyperviseur Hyper-V adressent alors un espace mémoire qui n’existe pas physiquement.

Scénario concret pour une entreprise française : Un poste de télétravailleur équipé d’une barrette DDR5 16 Go est compromis. L’attaquant modifie le SPD pour déclarer 32 Go. Au redémarrage, le système tente d’adresser 32 Go alors que seules 16 cellules DRAM sont présentes. Les adresses de 0 à 16 Go sont normales, mais les adresses de 16 Go à 32 Go pointent en réalité vers les mêmes cellules DRAM que les adresses de 0 à 16 Go.

“La condition d’aliasing mémoire ainsi créée brise une hypothèse fondamentale du système d’exploitation, du processeur et de l’hyperviseur. Windows traite des emplacements mémoire distincts en pensant qu’ils sont séparés, alors qu’ils sont en réalité les mêmes.” - USENIX Security 2026

Ce chevauchement d’adresses (ou aliasing mémoire) est la clé de voûte de l’attaque. Pour que le système ne s’effondre pas à cause de ce conflit, les chercheurs ont utilisé un paramètre de configuration de démarrage spécifique : removememory. Ce paramètre, qui peut être défini via l’outil bcdedit.exe, permet d’exclure une plage d’adresses de la gestion mémoire de Windows. Ils ont ainsi pu stabiliser l’environnement tout en conservant l’accès à la zone aliasée.

Contournement de VBS et HVCI : le Secure Kernel en ligne de mire

La Virtualization-Based Security (VBS) est l’un des piliers de la sécurité moderne de Windows. Elle utilise la virtualisation matérielle (Hyper-V) pour créer des Virtual Trust Levels (VTL).

• VTL 0 : Héberge le noyau Windows standard, les pilotes et les applications utilisateur.
• VTL 1 : Héberge le Secure Kernel, des composants hautement sensibles comme Credential Guard, et les Virtual Secure Enclaves. Le matériel garantit qu’aucun code s’exécutant en VTL 0 ne peut accéder à la mémoire du VTL 1.

L’aliasing mémoire permet de briser cette barrière. Si une plage d’adresses appartenant au VTL 1 est recouverte par une plage d’adresses du VTL 0 à cause du SPD falsifié, l’attaquant peut, depuis le niveau non sécurisé (VTL 0), lire et modifier la mémoire du Secure Kernel (VTL 1). C’est une rupture fondamentale de l’isolation promise par la virtualisation.

Désactivation du blocage des pilotes vulnérables

La première cible des chercheurs a été la bibliothèque skci.dll (Secure Kernel Code Integrity). Cette bibliothèque est responsable du maintien de la liste noire des pilotes signés mais vulnérables (Microsoft Vulnerable Driver Blocklist). HVCI empêche le chargement de tout pilote figurant sur cette liste.

En localisant skci.dll dans la mémoire du VTL 1 via l’aliasing, les chercheurs ont pu patcher directement le code de cette bibliothèque. En supprimant les entrées de la liste noire, ils ont désactivé le mécanisme de filtrage HVCI. Une fois cette protection contournée, l’attaquant peut charger dans le noyau un pilote signé vulnérable (comme des drivers exposant des primitives d’accès mémoire physique).

Chaîne d’attaque complète :

1. Accès initial : Obtention d’un accès administrateur local sur la machine cible (phishing, élévation de privilèges).
2. Modification SPD : Utilisation d’un outil signé pour écrire de nouvelles données sur la puce EEPROM du SPD via le bus SMBus.
3. Redémarrage : Le système redémarre et lit le SPD falsifié. L’aliasing mémoire est créé. Le paramètre removememory est défini via BCD pour stabiliser le système.
4. Accès VTL 1 : L’attaquant utilise l’aliasing pour cartographier et accéder à la mémoire du Secure Kernel (VTL 1).
5. Patching de skci.dll : Les données de la bibliothèque sont modifiées pour désactiver la liste noire des pilotes vulnérables.
6. Chargement du driver : Un pilote signé vulnérable est chargé, donnant un accès complet en lecture/écriture à la mémoire physique.
7. Désactivation des sécurités : Les agents de sécurité (Microsoft Defender, EDR) sont neutralisés directement en mémoire.

Désactivation de Microsoft Defender et des EDR tiers

L’impact de cette attaque sur les solutions de sécurité est catastrophique. Les chercheurs d’USENIX ont démontré la capacité de cette technique à neutraliser les défenses les plus robustes.

Les scénarios d’attaque ne se limitent pas à Windows Defender. La preuve de concept a montré des impacts sur Sophos Intercept X (modification des configurations en mémoire), la modification de code d’enclaves protégées par VBS (Virtual Secure Enclaves) et l’interférence avec les anti-cheats au niveau noyau, ce qui démontre l’étendue des dégâts potentiels.

“Cette attaque démontre que la sécurité par la virtualisation n’est pas une panacée si l’intégrité du matériel sous-jacent n’est pas garantie. C’est un signal fort pour les RSSI français : la confiance dans les mécanismes de sécurité logicielle doit être complétée par une vérification rigoureuse de la chaîne de confiance matérielle.” - Analyse d’un expert en sécurité des systèmes d’information

Correctif CVE-2026-23670 et posture de défense pour les entreprises

Microsoft a réagi en publiant un correctif dans le cadre de ses mises à jour de sécurité d’avril 2026 (Patch Tuesday). Ce correctif, référencé CVE-2026-23670, cible le mécanisme removememory utilisé dans la preuve de concept des chercheurs.

Désormais, les systèmes disposant de Secure Boot activé sont protégés contre la chaîne d’attaque telle qu’elle a été publiée. Le correctif empêche l’utilisation de removememory pour exclure des plages mémoire, si Secure Boot vérifie l’intégrité de la configuration de démarrage. Cependant, il est fondamental de comprendre que le correctif Microsoft ne résout pas le problème racine : l’absence de protection en écriture du SPD reste un risque matériel latent. Un attaquant pourrait potentiellement trouver d’autres méthodes pour stabiliser l’aliasing mémoire sans utiliser removememory.

Recommandations ANSSI et bonnes pratiques de défense en profondeur

Dans ce contexte, la résilience d’une infrastructure ne peut reposer sur un seul correctif. Une approche de défense en profondeur est impérative.

Actions prioritaires à mettre en œuvre immédiatement :

1. Déployer la mise à jour de sécurité d’avril 2026 (CVE-2026-23670) sur l’ensemble du parc Windows.
2. Vérifier que Secure Boot est activé dans les paramètres UEFI de chaque poste de travail et serveur. Le correctif Microsoft ne fonctionne que si Secure Boot est actif.
3. Auditer le matériel mémoire. Consultez les fabricants de vos modules (Corsair, G.Skill, ADATA pour le grand public, mais aussi Dell, HPE, Lenovo pour les serveurs) pour vérifier si leurs barrettes disposent d’une protection en écriture matérielle du SPD.
4. Limiter les privilèges administrateur. Cette attaque nécessite des droits administrateur local pour écrire le SPD. L’application du principe du moindre privilège est une barrière essentielle.
5. Surveiller les indicateurs de compromission (IoC) :
   • Modifications de la configuration de démarrage (bcdedit).
   • Accès anormaux au bus SMBus (outils comme RWEverything).
   • Tentatives de chargement de pilotes figurant sur la liste noire de Microsoft.
   • Altérations de la bibliothèque skci.dll ou d’autres composants du Secure Kernel.

Encadré technique : Vérification de l’état de Secure Boot

# Commande PowerShell pour vérifier Secure Boot
Confirm-SecureBootUEFI

# Vérification avancée de la configuration de démarrage
bcdedit /enum {current}

Focus sur les référentiels de sécurité

La norme ISO 27001, dans son annexe A, aborde la gestion des actifs (A.8) et la protection contre les codes malveillants (A.8.7). Bien qu’elle ne cible pas directement le SPD, un SMSI (Système de Management de la Sécurité de l’Information) mature impose une gestion rigoureuse des correctifs (A.8.8) et des configurations (A.8.9). La prise en compte de menaces matérielles comme “Download More RAM” s’inscrit parfaitement dans une démarche d’amélioration continue de la sécurité. De même, le RGPD impose une sécurisation des données personnelles par des mesures techniques appropriées (Article 32), ce qui inclut la protection des postes de travail contre des attaques noyau de ce niveau. Enfin, l’ANSSI recommande, dans ses guides de sécurisation, l’activation de Secure Boot et le recours à du matériel de confiance pour les environnements les plus sensibles.

Conclusion : une faille matérielle qui impose une défense en profondeur

L’attaque “Download More RAM” (CVE-2026-23670) n’est pas une vulnérabilité logicielle anecdotique. Elle démontre que les couches de virtualisation les plus avancées de Windows (VBS, HVCI) peuvent être anéanties si l’intégrité des composants matériels de base (la mémoire vive) n’est pas garantie. En ciblant les données de configuration SPD des barrettes DDR4 et DDR5, cette technique expose une nouvelle surface d’attaque que les équipes de sécurité doivent impérativement intégrer dans leur modèle de menace.

Le correctif d’avril 2026 de Microsoft est une première barrière efficace contre la méthode publiée, mais il ne constitue pas une solution définitive. La résilience d’une infrastructure passe par une combinaison de mesures techniques : déploiement rapide des patches, activation impérative du Secure Boot, audit de la protection en écriture du matériel mémoire, et une surveillance comportementale avancée.

En France, les RSSI et les DSI doivent immédiatement auditer leur parc, prioriser les correctifs systèmes, et intégrer ces nouvelles menaces dans leur analyse de risques au titre du RGPD et des exigences de l’ANSSI. La sécurité de demain ne pourra pas se permettre de négliger l’intégrité du matériel.