1. You arrive at BASTION-NGE01. The attacker is currently logged in. You have SSH access and a USB drive with UAC. What is your first collection action?
Acquire memory with LiME — memory is the most volatile evidence and must be captured before any other commands modify the system state
Run UAC with the full profile to capture everything at once
Copy /var/log/auth.log to your workstation before the attacker deletes it
Disconnect the server from the network to stop the attacker
Correct. Memory acquisition is Phase B in the collection sequence — the most volatile evidence. Every subsequent command you run (including UAC) modifies memory. If you have a pre-compiled LiME module, loading it and dumping memory should be the first action. If LiME is not available, proceed to UAC ir_triage for volatile data capture.
2. What is the primary advantage of running UAC from a USB drive rather than copying it to the compromised system's local disk?
UAC runs faster from USB than from the local disk
The USB drive provides additional storage for the collection output
The UAC binary comes from your trusted media — if the attacker has trojaned system commands, UAC from USB uses your clean copies instead
UAC requires USB to generate filesystem bodyfiles
Correct. Running tools from external trusted media ensures the tool binaries have not been tampered with by the attacker. If the attacker replaced /usr/bin/ps with a trojaned version that hides their processes, UAC from USB can use its own trusted copy of ps to get accurate results.
3. During live response, why is reading /proc/[pid]/exe more reliable than checking the process name shown by ps?
/proc/[pid]/exe shows the process's memory usage, which reveals its true purpose
/proc/[pid]/exe is a kernel-maintained symlink to the actual binary — even if the attacker renamed the process or deleted the binary from disk, the link reveals the true executable path
/proc/[pid]/exe contains the process's command-line arguments which ps hides
/proc/[pid]/exe is encrypted and cannot be tampered with by the attacker
Correct. /proc/[pid]/exe is a symlink maintained by the kernel pointing to the actual binary file. An attacker can disguise a cryptominer as [kworker/2:1+] in the process name, but /proc/[pid]/exe still points to /dev/shm/.cache/miner. If the binary was deleted, the link shows (deleted) — and you can still copy the binary via cp /proc/[pid]/exe /mnt/usb/recovered_binary.
4. You pipe live response output to your forensic workstation via SSH: ssh target "ps auxf" > evidence/processes.txt. Why is this preferred over saving output to the compromised system's local disk?
Writing to the local disk modifies the filesystem being investigated — timestamps change, disk blocks are allocated, and journal entries are created that contaminate the evidence
SSH encryption protects the evidence during transfer
The forensic workstation has more storage capacity
The attacker might delete locally saved files
Correct. Every file write to the compromised disk modifies filesystem metadata — inode timestamps, journal entries, block allocation tables. These modifications can overwrite evidence (deleted file data blocks) and contaminate the timeline. Piping output to your workstation over SSH ensures zero writes to the evidence disk.
5. What does lsof +L1 show, and why is it forensically significant?
It shows files larger than 1MB that are currently open
It shows files that have been deleted from the filesystem but are still held open by a running process — the attacker deleted the binary but the process is still running
It shows the last file accessed by each process
It shows files with only one hard link remaining
Correct. lsof +L1 lists files with a link count less than 1 — meaning the file has been deleted from the directory but is still held open by a process. This is a common attacker anti-forensic technique: launch the malware, delete the file from disk, but the process keeps running. The investigator can recover the binary via /proc/[pid]/fd/.
6. You need to collect evidence from a Docker container, but the liveness probe might restart it at any moment. What is the most critical collection command to run first?
docker inspect — to capture the container configuration
docker logs — to capture the application output
docker export — to capture the entire container filesystem before it is destroyed by a restart
docker diff — to see what files the attacker changed
Correct. docker export captures the complete merged filesystem — base image plus all attacker modifications. If the container restarts, the writable layer is destroyed and all evidence inside the container is lost. Docker logs and inspect data survive a container restart (until the container is removed), but the filesystem does not. Export first, then collect everything else.
7. Why is a cloud disk snapshot forensically cleaner than running dc3dd on the live system?
Cloud snapshots are encrypted by default
Cloud snapshots include the instance's memory state
A snapshot is a point-in-time capture of the entire disk without logging into or modifying the running system — dc3dd acquires blocks sequentially while the system continues writing
Cloud snapshots can be taken without the appropriate IAM permissions
Correct. A cloud disk snapshot captures every block at the same instant — a consistent point-in-time view. A live dc3dd image acquires blocks sequentially over minutes while the system keeps writing, potentially resulting in inconsistent state. Additionally, the snapshot requires no login to the VM — zero modification to the running system.
8. You collected auth.log and recorded its SHA256 hash. Three days later, the hash does not match. What is the most likely explanation?
The hash algorithm produced a collision
The file was modified after collection — either you are verifying a copy that was corrupted during transfer, or the wrong file was hashed initially
SHA256 hashes naturally change over time
The file system updated the file's metadata, changing the hash
Correct. A SHA256 hash mismatch means the file content changed between collection and verification. The most common causes: file was corrupted during transfer (network error, incomplete copy), the verification is running against a different file (wrong path), or the file was inadvertently modified (opened and saved by an analysis tool). Investigate by checking file sizes and re-transferring from the original.
9. You are the sole investigator for 8 compromised Linux servers. What is the correct triage strategy?
Run UAC ir_triage on all 8 servers first to secure critical evidence from every system, then return to the highest-priority systems for comprehensive collection
Perform full collection (memory, UAC full, disk image) on the first server before moving to the next
Image all 8 disks simultaneously using parallel SSH sessions
Focus only on the server that was compromised first
Correct. Multi-system triage: fast collection (ir_triage, 8-15 minutes each) across all systems first. This secures the most volatile evidence from every system. Then prioritize full collection on the systems where triage data reveals the most significant compromise. Spending 3 hours on full collection of server 1 while evidence degrades on servers 2-8 is the worst outcome.
10. The compromised server uses LUKS full disk encryption and the IT team powered it off before you arrived. What do you need before you can image the disk?
A write blocker that supports encrypted disks
The server's BIOS password to access the boot menu
The LUKS passphrase or key file — without it, the encrypted partition cannot be unlocked and an image of the raw encrypted blocks is forensically useless
A forensic tool that can decrypt LUKS automatically
Correct. LUKS encryption means the disk contents are encrypted at rest. When the system was powered off, the volume was locked. You must unlock it with the passphrase or key file before you can image the decrypted filesystem. An image of the encrypted blocks cannot be analyzed without the key. This is why live collection of running encrypted systems is preferred when possible — the volume is already unlocked.
11. What is the primary purpose of the bodyfile output generated by UAC?
It records the content of every file on the system
It records filesystem metadata (name, timestamps, size, owner, permissions) for every file — the input for timeline generation with mactime or plaso
It records which files were accessed during the UAC collection
It records the SHA256 hash of every file for integrity verification
Correct. The bodyfile is a standardized format containing filesystem metadata — file paths, all four timestamps (atime, mtime, ctime, crtime), file size, ownership, and permissions for every file on the system. It is the input for mactime (Sleuth Kit) which generates a chronological filesystem timeline — the primary analysis artifact for determining what happened and when.
12. Your live response collection script uses 2>/dev/null on most commands. What is the risk of this approach?
It makes the script run slower by redirecting output
It prevents the script from running on systems without /dev/null
Error messages that indicate missing evidence, permission problems, or unexpected system state are silently discarded — you may not know a collection step failed
It causes the hash generation to skip files with errors
Correct. 2>/dev/null suppresses error output, preventing "file not found" and "permission denied" messages from cluttering the output. But it also hides meaningful errors — a command that fails completely produces no output and no error. The mitigation: review the collection log for gaps, check expected file sizes, and verify the hash manifest includes all expected files.