A newly discovered Windows attack method dubbed BYOTC (Bring Your Own Trusted Caller) leverages the trust built into signed drivers to execute privileged actions through otherwise legitimate applications. Rather than exploiting vulnerabilities in drivers themselves, BYOTC subverts trust in a signed “trusted caller” to issue dangerous operations on behalf of attackers. Analysts from Xusheng.dev uncovered the strategy.
How BYOTC Works
Typically, drivers grant special permissions only to explicitly approved user-mode programs, commonly identified via digital signatures. These drivers are often designed to block untrusted apps or executables. The novel insight of BYOTC is that an attacker can compromise one of these trusted applications—injecting code, modifying memory or process lists—to act as the attacker’s agent. Despite the process being signed, its runtime integrity (loaded modules, code paths, etc.) can be corrupted. When such a tampered process sends a request via the driver, the driver believes it is interacting with a legitimate, signed client and grants elevated privileges.
Analysts highlight two cases. In one scenario, the attacker used a client program whose image signature was accepted by a security driver. After starting the client, the attacker injected a DLL, then used the altered client to ask the driver to stop Microsoft Defender’s service. In a second case involving System Informer, the driver had multiple integrity levels and checked file signatures, debug states, and loaded images. The critical vulnerability emerged when the parent process, which created a signed child process, held elevated handles and memory-write rights—allowing a hostile elevated parent to alter the child, which inherited maximum trust.
Patches, Mitigations, and Recommendations
System Informer responded by tightening its validation. It now requires that the creator of a trusted chain be either a process with MAXIMUM integrity or a protected Windows TCB/System process. It’s also changed how restarts are handled: a temporary service is used to ensure that an ordinary administrator cannot retain an elevated handle to act as the privileged creator. The update went out via System Informer’s Release Channel on August 29, 2026.
Security experts urge developers to re-examine their driver trust models. Key suggestions include: using Protected Process Light (PPL) wherever feasible; treating any loss of runtime integrity as permanent; preventing injection, modification or hostile parent-process involvement; ensuring sensitive operations require not just a signed executable, but validated execution context and creation history.
Indicators of Compromise (IoCs)
- Driver hash: SHA-256 “d86b9b20788b6bff70a1a4c4111b2ea33b9ec705cc6b8fe869362fc3899820a3” tied to the first BYOTC case.
- driver file “mbamchameleon.sys” with trusted client “MBAM.exe” abused to target “MsMpEng.exe” (Microsoft Defender process).
- Another case shows “SystemInformer.sys” and “SystemInformer.exe” involved in the trust chain, with a “malicious.exe” as the elevated parent process.
- IOCTL codes abused include 0x222008 (register trusted caller) and 0x222024 (privileged process termination).
This attack model connects to earlier signed driver abuse methods deployed by threat actors to disable defenses, exfiltrate data or lay groundwork for later-stage compromise. But BYOTC marks a shift: the driver may be functioning exactly as intended while the vulnerability lies in how it grants trust to a caller whose internals have been subverted.
The broader implications are significant. Security teams must no longer assume binary signing alone provides adequate protection. Runtime integrity—ensuring that a process has not been injected into, its memory unchanged, and its parent-child chain trusted—is now vital. Systems and driver designs must explicitly assess whether a so-called “trusted caller” remains unmodified, how it was launched, and whether its creator process is itself compromised or privileged. The days of relying on signature checks alone may be ending.
