CVE-2025-52915: A BYOVD Evolution Story

TL;DR

K7RKScan.sys exposes a process termination IOCTL to user-mode without sufficient caller or target validation. This flaw enables attackers to terminate arbitrary processes from kernel mode, bypassing user-mode protections that legitimate security tools rely on. Despite multiple version updates and security improvements, the vulnerability persists in the latest release-now gated by admin checks but still usable in BYOVD attack chains.

---

This analysis examines vulnerabilities discovered in K7Computing’s rootkit scanner driver K7RKScan.sys across two versions, showing how fundamental design flaws persist across driver releases despite security improvements.

Disclosure Timeline

I reported the vulnerability on June 3, 2025, but a week later CVE-2025-1055 appeared crediting another researcher for what looked like the same issue. Throughout this time, my report was being dismissed as “highly unlikely” while they kept asking for more and more proof. The situation became even stranger when it turned out they actually thought I was the other researcher who had received credit for the first CVE. Even after acknowledging this confusion, they continued requesting additional evidence while maintaining their stance. What made it particularly odd was that the first CVE had gaps in the technical details and only covered versions up to 23.0.0.10. So when I demonstrated that BYOVD issues still existed in the latest version, they ended up assigning me CVE-2025-52915.

The core problem is simple: a kernel-level process termination IOCTL exposed to user mode with poor validation. The LPE got patched, but the BYOVD risk stayed across all versions because the fundamental driver design never changed. The way this vulnerability shows up differs between driver versions:

• CVE-2025-1055 (v15.1.0.6): No caller validation enables both privilege escalation and BYOVD attacks
• CVE-2025-52915 (v23.0.0.10): Admin checks and process filtering were added, but BYOVD attacks still work

The Legacy Vulnerability: CVE-2025-1055 (v15.1.0.6)

How the Driver Works

K7RKScan.sys version 15.1.0.6 follows standard Windows driver setup, but with a critical security oversight. When the driver loads, it creates a communication channel that any user can access.

The driver initialization begins with basic memory allocation and device setup:

This routine creates a device at \\Device\\NTK7RKScnDrv with symbolic link \\DosDevices\\DosK7RKScnDrv, making it accessible to user-mode applications. The driver assigns sub_11434 to handle device open/close operations, while sub_114A0 processes IOCTL commands.

When a user application tries to open the driver, it goes through the CREATE handler. This function performs basic reference counting but includes the critical security flaw:

This function does basic reference counting to track how many applications have the device open, but here’s the critical flaw: it performs no security checks whatsoever. Any user on the system can successfully open a handle to this device.

The Kill Switch

Once a user opens a handle to the driver, the real risk begins in the IOCTL handler sub_114A0. This function interprets user-supplied commands, including one that terminates processes with full kernel privileges:

The logic is simple: when IOCTL 0x222018 is received with a process ID in the input buffer, the driver looks up that process and terminates it with SYSTEM privileges. No validation, no restrictions.

Attack Scenarios

This design creates two distinct attack vectors:

Direct BYOVD Attack: Attackers with admin privileges can manually load the driver and immediately begin terminating any process on the system, including heavily protected processes like MsMpEng.exe (Windows Defender) and NisSrv.exe.

Race Condition Privilege Escalation: Attackers can exploit the timing when K7’s legitimate software loads this driver during system scans. When scans complete or get canceled, there’s a brief cleanup window where the driver remains loaded. Standard users can exploit this timing by:

1. Monitoring for K7 Rootkit Scanner service activity
2. Detecting when the driver becomes accessible during cleanup phases
3. Rapidly opening \\.\DosK7RKScnDrv before the driver unloads
4. Sending IOCTL 0x222018 commands to terminate arbitrary processes with SYSTEM privileges

The Current Version: CVE-2025-52915 (v23.0.0.10)

Security Improvements

The current version of K7RKScan.sys (23.0.0.10) includes some security improvements compared to the legacy version. The most significant change appears in the driver initialization, which now includes enhanced security handlers.

The key difference is the new CREATE/CLOSE handler sub_140001E50, which adds proper privilege verification:

This enhanced handler checks for admin privileges using SeTokenIsAdmin() and enforces single-connection semantics. This change effectively mitigates the race condition-based privilege escalation vulnerability.

Process Protection Logic

Unlike the legacy version this time the termination logic has been moved into sperate fucntion

Beyond access control, the updated driver also adds process filtering to prevent termination of critical system components. The filtering function sub_140001680 implements multiple protection layers:

This filtering logic has multiple layers of protection. First, it maintains a hardcoded blacklist of critical system processes (csrss.exe, smss.exe, lsass.exe, winlogon.exe, svchost.exe) along with all K7-branded processes. Second, on Windows 8 and later systems, it checks for Protected Process (PP) and Protected Process Light (PPL) status.

Persistent BYOVD Risk

Even with recent changes, the core issue remains. The driver still doesn’t validate who’s calling it, meaning it can be used to terminate processes that resist standard shutdown methods. While the blacklist helps reduce misuse, it doesn’t offer complete protection.

In practice, this leaves processes and services that can withstand user-mode termination - such as those immune to taskkill /f - but aren’t protected with PPL still exposed. The driver provides a direct kernel-level path to terminate them.

This design creates the same attack vectors as the legacy version, but with updated requirements:

Direct BYOVD Attack: Attackers with admin privileges can manually load the driver and immediately begin terminating processes that survive standard administrative termination methods. The process filtering blocks critical system processes, but everything else remains vulnerable.

Timing Window Attack: Attackers can exploit the timing when K7’s legitimate software loads this driver during system scans. When scans complete or get canceled, there’s a brief cleanup window where the driver remains loaded. Admin users can exploit this timing by:

The timing attack works exactly like in the legacy version - the only difference is now requires admin privileges. While this prevents escalation from standard users, it unintentionally enhances attacker capabilities for those with admin access. K7’s presence gives admin attackers enhanced capabilities they wouldn’t have on systems without K7 installed.

Vulnerability Evolution

The progression between driver versions reveals a predictable pattern:

Version	Access Control	Process Filtering	Attack Surface
15.1.0.6	None	None	Any user → any process
23.0.0.10	Admin required	Blacklist added	Admin → non-blacklisted processes

This evolution shows how vendors typically approach security fixes: address the most critical vulnerability (privilege escalation) while preserving the core functionality that made the driver attractive to attackers in the first place.

Impact Analysis

The K7RKScan.sys case shows why BYOVD vulnerabilities persist across development cycles. Even when vendors fix privilege escalation issues, they often keep the kernel functionality that made the driver useful to attackers. Process termination through kernel drivers bypasses user-mode protections. This makes K7RKScan.sys valuable for killing security software and other restricted processes that resist standard termination methods.

Resources

• Full proof-of-concept for both CVEs code is available on GitHub.
• Vendor Response: Official K7 Computing advisory

Conclusion

K7RKScan.sys represents a common pattern in kernel driver security. The vendor successfully addressed privilege escalation but maintained the BYOVD-enabling functionality. This shows why comprehensive security reviews are essential during driver development - addressing surface-level issues often misses fundamental design problems.

PoC’s

• LPE

• BYOVD