Hackthebox Phantom Sherlock

HackTheBox Sherlock DFIR Scenario "Phantom"


Sherlock Scenario: A Linux server memory image contains evidence of a kernel-level compromise. The goal is to identify the hidden rootkit module, determine when and by which process it was loaded, recover its C2 infrastructure, enumerate the compromised shells, and reconstruct the kernel hooks and privilege-escalation mechanism directly from memory.

Start

Phantom is a Linux memory-forensics Sherlock centered on a hidden kernel rootkit. The supplied archive contains a LiME memory acquisition and the matching Ubuntu kernel symbol/type JSON. Those two artifacts are enough to investigate the system without loading or executing the rootkit.

Evidence extraction and inventory

Extract the password-protected archive: code:bash:unzip -P hacktheblue Phantom.zip
or with 7-Zip:
7z x -phacktheblue Phantom.zip
Inventory it:
find phantom -maxdepth 1 -type f -printf '%f\t%s bytes\n'
The archive contains:
Ubuntu_6.8.0-87-generic.json   64251191 bytes
dump_srv.mem                  6977671262 bytes
The JSON file is extremely useful: it is an ISF-style Linux symbol/type description containing symbol addresses and structure layouts for the exact kernel represented by the memory image. For evidence handling, hash the files before doing anything else:
sha256sum Phantom.zip phantom/dump_srv.mem phantom/Ubuntu_6.8.0-87-generic.json | tee hashes.sha256

Memory acquisition format

Examine the first 32 bytes:
od -Ax -tx1z -N 64 phantom/dump_srv.mem

45 4d 69 4c 01 00 00 00 ...
E  M  i  L
EMiL is the little-endian byte representation of the LiME magic value. A LiME file consists of one or more records with a 32-byte header followed by the physical-memory bytes for that range. The header can be interpreted as:
struct lime_header {
uint32_t magic;
uint32_t version;
uint64_t start;
uint64_t end;
uint64_t reserved;
};
The first ranges in this image are:
0x0000000000001000 - 0x000000000009dfff
0x0000000000100000 - 0x00000000bfecfffe
0x0000000100000000 - 0x00000001dffffffe
This matters because a byte offset in the LiME file is not automatically the same thing as a physical address. The LiME headers and any holes between physical ranges must be accounted for.

This is a preview of an article or content section that is not ready to be disclosed. It starts with limited visibility...

For this lab, use Volatility 3 for fast triage and direct LiME/kernel-structure parsing for validation. The direct parsing path is especially useful for the hidden module, printk caller metadata, tracepoint registration, ftrace hook enumeration, socket ownership, and the centralized callback address. Keep the analysis static; there is no need to execute recovered kernel code.