Hunting rootkits in memory
You catch code hiding at kernel level through inconsistencies in the SSDT, IDT, callbacks and module lists, and detect Linux loadable-kernel-module rootkits from a memory dump.
Level 501 · 12 lessons · 12 practice labs
Lessons
The kernel and hiding
- The kernel for analysts: user space, kernel space, system calls
- How rootkits hide: hooks, list manipulation, filters
- Cross-view: comparing two different lists
- Short task: compare the module list with a scan to find the hidden module
The Windows kernel
- System call hooks with windows.ssdt
- windows.callbacks and drivers: driverscan, modscan
- Driver IRP hooks and suspicious unsigned drivers
- Short task: find the hooking driver and recover its file from disk
The Linux kernel
- Linux LKM rootkits: the module lsmod does not show
- Hooks with linux.check_syscall and linux.check_idt
- Spotting eBPF abuse in memory
- Capstone: prove a rootkit hiding in a server’s memory and plan its removal
Practice labs
- Compare two process views: Compare the list and scan outputs and find the entry seen in only one.
- Find the hidden module: Identify the hidden module by comparing the module list with the module scan.
- Classify the hiding method: Classify with evidence whether hiding in three prepared dumps is done by hooking, list manipulation or filtering.
- Audit the system call table: List the entries pointing to a non-kernel module in windows.ssdt output.
- Inspect callbacks and drivers: Find the callbacks registered by an unrecognised driver with callbacks, driverscan and modscan.
- Find the hooking driver and match it on disk: Identify the unsigned driver setting hooks, dump it from memory and compare its hash with the file on disk.
- Look for the module lsmod does not show: Compare the module list with the hidden module check in a Linux dump.
- Check syscall and IDT hooks: Find the altered entries and the address they point to with linux.check_syscall and linux.check_idt.
- Inspect the eBPF programs loaded in memory: List the eBPF programs loaded in the dump and justify the suspicious one that differs from expected monitoring programs.
- Confirm a finding against a clean reference: Compare the suspicious kernel entry with a clean dump of the same version.
- Prepare the evidence package: Package the hidden module finding with plugin outputs, the dumped region and hashes.
- Prove it and produce a clean-up plan: Prove the hidden component in Selvikent Belediyesi's prepared server dump and write a plan covering rebuild and credential rotation.
About this course
You catch code hiding at kernel level through inconsistencies in the SSDT, IDT, callbacks and module lists, and detect Linux loadable-kernel-module rootkits from a memory dump.
What you will learn
- The kernel and hiding
- The Windows kernel
- The Linux kernel
Prerequisites
You should be experienced in the topics of the same path up to level 401.
Lab environment
Lessons run in your own Kali Linux terminal that opens in the browser. Nothing to install; the lab starts clean in every lesson.
Frequently asked questions
- Is this course right for my level?
- The course is at level 501; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.