Borrowing Microsoft-Signed Shims to Bypass Secure Boot on Corporate Hardware

By using a legitimate 'shim-signed' package from a Linux distribution like Ubuntu, an attacker can bypass Secure Boot protections on corporate laptops that already trust Microsoft's third-party certificates. This technique allows a custom-signed operating system to be authorized by the hardware's firmware, effectively subverting the integrity checks intended to prevent unauthorized boot software.

The Role of the Shim in Secure Boot

Secure Boot functions by checking the signature of the operating system against a database of accepted keys. Because Linux distributions update their kernels and bootloaders frequently, they use a 'shim'—a small, Microsoft-signed piece of software that handles the transition between the firmware and the Linux bootloader.

The shim is trusted by the BIOS because it carries a valid Microsoft signature. Once the shim is running, it provides a mechanism called MOK (Machine Owner Key) enrollment, which allows a user to manually enroll new keys into the system's trusted database.

“The actual reason secure boot exists is for the following: Ensuring the integrity of the booting OS.”

— Leo Smith - Not So Secure Boot

Borrowing Trust to Enroll Custom Keys

The vulnerability lies in the fact that the MOK enrollment process can often be accessed without a BIOS password. An attacker can use a legitimate 'shim-signed' file from a distribution like Ubuntu or Fedora to satisfy the initial Secure Boot check.

This visual supports the claim that the MOK enrollment process can often be accessed without a BIOS password.

Once the trusted shim is running, the attacker can trigger the MOK enrollment software. This interface allows them to select and enroll their own custom certificate, which they have used to sign their own malicious or unauthorized kernel. After enrollment, the hardware treats the attacker's custom OS as a trusted component of the boot chain.

This image illustrates the MOK enrollment software interface described in the text.

Limitations and Corporate Defenses

While this technique allows a custom OS to boot, it does not automatically grant access to the existing OS's data if that data is protected by TPM-sealed disk encryption. If the disk encryption key is bound to specific Platform Configuration Registers (PCRs), the TPM will refuse to release the key because the boot chain has changed.

Furthermore, many modern corporate environments use management tools like Microsoft Intune or Autopilot to lock down UEFI controls. If these controls are strictly enforced, the MOK enrollment interface may be inaccessible, preventing the attack from succeeding on high-security corporate fleets.