Quiz: Infrastructure Forensics

← Back to quiz index

3 questions

L1 (2 questions)

1. As a first responder to a suspected security incident, what should you do and what should you absolutely NOT do?

Show answer

DO: detect and confirm the anomaly, preserve volatile evidence (RAM, connections, processes), document what you see, contain the damage (isolate, do not destroy), notify the security/IR team, and maintain chain of custody. DO NOT: reboot the system (destroys volatile data), kill suspicious processes (destroys evidence), delete suspicious files, run unknown cleanup scripts, log in with shared credentials, or discuss the incident on public channels.

2. How do you verify whether system binaries have been tampered with on a Linux system?

Show answer

On RHEL/CentOS: rpm -Va | grep '^..5' lists files with changed MD5 checksums. On Debian/Ubuntu: debsums -c lists changed conffiles. For specific critical binaries (ssh, sshd, sudo, ps, ls), check with file (should be ELF binary, not script), sha256sum (compare against known-good hashes), and stat (check modification time). Also search for unexpected SUID binaries with find / -type f -perm -4000, as new SUID files are highly suspicious.

L2 (1 questions)

1. What is the evidence preservation priority order when responding to a compromised system, and why?

Show answer

Priority 1: Volatile data (lost on reboot) — running processes, network connections, open files, memory info, routing table, ARP cache, loaded kernel modules. Priority 2: Semi-volatile data (may rotate) — log files, temp files, user command histories. Priority 3: Non-volatile data (persistent) — filesystem timeline, disk image, configuration files. Capture in this order because volatile evidence disappears first and is often the most revealing.