CVE-2023-41444

iREC.sys -- arbitrary kernel read/write via IOCTL

Summary

Field	Value
Driver	`iREC.sys`
Vendor	iREC
Vulnerability Class	Arbitrary R/W / IOCTL Access Control
Abused Version	1.0.0.0
Status	Still loadable -- not widely blocklisted
Exploited ITW	No

BYOVD Context

Driver signing: Authenticode-signed with valid certificate
Vulnerable Driver Blocklist: Not included in Microsoft's recommended driver block rules
HVCI behavior: May load on HVCI-enabled systems
KDU integration: Not integrated
LOLDrivers: Listed at loldrivers.io

Affected IOCTLs

Arbitrary kernel virtual memory read
Arbitrary kernel virtual memory write
Physical memory mapping

Root Cause

iREC.sys is a kernel driver that was designed with essentially no security boundary between user mode and the kernel. It exposes device IOCTLs that perform direct kernel memory read, write, and physical memory mapping operations. The user-supplied input buffers contain target addresses and data, and the driver executes the requested operation without any access control validation. The device object is created with permissive security descriptors, meaning any user on the system can open a handle to it.

This is not a bug in the traditional sense. The driver was designed to provide these capabilities, likely for debugging or system management purposes. The vulnerability is the absence of any gate between user-mode callers and kernel-level memory operations. There is no privilege check, no PreviousMode validation, no caller verification. Once the driver is loaded, it is an open door to the kernel.

dru1d.ninja published a detailed exploit development writeup demonstrating the vulnerability discovery and exploitation methodology.

Exploitation

Exploiting iREC.sys is straightforward because no bug needs to be triggered. The driver itself is the exploit primitive.

An attacker loads the signed driver (either by dropping it to disk and creating a service, or by leveraging a BYOVD loader). Once the driver is running, the attacker opens a device handle via CreateFile and issues read IOCTLs to scan kernel memory for EPROCESS structures. Having located the current process's EPROCESS and the SYSTEM process's EPROCESS, the attacker uses the write IOCTL to copy the SYSTEM token pointer into the current process's token field. The process now runs with SYSTEM privileges.

The entire chain requires no heap spray, no race condition, no information leak. The driver provides deterministic, reliable, and repeatable kernel read/write on demand.

Detection

YARA Rule

rule CVE_2023_41444_iREC {
    meta:
        description = "Detects iREC.sys vulnerable driver"
        cve = "CVE-2023-41444"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $driver_name = "iREC" wide ascii nocase
        $irec_sys = "iREC.sys" wide ascii
    condition:
        $mz at 0 and ($driver_name or $irec_sys)
}

ETW Indicators

Provider	Event / Signal	Relevance
Microsoft-Windows-Kernel-File	Driver load event	Detects loading of iREC.sys
Sysmon	Event ID 6 -- Driver loaded	Hash and signature capture
Microsoft-Windows-Security-Auditing	Event 4697 -- Service installed	Driver service creation
Microsoft-Windows-Kernel-Process	Process token modification	Post-exploitation token swap

Behavioral Indicators

Loading of iREC.sys from a non-standard path
Kernel memory read/write IOCTL patterns from unknown processes
Token swap following iREC driver interaction

Broader Significance

iREC.sys belongs to the class of "vulnerable by design" drivers that are prime BYOVD (Bring Your Own Vulnerable Driver) candidates. Because it carries a valid Authenticode signature and is not on Microsoft's driver blocklist, threat actors can drop it onto a target system and use it as a kernel-level swiss army knife. The driver's presence on LOLDrivers indicates the security community has flagged it, but the lack of blocklist inclusion means it remains a live threat. This case study highlights why driver signing alone is insufficient as a security control: a legitimately signed driver with intentionally permissive IOCTLs is indistinguishable from a backdoor from a security perspective.