Secure Boot Bypass: 11 Microsoft-Signed UEFI Shims Actively Exploitable

What Happened

Cybersecurity researchers have identified 11 outdated but still-valid Microsoft-signed UEFI shim applications that can be weaponized to bypass Secure Boot on virtually any modern system running UEFI firmware. These aren't theoretical — the shims carry legitimate Microsoft signatures that firmware will trust unconditionally, meaning an attacker who gets them onto a target machine can load unsigned or malicious bootloaders before the OS ever starts.

Separately but compounding the picture: researchers also disclosed two new phishing kits — Jalisco and OmegaLord — actively targeting Microsoft 365 accounts and specifically engineered to defeat MFA. These kits use adversary-in-the-middle (AiTM) proxy techniques to steal session tokens in real time, making standard TOTP or push-based MFA effectively useless against them.

Taken together: attackers can compromise credentials through session-hijacking phishing, then follow up with a firmware-level persistence mechanism that survives OS reinstalls and endpoint detection.

Why It Matters

Secure Boot is the foundational trust anchor for most enterprise and server boot chains. Its entire purpose is to ensure only signed, trusted code runs before the OS loads — which is exactly why attackers want to break it. A bypassed Secure Boot means:

• Bootkits and rootkits can persist below the OS layer, invisible to EDR, AV, and forensic imaging
• Virtualization-based security (VBS) and Credential Guard on Windows can be undermined
• The compromise survives disk wipes and OS reinstalls

The critical detail here is that these shims are legitimately signed by Microsoft. UEFI firmware sees a valid signature and boots them. The fix isn't as simple as patching an app — it requires updating the UEFI Secure Boot revocation list (the DBX) to blacklist these specific binaries.

Meanwhile, the Jalisco/OmegaLord MFA-bypass phishing kits lower the bar for initial access dramatically. You don't need to crack a password or defeat MFA independently — you proxy the victim's own authenticated session.

What To Do

For the UEFI Secure Boot issue:

1. Check whether your systems apply DBX updates automatically. Most Linux distributions push fwupd or shim-signed updates that include revocation list changes. Verify these are running: fwupdmgr get-updates and fwupdmgr update.
2. For Windows systems, ensure Windows Update is current — Microsoft pushes DBX updates via Windows Update. Check Get-SecureBootUEFI -Name dbx for the current revocation database version.
3. Audit physical and boot-level access controls. Exploiting these shims typically requires local access or the ability to modify the EFI System Partition — harden those paths.
4. Monitor for unsigned or unexpected bootloader changes via your EDR's UEFI/firmware monitoring capabilities if available.

For the M365 MFA-bypass phishing kits:

1. Deploy phishing-resistant MFA immediately — FIDO2/passkeys or certificate-based auth. TOTP and push notifications do not stop AiTM attacks.
2. Enable Continuous Access Evaluation (CAE) in Entra ID to shorten session token lifetimes and enable real-time revocation.
3. Configure Conditional Access policies to enforce compliant/managed device requirements for M365 access.
4. Alert on token replay from unexpected IPs or user agents via Entra ID Sign-in logs or Microsoft Sentinel.