Volatility Plugins — Plugin windows.ssdt Let’s Talk About it

Now we’re stepping into kernel territory.

And once malware gets here, things get serious.

One of the biggest wins for kernel malware is SSDT hooking.

If you understand this, you understand how rootkits control the entire system.

What Is the SSDT

The System Service Descriptor Table (SSDT) is basically a lookup table used by the Windows kernel.

When a process asks Windows to do something like:

• open a file

• read registry data

• enumerate processes

• allocate memory

…the kernel looks up the corresponding system function in the SSDT and jumps to the code.

Each SSDT entry is just a pointer to kernel code.

How SSDT Hooking Works

An SSDT hook does something very simple — and very dangerous:

• It replaces one or more SSDT pointers

• Redirects them to malicious code

• That code runs before or instead of the legitimate kernel function

• 
  

And because this lives in the kernel:

• it affects every process

• it’s system-wide

• no user-mode security tool is safe

  
  

That’s why attackers love it.

Why Attackers Don’t Use It Everywhere

SSDT hooking comes with a big risk.

On 64-bit Windows, PatchGuard (Kernel Patch Protection) watches critical structures like:

• SSDT

• IDT

• GDT

• kernel code regions

If PatchGuard detects tampering, it doesn’t log an alert.

It blue-screens the system on purpose.

So yes — SSDT hooks still exist, but they’re much rarer today.

That said… attackers always find ways around protections. So we can’t ignore SSDT analysis.

Finding SSDT Hooks with Volatility

Volatility 3 gives us a plugin called:

windows.ssdt

Important thing to know:

This plugin does not only show suspicious entries. It dumps everything.

And that’s a lot.

Modern Windows systems can have 1,500+ SSDT entries.

So filtering is mandatory.

What the ssdt Plugin Shows

For each SSDT entry, Volatility gives:

• Table Entry (Index)

• Function Offset (Address)

• Function Name (Module)

• Function Owner (Symbol)(which kernel module owns it)

And this Second last column is the key.

The Simple Rule That Catches Rootkits

On a clean Windows system:

SSDT entries should point to only two modules:

• ntoskrnl.exe

• win32k.sys

That’s it.

So our job becomes very easy:

Show me SSDT entries that point anywhere else.

Anything outside those two is immediately suspicious.

Filtering the Noise (The Practical Way)

We pipe the output and remove known-good entries:

python3 vol.py -f /mnt/c/Users/Akash/Downloads/laptop.raw windows.ssdt | egrep -v '(ntoskrnl.exe|win32k.sys)'

Now instead of thousands of lines…you get only the interesting stuff.

Small note: Some systems use:

• ntkrnlpa.exe

• ntkrnlmp.exe

So adjust your filter if you ever hit that edge case.

Logical Step: Dump the Driver

Finding the hook is just step one.

Next step: extract the malicious driver from memory

Volatility gives us:

• moddump (Volatility 2)

• modules (Volatility 3)

Once dumped:

• reverse engineer it

• extract IOCs

• identify capabilities

• confirm attribution

-------------------------------------------------------------------------------------------------------------

Final Takeaway

SSDT hooking is:

• powerful

• dangerous

• rare (but real)

PatchGuard made it harder — not impossible.

And when attackers do use it, memory forensics exposes them very clearly.

If a kernel function suddenly belongs to a random driver…that driver has some explaining to do.

-------------------------------------------------Dean-----------------------------------------------------