root@thehacksparrow:~/writeups$ SYSTEM ONLINE
· log in sign up
← back to TryHackMe writeups
root@sparrow:~/writeups$ cat sneaky-patch.md
// Offensive

Sneaky Patch

24 Jul 2023 · 9 min read
OffensivewriteupstryhackmeEasylinux
Executive summary — Sneaky Patch is an Easy kernel-forensics room on TryHackMe: we start from a Linux system already compromised by a kernel-level rootkit shipped as a loadable module (LKM). Unlike a userspace backdoor, this module lives inside the kernel and evades conventional detection tooling. The journey is pure analysis: we enumerate loaded modules, single out the suspicious spatch, inspect its metadata with modinfo, pull strings from the .ko binary and decode the hex-encoded flag. A lsmod → modinfo → strings → hex decode journey.
PlatformTryHackMe
Operating systemLinux
DifficultyEasy
RoomSneaky Patch
Target IPMACHINE_IP

Attack map

[ACCESS]  session on the compromised host
   |  sudo su -> root for system-level analysis
   v
[dmesg]  kernel logs -> module loading events
   |
   v
[lsmod]  suspicious module: spatch (not in standard docs)
   |  modinfo spatch -> author "Cipher", "Cipher is always root"
   v
[strings]  spatch.ko -> [CIPHER BACKDOOR] secret in hex
   |  xxd -r -p
   v
[FLAG]  THM{sup3r_sn34ky_d00r}
   .  (alt) echo get_flag > /proc/cipher_bd -> dmesg

1. Context: why a kernel rootkit is so dangerous

Before touching the keyboard it helps to understand the terrain. A classic userspace backdoor leaves visible traces: added SSH keys, bind/reverse shells, malicious cron jobs. A kernel rootkit plays in a different league: it is implemented as a Loadable Kernel Module (LKM) and runs in ring 0, with direct access to system structures. From there it can hide processes, files and connections from conventional tools, because it is the kernel itself that lies.

The key idea: when the attacker controls the kernel, you cannot trust the answers the system gives you. Forensics focuses on what the module cannot fully hide: its own presence in the module list, its metadata and the contents of its on-disk binary.

2. Elevate to root for the analysis

We start from a session on the already-compromised host. To inspect kernel modules and low-level logs we need root privileges:

sudo su

Why: lsmod, modinfo over paths under /lib/modules and detailed access to dmesg require root on most hardened systems. It is the first step to gain full visibility.

3. Review the kernel logs with dmesg

The kernel ring buffer records boot events and, crucially, module loading. It is the first place to look for anomalous activity:

dmesg

The output shows system initialization and module loading events. We look for unusual messages or modules loaded at unexpected times, which are often the first hint of a malicious LKM.

4. Enumerate loaded modules with lsmod

The most important step of the analysis: list every active kernel module and spot the one that does not belong.

lsmod

Among the legitimate modules we find spatch, a module that does not appear in standard Linux kernel documentation. An unknown name in the module list is exactly the kind of anomaly we are hunting for.

Analysis: lsmod reads /proc/modules. A rootkit may try to unlink itself from this list, but many proof-of-concept LKMs (like this one) do not, leaving themselves visible. Any module whose name you don't recognize deserves immediate investigation.

5. Inspect the module metadata with modinfo

With the suspicious module identified, we pull its metadata:

modinfo spatch

The output reveals very clear indicators of malicious intent:

description:     Cipher is always root
author:         Cipher
filename:       /lib/modules/6.8.0-1016-aws/kernel/drivers/misc/spatch.ko
Red flags: a description like «Cipher is always root», an anonymous author («Cipher») and the location of the .ko. The drivers/misc/ path is a plausible hiding spot for a module trying to pass as legitimate. All these fields are set by the module's author, so their tone gives away the purpose.

6. Analyze the module binary with strings

We now have the exact path of the .ko. We extract the readable text from the binary to look for embedded secrets:

strings /lib/modules/6.8.0-1016-aws/kernel/drivers/misc/spatch.ko

Scrolling through the output we find a message left by the attacker with hex-encoded data:

[CIPHER BACKDOOR] Here's the secret: 54484d7b73757033725f736e33346b795f643030727d0a
Why it works: strings walks the compiled binary and prints sequences of printable characters. Malware authors often leave debug strings, keys or —as here— the flag itself encoded in the binary. Analyzing the on-disk .ko bypasses the rootkit's runtime lies entirely.

7. Decode the flag from hex

The hex string contains the flag. We decode it with xxd in reverse mode:

echo "54484d7b73757033725f736e33346b795f643030727d0a" | xxd -r -p

Result:

THM{sup3r_sn34ky_d00r}

xxd -r -p reverses (-r) a plain hex dump (-p) back to its original bytes. The trailing 0a is the newline.

8. Alternative method: the backdoor's /proc interface

The rootkit creates a /proc interface to interact with it. We can trigger the backdoor directly and recover the flag from the kernel logs:

echo "get_flag" > /proc/cipher_bd
dmesg | tail -5

Writing the control command get_flag to /proc/cipher_bd makes the module dump the (hex-encoded) flag into the kernel ring buffer, where we read it with dmesg.

Analysis: a /proc entry with a strange name like cipher_bd that does not correspond to any legitimate process is itself a rootkit IOC. This control channel shows how the module takes orders from userspace without opening a network socket.

[Verified against independent public write-ups] get_flag is not the interface's only function. Several external analyses of this same room, cross-checked against each other for this review, agree that /proc/cipher_bd is actually a full command-execution channel: writing any other string to it — for instance echo "id" > /proc/cipher_bd — makes the module run it as a shell command with root privileges and save the output to /tmp/cipher_output.txt. Reading that file back confirms execution as uid=0(root). get_flag is simply a hardcoded special-case string the author left to dump the flag instead of running a command.

Why it matters: this reframes the room's real lesson. spatch isn't just a flag dispenser — it is a persistent, unauthenticated, kernel-level root shell reachable by anyone who can write to /proc/cipher_bd, with zero logging and no network footprint. That is what makes a kernel backdoor categorically worse than a userspace one.

Findings summary

PhaseComponentIndicator / TechniqueImpact
Enumerationlsmod / /proc/modulesUnknown spatch module, absent from standard docsDetection of the malicious LKM
Metadatamodinfo spatchAuthor «Cipher», description «Cipher is always root», .ko in drivers/misc/Confirmation of malicious intent
Binary analysisstrings on spatch.koHex secret embedded after [CIPHER BACKDOOR]Flag extraction from disk
Control channel/proc/cipher_bd/proc interface: arbitrary write = command execution as root; get_flag = flag dumpUnauthenticated remote command execution (RCE) from userspace, zero logging

Lessons learned

  • Kernel rootkits gain stealth but still leave traces: the module may hide processes and files, yet its presence in lsmod, its metadata and its on-disk binary remain analyzable.
  • Analyze the binary, not just the live system: strings and modinfo against the on-disk .ko bypass the rootkit's runtime lies.
  • Catalog your legitimate modules: knowing which LKMs should be loaded turns any unknown name (like spatch) into an immediate alert.
  • Watch /proc: anomalous procfs entries (cipher_bd) that map to no real process are a reliable IOC of kernel-level compromise.
  • A writable /proc interface isn't a curiosity, it's RCE: in this case, cipher_bd executes as root any string that isn't get_flag. Always treat a writable procfs entry from an unknown module as a full compromise channel, not just an IOC to note down.