Application, Email and Cloud Forensics practice questions

The email was sent on a weekend

Why it fails: A weekend send time is merely a timestamp in the email's header and does not cryptographically bind to the sender's identity. Spammers and phishers deliberately send at off-peak hours, while legitimate banks often issue automated security alerts on weekends. Thus, the day-of-week alone has no probative value for spoofing.

The DKIM signature uses RSA-SHA256 algorithm

Why it fails: DKIM's RSA-SHA256 is a standard signing algorithm used by the vast majority of legitimate email senders, including banks. A valid DKIM signature that verifies against the d= and s= selectors actually increases confidence in the message's provenance. The algorithm choice is simply a configuration detail and provides no evidence of spoofing.

The X-Originating-IP header is present

Why it fails: X-Originating-IP is a header commonly inserted by webmail clients and local mail user agents to record the TCP peer from which the message was submitted; it is often present on legitimate mail. This header is ad-hoc, not defined in RFC 5322, and can be easily forged or stripped by the mail client, so its mere presence does not correlate with malicious intent.

Collect the container's log files from /var/log/

Why it fails: Collecting logs from /var/log/ inside the container would only capture files written by applications that specifically log to disk, missing stdout/stderr streams that the Docker logging driver (e.g., json-file, journald) stores on the host via `docker logs`. Moreover, when a container is stopped, its writable layer persists on disk, but relying on log files alone overlooks deleted files, binary artifacts, timestamps, and configuration changes that a full filesystem snapshot would reveal. This approach is incomplete because Docker-managed logs are not equivalent to the container's entire forensic copy.

Create a memory dump of the container's process

Why it fails: A container's processes are ordinary userspace processes from the host kernel's perspective, and their memory resides in volatile RAM that is freed as soon as the processes are terminated when the container stops. Since the container is already stopped, all process address space has been reclaimed by the kernel, making it impossible to recover a memory dump post-mortem without live acquisition (e.g., using `gcore` or `dd` from /proc) before shutdown. Docker provides no native mechanism to dump a stopped container's memory, so this option is forensically invalid in the current state.

Run docker attach to reconnect to the container

Why it fails: `docker attach` connects the current terminal to the container's running main process, sending input to its stdin and relaying its stdout/stderr, but this is impossible because no process exists when the container is stopped. Even if the container were running, attaching would alter the process's state, inject input, and modify the container's execution environment, thereby destroying evidentiary integrity. Thus, it is not an acquisition technique and would actively contaminate the evidence.

Wireshark

Why it fails: Wireshark is a network-protocol analyzer that captures and dissects packets at the data-link and transport layers, allowing an investigator to manually reassemble SMTP, POP3, or IMAP conversations if the traffic was intercepted. However, it does not parse or visually reconstruct email headers for forensic routing analysis, so it lacks the specialized, automated header-interpretation features of a purpose-built email header tool.

Volatility

Why it fails: Volatility is a memory forensics framework designed to acquire and analyze volatile RAM, extracting running processes, network sockets, open files, and registry keys from memory dumps. Although email content or addresses might be incidentally recovered from a memory image, Volatility has no built-in parser for RFC 5322 email header fields or message routing metadata, making it unsuitable for direct email-header examination.

FTK Imager

Why it fails: FTK Imager is an evidence-acquisition and disk-imaging tool that creates forensic images, mounts physical/logical drives, and lets investigators browse files and folders, including standalone email files such as EML or MSG. However, it does not parse email headers, decode routing hops, or evaluate authentication results; it merely makes the contents available for triage in other tools, so it cannot perform the header-specific forensic analysis required.

DB Browser for SQLite

Why it fails: DB Browser for SQLite only understands SQLite's file format, which is a transactional SQL database with a B-tree page layout. An Outlook PST is a proprietary MAPI personal folder store, not a SQLite database, so this tool would fail to parse the PST's internal structures and would not recover email items, dates, or recipients.

MailXaminer

Why it fails: MailXaminer does support PST analysis and can produce reports, but the scenario's emphasis on a forensic examiner selecting the most specialized tool points to Aid4Mail, which is purpose-built with stronger evidence-preservation and metadata-integrity mechanisms for Outlook data. MailXaminer is more of a broad email forensics suite, whereas Aid4Mail is tightly scoped to PST/OST examination.

Outlook Express

Why it fails: Outlook Express is a legacy email client that stores mail in .dbx or .mbx formats, not a forensic utility. Running Outlook Express to open a PST would be inappropriate because it cannot natively interpret PST's MAPI structures, and any attempt to import or convert the file could modify timestamps and associated metadata, compromising evidentiary integrity.

Inability to collect memory dumps

Why it fails: Memory dumps are not inherently impossible in cloud environments. Investigators with properly scoped access can acquire volatile memory by using hypervisor-level introspection, VM snapshot files (.vmem), or agent-based tools (e.g., dumping /dev/mem and analyzing with Volatility). The challenge is a matter of permission, not technical feasibility, so this option misrepresents the baseline capability of cloud forensics.

Lack of logging

Why it fails: Modern cloud providers offer extensive logging by default or on demand, including AWS CloudTrail, Azure Monitor, Google Cloud Audit Logs, VPC flow logs, and API logging. The real complication is not a lack of logs but managing log volume, retention policies, and the ability to correlate events across distributed services. Therefore, claiming a lack of logging is factually incorrect and overlooks the actual log-management challenges in cloud forensics.

Data volatility

Why it fails: Data volatility is a general forensics challenge that applies to any computing environment, including bare-metal systems, not just the cloud. While ephemeral instances, autoscaling, and short-lived containers can make cloud data transient, forensic teams can use snapshots and proactive acquisition strategies to capture such data. Compared with multi-tenancy, volatility is not the most significant or cloud-specific challenge, as it does not involve the legal, privacy, and isolation complexities introduced by shared infrastructure.

Message-ID

Why it fails: Message-ID is a globally unique identifier assigned by the first message server or client, formatted as something like abc123@example.com. It is used for correlation, thread linking, and deduplication, but it contains no IP address or routing information. An investigator might use it to search logs, but it does not record the path of relays.

DKIM-Signature

Why it fails: DKIM-Signature is an email authentication header that uses public-key cryptography to allow the verifying side to check whether a message was signed by a domain's private key. It contains parameters like v=, a=, c=, d=, and bh=, but those hold a signature value and key selector, not the IP addresses of intermediate servers. While it can help confirm a domain's involvement, it does not provide a hop-by-hop IP trail.

X-Originating-IP

Why it fails: X-Originating-IP is a non-standard, informal header commonly added by webmail providers and some client servers to indicate the IP address of the sender's device. It is often absent if the MTA does not add it, and because it is a single header that is easily forged by the sender, it is not dependable for evidence. Received headers are added by each and every relay and are under the control of the servers, making them far more trustworthy.

GET

Why it fails: GET is the HTTP method recorded in the cs-method field at the beginning of the IIS log entry. It describes the action the client requested (retrieving a resource) but cannot be the status code. In this log entry, the presence of GET is contextual and does not indicate the outcome of the request.

80

Why it fails: 80 is the value in the s-port field, which records the server port the client connected to (standard plain HTTP port). It is part of the connection metadata, not the HTTP result. Even though port 80 appears in the log, it doesn't tell you whether the request succeeded or failed.

0

Why it fails: In the extended log format, sc-substatus is a numeric substatus code that provides more granular error detail within an IIS error status. A 0 here means no substatus was generated; it is a supplementary field, not the primary status code. It cannot replace the sc-status value 200 as the answer.

Chain of custody documentation

Why it fails: Chain of custody documentation is a foundational evidentiary requirement in every forensic examination, regardless of the environment, and cloud forensics is no exception. While cloud investigations may rely on provider-generated logs and metadata rather than physical seizure, the need to document who accessed, handled, and analyzed data remains unchanged. Because it is a universal discipline-wide obligation rather than a condition introduced by cloud architecture, it is not a challenge specific to cloud forensics.

Physical access to the hard drive

Why it fails: In most public cloud investigations, the investigator cannot physically seize the server hard drives and must work through the provider's API or legal process, but this limitation already exists in traditional remote and network-based forensic work. The absence of physical access is an operational obstacle, not a distinguishing attribute of cloud forensics, because many non-cloud systems also reside in locked racks or remote data centers. Therefore, while access may be indirect, it is not the defining challenge that separates cloud forensic practice.

A backup operation was performed

Why it fails: A proper MySQL backup operation would normally be performed with mysqldump (creating logical SQL dumps) or with the mysqlbackup/Enterprise Backup tool (creating physical file snapshots). These utilities write to a controlled backup directory with a consistent format and usually record LSN coordinates or binary log positions for point-in-time recovery. In contrast, this record shows a bare SELECT INTO OUTFILE targeting /tmp/export.csv, which lacks the transactional consistency, file naming conventions, and access controls of a legitimate backup. Furthermore, legitimate backups are typically scheduled and performed by privileged service accounts, not as an ad hoc query in a user session.

A stored procedure execution

Why it fails: A stored procedure execution would appear in the query log as a CALL statement, such as CALL proc_name(args), or as a series of statements that comprise the procedure body. There is no CALL keyword and no procedure definition in this log entry; instead, it is a single, standalone SELECT statement with an INTO OUTFILE clause. Additionally, stored procedure executions do not directly produce output files unless the procedure itself contains an INTO OUTFILE, and this log shows the direct statement, not a procedure invocation.

A SQL injection attack using UNION

Why it fails: This query is not a UNION-based injection because it contains no UNION keyword, no subqueries with a UNION, and no evidence of SQL syntax breaking. UNION-based injection typically requires concatenating a second SELECT with different column counts, often using NULL placeholders to align types. The recovered statement is syntactically clean: it selects specific columns from customer_data and exports them to a file. Injection attacks would also be unlikely to target a file write; they usually focus on data retrieval via error messages, boolean responses, or timing, not INTO OUTFILE, which requires the FILE privilege.

The email is legitimate but routed through a different server

Why it fails: A legitimate email can pass through multiple MTAs, but any authorized relay path will still carry the original sender's DKIM signature and the final Received header will show a source IP covered by the sender's SPF record. The absence of DKIM and the IP mismatch contradict a benign relay, because even an alternate server in a different geographic location would authenticate for the original domain rather than presenting an unrelated IP. Thus the 'different server' theory does not hold.

The email was sent from a mobile device

Why it fails: The device used to compose a message does not affect the email's authentication headers, because mobile clients submit mail to a provider's outbound MTA that applies DKIM on behalf of the domain. A phone-sent email would therefore have a valid DKIM signature and an originating IP belonging to the provider's authenticated mail infrastructure. The IP mismatch in the Received header points to a forged or hijacked sending host, not to a mobile origin.

The email server is misconfigured

Why it fails: A misconfigured internal server might indeed omit DKIM signing, but it cannot cause the originating IP shown in the Received header to be outside the sender's domain's SPF-allowed ranges. Misconfiguration could explain missing authentication, yet it does not explain why the email's transmission path starts from an unauthorized IP, which is the hallmark of a spoofed envelope. In a forensic analysis, Occam's razor strongly favors deliberate spoofing over an unlikely sequence of configuration errors.

Delete the instance immediately

Why it fails: Deleting the instance immediately destroys the very evidence you are investigating: the ephemeral root volume (if not configured to persist) and any forensic artifacts on the ephemeral store vanish, and the instance's memory and process state are lost. AWS termination is not a reversible operation; a terminated instance's EBS volumes are typically deleted (unless the 'DeleteOnTermination' flag was changed), so you lose the ability to perform disk forensics, recover deleted data, or capture malware. Instead, the correct isolation step is to detach or snapshot the volumes and restrict network access, preserving the state while preventing further compromise.

Check the VPC flow logs for network traffic

Why it fails: VPC Flow Logs only record IP traffic metadata—such as source and destination addresses, ports, and byte counts—and reveal nothing about what actually executed on the instance, whether a malicious process is running, or what filesystem changes were made. They are also only useful if they were enabled and capturing data before and during the incident, so they may not even contain the relevant timeframe if logging was not already configured. While examining flow logs is a valuable later step for traceability, it does nothing to stop an active adversary or preserve volatile data, so it is not the immediate action.

Notify the user who launched the instance

Why it fails: The user recorded in CloudTrail who launched the instance is not necessarily an authorized actor—it could be an adversary who gained access to AWS credentials or IAM roles, and informing them gives the attacker the chance to destroy evidence, delete logs, or escalate privileges before you can collect forensic data. Even if the user is benign, notification is an operational decision that should follow your incident response and communication plan, not be made ad hoc during a forensic investigation. In every case, the priority is to preserve evidence and contain the incident, not to contact parties who may themselves be compromised or hostile.

docker diff

Why it fails: docker diff compares a container's filesystem against its base image, reporting added, deleted, or modified files (A/D/C). It reflects only runtime filesystem mutations that occurred after the container was started, not the sequence of build instructions or layers that defined the image. Therefore it cannot expose build history; it shows what changed in the container's writable layer, not how the image was constructed.

docker logs

Why it fails: docker logs retrieves the standard output and standard error streams generated by a container's primary process during runtime. It is a runtime diagnostic tool for application output and error messages, not a source of image metadata or layer information. Since images are immutable artifacts with no running process, docker logs has no connection to the build commands or layer history of an image.

docker inspect

Why it fails: docker inspect returns low-level JSON metadata for Docker objects such as containers, images, networks, or volumes. For images, it can show configuration details like environment variables, labels, exposed ports, and entrypoint, but it does not enumerate the ordered build instructions that generated each layer. The build history is stored separately in the image's configuration history array and is specifically surfaced by docker history, not by inspect.

A scheduled backup

Why it fails: A scheduled SQL Server backup uses the BACKUP DATABASE statement, which invokes the VDI interface to write database pages to a backup device; it never executes row-level DML such as INSERT against user tables. Backups copy the entire database or files, not target a specific sensitive table with INSERT operations. The presence of bulk INSERTs into CreditCards is therefore incompatible with a backup job, which would leave no DML artifacts in the transaction log.

A SQL injection attack on the database

Why it fails: A SQL injection attack typically manifests in the transaction log as SELECT statements or error messages from malformed input, such as UNION-based queries attempting to retrieve data. While stacked queries could theoretically issue INSERTs, the classic exfiltration signature is a series of SELECT or UNION SELECT queries, not repeated bulk INSERTs into the same sensitive table. Bulk INSERTing rows would require a separate payload to store or transfer data, and the observed behavior lacks the query patterns associated with injection.

Normal database maintenance

Why it fails: Normal database maintenance routines—such as rebuilding indexes, updating statistics, running DBCC CHECKDB, or shrinking files—do not generate INSERT statements against user tables like CreditCards. Maintenance tasks operate on metadata and internal structures, using commands like ALTER INDEX or UPDATE STATISTICS, not row-level data manipulation. If a maintenance job were involved, you would see system stored procedures (e.g., sp_updatestats) and no new rows in a sensitive credit card table.

VPC Flow Logs

Why it fails: VPC Flow Logs are network-level telemetry that record only the metadata of IP traffic—such as source/destination addresses, ports, protocol, packet and byte counts, and ACCEPT/REJECT decisions—transiting an Elastic Network Interface. They do not capture OS-level activities like shell commands, local process execution, or file system modifications. At most, flow logs could show a connection from the instance to the SSM endpoint, but that is a network artifact, not evidence of what the Systems Manager agent actually executed inside the guest OS.

EC2 instance metadata

Why it fails: EC2 instance metadata is a service accessible from within the instance (via 169.254.169.254 or IMDSv2) that provides configuration details such as AMI ID, instance ID, hostname, security groups, IAM role credentials, and user-data. While user-data can contain a bootstrap script that runs at launch, instance metadata does not record a historical log of commands executed by users or processes after boot. Therefore, examining instance metadata might reveal the instance's intended configuration, but it cannot reveal the actual command history or runtime actions of the analyst's target.

AWS CloudTrail logs

Why it fails: AWS CloudTrail records control-plane API calls made by principals, such as the SendCommand, RunInstances, or DescribeInstanceInformation operations invoked against the AWS Systems Manager API. CloudTrail proves that a command request was made, by whom, and when, but it does not contain the command's actual execution results, guest-OS output, or effects inside the instance. Thus, it is useful for establishing the chain of command, but it cannot substitute for the SSM Agent logs that capture what the instance itself actually executed.

The email originated from 203.0.113.5

Why it fails: SPF authentication verifies only that a particular SMTP client IP was listed in the SPF record for the Return-Path domain, not the original source of the email. The actual originating IP address must be traced through the 'Received: from' header chain, starting with the topmost received header, which likely shows a different client IP than 203.0.113.5. If 203.0.113.5 appears in the SPF record, it only indicates that server is an authorized sending relay, not the original MUA.

The email failed SPF check

Why it fails: The email's Authentication-Results header explicitly reports 'spf=pass' for the domain example.com, and the SPF check uses the SMTP MAIL FROM address against the domain's DNS TXT record. A 'pass' means the connecting IP was positively verified; a failed SPF check would produce 'fail', 'softfail', or 'permerror' instead. Therefore the assertion that SPF failed contradicts the direct header evidence and is factually incorrect.

The email is definitely legitimate

Why it fails: An SPF pass is only an authorization check for the envelope sender (MAIL FROM/Return-Path) and says nothing about the content, attachments, links, or whether the message was actually composed by the account owner. An attacker can pass SPF by abusing an authorized mail server or by choosing a domain they control, so SPF alone does not prove legitimacy. Additional corroborating evidence is required, particularly DKIM signatures and a DMARC policy of p=reject, along with content analysis, before classifying the email as legitimate.

docker cp <container_id>:/path /host/path

Why it fails: docker cp is a file-copy utility that extracts a single specified path from a container's writable layer, not a complete forensic image. It only retrieves the exact files or directories named on the command line, so it omits the read-only image layers, deleted inodes, and other runtime data needed for a thorough investigation. Even if the container is live, this selective copy cannot be hashed as a single coherent artifact or used to reconstruct the full filesystem state.

docker save <image_id> -o output.tar

Why it fails: docker save <image_id> -o output.tar exports the image metadata and its immutable layers, not any files that were written when the container ran. Using this command would capture only the blueprint used to create the container, missing all runtime modifications, temporary files, and container-specific configuration. For a container-level investigation, the analyst needs the container’s current filesystem, which docker export provides, not the underlying image's layer set.

docker commit <container_id>

Why it fails: docker commit <container_id> packages the container's current writable layer on top of its base image to produce a new image, which is a packaging operation unsuited to forensic preservation. It can alter container state or create an inconsistent snapshot if the container is running, and the resulting output is a new image rather than a flattened, forensically sound archive. This method also does not preserve the exact runtime filesystem in a way that can be verified and analyzed independently of Docker.

Aid4Mail

Why it fails: Aid4Mail is a comprehensive email migration and conversion utility, but its native file support centers on PST, EML, MBOX, and cloud mailbox formats, not the offline OST container used by Outlook in cached Exchange mode. To process an OST, an analyst would first have to reconstruct or access the associated Exchange profile and export the data to PST, an extra step that changes the artifact and may lose unsynced or deleted items. Therefore it is not a direct OST extraction tool for this forensic scenario.

EmailTracker Pro

Why it fails: EmailTracker Pro is designed to analyze the routing and authentication metadata inside individual email headers, such as Received lines, SPF, DKIM, and DMARC results, to trace message provenance and possible geolocation. It does not parse or enumerate the contents of OST container files; it operates on email messages or header extracts already obtained from a mail store. Selecting it for raw OST artifact extraction confuses email header forensics with mailbox file carving and recovery.

MailXaminer

Why it fails: MailXaminer is a forensic email examination platform that primarily ingests PST files, along with other exported email formats, to perform indexing, searching, and reporting for eDiscovery; however, it lacks native read/write support for the OST store's internal replication engine and Offline Address Book structures. Analysts must convert an OST to PST through Outlook or a specialized converter before MailXaminer can process the data, which means it cannot directly extract email artifacts from the original OST evidence. Its wrongness is not just a format gap but an investigative workflow limitation that could compromise evidence integrity.

The DKIM signature is optional and can be ignored.

Why it fails: DKIM-Signature is not optional evidence for an investigator; if the header is present, it is an authentication mechanism that must be verified against the sender's public key. A failed DKIM verification indicates the message either was not signed by the claimed domain or has been altered since signing, so ignoring that result would allow a spoofed message to bypass scrutiny.

The recipient's email server does not support DKIM.

Why it fails: DKIM support is a property of the receiving mail server, not a property of the email itself. If the recipient's server did not support DKIM, it would simply ignore the DKIM-Signature header and perform no validation, resulting in no DKIM failure status. Since a failure was observed, the server did attempt to verify the signature, so the cause must be a signature mismatch or invalid DNS key, not lack of server support.

The email was encrypted and cannot be verified.

Why it fails: DKIM verification is independent of encryption: the digital signature covers canonicalized message content and is verified after transport decryption, so TLS or end-to-end encryption does not prevent the receiving server from checking it. A DKIM failure cannot be explained by encryption because encryption would not change the cryptographic relationship between the signature and the signed content. The failure therefore stems from an invalid signature, content modification, or a DNS lookup/key issue, not from encryption.

The 'From' header domain matches the 'Return-Path' domain

Why it fails: While a mismatch can be a clue, a match does not rule out spoofing because attackers can forge the From header to match the Return-Path or use domains they control. For example, if an attacker owns a lookalike domain or uses a compromised mailbox, both headers may align. Therefore, consistency between these fields is not a reliable indicator of legitimacy; it only indicates that the visible sender and the envelope sender are the same, which can still be spoofed.

The 'DKIM-Signature' header validates successfully

Why it fails: A valid DKIM signature proves that the message body and certain headers were signed by a key published in the signing domain's DNS. However, it does not authenticate the human-visible From address unless the signature's 'd=' domain aligns with that address, and even then an attacker can sign using their own domain if they control it. Successful validation alone is a sign of integrity and origin of the signing domain, but it does not prevent spoofing of the From header when the signature is from a different or unrelated domain.

The 'Message-ID' header contains the sender's IP address

Why it fails: The Message-ID header is a globally unique identifier typically formatted as a long random string followed by a domain, such as '<unique-timestamp@example.com>', and it does not embed IP addresses. It is generated by the sending mail client or server to aid in threading and tracking messages, and it neither contains nor exposes the sender's IP address. Therefore, its presence or format cannot be used as an indicator of spoofing.

Perform a memory dump of the server and search for the base64 string

Why it fails: A memory dump captures volatile data such as running processes and network connections, but the base64 string in the Apache log is a static artefact already stored on disk, not a process in memory. This approach is tempting because memory forensics can reveal active webshell execution traces like process listings or socket states, which would confirm execution in a scenario where the log entry alone was ambiguous. However, here the log itself documents the HTTP request, so the correct method is to verify the webshell’s residual file on the filesystem or its execution via audit logs, not to search memory for the encoded request string.

Analyze the MySQL transaction logs for any database queries triggered by the webshell

Why it fails: MySQL transaction logs would only contain evidence if the webshell's payload actually performed database queries, but the 'cmd' parameter indicates remote code execution via a shell command, not SQL injection. Database logs do not record PHP process invocations or system commands sent to the operating system shell, so they are completely orthogonal to confirming execution of the webshell. Even if the webshell had interacted with the database, those logs would only show the queries, not the PHP code that triggered them, leaving the execution itself unconfirmed.

Search for the decoded PHP code in the web server's document root

Why it fails: Searching for the decoded PHP code in the web server's document root may locate the webshell file, but its presence only proves the file was written to disk, not that it was executed. The Apache log entry already documents the HTTP request with the 'cmd' parameter; to confirm execution, you need evidence that the PHP interpreter actually ran the code, which process accounting captures via 'execve' events. The decoded code is a static artifact that could have been uploaded but never invoked, or could be a decoy planted by the attacker, so finding it does not provide dynamic execution proof.