Message-ID: <CA+EYf7N5BpShtv=kZj8d-FOmgzutQbKTj9RwVpKyJ=bS7OX0Gg@mail.gmail.com>
Date: Sun, 15 Feb 2026 10:26:38 +0530
From: Darsh Naik <darsh.naik53@...il.com>
To: fulldisclosure@...lists.org
Subject: [FD] 🚨 Public Disclosure: Remote BitLocker Bypass via Intel AMT — SYSTEM Access Without Login

🔓 The Attack Path — No Login, SYSTEM Access

1. Boot into setup.exe (via USB, PXE, or OOBM like Intel vPro).
2. Click “Repair your computer” → Enter WinRE.
3. Press Shift + F10 → SYSTEM-level Command Prompt.
4. From there, attacker can:
   - Run `net user` to create new admin accounts
   - Use `diskpart` to wipe or reformat drives
   - Use `manage-bde -off` or `bcdedit` to disable BitLocker
   - Replace `utilman.exe` to bypass login
   - Implant persistence or backdoors

🧠 Why BitLocker Doesn’t Save You

- BitLocker is inactive in Setup or WinRE — the OS hasn’t loaded, and the
BitLocker driver isn’t running.
- If BitLocker is TPM-only (no PIN/USB), the drive is already unlocked at
boot.
- TPM 2.0 *can* block key release — but only if:
  - Secure Boot is enforced
  - PCR bindings are tightly configured
  - Boot order is locked
  - USB/PXE boot is disabled
  - OOBM is secured

Most orgs don’t meet all those conditions. Even if BitLocker triggers
recovery, an attacker can still wipe the drive or implant malware.

> CVE-2025-26637 and tools like BitUnlocker show how these vectors are
being actively explored.

🧨 “But We Have Immutable Backups”

That protects data availability — not system integrity.

If I implant malware or create a hidden admin account, you’ll restore into
a compromised environment. Immutable backups don’t detect or prevent:
- Credential theft
- Persistence
- Backdoored reboots
- Silent compromise of trust

🌐 Remote Risk: OOBM

With Intel vPro, I can:
- Mount virtual media
- Boot into Setup or WinRE
- Execute all of the above remotely, without touching the device

Intel’s own docs highlight how vPro enables remote boot and media mounting
— a dream for IT, and a gift for attackers if misconfigured.

🧱 This Isn’t About “Wasting Access”

It’s about how Microsoft’s own tooling enables unauthenticated SYSTEM
access in environments that are supposed to be secure.

If your only defense is “well, that’s by design,” then the design *is* the
vulnerability.

🔒 BIOS/UEFI Passwords: A Broken Mitigation

Microsoft may argue that setting a BIOS/UEFI password mitigates this
attack. But in practice, this “defense” is deeply flawed:

- **No visual feedback**: Users can’t see what they’re typing — no
asterisks, no characters, nothing.
- **No Caps Lock indicator**: If Caps Lock is on, users won’t know — and
their input silently fails.
- **No support for special characters**: Most firmware restricts input to
basic alphanumeric characters.
- **Short password limits**: Many systems cap passwords at 8–16 characters.
- **No brute-force protection**: Some BIOS/UEFI setups don’t lock out after
failed attempts.

The result? Users get scared, fumble their input, and retreat to normal
boot — where the system is already unlocked and vulnerable. The illusion of
security becomes the attack vector.

If this is the only mitigation, then the system is fundamentally broken.

— Darsh
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

Powered by blists - more mailing lists