When Delete Fails: Weaponizing ISOs to Defeat EDR Remediation

In the realm of advanced Windows exploitation and kernel interactions, the ‘Bring Your Own Vulnerable Driver’ (BYOVD) technique remains a staple in a Red Teamer’s arsenal. The premise is straightforward: leverage a legitimate, signed kernel driver with known vulnerabilities to execute privileged operations, such as terminating protected Endpoint Detection and Response (EDR) processes, from Ring 0.

However, the security landscape is adaptive. Modern EDR and XDR solutions, including Cynet and Trend Micro Vision One, have evolved beyond simple blocking. They often employ aggressive sanitization routines: upon detecting a known malicious driver hash (like the well known zam64.sys from Zemana AntiMalware), the EDR not only terminates the loading process but immediately quarantines or deletes the .sys file from the disk.

This destructive response creates a logistical challenge for the attacker. If the weaponization tool fails on the first attempt, the payload is gone, requiring a fresh drop which invariably triggers another alert. Yet, analysis of this behavior reveals a fundamental flaw: A reliance on file system write access to mitigate the threat. By introducing a read-only ISO container, this sanitization mechanism can be turned into a futile loop, allowing an attacker to exploit a race condition and successfully disable the EDR (with alerts but disabled).

The Sanitization Loop and Race Conditions

When a program attempts to register and load a vulnerable driver, EDR solutions utilizing file system mini-filters intercept the operation. Solutions like Trend Micro Vision One and Cynet typically follow a distinct pattern:

1. Detection: The driver write or load attempt matches a known bad signature.
2. Intervention: The loading process is halted.
3. Remediation: The driver file is deleted to prevent future attempts.

Between the drop of the driver and its deletion, a race condition exists. It is a narrow window, often milliseconds. In a standard file system environment (NTFS), the EDR usually wins, or if it doesn’t, it successfully removes the file, preventing a second attempt. The attacker runs out of ammunition before they can force the door open.

The ISO Anomaly: Immutable Ammunition

The “Head First Through the Wall” strategy changes the environment to nullify the remediation step. Windows natively supports mounting ISO images, treating them as virtual optical drives. Crucially, these mounted volumes are read-only.

By packaging the compiled attack toolkit, specifically the loader (main.exe) and the vulnerable driver (Terminator.sys) into an ISO, we can observe a different behavior:

1. The ISO is mounted (e.g., as Drive E:).
2. The loader (main.exe) is executed directly from the read-only volume.
3. It attempts to create the service and load the driver.
4. The EDR detects the threat and attempts to delete E:\Terminator.sys.
5. The operating system returns STATUS_MEDIA_WRITE_PROTECTED.
6. The EDR’s remediation routine fails, but the file remains intact.

Exploiting the Loop

With the “ammunition” now indestructible, the limitation of a single attempt is removed. The EDR is forced into a loop of detection and failed remediation. This persistence allows the attacker to aggressively spam the load request.

Tests conducted against active Cynet and Trend Micro Vision One installations demonstrate that while the EDR is efficient, it is not infallible under high-frequency stress. By repeatedly executing main.exe in rapid succession, the race condition is eventually won. The EDR's processing overhead, analyzing the file, making the decision, attempting the deletion, and handling the error, creates brief gaps in coverage.

It typically takes between 5 to 8 rapid execution attempts. Eventually, the driver slips through the filter checks during a momentary lapse in the EDR’s enforcement cycle and successfully loads into the kernel.

Successful disable Trend Micro EDR / XDR

Impact and Persistence

Once Terminator.sys is loaded, the game effectively ends for the EDR. The driver, originally part of Zemana AntiMalware, allows trusted processes to issue IOCTLs that can terminate any process ID (PID), regardless of its protection level (PPL).

As illustrated in the screenshot above, the tool successfully registers itself as trusted and systematically terminates the core processes of the EDR. While the UI agent might appear responsive or “ghosted,” the underlying sensors and enforcement drivers are severed.

The loader tool used (main.exe) is designed for operational efficiency. It checks for existing services before attempting a new load. If the driver is successfully loaded once, subsequent executions simply reuse the existing kernel service to terminate additional PIDs without re-triggering the initial race condition.

Full source code: https://github.com/FLX-0x00/BYOVD-Zemana (forked and modified)

Conclusion

The effectiveness of this technique highlights a critical distinction between “detecting a threat” and “neutralizing a threat.” Relying on file deletion as a primary mitigation strategy is insufficient when the environment (Read-Only File Systems) prevents modification.

For Blue Teams and security architects, this underscores the necessity of defense-in-depth strategies. Blocking known vulnerable drivers must occur at the API or integrity level, such as utilizing Microsoft’s Vulnerable Driver Blocklist or enforcing strict Windows Defender Application Control (WDAC) policies, rather than relying solely on reactive file scanning and deletion.

Cheers, FLX