BYOTC Attack Abuses Trusted Windows Clients to Access Privileged Kernel Driver Operations

A newly documented Windows attack pattern, dubbed Bring Your Own Trusted Caller (BYOTC), shows how attackers can bypass driver-level authorization controls without exploiting a traditional memory-corruption flaw.

Instead of attacking a privileged kernel driver directly, an adversary compromises or abuses the legitimate user-mode application that the driver already trusts.

The technique expands on the well-known Bring Your Own Vulnerable Driver (BYOVD) model. In BYOVD attacks, threat actors load a legitimately signed but vulnerable driver to obtain kernel-level capabilities.

Microsoft’s vulnerable driver blocklist and the community-maintained LOLDrivers database aim to reduce that exposure by tracking drivers known to be vulnerable or maliciously abused.

Security, anti-malware, inspection, and self-protection drivers may legitimately need to terminate processes, access protected handles, or perform other operations unavailable to standard user-mode software.

Rather than exposing these functions to every process, vendors often allow requests only from a signed or validated client application.

That approach creates a critical second boundary. A signed executable proves the origin of the file that launched the process, but not that the running process remains under the vendor’s exclusive control.

If an administrator-level attacker can inject a DLL, manipulate memory through a retained process handle, or hijack a trusted process-creation chain, the driver may accept malicious commands from a caller that still appears legitimate.

In effect, BYOTC turns the trusted client into a confused deputy at the user/kernel boundary. The kernel driver correctly verifies that a request came from an approved process, yet that process is no longer trustworthy.

One example involves Malwarebytes’ mbamchameleon.sys, a component associated with Malwarebytes Chameleon that is designed to help resist malware interference.

The driver exposed IOCTL 0x222024, which could ultimately invoke ZwTerminateProcess a legitimate feature intended to stop hostile processes.

Research disclosed in September 2026 found that the driver first allowed a process to register as trusted through IOCTL 0x222008, based on whether the caller image was signed by Malwarebytes.

An attacker with administrator privileges could launch the legitimate signed MBAM.exe, inject code into the process, register it with the driver, and invoke the privileged termination operation against a security process such as Microsoft Defender’s MsMpEng.exe.

The issue was not a malformed IOCTL or a driver memory-safety bug. It was the assumption that a signed process remained trustworthy after startup.

Xusheng Researchers said that, BYOTC targets a different problem: privileged driver features that are intentional, but inadequately protected by the user-mode trust model.

BYOTC Attack Abuses Windows Clients

Malwarebytes Chameleon is a legitimate protection component, but that trust relationship can become dangerous when an attacker controls its client process.

A more sophisticated BYOTC case affected System Informer’s SystemInformer.sys driver.

System Informer applies multiple integrity checks to clients, including executable verification, module-load monitoring, debugger detection, protected process handles, and a secure process-creation history.

Its most sensitive process-termination messages require a client to reach the MAXIMUM integrity level.

However, Windows process creation introduces a difficult exception: the process that creates a child retains powerful initialization handles.

An elevated malicious parent could create a legitimate System Informer process, retain permissions such as PROCESS_VM_OPERATION and PROCESS_VM_WRITE, modify the child during initialization, and then use it to build a new, apparently trusted process chain.

The vulnerability was therefore not simply code injection. It was a trust-escalation flaw in which a child process could receive higher trust than the entity that still controlled its initialization.

System Informer addressed the issue by anchoring its secure creation chain in Windows-protected service infrastructure.

Its revised design uses a temporary service launched through services.exe, a Windows TCB-protected process, as the trusted root for creating the higher-integrity client.

System Informer’s driver architecture already verifies user-mode binaries and restricts unsigned module loading, illustrating the depth of protections needed to defend privileged client-driver communication.

BYOTC is especially relevant to EDR, antivirus, anti-cheat, endpoint-management, and system-inspection products.

These tools commonly expose powerful kernel operations while relying on user-mode components to determine who may invoke them.

Defenders should test whether a trusted client can be injected into, debugged, launched by an attacker-controlled parent, or modified through inherited process handles.

They should also ensure trust revocation is permanent: once an untrusted module, debugger, or tampering event is detected, a process should not regain privileged status simply because the condition disappears.

The strongest design anchors the trusted client in Windows-enforced protections such as Protected Process Light, rather than relying only on signer checks or vendor-maintained process state.

But PPL remains difficult to deploy outside specialized protected-service models.

BYOTC ultimately highlights a gap in Windows driver security: recognizing a signed executable is not the same as preserving the runtime integrity of the process behind it.

★ Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.