SakDriver: Kernel Driver Rootkit Research Notes - Technical Analysis and Design Insights into Registry Callback-Based Stealth Communication in Kernel-Mode Rootkits

 

SakDriver: Kernel Driver Rootkit Research Notes

Technical Analysis and Design Insights into Registry Callback-Based Stealth Communication in Kernel-Mode Rootkits

 

 

“To understand the immeasurable, the mind must be extraordinarily quiet, still.”
— Jiddu Krishnamurti

 

 

Seeker(李标明) · @clibm079   

China · Independent Malware Analyst & Researcher 

From 2026.08.21 to 2026.08.27

---

Prologue: Curiosity-driven, keep moving and transcending the past

I came across a new rootkit malware called SakDriver during that quiet exploration stage, which gained extremely high attention when it was shared on the X platform. After finishing the last article about “Windows Internals: Research Notes from the 6th to 7th Edition” on Aug 10, 2026, I started to analyze this kernel driver. It’s very cool and a valuable malware to research.

 

It took me about one week to read the malware analysis: “SakDriver: Reversing a Kernel Driver Rootkit” by 0xSec. Thanks for sharing. At the same time, I did static analysis about the detail. For one week of studying and preparing, I started to debug and expand my personal research and make a record for the whole process.

 

Here, I’m just focusing on the registry callback of the CmRegisterCallbackEx, because when I tried to study the rootkit, I found the state is running but didn’t work, with the curiosity, so here it is, and it is very limited observation and my personal perspective. If you would like to learn more details, please read 0xSec’s malware analysis. Thank you.

 

SakDriver 1.0

MD5: b5f122f3f07f618c0a7678fa40801faa
SHA1: 7440358c5041eba34e8673100989df756a6426da

SHA-256: 4e95aba17c1a423cda5cc9f9f04f7cf8db17e294eb31ed1aa85063601b82fe8d

 

Time date stamp: 2026-03-20 01:14:01

Mode: 64-bit

Type: Driver

 

 

Technical Analysis

 

Rootkit Activation: Required Conditions

Let’s move simply at the beginning. First, to use the tool WinDbg to connect the VM. Using the commands “sc create” and “sc start” to install and start it in VM, and it would trigger the WinDbg as follows:

Figure 1.1: to create and start the kernel driver SakDdriver with commands.

 

 

On the host, WinDbg would pause at a certain nt!debugservice, using the “lm” to list modules and get the base address of sak_00A, and then to rebase the program in IDA, and set a breakpoint with the address of the function that we need to inspect with WinDbg, and execute the command “g” as follows:

Figure 1.2: to set a breakpoint for a function.

 

 

It will hit the breakpoint and jump into the callback function.

Figure 1.3: Hitting the breakpoint.

 

 

Inside the callback function, finally it will exit the function when the condition compares to the number 2; the right path should first jump to the address “fffff803`16e5a260”.

Figure 1.4: exit the callback Function without the condition being satisfied.

 

 

Based on this function, the rootkit's interesting functionality appears to require several conditions to be satisfied. Let's observe the conditions from the callback to run and the conditions for the command-dispatch functionality to execute.

 

 

The callback itself

CmRegisterCallbackEx causes the callback to receive registry notifications. So ordinary registry activity can reach this function. But that doesn't automatically activate the rootkit's capabilities without the private trigger mechanism. The following analysis supports this kind of hypothesis.

Figure 2: CmRegisterCallbackEx and callback function.

 

 

More detail from remarks: To be notified of registry operations, a kernel-mode component (such as the driver component of an antivirus software package) can call CmRegisterCallback or CmRegisterCallbackEx to register a RegistryCallback routine.

 

But here a malicious author used it to expand their kernel capability.

 

 

The magic number condition

Review the code; the kernel driver also checks specific Argument2 that is not simple a data structure.

 

First, Argument2 + 0x14 contains a DWORD that must equal 3, and Argument2 + 0x20 contains a DWORD that must equal 32.

 

Second, the special Argument2[3] points to a second-level structure, Argument2 is essentially a nested request structure. The hexdecimal magic number must equal 0x2625B7146B.The magic number functionality is more like an authentication. Who creates Argument2 ?.

Figure 3.1: Argument2 is a nested request structure.

 

 

I compiled a C++ program to write serveral parameters to the registry, and to debug but failed again.

It seems that I probably do not trigger the authentication path simply by writing an arbitrary registry key/value. In addition, it doesn’t support interacting from user mode to rootkit.

 

In my view, based on the current analysis, there’s no self-trigger mechanism found that is embedded in the rootkit, It is possible that a solo trigger mechanism that separates from a capability mechanism, remains unidentified, and it would be like this: the Windows Kernel triggers the callback with Argument1 (Registry Operation Code) and the Argument2 that can be triggered by passing a specific custom structure.

 

More detail about [in, optional] Argument2: A pointer to a structure that contains information that is specific to the type of registry operation. The structure type depends on the REG_NOTIFY_CLASS-typed value for Argument1.

Figure 3.2: the parameters Argument1 and argument2.

 

 

The RegistryCallback funtion and the calling convention, and on x64 Windows, as follows:

Figure 3.3: the calling convertion and on x64 Windows.

 

 

When hitting the breakpoint at the callback function, dumping the Argument2 structure, the rdx = 0x0E (14) means this is RegNtPreQueryKeyInformation — a registry query operation, not RegOpenKeyEx (which would be 1).

Figure 3.4: the parameters Argument1 value and argument2 structures.

 

 

To decod the above structure (64-bit), the kernel is passing its own structure, not the rootkit's custom structure. Like the above process of debugging mentioned and finally exiting the callback function. It is possible proving that a custom trigger mechanism can build the custom structure with Argument2[3] pointing to the magic number 0x2625B7146B.

Figure 3.5: the kernel passing its own structure without triggering.

 

 

The command ID condition

After passing a specific structure containing the magic number 0x2625B7146B validation, the code examines the command ID and determines what functionality is requested and then executes the real payload.

Figure 4: the command ID and dispatches.

 

 

The registry-service path condition

The callback validates the queried key-name and value-name by checking query success, pointers/buffers, and nonzero lengths. This performs defensive validation before the actual comparisons. The rootkit does a separate check for registry values such as:

Type

Start

ImagePath

ErrorControl

DisplayName

Group

DependOnService

FailureActions

It must match one of eight service-configuration values; if not, it will exit the callback function.

Figure 5: defensive validation and actual comparision.

 

 

Current Observation

From the above technical analysis and observation, SakDriver is a kernel driver as a persistence component; it appears to employ conditional activation of its kernel capabilities. Merely invoking the registry callback seems insufficient; the special command path requires a specific request layout, a magic value, and a recognized command identifier, but about the trigger mechanism, until now, the actual trigger of the custom request structure remains unidentified. There’s no self-trigger mechanism found that is embedded in the rootkit; it is possible that it has its own rootkit client that works at the same level as Ring0 and separates from the real payload or capability mechanism.

 

It should be noticed that the true trigger mechanism—the rootkit client driver—is a separate component that is often deleted after use to avoid forensic discovery.

Figure 6: the callback function mental model.

 

 

To be honest, I didn't actually know this yet. This was my hypothesis based on the above limited observations. One decompiled sample is usually not enough to reconstruct the complete map with confidence.

 

Thanks to @smica83, who shared the sample with the MalwareBazaar Database on 2026-06-05 16:38. Thanks to the reference sources from @xeroxsec, it would take me more time without the detail of the malware analysis report shared on 2026-07-26. Thanks to the great summary from @cr3ghost on X, which suggests a sample worthy of research at 9:00 PM on Jul 31, 2026.

 

For more technique details, please check them out.

Figure 7: summary about SakDriver by @cr3ghost.

 

 

 

References

[1]. https://0xsec.gitbook.io/0xsec/malware-analysis/sakdriver-reversing-a-kernel-driver-rootkit

Epilogue: What This Exploration Taught Me

1.      Sakdriver is a good example; it is an ongoing arms race. As EDR agents moved deeper into the Windows kernel to catch malicious activity, malware authors were forced to follow them into the lowest levels of the operating system, and malware analysts would be forced too.

2.      Let every kind of encounter in life make you learn, progress, understand yourself, and transcend the past.

Annotation: In all the sentences I wrote and used the word “you or your or yourself” in, it talked to me or “the malware sample itself, especially in my poem I did”, not the reader. I must clarify my motivation.

End of Report

──────────────────────

Seeker(李标明) · @clibm079    

China · Independent Malware Analyst & Researcher