Sous Windows 11, Hyper-V et la sécurité basée sur la virtualisation (VBS) accaparent VT-x/AMD-V dès le démarrage. Résultat : VirtualBox et VMware Workstation tombent en mode dégradé — la fameuse « tortue verte » dans la barre d’état de VirtualBox — et la virtualisation imbriquée (nested virt) devient tout bonnement impossible. Tant que l’hyperviseur Windows tient VT-x, l’hyperviseur tiers ne peut pas l’exposer à son tour à une VM invitée.

Cette page rassemble ce qu’il faut désactiver pour rendre VT-x à VirtualBox / VMware, et plus largement pour dégager les couches de sécurité de Windows 11 dont on ne veut pas sur une machine de lab.

On retire ici des protections système réelles. Conséquences directes :

  • WSL2, Docker Desktop (backend WSL2 ou Hyper-V), Windows Sandbox ne fonctionneront plus.
  • Credential Guard, HVCI (intégrité mémoire), Windows Hello / PIN sont désactivés — la machine est nettement plus exposée au vol de credentials et aux rootkits noyau.
  • Combiné à la suppression de Defender (plus bas), il ne reste aucune défense de base.
  • À réserver à un poste de test / lab, jamais à une machine avec des données sensibles.

Sauf mention contraire, les commandes qui suivent sont à lancer dans un PowerShell administrateur, VM éteinte, suivies d’un redémarrage (parfois deux ou trois).

Comprendre qui vole VT-x

Contrairement à une idée répandue, Windows Defender n’y est pour rien : un antivirus ne prend jamais VT-x. Ce qui accapare la virtualisation matérielle, c’est l’hyperviseur Windows (Hyper-V) et la pile VBS / VTL1 qui tourne au-dessus (Credential Guard, HVCI, System Guard…).

Seul bémol : la protection contre les falsifications de Defender est une cause classique de clés DeviceGuard qui repassent à 1 après chaque reboot. Si Defender est déjà parti, tant mieux pour la persistance des réglages ci-dessous.

Diagnostic

Avant de tout casser, savoir quelle brique est active.

  • Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning
    • État de VBS et des services associés. VirtualizationBasedSecurityStatus : 0 = VBS éteinte, 1 = activée mais pas en cours, 2 = activée et en cours. Dans SecurityServicesRunning : 1 = Credential Guard, 2 = HVCI / intégrité mémoire, 3 = System Guard, 5 = protection de pile matérielle noyau, 7 = Hypervisor-Enforced Paging Translation. C’est ce tableau qui dit quelle brique cibler.
  • bcdedit /enum {current} | findstr /i "hypervisorlaunchtype vsmlaunchtype loadoptions"
systeminfo | findstr /i "hypervis"
    • Indique si l’hyperviseur est lancé au boot et pourquoi.
  • CiTool --list-policies
    • Sur 24H2 / 25H2, révèle les politiques WDAC / Code Integrity (.cip / .p7b) qui maintiennent parfois l’hyperviseur en vie même après avoir tout désactivé. Une « Microsoft Windows Virtualization Based Security Policy » ici = VBS verrouillée par politique.

Désactiver VBS, Device Guard, Credential Guard et HVCI

Tout passe par le registre. La clé WindowsHello est celle que la plupart des tutos oublient : c’est elle qui rend la désactivation persistante sur 24H2+, au prix du PIN / Windows Hello.

  • $scen = "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios"
foreach ($s in 'HypervisorEnforcedCodeIntegrity','CredentialGuard','SystemGuard','KernelShadowStacks','WindowsHello') {
    New-Item -Path "$scen\$s" -Force | Out-Null
    Set-ItemProperty -Path "$scen\$s" -Name Enabled -Value 0 -Type DWord
}
    • Coupe HVCI (intégrité mémoire), Credential Guard, System Guard, les kernel shadow stacks et Windows Hello. Retirer 'WindowsHello' de la liste si l’on veut garder le PIN — mais alors HVCI a tendance à revenir après un reboot.
  • $dg = "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard"
Set-ItemProperty -Path $dg -Name EnableVirtualizationBasedSecurity -Value 0 -Type DWord
Set-ItemProperty -Path $dg -Name RequirePlatformSecurityFeatures  -Value 0 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LsaCfgFlags -Value 0 -Type DWord
    • Désactive VBS elle-même et l’isolation LSA. LsaCfgFlags = 0 neutralise Credential Guard côté LSA.
  • $gpo = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard"
New-Item -Path $gpo -Force | Out-Null
Set-ItemProperty -Path $gpo -Name EnableVirtualizationBasedSecurity -Value 0 -Type DWord
Set-ItemProperty -Path $gpo -Name RequirePlatformSecurityFeatures  -Value 0 -Type DWord
Set-ItemProperty -Path $gpo -Name HypervisorEnforcedCodeIntegrity  -Value 0 -Type DWord
Set-ItemProperty -Path $gpo -Name LsaCfgFlags                      -Value 0 -Type DWord
    • Miroir côté stratégie de groupe (GPO). Sans lui, une politique peut re-forcer VBS au démarrage suivant. Équivalent graphique : gpedit.msc → Configuration ordinateur → Modèles d’administration → Système → Device Guard → « Activer la sécurité basée sur la virtualisation » → Désactivé.

Retirer Hyper-V et les fonctionnalités liées

  • Get-WindowsOptionalFeature -Online |
  Where-Object { $_.State -eq 'Enabled' -and $_.FeatureName -match 'Hyper|Virtual|Container|Linux|Hypervisor' }
    • Liste ce qui est réellement activé avant de couper — utile pour n’oublier aucune distribution WSL ni conteneur.
  • $features = 'Microsoft-Hyper-V-All','HypervisorPlatform','VirtualMachinePlatform',
            'Containers-DisposableClientVM','Microsoft-Windows-Subsystem-Linux'
foreach ($f in $features) {
    Disable-WindowsOptionalFeature -Online -FeatureName $f -NoRestart -ErrorAction SilentlyContinue | Out-Null
}
    • Désactive Hyper-V, la Plateforme d’hyperviseur Windows, la Plateforme d’ordinateur virtuel, Windows Sandbox et WSL. Variante DISM avec purge du payload : dism /online /disable-feature /featurename:VirtualMachinePlatform /Remove.

Couper l’hyperviseur au démarrage

  • bcdedit /set hypervisorlaunchtype off
bcdedit /set vsmlaunchtype off
    • Empêche le lancement de l’hyperviseur et du Secure Kernel au boot. C’est nécessaire mais pas toujours suffisant du premier coup : il faut parfois deux ou trois redémarrages avant que la tortue verte disparaisse.

Supprimer Windows Defender

Là où Windows réactive Defender sans arrêt, l’outil open-source windows-defender-remover de ionuttbara le retire proprement (installeur hors-ligne, prise en charge des versions récentes) :

→ github.com/ionuttbara/windows-defender-remover

  • Étape 1 — désactiver la protection contre les falsifications AVANT tout. Paramètres → Sécurité Windows → Protection contre les virus et menaces → Gérer les paramètres → Protection contre les falsifications = Désactivé. Sans ça, la suppression échoue.
  • Étape 2 — télécharger le binaire depuis l’onglet Releases du dépôt, puis le lancer en administrateur.
  • Étape 3 — choisir Remove Windows Defender, laisser l’installeur hors-ligne faire son travail.
  • Étape 4 — redémarrer.

Outil non signé par Microsoft : SmartScreen et Defender lui-même vont tenter de le bloquer (d’où l’étape 1). Ne le télécharger que depuis le dépôt officiel ionuttbara/windows-defender-remover, jamais depuis un mirror. La suppression est réversible via l’outil, mais laisse la machine sans antivirus tant que rien d’autre n’est installé.

Vérifier après redémarrage

  • Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning
    • Objectif : VirtualizationBasedSecurityStatus = 0 et SecurityServicesRunning vide ({}). Vérifiable aussi dans msinfo32 → « Sécurité basée sur la virtualisation : non activée ».
  • bcdedit /enum {current} | findstr /i "hypervisorlaunchtype"
    • Doit afficher hypervisorlaunchtype Off.
  • Côté VirtualBox, le VBox.log de la VM doit contenir HM: HMR3Init: VT-x w/ nested paging and unrestricted guest execution hw support — et surtout pas HMR3Init: Attempting fall back to NEM (Hyper-V is active). Plus de tortue verte dans la barre d’état = c’est bon.

Cas particulier : VBS verrouillée en UEFI

Si, après reboot, SecurityServicesRunning contient encore 1 (Credential Guard), c’est un verrou firmware. Il faut alors la procédure SecConfig.efi.

Cette manip touche à la séquence de boot EFI. À ne tenter qu’en dernier recours, en sachant restaurer un environnement de récupération.

  • mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d
    • À lancer dans une invite de commandes (cmd) administrateur — la syntaxe copy / %WINDIR% ne s’interprète pas sous PowerShell. Crée une entrée de boot DebugTool qui désactive l’isolation LSA et VBS au niveau firmware. Au redémarrage, appuyer sur F3 pour confirmer. Alternative officielle : le Device Guard and Credential Guard hardware readiness tool de Microsoft (DG_Readiness_Tool_v3.6.ps1 -Disable), puis F3 aux deux invites.

Sur Windows 11 25H2, certaines builds refusent toujours de lâcher VTL1 : DG_Readiness_Tool ne fait plus rien et le Secure Kernel reste actif à cause des politiques WDAC (visibles via CiTool --list-policies). Si c’est le cas, la seule solution fiable pour du nested virt régulier reste un hôte Linux (KVM/libvirt), qui n’a aucune de ces contraintes.

Activer la virtualisation imbriquée

Une fois VBS et Hyper-V hors du chemin, exposer VT-x à la VM :

  • VBoxManage modifyvm "MaVM" --nested-hw-virt on --nested-paging on --cpus 4
VBoxManage showvminfo "MaVM" | Select-String -Pattern "Nested"
    • Active la virtualisation imbriquée pour VirtualBox. Le support côté hôte est arrivé avec VirtualBox 6.0 pour les CPU AMD et 6.1 pour Intel ; --nested-paging (actif par défaut) est un prérequis de --nested-hw-virt. VM éteinte, pas en saved state. La case « Enable Nested VT-x/AMD-V » de l’interface reste grisée sur hôte Intel — la ligne de commande l’active quand même.

VMware Workstation profite du même nettoyage : sans Hyper-V pour lui prendre VT-x, il repasse en mode VMM natif au lieu de la couche WHP dégradée. Aucune commande spécifique — le simple fait d’avoir coupé l’hyperviseur suffit.