Lorsqu’un administrateur ou un auditeur en sécurité physique évoque une clé USB capable d’ouvrir n’importe quelle session Windows ou Linux sans connaître le mot de passe et sans modifier un seul octet sur le disque dur, il fait référence à Kon-Boot. Contrairement aux utilitaires historiques d’édition hors-ligne de la base SAM (chntpw, Offline NT Password & Registry Editor) qui écrasent définitivement le condensat de mot de passe sur le système de fichiers NTFS, Kon-Boot opère exclusivement en mémoire vive (RAM) durant la séquence d’amorçage.

Toutefois, cette technique redoutable sur les postes non chiffrés se heurte à un mur mathématique et matériel infranchissable dès lors que l’architecture Zero-Trust Endpoint combine UEFI Secure Boot, TPM 2.0 et le chiffrement intégral de disque (BitLocker AES-XTS ou LUKS2).

1. Mécanique interne de Kon-Boot : l’altération du noyau à la volée en RAM

Kon-Boot s’insère comme un chargeur d’amorçage intermédiaire (Bootkit éphémère en RAM) entre le microcode de la carte mère (BIOS Legacy ou UEFI) et le chargeur du système d’exploitation (bootmgr / winload.efi sur Windows, GRUB2 / vmlinuz sur Linux).

Comment fonctionne le contournement en mémoire ?

1. Interception de la chaîne d’amorçage (Bootmgfw.efi -> Winload.efi) : Kon-Boot démarre depuis la clé USB, installe un gestionnaire en mémoire et passe la main au chargeur Windows présent sur le disque interne.
2. Signature scanning et patching de ntoskrnl.exe / msv1_0.dll : Au moment où winload.efi décompresse le noyau Windows en RAM mais avant que le contrôle d’intégrité logiciel ne prenne le relais, Kon-Boot localise la sous-routine de validation d’authentification locale dans le package d’authentification msv1_0.dll (fonction MsvpPasswordValidate ou RtlCompareMemory).
3. Court-circuitage de l’instruction conditionnelle : L’instruction assembleur qui compare le condensat NTLM saisi par l’utilisateur au condensat stocké dans la base SAM est remplacée en RAM par un retour systématiquement positif (mov al, 1 / xor eax, eax).
4. Absence de trace sur disque : Dès que la machine redémarre sans la clé USB, la RAM est purgée et le système retrouve son comportement nominal.

2. Pourquoi BitLocker + TPM 2.0 + Secure Boot neutralisent Kon-Boot à 100 %

Pour que Kon-Boot puisse modifier winload.efi ou msv1_0.dll en mémoire vive, deux conditions préalables absolues doivent être réunies : le firmware doit accepter d’exécuter le code de la clé USB, et la partition système contenant le noyau Windows doit être lisible en clair au moment de l’amorçage. Sur une architecture moderne correctement configurée, ces deux conditions sont simultanément révoquées.

Verrou n°1 : Le chiffrement intégral préalable au démarrage (BitLocker / LUKS2)

Sur un volume chiffré par BitLocker (algorithme XTS-AES-128 ou XTS-AES-256) ou Linux LUKS2 (cryptsetup), la partition système (incluant ntoskrnl.exe, System32\config\SAM et msv1_0.dll) n’est qu’une suite d’octets pseudo-aléatoires indiscernables d’un bruit blanc tant que la clé maîtresse de volume (VMK : Volume Master Key) n’a pas été déverrouillée.

• Si l’auditeur démarre sur la clé USB Kon-Boot, celle-ci s’exécute avant le déverrouillage du volume BitLocker.
• Kon-Boot ne voit donc aucun système de fichiers NTFS, aucun noyau ntoskrnl.exe à instrumenter et aucune DLL à modifier : la partition est mathématiquement opaque.

Verrou n°2 : L’attestation matérielle par les registres PCR du TPM 2.0

Même si le chargeur BitLocker (bootmgr) est stocké en clair sur la partition système EFI (ESP) pour pouvoir s’exécuter, la clé de déchiffrement VMK est scellée (Sealed) à l’intérieur de la puce matérielle TPM 2.0 selon les valeurs exactes des PCR (Platform Configuration Registers) :

• PCR 0 à 3 : intégrité du firmware UEFI et des options ROM.
• PCR 4 : condensat SHA-256 exact du binaire d’amorçage (bootmgfw.efi).
• PCR 7 : état de la politique UEFI Secure Boot et des certificats d’autorité (PK, KEK, db, dbx).

Si un opérateur tente d’intercaler Kon-Boot dans la séquence d’amorçage ou de désactiver Secure Boot dans les réglages UEFI, la chaîne de mesure cryptographique (Measured Boot) produit une valeur de PCR 4 ou PCR 7 différente de celle enregistrée lors du scellement initial. Le TPM 2.0 refuse alors matériellement de libérer la clé VMK et Windows affiche l’écran bleu BitLocker Recovery réclamant la clé numérique de récupération à 48 chiffres.

3. Le cas des contournements d’identifiants en ligne (Compte Microsoft / Cached Domain Logon)

Même dans le scénario dégradé où un poste serait dépourvu de chiffrement de disque (cas d’un poste de laboratoire ancien), le contournement de MsvpPasswordValidate présente une limite structurelle majeure :

• Absence du secret de déchiffrement DPAPI : Sous Windows, l’ouverture de session légitime dérive une clé maîtresse DPAPI (Data Protection API) à partir du véritable mot de passe de l’utilisateur.
• Lorsqu’une session est ouverte de force par altération mémoire (Kon-Boot), le système ne possède pas le mot de passe réel en mémoire : le trousseau DPAPI, les certificats privés EFS, les mots de passe enregistrés dans les navigateurs (Chrome/Edge) et les jetons Kerberos Active Directory restent indéchiffrables.

4. Checklist de conformité matérielle (Postes de travail & Serveurs)

Pour garantir l’immunité totale d’un parc face aux outils d’injection pré-boot et d’accès physique direct :

Sources

• Documentation officielle Microsoft : BitLocker Countermeasures & TPM Platform Configuration Registers (PCR)
• Spécification UEFI Forum : Secure Boot & Revocation List (DBX)
• Documentation officielle Kon-Boot : Limitations face au chiffrement intégral de disque (BitLocker / FileVault / LUKS)
• Guide ANSSI : Recommandations de configuration matérielle et UEFI des postes clients

Si vous voulez plus d’information sur l’infrastructure vous pouvez voir mon repo à ce sujet : https://github.com/ravindrajob/InfraAtHome