Reverse-Engineering a 0-Day: PoisonX BYOVD Driver Bypasses CrowdStrike EDR

BYOVD Attacks Escalate Against EDRs

Bring-Your-Own-Vulnerable-Driver attacks are becoming common as adversaries attempt to circumvent endpoint detection techniques. In BYOVD, the attacker deploys a driver with genuine and vulnerable but signed credentials on a victim’s computer and then leverages its hidden capabilities.

The attacker exploits the driver’s vulnerabilities for conducting deeper attacks such as ending security software services, disabling tampering protection, or extracting confidential data. It is important to note that 64-bit versions of Windows operate using Driver Signature Enforcement (DSE), which means that only drivers that have been signed can be loaded into the operating system.

This leaves the adversary with no choice other than to find signed drivers that are vulnerable to exploitation, leading to the rise of BYOVD attacks. For CrowdStrike, the targeted process was the Falcon’s sensor running under Protected Process Light (PPL).

In early 2026, a previously unknown Microsoft-signed driver was identified as exposing exactly that capability. This “0-day” BYOVD bug allowed an attacker to kill the CrowdStrike Falcon service by sending a crafted IOCTL to the driver’s undocumented interface.

The PoisonX Architecture

Weaponizing Microsoft-signed kernel integrity to dismantle PPL-protected security sensors.

Vector

DSE Bypass

Exploits valid MS-signatures to load into kernel space without triggering OS alerts.

Exploit

IOCTL 0x22E010

Undocumented interface accepts arbitrary PIDs to invoke kernel termination routines.

Impact

PPL Neutralization

Ring 0 execution bypasses user-mode ‘Access Denied’ protections on security processes.

Reverse Engineering Insight

Kernel-Mode Logic: PoisonX.sys

CRITICAL

                    // PoisonX.sys: Device Dispatcher Loop

                    NTSTATUS ProcKiller(PVOID Buffer) {

                      ULONG PID = atoi((char*)Buffer);

                      // Kernel open ignores PPL protection flags

                      if (ZwTerminateProcess(PID) == STATUS_SUCCESS) {

                        RtlCopyMemory(Out, “ok”, 3);

                      }

                    }

TRUST MODEL

Zero validation of user-mode signature or privilege.

SENSOR EVASION

Targeted termination of EDR services by direct handle manipulation.

Defensive Controls

VDB Enforcement: Synchronize active blocklists.

HVCI: Enforce Memory Integrity at OS root.

Audit: Alert on driver installation (EID 7045).

XCITIUM THREATLABS

Uncovering a Microsoft-Signed Process-Killer Driver

The malware was initially found in a family of drivers (more than 15 versions) all signed by Microsoft and undetectable by antivirus software. A VirusTotal scan confirmed 0/71 detections and a valid Microsoft Hardware Compatibility signature.

In simple terms, the driver (PoisonX.sys) appeared totally legit for the operating system. Such drivers have previously been detected in the “Bring Your Own Vulnerable Driver” attacks on EDR solutions.

IDA Pro was used to bypass the obfuscation and directly analyze the dispatch handler of the driver. Two IOCTL calls were discovered. (0x22E010) was followed by a call to the procKiller procedure. This procedure contains the malicious payload itself. The execution process includes the following actions:

Read PID string: The driver treats the DeviceIoControl input buffer as a null-terminated ASCII string containing the target process ID (PID) in decimal form.
Convert to integer: The code calls atoi() on this string to get a numeric PID.
Terminate the process: It calls a helper (TerminateProcess) with the PID. If successful, it writes the string "ok" back to the output buffer.

Inside the TerminateProcess helper, the kernel code uses ZwOpenProcess to obtain a handle to the given PID and then calls ZwTerminateProcess on that handle. This is the crux: from kernel mode, ZwOpenProcess does not enforce the PPL restriction, so it happily opens and kills the protected process. In sum, a user-mode program can feed a PID to PoisonX.sys, and the driver kills any process and returns “ok”.

Key details from the analysis include the driver’s device interface and IOCTL: the symbolic link was discovered as \\.\{F8284233-48F4-4680-ADDD-F8284233} and the kill command used IOCTL 0x22E010. In practice, an attacker only needs to open the device and send that IOCTL with a PID to trigger the kill.

Reverse-Engineering the PoisonX IOCTL

One IDA shows the DeviceIoControlHandler switch that maps IOCTL 0x22E010 to procKiller. By cleaning up function names and types, it was documented that the entire malicious logic is wrapped in a single IOCTL handler.

procKiller writes only the literal "ok" on success and has no other verification or checks. In other words, the interface is as open as it gets: anyone who can load the driver and find the device path can kill any PID by calling DeviceIoControl(hDevice, 0x22E010, pidString, ...). The code contains no signature checks or ACLs it implicitly trusts that only privileged processes load the driver.

This pattern echoes other known cases. For example, the GMER rootkit tool’s driver exposes an IOCTL (0x9876C094) that also wraps ZwTerminateProcess, allowing user mode to kill processes by PID. More recently, Safetica’s security product had a kernel driver ProcessMonitorDriver.sys with a CVE-2026-0828 vulnerability: it exposed an IOCTL that let any user-mode app terminate arbitrary protected processes. These examples show that exposing process-termination routines via IOCTL can be disastrous if not carefully controlled.

Building a Proof-of-Concept Exploit

With the driver analyzed, creating an exploit was straightforward. The coded POC (PoisonKiller) that automates the process. The steps are simple:

Load the vulnerable driver. The signed PoisonX.sys is installed as a kernel driver (using OSRLOADER or sc create), which creates the \\.\{GUID} device.
Open the device. The POC calls CreateFileW("\\\\.\\{F8284233-48F4-4680-ADDD-F8284233}", ...) to get a handle to the driver.
Prepare the PID. The target process ID (e.g. the Falcon service PID) is converted to a decimal ASCII string.
Send the kill IOCTL. The exploit calls DeviceIoControl(hDevice, 0x22E010, pidString, ...). The driver’s procKiller runs and kills the process.

In execution, the POC output shows “[+] Device opened”, then “[+] Sending kill command”, and finally “Driver response: ok” followed by “[+] Process terminated”. A real test on a system with CrowdStrike loaded showed the Falcon process disappearing after the IOCTL call.

Thus, the exploit workflow can be summarized:

Open the driver (via its symbolic link).
Supply the target PID as text to the IOCTL.
The driver kills the process at kernel level.

These steps could be packaged in a simple script or tool, essentially giving an attacker a “kill switch” for PPL-protected services.

Weaponizing Signed Drivers: Other Cases

PoisonX is not the exception, rather the result of a growing trend of abusing signed drivers. As was shown earlier, there are several other examples of maliciously using signed drivers, such as Safetica’s CVE-2026-0828 and GMER.

For detecting such misuse, one might look out for suspicious device creations, calls to an IOCTL, and even logging of event IDs. For PoisonX, the unexpected exit of some process or installation of new kernel driver by another could serve as warnings of such an attack.

To sum up, even a zero-day kernel can easily be exploited through a single driver, which, again, is due to trusting the user too much. Through analysis of the structure of IOCTL call and proof of concept code, we’ve seen exactly how this 0-day worked.

Conclusion: When a Signed Driver Becomes the Kill Switch for Security

PoisonX shows how modern defense evasion has moved below user mode and into the kernel. A Microsoft-signed driver, trusted by the operating system and invisible to antivirus during initial discovery, exposed a hidden IOCTL that let an attacker terminate protected security processes by PID. In practice, that meant a single driver could turn CrowdStrike Falcon from a running control into a silent target.

Why This Threat Matters

This is not just another malware loader. It is a trust failure inside the driver model itself.

Driver Signature Enforcement allows signed drivers to load, even when the logic behind them is dangerous.
The PoisonX interface performed no meaningful validation, it simply accepted a PID and killed the process.
Kernel mode bypassed Protected Process Light safeguards that normally block this from user mode.

Why Organizations Are Exposed

BYOVD attacks keep working because they exploit the exact thing defenders must trust, signed kernel components.

Once the driver is loaded, the attacker no longer needs noisy exploitation. They need only a device handle, an IOCTL, and the target PID. That is enough to sever security telemetry before the real intrusion begins.

Where Xcitium Changes the Outcome

This kind of attack requires two layers of defense.

Xcitium Vulnerability Assessment helps surface risky driver exposure, weak policy settings, and missing preventive controls such as active blocklists and HVCI, before attackers operationalize them.
Xcitium Advanced EDR breaks the follow-on attack chain by stopping malicious driver-loading and post-execution abuse before it turns into system compromise. In Xcitium’s BYOVD protection model, the attacker does not get the quiet shutdown they need. A signed driver may try to load, but code can run without being able to cause damage.

If you have Xcitium in place, this attack does not succeed the way the attacker needs.

Do Not Trust the Signature Alone

PoisonX proves that kernel trust without runtime control is no longer enough. Enforce blocklists, enable memory integrity, and stop driver-based attack chains before they silence the tools you depend on.

Like what you see? Share with a friend.