A signed kernel driver is one of the most powerful execution primitives available on Windows. Once loaded, it operates with unrestricted access to memory, processes, filesystems, and network traffic.

wskmon.sys takes full advantage of that position. Rather than acting as a simple kernel implant, it implements a complete network-accessible backdoor inside a trusted, WHQL-signed driver.

Overview

wskmon.sys is a 64-bit Windows kernel-mode driver that acts as a fully-featured remote access backdoor. Unlike conventional rootkits, it requires no IOCTL interface, no user-mode agent, and no injected DLL. The entire attack surface is a single .sys file that registers a Windows Filtering Platform (WFP) stream callout to intercept inbound TCP traffic. Commands arrive encrypted over the network, are authenticated with HMAC-SHA256, and executed entirely within the kernel. The driver was first submitted to VirusTotal on 2026-06-15 03:55:33 UTC from China. Its Authenticode certificate carries the subject 深圳市奥联信息安全技术有限公司 (Shenzhen Aolian Information Security Technology Co., Ltd.) — allowing the driver to load on systems that trust Microsoft’s driver-signing ecosystem.

This report documents the driver’s architecture, network protocol, command handlers, cryptographic design, and detection opportunities derived from reverse engineering and behavioral analysis.

Field	Value
Subject (CN)	深圳市奥联信息安全技术有限公司
SpcSpOpusInfo	深圳市奥联信息安全技术有限公司
Signing timestamp	2026-04-17 14:39:00 UTC
First VT submission	2026-06-15 03:55:33 UTC (origin: China)
Driver compile timestamp	Sat Apr 4 06:05:19 2026 (0x69D10C8F)
SHA-256	495c7e5513fa7766c236e76d8520139139fc4ad7203ddcb2ccdae17bdb691979

Most kernel backdoors rely on a user-mode agent to communicate with a C2 server and relay commands via IOCTL calls to the kernel driver. wskmon.sys eliminates this detection opportunity entirely:

• No IOCTL interface — commands arrive directly over the network via WFP stream inspection
• No user-mode agent — the driver operates completely autonomously after loading
• In-memory command execution — the only artifact on disk is the driver itself; commands are never written to disk before execution
• WHQL-grade signature — passes driver integrity checks on all Windows versions including those with Secure Boot

Technical Analysis

On load, the driver registers a stream-level WFP callout via FwpsCalloutRegister1 that inspects all inbound TCP traffic. The classify routine triggers on two patterns:

• Raw TCP: stream begins with magic bytes 7F 4E 54 46 (\7FNTF)
• HTTP POST: driver reads up to 0x400 bytes and scans the POST body for the magic sequence 7F 4E 54 46. This dual-mode detection allows operators to blend malicious commands into legitimate-looking HTTP traffic, evading network detection that inspects only headers or URIs.

Immediately following the magic value is a 1-byte command type field, which determines the requested operation. The protocol supports at least three command classes:

• 0x01 – Remote shell execution
• 0x02 – File write operation
• 0x03 – Shellcode execution

To authenticate commands, the protocol includes a 32-byte HMAC-SHA256 tag located at offset 0x05. The authentication value is computed over the concatenation of the command type and encrypted payload using a hardcoded 256-bit secret key embedded within the driver’s data section. This mechanism prevents unauthorized command injection and allows the malware to verify the integrity and authenticity of received packets.

At offset 0x25, a 4-byte big-endian length field specifies the size of the encrypted payload. The protocol enforces different maximum payload sizes depending on the command type, with shell execution commands limited to 0x1000 bytes and file or memory operations supporting substantially larger payloads.

The payload itself begins at offset 0x29 and contains command-specific data protected using a rotating XOR cipher.

The next figure presents a high-level architectural overview of the execution chain employed by the wskmon.sys kernel-mode backdoor, illustrating how specially crafted network traffic is intercepted, authenticated, decrypted, and ultimately used to execute attacker-controlled operations on a compromised host.

Depending on the Type set by the attacker:

Type 0x01 — Execute Shell Command

Type 0x01 takes a raw command string as payload and executes it as NT AUTHORITY\SYSTEM on the target machine. After XOR decryption, the WorkerRoutine calls RE_enumerate_target_processes to find a svchost.exe instance running as SYSTEM, attaches to it from kernel mode via KeStackAttachProcess, writes the command string into its address space, and spawns a remote thread via RtlCreateUserThread. The driver automatically prepends cmd.exe /c to the decrypted string, meaning the operator only needs to supply the command itself. Because execution happens inside a Session 0 svchost.exe, spawned processes have no visible window on the interactive desktop — a natural stealth property.

Type 0x02 — Write File

Type 0x02 allows the operator to write arbitrary content to any path on the filesystem, bypassing all ACLs from kernel mode. The decrypted payload is structured as a 2-byte big-endian path length, followed by the UTF-8 file path, followed by the raw file content. The driver converts the path to a Unicode string and calls ZwCreateFile with FILE_OVERWRITE_IF, meaning it will create the file if it does not exist or silently overwrite it if it does — including paths in protected system directories that would be inaccessible to even an Administrator from user mode.

One unusual aspect of wskmon.sys is that it does not require a dedicated listening service. Because the driver intercepts inbound traffic at the WFP layer, any TCP service can potentially act as a carrier for backdoor commands.

Demonstration

To demonstrate the attack, the victim machine is running Python’s built-in HTTP server on port 8000. The listening application itself is unaware of the backdoor protocol and merely serves as a transport channel. From the attacker’s Linux machine, a single HTTP POST request is crafted with the NTF payload embedded in the body and sent to port 8000. Python’s HTTP server receives the connection, and its response is irrelevant — the WFP callout has already intercepted the TCP stream at the kernel level, extracted the magic bytes, verified the HMAC, decrypted the command, and queued execution before the HTTP server even finishes parsing the request line.

For this demonstration, the command sent was notepad.exe. The process spawned successfully and is visible in process hacker — but notably, its parent process is svchost.exe, not the user’s shell or any interactive application, which is an immediate anomaly indicator for a forensic analyst. The notepad window itself never appears on the desktop, this is a direct consequence of Windows Session 0 isolation.

The following screenshot demonstrates the full exchange — the HTTP POST sent from the attacker on the left, the process tree on the target showing notepad.exe parented to svchost.exe on the right:

Please find the full python code: client_http.py

Overall, wskmon.sys represents a sophisticated example of a modern kernel backdoor, combining stealth, persistence, and full-system compromise capabilities into a single signed driver. Its architecture highlights the security implications of kernel trust abuse and underscores the need for stronger driver vetting, continuous kernel telemetry, and behavioral detection mechanisms capable of identifying malicious activity below the user-mode boundary.

Detection Opportunities

• Unexpected WFP stream callout registration (e.g., via FwpsCalloutRegister* / FwpmCalloutAdd*).
• Suspicious WHQL-signed driver loading
  • Newly observed or low-prevalence signed drivers loaded into the kernel.
  • Driver loads shortly followed by network interception or process injection activity.
• Network traffic containing NTF protocol markers
  • Detection of the magic sequence 7F 4E 54 46 (\x7FNTF) within raw TCP streams or HTTP POST bodies.
  • Inbound traffic exhibiting the protocol structure (magic, command type, HMAC field, length field).
• svchost.exe spawning unusual child processes
  • svchost.exe launching utilities such as cmd.exe, powershell.exe, rundll32.exe, mshta.exe, or custom binaries.
  • Child processes running in Session 0 with atypical command lines.
• RWX memory allocations in SYSTEM processes
  • Memory regions allocated with PAGE_EXECUTE_READWRITE.
  • Newly allocated executable memory followed by thread start addresses residing in that region.
• Shellcode execution from non-image-backed memory
  • Threads whose start addresses do not map to a loaded module.
  • Execution from anonymous or dynamically allocated memory.
• Arbitrary file creation or overwrite from kernel context
  • File writes to protected paths (e.g., System32, drivers directories, startup locations).
  • Overwrites of existing system files without corresponding user-mode activity.
• Indicators of compromise (IOCs)
  • Presence of wskmon.sys.
  • SHA-256: 495c7e5513fa7766c236e76d8520139139fc4ad7203ddcb2ccdae17bdb691979.
  • Certificate subject: 深圳市奥联信息安全技术有限公司.

Conclusion

Unlike many kernel implants that merely provide stealth or privilege escalation, wskmon.sys embeds an entire remote-access framework directly into a signed driver. The combination of network communication, command execution, file operations, and shellcode loading inside kernel space removes many of the user-mode artifacts defenders traditionally rely on.