New BYOTC Attack Hijacks Trusted Windows Apps to Abuse Privileged Kernel Drivers

A new Windows attack shows how a trusted program can become a path to sensitive system functions. The method, called Bring Your Own Trusted Caller, or BYOTC, turns a legitimate user-mode application into the tool that asks a privileged driver to perform dangerous actions.

Unlike a conventional vulnerable-driver attack, the driver may be working exactly as designed. Its sensitive features can include stopping processes, opening privileged handles, or resisting interference, but attackers seek to take control of the approved application allowed to request those features.

Analysts at Xusheng.dev identified the pattern in two driver designs. The findings show that a valid digital signature can confirm the program that launched, yet fail to guarantee that the running process remains under the software maker’s control.

Xusheng.dev said in a report shared with Cyber Security News (CSN) that the impact is serious because a compromised trusted client can make a harmful request with an authorization check that appears valid.

That risk adds a new layer to trusted Windows driver abuse associated with attempts to disable security tools before ransomware, credential theft, or other payloads are deployed.

New BYOTC Attack Hijacks Trusted Windows Apps

BYOTC differs from BYOVD in a key way. BYOVD relies on a flaw in a signed driver; BYOTC instead exploits the trust relationship between a driver and its approved user-mode caller.

In effect, the driver becomes a confused deputy, carrying out a powerful action for an attacker hiding inside a trusted process. One case involved a security driver, which accepts a registration request only from an application whose image is signed by its vendor.

The researcher launched the client, injected a DLL into its process, and then used the now-trusted application to ask the driver to terminate Microsoft Defender’s service. This resembles the risk described in new Windows process injection, where malicious code operates inside a legitimate process.

The problem is not a broken signature check in isolation. A signature identifies the file used to create a process, but it does not continuously prove that code, memory, loaded modules, and control flow have remained unchanged.

An attacker with administrator rights can exploit a trusted client after launch and inherit access to functions others cannot reach.

Defensive reviews are therefore more demanding. Teams should not merely ask whether a driver blocks untrusted executables; they should test whether a trusted client can be injected, modified, debugged, or launched through a hostile parent process.

These checks matter especially for drivers that can stop endpoint protections, a capability often seen in signed driver abuse campaigns.

Evil Parent Exposes Trust Gap

The second case targeted System Informer, whose driver applied multiple integrity levels and verified executable files, signatures, debug state, and loaded images.

Its most sensitive process-termination operation required the highest level, called MAXIMUM, so the design initially appeared better protected than a simple signer check.

Researchers found that Windows process creation still left a narrow opening. The legitimate creator needs strong handles while preparing its child, and the driver allowed that creator additional memory-operation and memory-write rights.

An elevated hostile program could create a verified instance, alter it through that handle, and use it to build a child that inherited maximum trust.

System Informer has addressed the gap by requiring a MAXIMUM creator or a protected Windows TCB/System process at the root of a new trusted chain.

It also changed its restart path to use a temporary service, preventing an ordinary administrator from retaining the privileged creator handle. The updated signed driver reached the Release Channel on August 29, 2026, according to the report.

The research recommends anchoring trust in Protected Process Light, or PPL, where possible, and treating loss of integrity as permanent rather than restoring trust when a temporary condition disappears.

Developers should block known-abusable drivers, examine every privileged driver operation, and validate the caller’s runtime integrity and creation history. This is a broader Windows design concern, not simply another kernel driver vulnerability to patch.

Indicators of Compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.

The post New BYOTC Attack Hijacks Trusted Windows Apps to Abuse Privileged Kernel Drivers appeared first on Cyber Security News.