Bypass Detection·Jun 2, 2026

Aqua EFI Bypass: Modified Bootloader Running Before Windows

Aqua EFI Bypass replaces the legitimate bootx64.efi bootloader on the EFI System Partition with a modified version (SHA-256: 91d9db5f...cbd5). Because the modified bootloader executes before the Windows kernel initializes, standard Windows-level anti-cheat mechanisms cannot inspect or detect it during the boot sequence. Detection requires direct inspection of the EFI System Partition and mandates that Secure Boot be verified as enabled.

FiveMBypass DetectionEFI BootloaderPre-OS BypassSecure Boot

Defensive use only. Detection methodologies published for server administrators, DFIR practitioners, and anti-cheat researchers. No evasion guidance is provided.

Overview

The EFI System Partition (ESP) is a dedicated FAT32 partition present on all UEFI-based systems. It contains the bootloader chain that the system firmware reads before any operating system code runs. On Windows systems, the standard bootloader is bootx64.efi, located at \EFI\Microsoft\Boot\bootmgfw.efi (with a secondary copy at \EFI\Boot\bootx64.efi for fallback booting). The Aqua EFI Bypass replaces one or both of these files with a modified EFI executable.

Because the modified bootloader runs before Windows begins initializing, anti-cheat software that operates entirely within the Windows kernel — including kernel-mode drivers that load at early boot — does not have an opportunity to observe or interrupt the bypass component. The bypass establishes its foothold in the system firmware execution chain, then allows a normal-appearing Windows boot to proceed.

Secure Boot is the primary countermeasure. When Secure Boot is enforced, the UEFI firmware verifies the cryptographic signature of each bootloader before executing it. An unsigned or incorrectly signed modified bootx64.efi will cause the boot to fail with a Secure Boot violation. This bypass therefore requires that Secure Boot be disabled on the target system. A Secure Boot status of disabled or not supported during a screenshare check is itself a significant IOC.

Primary IOCs

1

Mount EFI system partition

Open an elevated Command Prompt. Run mountvol X: /S to mount the EFI System Partition to drive letter X (choose any unused letter). Then run dir X:\EFI\ to list the EFI directory tree. If mountvol fails, use diskpart: type diskpart, then list vol to identify the ESP volume, select vol <n>, and assign letter=X.

2

Hash bootx64.efi against known-good value

After mounting, run certutil -hashfile X:\EFI\Boot\bootx64.efi SHA256. Compare the output against the known-good SHA-256 for your Windows version and build. The Aqua bypass bootloader has SHA-256 91d9db5fbf3c89b0df5d674f0e367afd3ac9e45ff1c13040ee2279cf3314cbd5. Any hash mismatch against a known-good reference is a positive IOC. Also check X:\EFI\Microsoft\Boot\bootmgfw.efi.

3

SHA-256 and SHA-1 comparison

Run both: certutil -hashfile X:\EFI\Boot\bootx64.efi SHA256 and certutil -hashfile X:\EFI\Boot\bootx64.efi SHA1. The bypass bootloader SHA-1 is d8fca4d3fa670c6d54fc274a0625cd4bad2016ab. Cross-referencing both hashes against the known IOC values eliminates any ambiguity from hash algorithm selection. A match on either confirms the bypass file.

4

Secure Boot status check

Run msinfo32 (System Information). In the right pane, locate Secure Boot State. A value of Off or Unsupported is required for this bypass to function and is itself a significant IOC on a gaming system. Alternatively, open Settings → System → Recovery → Advanced startup → Restart now → Troubleshoot → Advanced options → UEFI Firmware Settings to inspect the Secure Boot configuration directly in firmware.

5

EFI partition file listing for unexpected files

After mounting, run dir /S X:\EFI\ to enumerate all files on the ESP. A legitimate Windows ESP will contain a small set of known files under EFI\Microsoft\Boot\ and EFI\Boot\. Look for any additional .efi executables, unexpected subdirectories, or files with anomalous modification timestamps. Some EFI bypass implementations place additional loader components alongside the modified bootloader.

EFI System Partition Inspection

The EFI System Partition is hidden from normal File Explorer browsing and is not assigned a drive letter by default. It is only accessible via elevated Command Prompt using mountvol or diskpart. The partition is formatted as FAT32 and is typically 100–260 MB in size on a Windows 11 system.

A legitimate Windows 11 ESP contains the following key files and directories under the \EFI root:

  • \EFI\Boot\bootx64.efi — fallback UEFI bootloader, signed by Microsoft
  • \EFI\Microsoft\Boot\bootmgfw.efi — Windows Boot Manager, signed by Microsoft
  • \EFI\Microsoft\Boot\BCD — Boot Configuration Data store
  • \EFI\Microsoft\Recovery\BCD — Recovery BCD

A modified bootx64.efi will typically have a significantly different file size from the legitimate version (Microsoft's signed bootloader for Windows 11 is approximately 1.1–1.3 MB depending on the build). The bypass EFI binary may be smaller (containing only the bypass loader) or larger (if it bundles additional components). File size alone — combined with a failed hash check — is sufficient to flag the file for further investigation.

After completing inspection, unmount the ESP: in elevated Command Prompt run mountvol X: /D (or use diskpart remove letter=X) to restore the hidden state of the partition.

Screenshare Check Methodology

1

Verify Secure Boot status via msinfo32

Ask the subject to press Win+R, type msinfo32, and press Enter. Direct them to scroll to Secure Boot State in the System Summary pane. The result must read On. If it reads Off or the field is absent, that is a mandatory escalation point. Secure Boot disabled is a prerequisite for EFI bootloader bypass.

2

Mount and list ESP contents

Ask the subject to open an elevated Command Prompt and run mountvol Z: /S && dir Z:\EFI\. Verify that the only subdirectories under EFI are the expected Boot and Microsoft folders (and any OEM entries like EFI\ubuntu if dual-booting, which should be disclosed). Any unknown .efi files are an immediate IOC.

3

Hash the bootx64.efi file live

With the ESP still mounted to Z:, ask the subject to run certutil -hashfile Z:\EFI\Boot\bootx64.efi SHA256. Record the output hash. Cross-reference against the known IOC hash 91d9db5fbf3c89b0df5d674f0e367afd3ac9e45ff1c13040ee2279cf3314cbd5. A match is definitive. A mismatch against a known-good build hash is equally actionable.

4

Check bootmgfw.efi signature

Ask the subject to run certutil -hashfile Z:\EFI\Microsoft\Boot\bootmgfw.efi SHA256. This is the primary Windows Boot Manager and a second replacement target. Compare against known-good values for the installed Windows build. Both bootx64.efi and bootmgfw.efi should be checked since some bypass implementations target one or both.

5

Unmount ESP and verify BIOS boot order

After inspection, ask the subject to unmount via mountvol Z: /D. Then ask them to open msinfo32 and confirm the BIOS Mode is UEFI. A system reporting Legacy (CSM/MBR boot) warrants separate investigation as it indicates the system is not using UEFI boot at all, which precludes Secure Boot enforcement entirely.

Detection Notes

Secure Boot enforcement eliminates this class of bypass entirely. Server administrators should consider making Secure Boot status a requirement for participation. A player presenting with Secure Boot disabled and no legitimate dual-boot or Linux rationale has no credible excuse on a system intended solely for gaming.

The SHA-256 and SHA-1 hashes documented here are for the specific bypass sample analyzed. Actors may produce new builds of the modified bootloader; in those cases, a hash-based positive identification will not match, but a mismatch against the legitimate Microsoft-signed bootloader hash for the installed Windows build remains a valid IOC. Always maintain a reference database of legitimate bootloader hashes per Windows build for comparison.

Investigators should be aware that certain legitimate software (BitLocker with custom TPM configurations, some hardware vendor OEM entries) can add files to the ESP. These should be identifiable by their vendor certificates and known file sizes. The presence of unsigned or anomalously-sized EFI binaries with no legitimate vendor explanation is the definitive flag.