BYOTC Attack Hijacks Windows Apps to Abuse Privileged Kernel Drivers

Key Takeaways

• A novel Windows attack, “Bring Your Own Trusted Caller” (BYOTC), allows attackers to leverage legitimate user-mode applications to execute privileged actions via kernel drivers.
• Unlike traditional “Bring Your Own Vulnerable Driver” (BYOVD) attacks, BYOTC exploits the trust relationship between a driver and its approved caller, rather than a flaw in the driver itself.
• Researchers demonstrated the attack by injecting malicious code into signed applications, enabling them to control kernel drivers and disable security services like Microsoft Defender.
• System Informer, one of the affected drivers, has released a patch (August 29, 2026) to mitigate the “evil parent” attack vector.
• The attack highlights that a valid digital signature only verifies a program’s initial launch, not its ongoing integrity or control flow.

A sophisticated new attack vector targeting Windows systems has emerged, demonstrating how seemingly innocuous, trusted user-mode applications can be weaponized to manipulate highly privileged kernel drivers. Dubbed “Bring Your Own Trusted Caller” (BYOTC), this method allows malicious actors to transform legitimate software into a conduit for executing dangerous operations typically restricted to the kernel.

Unlike its predecessor, the “Bring Your Own Vulnerable Driver” (BYOVD) attack, BYOTC does not depend on a flaw within the driver itself. Instead, it exploits the inherent trust model between a driver and its authorized user-mode applications. This means the driver may be functioning precisely as intended, offering capabilities such as process termination, privileged handle acquisition, or resilience against interference. The attacker’s objective is to seize control of the approved application, thereby inheriting its legitimate authority to request these sensitive driver functions.

Analysts at Xusheng.dev were instrumental in identifying this attack pattern across two distinct driver designs. Their research reveals a critical security gap: while a valid digital signature confirms the authenticity of a launched program, it does not guarantee that the running process remains under the software vendor’s intended control. As Xusheng.dev said in a report, the implications are severe, as a compromised trusted client can issue harmful requests that bypass authorization checks, appearing entirely legitimate.

This newly identified risk introduces another layer of complexity to the landscape of trusted Windows driver abuse. Such abuse is frequently observed in campaigns where threat actors aim to disable crucial security tools before deploying payloads like ransomware or stealing credentials.

New BYOTC Attack Hijacks Trusted Windows Apps

The fundamental distinction between BYOTC and BYOVD lies in their exploitation targets. BYOVD capitalizes on a vulnerability within a signed driver itself. In contrast, BYOTC leverages the established trust relationship between a driver and its legitimate user-mode application. This effectively turns the driver into a “confused deputy,” executing powerful commands on behalf of an attacker who has infiltrated an otherwise trusted process.

One case study involved a security driver designed to accept registration requests exclusively from applications signed by its vendor. The researcher successfully launched the legitimate client application, injected a Dynamic Link Library (DLL) into its process, and subsequently commanded the now-trusted application to instruct the driver to terminate the Microsoft Defender service. This technique mirrors the risks associated with modern Windows process injection, where malicious code operates from within a legitimate process.

The underlying issue extends beyond a simple failure in signature verification. A digital signature primarily validates the file used to initiate a process; it does not provide continuous assurance that the code, memory, loaded modules, or control flow within that running process have remained untampered. An attacker who has already achieved administrator privileges can exploit a trusted client after its launch, thereby inheriting access to high-privilege functions that would otherwise be inaccessible.

Consequently, defensive strategies must become more rigorous. Security teams should not merely confirm that a driver blocks untrusted executables. They must also assess whether a trusted client can be injected, modified, debugged, or launched under the control of a malicious parent process. These expanded checks are particularly vital for drivers possessing the capability to disable endpoint protection mechanisms, a common tactic in signed driver abuse campaigns.

Evil Parent Exposes Trust Gap

A second instance examined by researchers involved System Informer, a tool whose driver implemented robust security measures, including multiple integrity levels and verification of executable files, signatures, debug states, and loaded images. The most sensitive operation, process termination, mandated the highest integrity level, “MAXIMUM,” initially suggesting a well-protected design compared to a basic signer check.

However, researchers discovered a subtle vulnerability during Windows process creation. The legitimate parent process requires strong handles while preparing its child process. The driver, in this scenario, granted the creator additional memory-operation and memory-write permissions. An elevated hostile program could exploit this by creating a verified instance of System Informer, modifying it through the granted handle, and then using this altered instance to spawn a child process that inherited maximum trust.

System Informer has since addressed this vulnerability. The updated driver now mandates that the creator process itself must possess “MAXIMUM” integrity or originate from a protected Windows TCB/System process at the root of any new trusted chain. Furthermore, the restart mechanism has been modified to utilize a temporary service, preventing an ordinary administrator from retaining the privileged creator handle. This patched, signed driver was released to the public on August 29, 2026, as detailed in the report.

The research strongly advocates for developers to anchor trust in Protected Process Light (PPL) where feasible and to treat any loss of integrity as a permanent compromise, rather than

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.