HackTheBox Sherlock DFIR Medium Scenario "Midnight"
A production server crashed unexpectedly and rebooted. The crash happened at a strange time, and we doubt it was a simple hardware fault. A kernel crash dump was captured. Your mission is to analyze it to find the real cause of the crash and determine if any other suspicious activity was present on the system.
Midnight Crash is a medium-difficulty Hack The Box Sherlock focused on Linux kernel crash-dump analysis. A production Ubuntu server rebooted after an unexpected kernel failure, and the available evidence consists of a kdump image together with the matching uncompressed kernel image containing debug symbols:
The investigation is performed with the Linux crash utility. The debug-symbol image must match the exact kernel version that produced the dump; otherwise, structure offsets and symbol names may be interpreted incorrectly. Load the symbols first and the memory dump second:
cd MidnightCrash
crash vmlinux-dbgsym ubuntu22.04-5.15.0-25-generic-202511032103.kdump
Short Recap
This Sherlock is a Linux kernel memory-forensics investigation rather than a conventional disk-forensics exercise. The dump preserves system metadata, active tasks, loaded kernel modules, open files, network configuration, kernel messages, and many internal structures as they existed when the system failed.
The central tool is crash, loaded with the exact debug-symbol image for the captured kernel. The most useful commands are sys, net, log, files, mod, sym, struct, ps, and task. The investigation requires several complementary techniques: interpreting panic output, normalizing time zones, correlating the active task with its file descriptors, resolving an instruction pointer to a module symbol, distinguishing a module's metadata address from its code base, tracing child processes, and checking kernel credential objects.
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 the Linux crash utility with the matching vmlinux debug-symbol image. Useful techniques include reading the system and network summaries, reviewing the kernel ring buffer, inspecting a process's open file descriptors, resolving module symbols, examining module callbacks, traversing parent-child process relationships, and validating Linux credential structures. The objective is to reconstruct the panic path and identify related suspicious activity from volatile memory without relying on the live system.