OS and Network Forensics practice questions

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB

Why it fails: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB exposes PnP device nodes for every USB device and hub that has ever been enumerated on the system, organized by VID/PID and instance ID. While it confirms that a particular USB peripheral was present, its values are hardware identifiers and configuration data, not forensic timestamps — there is no first connection or install date stored in this key. It may show the parent hub or ContainerID, but it cannot answer when the device was first plugged in, so it is not the correct source.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

Why it fails: The DeviceClasses key with GUID {53f56307-b6bf-11d0-94f2-00a0c91efb8b} represents the storage volume device-interface class, which Windows uses to surface volume symbolic links such as \\?\\Volume{GUID}. This key shows that a storage volume (which could be a partition on a USB drive or an internal hard disk) was exposed to user-mode applications, but it does not record the time the USB device was first attached. Because this GUID applies equally to fixed internal disks, it is neither USB-specific nor a first-connection timestamp source.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Why it fails: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 stores per-user, MRU-style mount point mappings for volumes the logged-in user has accessed, including entries that reference USBSTOR device paths. However, the timestamps visible in this hive are the LastWrite times of the mount point keys, reflecting when that specific user mounted or accessed the volume, not when the device was first connected system-wide. It can indicate user awareness or use of a USB volume in a user profile, but it cannot supply the device's first-connection timestamp and is therefore incorrect.

Jump lists

Why it fails: Jump lists are per-application menus that record files recently opened within that application (e.g., Word or Excel). While they contain LNK files embedded as entries, they are scoped to a specific application and user interaction, not a global file-system access record. Therefore, for broad tracking of recently accessed files across the system, LNK files are the more appropriate artifact.

ShellBags

Why it fails: ShellBags are registry keys that store per-folder view preferences such as icon size, sort order, and window position. They are updated when a user opens a folder in Explorer, so they can indicate which folders were browsed, but they do not track individual file access or recent files. Thus they are not the correct artifact for tracking recently opened or accessed files.

Prefetch files

Why it fails: Prefetch (.pf) files are generated by Windows to speed up application startup; they contain the list of files and libraries loaded when an executable runs. They provide evidence of application execution and its referenced files at runtime, but they do not record user-initiated file opens or recent file lists. Therefore, they are not the primary artifact for tracking recent file access.

HKEY_LOCAL_MACHINE\SAM\SAM

Why it fails: The SAM hive (HKEY_LOCAL_MACHINE\SAM\SAM) stores the Security Account Manager database, which contains local user password hashes, security descriptors, and group membership information. It contains no AutoRun or startup entries, so it cannot be used to execute programs at user logon. Additionally, access to this hive is deliberately restricted even for administrators because of the sensitive credential material it holds, making it a very unlikely target for simple persistence.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Why it fails: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon primarily configures the interactive logon process, including the Userinit and Shell values that run during logon. While those values can be misused to launch programs, this is a less common and more disruptive persistence strategy than standard Run key abuse; modifying Winlogon can destabilize the whole logon experience and usually requires privileged access, so it is not the typical key used for per-user startup entries.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Why it fails: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services is the registry root for the Service Control Manager, storing each service's start type, binary path, dependencies, and recovery options. A service entry is not launched through the same shell startup flow as user Run keys; it is started by the kernel/service control manager and typically requires SYSTEM or administrative privileges to install. While malware can use services for persistence, this is a distinct mechanism from ordinary user-logon auto-start and is not a per-user Run-style location.

/var/log/boot.log

Why it fails: /var/log/boot.log is not relevant because it captures the status of system services and kernel modules during the boot sequence, such as daemon start and stop messages from init scripts or systemd. It contains no record of user authentication attempts, sudo invocations, or login sessions, making it useless for investigating login activity.

/var/log/dmesg

Why it fails: /var/log/dmesg is incorrect because it holds the kernel's ring buffer, which stores low-level messages about hardware detection, drivers, memory, and filesystem errors. These environmental messages have no relation to user or service login events, and authentication attempts are never routed to this log.

/var/log/kern.log

Why it fails: /var/log/kern.log is a wrong choice because it is dedicated to kernel-originated messages, including device drivers and kernel-level errors, and while it may include some security-related kernel warnings, standard authentication events such as SSH logins or su/sudo usage are not written to this file. User authentication is handled by PAM and login services, which log to auth.log, not kern.log.

Jump list data from the taskbar showing recently opened files

Why it fails: Jump lists are stored in %APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations and contain lists of recently opened files or tasks per application, such as Word or Notepad. They are valuable for showing file access or task usage, but they do not maintain a per-program execution counter or a global timeline of every program launch. Thus they can corroborate program use only when the user also opened a document, not as a standalone execution history.

Prefetch file metadata indicating application launch times

Why it fails: Prefetch files, located in C:\Windows\Prefetch, are binary metadata files created by the Windows Prefetcher to speed up application startup. They record the first and last run times and a run count for each application, but only for executables that are loaded via the prefetching mechanism and on a system-wide basis, not per user. Moreover, they are not registry-based and do not capture the interactive session context that UserAssist does.

ShellBags data displaying folder view settings and sizes

Why it fails: ShellBags are registry keys under HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags that store the view settings (e.g., icon size, sort order, window position) for folders that a user has opened in Windows Explorer. They are useful for demonstrating folder navigation and that a user was aware of certain directories, but they contain no program execution counts or timestamps. They are entirely unrelated to launching applications.

bulk_extractor -o timeline.csv /dev/sda1

Why it fails: bulk_extractor is a high-speed data carving utility that extracts discrete artifacts such as emails, credit card numbers, and URL histories from raw images — it does not parse file system metadata or produce a chronological record of system activity. Its -o flag simply designates an output directory, not a timeline CSV. Therefore, while useful for finding specific payloads, it cannot generate an event timeline, making this command ineffective for the examiner's purpose.

plaso.py -i /var/log -o timeline.csv

Why it fails: plaso.py is not the intended front-end command in the Plaso framework; timeline collection is performed by log2timeline.py, which creates a .plaso storage file, and processing/export is done with psort.py. Additionally, -i and -o are not used in that manner — log2timeline.py accepts source paths and storage file arguments, while psort.py controls output format via -o. Running plaso.py with these flags would fail because the tool expects a different operational flow, so this option misunderstands Plaso's command structure.

sleuthkit_timeline -m /mnt/evidence -d timeline.csv

Why it fails: The Sleuth Kit's timeline tools are 'fls' and 'mactime', not a command named 'sleuthkit_timeline'. The mactime utility consumes a body file (created by fls -m) and produces a chronological timeline, whereas the options shown here (-m for mount point, -d for output) do not match mactime's interface, which uses -b for the body file and an optional date range. This command would be unrecognized and fail, and even if substituted with mactime, the -d flag is not valid for specifying CSV output.

.plist files in ~/Library/Preferences

Why it fails: While ~/Library/Preferences contains plist files that may retain a last-opened or modification timestamp, these are application-specific preference containers, not a centralized record of file-system activity. An intruder's changes to arbitrary files are not systematically logged here, and plists are easily modified by applications themselves, undermining their reliability for constructing a forensic timeline. Thus they are not the artifact an analyst would target for a global file-system change history.

Unified logging (log stream)

Why it fails: Unified logging (log stream) captures system, kernel, and application debug messages, including many operational events, but it is not a purpose-built audit of file-system mutations. While some file-related messages may appear transiently in the os_log buffer, the log is ring-buffered and selectively persisted, lacking the comprehensive path and timestamp metadata necessary to rebuild a reliable change timeline. It can support analysis, but it is not the primary structured source for file-system forensics on macOS.

Quick Look server logs

Why it fails: Quick Look server logs (from the quicklookd daemon) only document when the system generated a preview or thumbnail for a specific file from the user's perspective. They do not record file creations, deletions, renames, or writes outside of the Quick Look previewing context, and the logs themselves are not structured for forensic timeline reconstruction. Searching these logs for a file-system change history would be an investigative dead end.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Why it fails: The HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run key is exclusively used for specifying applications that auto-start when a user logs on, containing registry values that point to executable paths and command-line arguments. It has no relationship to the Plug and Play device tree or USB storage device enumeration, so it will not contain any serial numbers, vendor IDs, or connection timestamps. Its presence on a system is relevant to persistence analysis, not to reconstructing removable storage history.

NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Why it fails: The NTUSER.DAT hive's Explorer\MountPoints2 subkey is a per-user registry area that tracks logical drive-letter mappings and the graphical shell's state for mounted volumes, such as whether a drive was opened in Explorer and its auto-run behavior. While it may indicate that some storage device was assigned a particular drive letter, it does not store the device's unique serial number, manufacturer, or instance ID, and it can contain stale or ambiguous entries that are not reliably tied to a specific physical USB device. Therefore it is insufficient for definitive USB device history identification.

HKLM\SAM\SAM\Domains\Account\Users

Why it fails: HKLM\SAM\SAM\Domains\Account\Users resides within the Security Accounts Manager hive and contains only user account information, including NTLM hashes, password history, and account policy attributes. It is structurally isolated from the Windows\(ControlSet)\Enum\USBSTOR device-instance path, and there is no mechanism by which USB storage device plug/unplug events would be written to this hive. The SAM database is meant for authentication and account management, not for recording hardware device activity.

Tcpdump

Why it fails: Tcpdump is a command-line packet capture tool that uses libpcap and BPF filters to collect raw frames, but it only prints packet summaries or hex/ASCII dumps of headers and payloads. It lacks interactive protocol dissectors, semantic stream reassembly, and graphical analysis, forcing analysts to manually piece together application-layer sessions, which makes it underpowered for deep forensic inspection compared to Wireshark.

Netstat

Why it fails: Netstat is a host-level network utility that reports active TCP/UDP connections, listening ports, routing tables, and per-interface statistics by reading kernel tables. It does not capture or decode packet content at all — only stateful endpoint information from the local OS, so it cannot reveal payload datagrams or the actual bytes exchanged on the wire. This makes it useful for a quick connectivity check but irrelevant for analyzing network traffic content.

Nmap

Why it fails: Nmap is a network scanning and enumeration tool that sends crafted probes to discover live hosts, open ports, running services, and even OS/version fingerprints through banner and response analysis. It does not passively capture traffic on an interface nor reassemble existing connections, and while its NSE engine has some HTTP and service scripts, it lacks packet-level payload inspection and stream reassembly for general forensic traffic review. Therefore it is a scanner, not a packet inspection tool.

IDS logs

Why it fails: IDS logs are inferior because an intrusion detection system only records alerts triggered by traffic that matches a known attack signature or an anomalous pattern; it does not log every connection. On a busy network, the vast majority of outbound connections are 'normal' and therefore never generate an alert, so IDS logs cannot be used to reconstruct the complete set of outbound connections that occurred.

Proxy logs

Why it fails: Proxy logs only capture traffic that is explicitly routed through the proxy server, typically limiting visibility to HTTP/HTTPS and sometimes FTP or other text-based protocols. This leaves outbound connections using non-HTTP protocols like SSH, SMTP, DNS, or custom UDP/TCP applications completely unrecorded, making proxy logs an incomplete and protocol-restricted source for identifying outbound traffic.

NetFlow logs

Why it fails: NetFlow logs provide aggregated flow summaries rather than metadata for each individual packet or connection, merging many packets of the same 5-tuple into a single flow record. Theserecords are frequently sampled (e.g., 1 in 100 packets) and lost on resource limits, so short-lived or low-volume outbound connections may be entirely missed, preventing the kind of exhaustive connection-level visibility that firewall logs offer.

HKLM\SYSTEM\CurrentControlSet\Services

Why it fails: Services key is used for service installations, not typical Run keys.

HKLM\SAM\SAM

Why it fails: SAM hive stores user account info, not autorun.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Why it fails: Winlogon key can be used for persistence but is less common; the question asks for 'commonly used', Run keys are more typical.

HKLM\SYSTEM

Why it fails: HKLM\SYSTEM is a registry hive that stores hardware, device, and system configuration data, such as control sets, mounted devices, services, and boot configuration. Although registry keys have last-write timestamps, these are not typically extracted as individual timeline events or used to reconstruct user or file system activity. Timeline analysis prioritizes artifacts that record file access, execution, or modification patterns; static system configuration in this hive does not serve that purpose.

HKLM\SAM

Why it fails: HKLM\SAM hosts the Security Accounts Manager database, storing local user account credentials, password hashes, and account policy flags, not file system or activity timestamps. While it contains password-last-set times, these are account administration data, not events that reflect user file access or program execution. Consequently, it is not a source for typical timeline artifacts used to reconstruct forensic event sequences.

Windows Event Logs

Why it fails: Windows Event Logs do contain timestamped records of system and application events, but they are structured logs rather than file-system metadata artifacts like LNK or Prefetch files. Traditional timeline analysis, as exemplified by tools like mactime or fls, focuses on MAC timestamps from file system metadata and embedded artifacts, not on event log records. While modern tools may incorporate event logs, the classic timeline artifacts referenced in this question are LNK and Prefetch files, making event logs the odd option here.

Compile a kernel module

Why it fails: Building a kernel module requires a full toolchain — `gcc`, `make`, kernel headers, and often `dkms` — and the resulting `.ko` object would be loaded with `insmod` or `modprobe`. Merely fetching a script with `wget` and executing it does not compile anything, and the shell script's contents would not match a kernel compile workflow. An attacker who wanted a rootkit via LKM would not use this one-liner; they would need to stage source files and tooling on the host.

Update the system packages

Why it fails: Legitimate package updates use the distribution's package manager, such as `apt-get update && apt-get upgrade` or `yum update`, which verifies package signatures from configured repositories. Downloading an unnamed script via `wget` and running it with elevated privileges bypasses all integrity and authenticity checks. Furthermore, the filename `shell.sh` is not a package artifact, and a true package update would never involve immediately executing a shell script from a remote URL.

Perform a system backup to a remote server

Why it fails: A remote backup operation would rely on tools like `tar`, `rsync`, `scp`, or `duplicity`, often with an incremental schedule and encrypted transfer. The observed actions — downloading a script, chmodding it executable, and running it — do not collect, archive, or transfer any data. Even if the script later contained a reverse shell, its initial behavior is clearly not a backup because it takes no source paths or destination arguments.

bash_history

Why it fails: bash_history stores commands entered in the terminal, not file access via GUI.

.plist files in ~/Library/Preferences/

Why it fails: .plist files store application preferences, not a comprehensive list of accessed files.

Unified Logging (log stream)

Why it fails: Unified logging provides system logs but is not specifically designed for file access history.

/proc/1234/status

Why it fails: status provides process status information but not the full command line.

/proc/1234/maps

Why it fails: maps shows memory mappings, not command line.

/proc/1234/fd

Why it fails: fd is a directory containing file descriptors, not command line.

.bashrc in user home directories

Why it fails: .bashrc in user home directories is a shell startup script that runs only when a user starts an interactive Bash terminal; it does not execute during non-interactive sessions such as SSH commands, system services, or graphical login, so an attacker cannot rely on it for automatic execution at every boot. While an attacker can append a malicious command or reverse shell, this mechanism is inherently user-session dependent and less common for persistent access because many systems run headless daemons and rarely have an interactive shell opened. Moreover, modifying .bashrc is readily visible to the account owner, making it a fragile persistence choice for attackers seeking covert, long-term access.

/etc/passwd file modification

Why it fails: Directly editing /etc/passwd to insert a new user account with a known UID/GID and password hash is an outdated and highly visible technique; the file is world-readable and parsed by virtually every system command, so the addition is immediately obvious to system administrators and can be detected by file-integrity monitoring tools like Tripwire, AIDE, or osquery. Modern systems use /etc/shadow to store password hashes, meaning a passwd-only entry would be non-functional or require corresponding shadow changes. Because it leaves blatant artifacts and does not survive filesystem integrity checks, it is not a typical, stealthy persistence mechanism and is far less common than authorized_keys, cron, or systemd.

Block the IP address 10.0.0.5 at the firewall

Why it fails: Blocking the IP address 10.0.0.5 at the firewall is an ephemeral, signature-based response: the observed source is likely one node in a distributed attack, and modern brute-forcing tools rotate addresses via botnets or open proxies. This action does not alter the fact that sshd still accepts password authentication and root login, so the same attack pattern will continue from new IPs. The durable fix is to harden the SSH service itself, with IP-based blocking (if any) only as a supplementary layer such as fail2ban.

Delete the root user account

Why it fails: Deleting the root user account is not a viable remediation because UID 0 is the superuser that the kernel and system tools expect; even with root's shell removed or account locked, processes and file ownership rely on that UID, and many administrative operations cannot be performed without it. It also does not reduce the brute-force exposure on other accounts, and if sshd still allows password authentication, attacker can target any enabled username (e.g., a service account) with the same dictionary attack. The correct scope is to disable remote root login and password auth while leaving the local root account intact for single-user mode and console recovery.

Change the root password to a complex password

Why it fails: Replacing the root password with a complex value raises the guessing threshold, but it leaves PasswordAuthentication enabled, so the attack surface remains and a botnet can continue hammering sshd indefinitely with new guesses against PAM. Complex passwords are still vulnerable to credential-stuffing, keyloggers, or accidental exposure, and they do nothing to prevent anonymous 'root' login attempts from being processed at all. To eliminate the class of brute-force attack, you must disable password verification for SSH entirely and rely on key-based authentication, which presents no reusable secret to guess.

bash_history

Why it fails: bash_history stores only the interactive command-line entries for the Bash shell, reflecting user-typed commands rather than the actual file system mutations they may have caused. It is trivially editable or deletable by the user, does not capture commands executed by other shells, GUI applications, or background services, and lacks the comprehensive, timestamped event coverage needed for forensic timeline reconstruction on macOS.

Unified Logging

Why it fails: Unified Logging (the os_log infrastructure) is a centralized, high-performance logging system that records kernel and user-space messages, but it is neither a file-system event journal nor designed to enumerate every file change. Its entries are typically string-based log lines with variable granularity, are subject to time-based pruning and privacy redaction, and depend on loggers actively choosing to emit events—so it cannot reliably construct an exhaustive file system timeline in the way FSEvents can.

.plist files

Why it fails: Property list (.plist) files hold structured application preferences, metadata, and sometimes user activity traces such as recent documents or last-opened timestamps, but they are application-specific and far too sparse to represent a system-wide file system chronology. Their presence and values depend on each application's behavior and can be easily modified by normal operation or deliberate anti-forensics, making them an inadequate substitute for the comprehensive event stream that FSEvents provides.

The source MAC address is from a well-known vendor

Why it fails: The source MAC address revealing a well-known vendor is a dead-end clue because the OUIs simply identify the manufacturer of the NIC, not the intent or state of the device. Workstations, servers, IoT devices, and attacker-controlled VMs all carry similar vendor-assigned MAC addresses, and spoofing or virtual network adapters often mask the true identity. A MAC vendor does not in any way correlate with worm behavior, so this has zero evidentiary weight.

The packet contains a payload with the string "SMBv2"

Why it fails: Seeing the string "SMBv2" in the payload is a red herring because SMBv2 is a legitimate, widely used dialect of the Server Message Block protocol; its negotiation handshake explicitly advertises "SMBv2" in the NegProt response and in packet type identifiers. Normal Windows file-sharing traffic includes these exact strings, so it is not an indicator of compromise. Moreover, a bare TCP SYN has no payload at all, so if a payload is present, the analyst must inspect its structure and context rather than merely matching a protocol name.

The destination IP 203.0.113.5 is a known web server

Why it fails: Knowing that 203.0.113.5 is a web server does not strengthen the worm hypothesis because web servers normally listen on TCP 80/443, while the observed traffic targets port 445 for SMB file sharing. A web server may also expose SMB services in some enterprise environments, but its role as a web server does not explain the surrounding SYN sweep pattern, nor is "known legitimate role" itself a cause for dismissing or suspecting malicious activity. The destination's service type is irrelevant to whether the source is a worm scanning for SMB vulnerabilities.

Store recently opened documents (MRU list)

Why it fails: Recent documents are maintained separately by Windows Explorer: the shell stores an MRU of opened files under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs, backed by .lnk shortcuts in the user's Recent folder, plus bagMRU/bagRT for folder navigation. UserAssist targets executable image paths launched through the shell's Run/RunMRU or double-clicking programs, not the files those programs open. Thus UserAssist is not the correct artifact for recently opened documents.

Record USB device insertion history

Why it fails: USB insertion history is recorded by the plug-and-play manager in the SYSTEM hive, not in the user's UserAssist subkeys. SYSTEM\CurrentControlSet\Enum\USBSTOR enumerates USB mass-storage devices that were attached, and SYSTEM\CurrentControlSet\Enum\USB tracks device instances, while SetupAPI log files add timestamps. UserAssist contains only executable launch data and would not reveal a USB flash drive's insertion.

Log network share connections

Why it fails: Network share connections are stored in the registry under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 as mount-point subkeys for UNC paths, and associated shell bag and MUICache entries preserve display names and connection context. UserAssist tracks local GUI launches of executable files; it does not maintain a log of `net use` mappings or Explorer's network share connections. Therefore network share history is outside UserAssist's scope.