Kiran 
A new attack pattern is forcing security vendors to rethink what “trusted” really means at the Windows kernel boundary, and it doesn’t require a single vulnerable line of driver code.
Security researcher xusheng has documented a technique called Bring Your Own Trusted Caller (BYOTC), a cousin of the well-known Bring Your Own Vulnerable Driver (BYOVD) tactic.
While BYOVD exploits a flaw in a signed kernel driver, BYOTC exploits something far harder to patch: the trust relationship between a privileged driver and the legitimate user-mode application it’s designed to obey.
BYOTC Explained: New Windows Driver Attack Hijacks Trusted Apps
In both real-world case studies detailed in the research, the driver code was working exactly as intended; the attacker simply hijacked the “trusted” client that talks to it.
Security and system-inspection drivers legitimately need dangerous capabilities: terminating processes, opening privileged handles, resisting tampering.
To avoid handing that power to any process that asks for it, vendors build caller-authentication checks into their drivers. BYOTC targets exactly that checkpoint.
Instead of attacking the kernel interface, an attacker obtains code execution inside, or otherwise manipulates, the one user-mode program the driver already trusts, then makes that process issue the privileged request on the attacker’s behalf. It’s a textbook confused-deputy problem, just relocated to the user/kernel boundary.
The simplest demonstration involved Malwarebytes’ mbamchameleon.sys, which exposed an IOCTL capable of invoking ZwTerminateProcess a feature, not a bug, meant for eliminating malicious processes.
The driver trusted only callers whose executables were signed by Malwarebytes. The researcher launched the legitimate, signed MBAM.exe, injected a DLL into it, registered it as trusted, and then used it to kill Microsoft Defender‘s MsMpEng.exe. A valid signature proves what started the process, not what it’s currently executing.
System Informer’s SystemInformer.sys used a far more rigorous model, assigning clients cumulative integrity levels up to MAXIMUM based on image verification, handle protection, and secure creation history.
The flaw wasn’t in any single check it was in the chain: an administrator-level malicious process could create and modify a “HIGH” instance of System Informer via a legitimate creator handle, then let that compromised process spawn the MAXIMUM instance, inheriting trust it never earned. Every individual check passed while the chain itself was corrupted.
System Informer’s developers responded by rooting the trust chain in services.exe, a Windows-protected TCB process an ordinary administrator cannot forge, and by making integrity violations “sticky” so trust can’t be silently restored. Malwarebytes, notified in June 2025, had not shipped a fix as of the September 2026 disclosure.
The researcher argues that BYOTC ultimately isn’t a per-vendor bug; it’s a gap Microsoft itself needs to close, since Windows currently lacks a general-purpose way for third-party drivers to grant a user-mode process power while guaranteeing that process stays uncompromised. A third, still-embargoed BYOTC case study is expected later this month.
Site: Thecyberdef.com
Follow TheCyberDef on Google News, LinkedIn & X for the latest cybersecurity updates. Stay informed.
About the Author
