Select Two (Multi-Select) Questions

log2timeline

log2timeline is a tool for extracting timeline data from various sources.

Plaso

Plaso (formerly log2timeline) is the successor for timeline analysis.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

This HKLM Run key is a critical persistence location: at every user logon, the Winlogon process reads it and launches each listed executable for all accounts, requiring administrative privileges to modify. Values are command lines (e.g., 'C:\malware.exe') that run early in the logon sequence, before the desktop is fully interactive. Because it has system-wide scope, it is a top target for malware persistence and a primary check during a forensic investigation for auto-start mechanisms.

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

This per-user Run key is processed at logon for the currently logged-in user, with each value executed in that user's context after the shell initializes. Unlike its HKLM counterpart, it does not require administrator rights to write, making it a common low-privilege persistence vector for trojans or initial access payloads. Forensic analysts should inspect both this key and the HKLM Run key because malware chooses based on the privilege level available; either can hold the attacker's command line, but this one is restricted to a single account.

/data/media/0/Android/data/com.whatsapp/

This path is the app-specific external storage directory for WhatsApp on shared storage, exposed via FUSE and sometimes accessible to forensic tools even without root. It holds user-visible artifacts such as transmitted images, videos, voice notes, and document files, and may also contain encrypted database backups (e.g., msgstore.db.crypt14) that, when credentialed or decrypted, can reveal message history. In a logical acquisition, this location is a priority because it often survives app data clearing and can corroborate messages recovered from the internal database. It is correct because it is a designated app-owned location on external media where WhatsApp materializes attachments with metadata like file names and timestamps.

/data/data/com.whatsapp/databases/msgstore.db

This is the primary SQLite database within WhatsApp's private internal storage, directly containing message rows, chat metadata, and sender/receiver identifiers. It is the authoritative source for message content, and deleted messages may be recoverable from unallocated database pages or from the write-ahead log (msgstore.db-wal) if the application crashed or was not cleanly checkpointed. Because the app sandbox is protected by SELinux and requires root or a forensic image with an unlocked bootloader to access, this path is a high-value target in physical or full-file-system acquisitions. It is correct because it directly answers the question of recovering WhatsApp message history, including threads and attachments references.

The number of times the application has been executed

Prefetch stores a run counter.

The exact date and time of each execution

Prefetch records the last execution time; multiple times can be approximated via timestamps.

File slack

File slack is the unused space between the end of a file and the end of the last cluster.

Volume slack

Volume slack is the unused space at the end of a partition.

RAM slack

RAM slack is the space between the end of a file and the end of the sector.

4648

Event ID 4648 records a logon attempt using explicit credentials, such as when a user runs a process with `runas` or supplies alternate domain credentials for a network connection. This satisfies the stem’s constraint of “explicit credential usage” because the event logs the target account and the source process, distinguishing it from interactive logon events like 4624.

4624

4624: An account was successfully logged on.

Date and time of evidence collection

The exact date and time of evidence collection is a cornerstone of chain of custody, as it creates an unambiguous chronological reference point. This timestamp, along with the location and the person collecting the evidence, establishes when the evidence first came into official custody. It allows the court to reconcile the evidence's timeline with investigator actions and to detect any gaps or irregularities. Without a precise date and time, the entire chain of custody could be challenged for lack of evidence integrity.

Signature of the person handling the evidence

The signature of each person who handles the evidence is a mandatory component because it provides individual accountability at every transition point. Signatures, as well as printed names sometimes, allow a prosecutor to identify who had possession at each stage and to call those witnesses to testify to their handling. Without a signature, the chain of custody breaks, and the evidence could be excluded as unauthenticated. This signature is distinct from the date/time, as it confirms not when the event occurred but who was responsible for it at that moment.

Compute the SHA-256 hash of the image and compare it to the original drive's hash

Computing the SHA-256 hash of the acquired image and comparing it against the hash computed from the original drive is the gold standard for forensic integrity verification. SHA-256 is a NIST-approved cryptographic hash function that produces a unique 256-bit digest; because it is collision-resistant and preimage-resistant, even a single flipped bit in the image will cause a completely different digest. This comparison verifies that the acquisition process created a bit-for-bit identical copy, providing a defensible basis for subsequent analysis and court testimony.

Compute the MD5 hash of the image and compare it to the original drive's MD5 hash

Computing and comparing MD5 hashes is a valid integrity check and has been the traditional forensic standard for decades, but MD5 is no longer considered collision-resistant. Since 2004, researchers have demonstrated that crafted inputs can produce identical MD5 digests, so an adversary could theoretically alter the image while preserving its hash. In practice, however, MD5 remains widely used for fast verification because real-world forensic acquisitions do not involve deliberate hash collision attacks; nonetheless, pairing MD5 with a stronger algorithm like SHA-256 is recommended for robust assurance.

Use the 'verify' function within FTK Imager which automatically computes and compares hashes

FTK Imager's 'Verify' function is a built-in, automated integrity check that recomputes one or more cryptographic hashes of the acquired image and compares them against the hash values stored in the image metadata during the original acquisition. This is a correct method because it performs the same type of secure hash comparison as a manual hashing process, but eliminates transcription errors and ensures consistency with the acquisition workflow. It typically verifies MD5 and SHA-1/SHA-256, giving the examiner immediate confirmation that the image has not been altered since capture.

Host system audit logs

Host system audit logs, such as those from auditd, systemd journal, or syslog, are the strongest artifact because the host kernel records container process activity in a way that survives container removal. These logs commonly capture container-ID-tagged process executions, file access, syscalls, and seccomp/AppArmor denials, allowing an investigator to reconstruct the container's interactions with the host. Unlike in-container logs, an attacker who deletes or overwrites files inside the container cannot easily erase the host-side audit trail.

Docker image layer files

Docker image layer files preserve the container's filesystem as a series of immutable read-only diffs, typically stored under /var/lib/docker/overlay2, and remain available even if the running container is destroyed. Each layer's diff_id and metadata reveal exactly which files were added, changed, or deleted at each build step, enabling static discovery of dropped malware, malicious scripts, or tampered system utilities. Because layers are content-addressed and shared, they also help identify the same malicious image pulled across multiple hosts.

Container logs (stdout/stderr)

Container logs (stdout/stderr) are written to a JSON-file log on the host, e.g., /var/lib/docker/containers/<id>/<id>-json.log, and often survive after the container exits, providing a record of application output, error messages, and command responses. These logs are useful for detecting exploit payloads, suspicious commands sent to a reverse shell, or application-level evidence like database errors from an injection attack. However, an attacker can disable the logging driver or operate through interactive shells that produce no stdout output, so the absence of log entries does not clear a container.

SSH authorized keys

SSH authorized keys are a persistence mechanism because they enable an attacker to retain remote access without needing to re-exploit the system each time; by placing a public key in a user's ~/.ssh/authorized_keys file, the attacker can authenticate over SSH indefinitely, even if the user's password is changed. While they do not autonomously execute commands like cron or init scripts, the ongoing availability of a credentialed login channel is a recognized persistence technique in intrusion activity and should be examined in a forensic investigation.

Startup scripts in /etc/init.d

Startup scripts in /etc/init.d are executed by SysV init at system boot when services are started. An attacker who plants a script there gains automatic code execution with root privileges every time the machine boots, making it a classic and highly persistent execution mechanism. Since these scripts run as root before the normal user session, they are a common target for malware on legacy Linux distributions and need to be scrutinized during incident response.

Cron jobs

Cron jobs are scheduled tasks defined in crontabs, such as /etc/cron.d or a user's own crontab, that run commands at specified times or intervals. Because the cron daemon launches at boot and processes these entries, a malicious cron job will execute repeatedly with the privilege of its owner, thereby maintaining persistence independent of system reboots. They are attractive to attackers because they can achieve regular, quiet execution without modifying startup files.

Modifications to /etc/passwd to add new users

Adding a new user to /etc/passwd creates a persistent login account that survives reboots and can be accessed locally or over SSH. Attackers often give the new user UID 0 (root) so the account possesses full superuser privileges, effectively installing a permanent backdoor credential. Unlike memory-only payloads or one-time exploits, this account remains on disk and available until explicitly removed, making it a strong persistence mechanism from an access standpoint.

POST /upload.php HTTP/1.1 200 0

A POST request to /upload.php that returns HTTP 200 with a zero-byte response body indicates the server accepted a client upload even though the reply was empty. In Apache access logs, the trailing '0' is the response size in bytes, so this record is consistent with a PHP upload handler completing successfully and not returning content. Combined with the known purpose of upload.php, this is a strong forensic foothold for a web shell planted through the application's file-upload feature.

POST /uploads/shell.aspx HTTP/1.1 200 - -

A successful POST to /uploads/shell.aspx is unusual because an attacker is writing directly into a URL-accessible directory rather than going through a typical upload handler; this can happen when a vulnerable script writes attacker-controlled files or WebDAV is enabled. HTTP 200 means the server returned a success status for that write, and the .aspx extension is critical because ASP.NET will execute the code when the file is later requested. Therefore this log line marks the moment the malicious server-side payload became resident in the web root.

GET /uploads/shell.aspx?cmd=dir HTTP/1.1 200 - -

This GET request targets the previously uploaded /uploads/shell.aspx and passes a command through the cmd parameter, which is the classic invocation pattern for ASP.NET command-execution web shells such as cmdasp.aspx. The 200 response confirms that the file was retrieved and interpreted by the server; had the file been missing or blocked, the status would be 404 or 403. Because a normal ASPX application would not use a cmd parameter for directory listing, this record demonstrates post-upload remote code execution.

Directory traversal

The repeated '../' sequences, often encoded as '%2e%2e%5c' or '%2e%2e/', are classic indicators of directory traversal in IIS logs. An attacker sends these sequences to escape the web root and access sensitive files outside it, such as Windows system files or configuration stores. The log entries show a deliberate attempt to navigate the server's directory hierarchy, which is the defining characteristic of a directory traversal attack.

Privilege escalation attempt

This request is a valid privilege escalation attempt because the attacker is trying to access the SAM file (Security Account Manager), which stores Windows password hashes. Successfully retrieving this file through directory traversal could allow offline password cracking and ultimately administrative access. While the technique is directory traversal, the underlying objective is to escalate privileges, so this option correctly describes the attacker's goal.

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

This is the Run key for the current user.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

This is a standard Run key for all users.

WinPmem

WinPmem is a memory acquisition tool for Windows.

FTK Imager

FTK Imager can acquire physical memory on Windows.

Direct evidence

Direct evidence directly proves a fact without inference.

Circumstantial evidence

Circumstantial evidence requires inference to connect to a fact.

$LogFile

The $LogFile records metadata changes, including deletions; can help reconstruct file history.

$MFT (Master File Table)

The MFT contains file records; even after deletion, the record may remain until overwritten.

Network connection to 198.51.100.10:8080

This is a network-based IoC indicating C2.

Registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\UpdateSvc

Persistence via Run key.

File path C:\Windows\System32\drivers\etc\hosts

Hosts file modification is a common technique for DNS poisoning or blocking.

Process Monitor

Captures registry, file system, and process activity in real time.

Regshot

Takes before-and-after snapshots of the registry for comparison.

Process Explorer

Advanced task manager showing processes, handles, and DLLs.

Performing strings analysis on the packed binary

Strings may reveal embedded data or unpacked code regions.

Running PEiD to identify the packer

PEiD can detect many common packers, guiding the analyst on how to unpack.

Using OllyDbg to step through the unpacking routine

OllyDbg is a debugger that can trace unpacking code.

The X-Originating-IP header value

Some mail servers add this header with the original client IP.

The last (bottommost) Received header's IP

The bottommost Received header typically shows the connection from the original sender's MTA or client.