New BYOTC Attack Hijacks Trusted Windows Apps to Abuse Privileged Kernel Drivers
Researchers uncover Bring Your Own Trusted Caller (BYOTC), a novel Windows attack technique that exploits the trust relationship between legitimate applications and privileged kernel drivers to disable security tools.
A new Windows attack technique, dubbed Bring Your Own Trusted Caller (BYOTC), has been identified by researchers, allowing threat actors to leverage legitimate, signed applications to abuse privileged kernel drivers. This method circumvents traditional security measures by exploiting the inherent trust Windows places in signed executables, turning them into conduits for malicious actions.
Unlike Bring Your Own Vulnerable Driver (BYOVD) attacks, which rely on flaws within the driver itself, BYOTC targets the trust relationship between a driver and its approved user-mode caller. The driver may function as intended, but an attacker, having gained control of a trusted client application, can issue unauthorized, privileged commands that the driver then executes. This creates a "confused deputy" scenario where the driver performs actions on behalf of an attacker masquerading as a legitimate process.
Analysts at Xusheng.dev detailed the BYOTC technique, highlighting its potential to disable critical security software like Microsoft Defender before deploying further malicious payloads such as ransomware or credential theft tools. The core issue lies in the fact that a digital signature verifies the identity of the application that initiated a process, but it does not guarantee the ongoing integrity of that process. An attacker with administrative privileges can inject malicious code into a trusted application, thereby inheriting its privileges and access to sensitive system functions.
One of the identified attack vectors involved a security driver that accepted registration requests only from applications signed by its vendor. Researchers demonstrated how, after injecting a DLL into a legitimate client process, they could use that now-trusted application to command the driver to terminate Microsoft Defender's service. This underscores the need for deeper security analysis beyond simple signature checks, focusing on runtime integrity and the creation history of processes.
The second case study involved System Informer, a tool with a driver that implemented multiple integrity checks, including executable file verification, digital signatures, and debug state. Even with these robust measures, attackers found a way to exploit the process creation mechanism. Windows grants specific handles and memory-operation rights to legitimate parent processes during child process creation. An elevated attacker could leverage these rights to create a verified instance, modify it, and then use it to launch a child process that inherited maximum trust, ultimately enabling privileged actions.
System Informer has since patched this vulnerability by enhancing its driver's requirements. The updated driver now mandates a MAXIMUM integrity level creator or a protected Windows TCB/System process at the root of a trusted chain. Furthermore, it modified its restart process to use a temporary service, preventing ordinary administrators from retaining the necessary privileged creator handle. The fix was released to the Release Channel on August 29, 2026.
The research team recommends that developers anchor trust in Protected Process Light (PPL) where feasible and treat any loss of runtime integrity as a permanent condition rather than attempting to restore trust after a temporary exploit. Broader recommendations include blocking known-abusable drivers, scrutinizing every privileged driver operation, and rigorously validating a caller's runtime integrity and its creation lineage. This BYOTC technique represents a significant design concern for Windows rather than a simple kernel driver vulnerability.
Indicators of Compromise (IoCs) provided include specific SHA-256 hashes for affected drivers, associated executable files, the targeted Microsoft Defender process, and the IOCTL codes used for driver registration and process termination requests. These details are crucial for security teams to detect and investigate potential BYOTC-based attacks.