In this simulation, you will learn how to capture and analyze volatile system data. Understanding how to correlate active processes with their associated open files and network sockets is critical during live system forensics.
CHFI (312-49) Digital Forensics Simulation
Investigation Scenario
A CentOS 8 database server at a healthcare organization is suspected of active data exfiltration. Because pulling the power plug to create a dead-box image would destroy volatile RAM artifacts, the digital forensics team initiates a "live response" data collection following the Order of Volatility protocols.
The investigator executes a trusted, statically-compiled binary from a USB drive to document current system states. They need to identify which specific malicious process is maintaining an unauthorized outward-bound network socket while simultaneously reading sensitive database files from the disk.
Evidence Collected
System State: Live Volatile Data Collection Tool Source: Sanitized Forensic USB Drive (/mnt/usb_forensics/) Artifact Type: Process to File Descriptor Mapping
The investigator pipes the standard output of their command into an evidence text file on their USB drive. A review of the volatile data output reveals the following suspicious entries:
Which Linux command allows an investigator to view a list of all open files and the processes that opened them?
Forensic Hint: Think "LiSt Open Files." In UNIX-based systems, almost everything (including network sockets) is considered a file. You need the tool that maps a Process ID (PID) to its file descriptors (FD).
Expert Analysis
What the evidence shows: The collected volatile data snippet clearly identifies a nc (netcat) process running as root with PID 3499. This single process holds two critical file descriptors open: a network socket transmitting to an external IP, and read access to the sensitive patient_records.csv file.
Forensic Stage: Collection (Volatile Data / Live Response).
Why the correct answer is correct: The lsof (List Open Files) command directly queries the kernel's virtual file system. It is uniquely capable of mapping running processes (PIDs) to their active file handles, network sockets, and pipes, proving exactly what a suspicious program is interacting with in real-time.
Why others are wrong:
ls -la: Lists directory contents and permissions stored statically on disk. It provides zero visibility into active processes or memory mappings.
top: Provides a dynamic, real-time view of system resource utilization (CPU/Memory) by processes, but does not enumerate the file descriptors they are holding.
ps aux: Displays a static snapshot of currently running processes and their arguments, but lacks the ability to map those processes to the specific files or sockets they have opened.
Real-world forensic action: Following the discovery, the investigator would immediately initiate a physical memory (RAM) dump using a tool like LiME or AVML to capture the netcat payload and any unencrypted data in memory, prior to isolating the machine from the network.
MINI LESSON: Order of Volatility (RFC 3227)
During a digital forensic investigation, evidence must be collected starting with the most volatile data (data that will be lost first). If an investigator had immediately powered down this server to take a physical disk image, the active network connections and the process-to-file mapping (PID 3499 accessing the CSV) would have been permanently destroyed. Always capture routing tables, ARP cache, process statistics, and open files/sockets during the live response phase before moving to persistent storage.