The Module That Isn't There: Cross-View Rootkit Detection

A capable LKM rootkit hides by unlinking itself from the kernel's module list, so it vanishes from lsmod and /proc/modules. But loading it still created a /sys/module/<name>/ entry and tainted the kernel — traces it doesn't scrub. The forensic technique is a CROSS-VIEW: reconcile the module list from two kernel sources and flag what one shows that the other hides.

A host's kernel state was captured to /root/case/: proc_modules.txt (the lsmod view of loaded modules), sys_module.txt (the entries under /sys/module/), modules.builtin (names of modules compiled into the kernel), and dmesg.txt. A module present in /sys/module but absent from /proc/modules is suspect.

The trap: BUILT-IN modules — compiled into the kernel, not loaded as .ko files — also appear in /sys/module and never in /proc/modules. That's normal. A naive 'in /sys but not in /proc' rule flags every builtin (a flood of false positives). The real test is: in /sys/module, NOT loaded, AND NOT built-in. Exactly one module fits — the rootkit.

1. Identify the hidden module's name and record it in /root/case/hidden_module.txt.

2. Write a detector at /root/detect.sh that works from the captured files in `/root/case/` (not this box's live /sys/module, which doesn't hold the rootkit) and prints the modules present in sys_module.txt but neither loaded nor built-in, one bare module name per line. Grading runs bash /root/detect.sh, and also re-runs it against a second, unseen host's capture as bash /root/detect.sh <casedir> — so read the files from the directory given as the first argument, defaulting to /root/case (${1:-/root/case}/sys_module.txt etc.), not from a hardcoded path or module name. MITRE ATT&CK: T1014, T1562.001.