SSDT Hooking: A Personal Walkthrough of Kernel-Mode Intrigue (Uroboros Echoes)

 

 

SSDT Hooking: A Personal Walkthrough of Kernel-Mode Intrigue (Uroboros Echoes)

 

 

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

 

By Seeker(李标明) China

Independent Malware Analyst & Researcher

Download the Full Report (PDF)

---

Prologue: The Temple and the Kernel

Recently, I still climbed a mountain and visited the temple again and again, as you know from my last report, the IDT hooking report mentioned. Here I didn’t give up but kept moving to SSDT hooking; everything is very subtle and slow.

 

After discovering the IDT hooking, I got a bad cold, and I moved more slowly on my own kernel research. I couldn’t even think, and I also did not buy medicine but tried to drink a lot of water. And some stuff about driver knowledge I also need to learn. Sometimes I remembered I strongly felt the energy conversion from one place to another in my body. I felt good when I woke up, which was the only time I really felt those things deeply. I am also honestly saying: in the temple, I felt my finger and heart beating music-like, the feeling stronger than before, and now I like to do internal observation.

---

Sample choice: Uroboros

Yeah, it’s still the nation-state group APT called Turla.

 

Sample md5: ed785bbd156b61553aaf78b6f71fb37b                          

---

 

SSDT Hooking: the key and flow

KiSystemServiceStart is a critical internal function in the Windows kernel that acts as the entry point for system calls (syscalls) made from user mode to kernel mode. Due to the user-mode-to-kernel-mode flow, it happened before KeServiceDescriptorTable, so I tried to look for what happened inside.

 

As you see, this instruction loads the address of KeServiceDescriptorTable into register r10. The table KeServiceDescriptorTable holds the service descriptor table (SDT) for system calls.

Fig.1 snippet nt!KiSystemServiceStart

 

Following the base address to explore the structure of KeServiceDescriptorTable, which includes the ServiceTableBase (fffff800`02aad400) and Number of Services (hex 191 = 401 services).
Note: Debug on Windows 7 x64.

Fig.2 the structure of KeServiceDescriptorTable

 

 

Using the “dps fffff800`02aad400 L191” to dump memory as pointers and symbols, do it with the base address of the KiServiceTable (the SSDT) and L191 (decimal 401 entries). The highlighted values do not point to valid kernel code addresses (i.e., not within the ntoskrnl.exe or other legitimate kernel module address ranges like fffff800... or fffff880... etc.). And there are VA Type: NonAddressable and Memory Access Error.

Fig.3 invalid kernel code addresses

 

Conclusion: It is a malicious driver that has overwritten some SSDT entries and redirected these syscalls for control/monitoring. Based on the memory entries, this strongly implies that some SSDT entries have been hooked or tampered with.

 

 

In this analysis, I identified overwritten entries in the System Service Descriptor Table (SSDT), clearly demonstrating active SSDT hooking behavior by a kernel-mode component. While I did not pursue full tracing of the hook destination in this report, this confirms the presence of traditional kernel-level persistence — a technique historically used by advanced APTs such as Turla. This work follows my prior research into IDT hooking and continues my exploration of legacy rootkit techniques that remain relevant in modern threat landscapes.

 

Epilogue: What the Kernel Taught Me

There’s no other best solution but to understand what it is.

“Do or do not, there is no try.”
— Master Yoda

End of Report