A newly detailed injection technique has put Windows systems in the spotlight, revealing how attackers could abuse a deeply embedded part of the operating system to run malicious code inside another process without raising alarms.
The method exploits the Windows graphical subsystem, specifically win32k.sys, using a legitimate kernel-to-user callback path that Windows itself relies on for normal operations.
What makes this particularly concerning is that the technique stays inside expected system behavior, making it far harder for security tools to detect.
At the heart of the attack is a structure called the KernelCallbackTable, a table of function pointers stored in every GUI-enabled Windows process.
This table helps the OS hand off graphical tasks from the kernel to user-mode routines. Attackers who understand how it works can locate it through a process’s memory and identify which callbacks are active.
The goal is to find an execution path without visibly tampering with the table itself. Security researcher n0qword identified this technique and documented its full implementation, publishing the findings along with a working proof of concept on GitHub.
The research highlights how the attack avoids the most detectable form of this exploitation class, which typically involves directly overwriting entries in the callback table.
By taking a more indirect route, it sidesteps integrity checks that would flag structural changes, giving it a clear stealth advantage over older injection methods. The approach avoids leaving the obvious footprints that traditional process injection creates.
Rather than spawning a new remote thread or pushing code through Windows asynchronous procedure calls, this method quietly redirects an existing and expected callback function at the moment the system invokes it.
The result is a cleaner execution path that blends into normal Windows activity without standing out in process-level monitoring.
While shared strictly for educational and defensive research purposes, its underlying mechanics represent a genuine risk if adopted by malicious actors.
Security teams need to understand how callback-based methods work to have any real chance of detecting or blocking them.
As n0qword said in a report shared with Cyber Security News (CSN), the technique “can provide a stealthier alternative to more conventional primitives such as remote thread creation or APC-based injection.”
Hackers Could Abuse WM_COPYDATA Callback Path
The specific callback entry at the center of this technique is __fnCOPYDATA, which is tied to the WM_COPYDATA Windows message type.
This entry is especially attractive to an attacker because it can be triggered externally and predictably by sending a WM_COPYDATA message to a target window using the standard SendMessage function.
That reliability makes it a strong execution primitive requiring no complex setup and no unusual process conditions.
The attack begins by reading the target process’s memory to locate its KernelCallbackTable and resolve the address of the __fnCOPYDATA routine.
Shellcode is written into the remote process using allocated executable memory, and a small inline hook is placed at the beginning of that function.
This hook redirects execution to the attacker’s shellcode the moment the callback fires. Once execution completes, the original bytes are restored to keep the process stable and minimize residual signs of tampering.
Evasion Design and What Defenders Should Watch For
One of the most notable aspects of this technique is how deliberately it avoids detection. Traditional KernelCallbackTable injection overwrites table entries directly, which security products can catch by validating the PEB or running integrity checks.
This newer approach leaves the table completely untouched and hooks the function the table points to, so the table looks fully normal from the outside. That design choice makes it much harder for automated tools to flag anything suspicious.
For defenders, monitoring the callback table alone is no longer sufficient. Security solutions must also watch for unexpected inline modifications to functions the KernelCallbackTable references, particularly user32.dll routines tied to message types like WM_COPYDATA.
The research recommends restricting any testing of such techniques to controlled lab environments under proper authorization.
Defenders should also watch for unusual WM_COPYDATA message traffic between unrelated processes, which could indicate an attempt to trigger a hijacked callback in a real attack.
