Application, Email and Cloud Forensics practice questions

Cross-site scripting (XSS)

Why wrong: The log entry contains SQL UNION syntax, whereas XSS payloads rely on script tags, event handlers like onerror, or javascript: URIs that execute in the victim's browser. XSS attacks target client-side interpretation of dynamic HTML, not the server-side database query. A UNION SELECT clause is a structured query language operation that fuses result sets from the database, which has no effect on raw HTML rendering. Therefore, the observed payload does not match the injection pattern expected for cross-site scripting.

Path traversal

Why wrong: Path traversal typically constructs sequences such as ../../etc/passwd or encoded variants like %2e%2e%2f to escape the webroot and read arbitrary files. The apache log entry cited here does not contain any dot-dot-slash or similar traversal pattern; it contains the SQL keyword UNION SELECT. Path traversal manipulates file path strings used by file system functions, while UNION SELECT manipulates a database query. Hence the attack is not a path traversal.

Remote file inclusion

Why wrong: Remote File Inclusion requires the attacker to supply an external resource URL, e.g., http://evil.com/shell.txt or ftp://attacker/payload, in a parameter that is passed to an include function such as PHP's include() or require(). The log entry shows no URL scheme or external host; the payload is SQL syntax. RFI seeks to execute a remotely hosted script on the web server, whereas UNION SELECT merely extends an SQL result set to extract database content. The absence of any URI-based payload rules out RFI.

The email was sent on a weekend

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: `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.

VPC Flow Logs

Why wrong: VPC Flow Logs capture network traffic metadata, such as source and destination IP addresses, ports, and packet counts, for traffic flowing through your VPC. They do not log API calls or user actions at the management plane level, so they cannot reveal which principal issued a DeleteBucket command. While they may be useful for analyzing data exfiltration after a breach, they are irrelevant for identifying the API call itself.

Amazon S3 access logs

Why wrong: Amazon S3 access logs record object-level requests made to an S3 bucket, such as GET, PUT, and DELETE operations on individual objects. They do not include management API calls like DeleteBucket, which operates on the bucket itself rather than on an object within it. Even if server access logging is enabled, it will not show the bucket deletion event or the identity of the caller; that information resides only in CloudTrail.

AWS Config

Why wrong: AWS Config is a service that continuously records and evaluates resource configuration changes, and it can show the resulting state of a resource after a change (for example, that a bucket was removed). However, it does not log the API call that caused the change, nor does it record the identity of the principal who made the call. AWS Config is designed for compliance and configuration tracking, not for providing an audit trail of API activity, so it cannot answer 'who deleted the bucket and when'.

Wireshark

Why wrong: 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 wrong: 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 wrong: 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.

Server-side request forgery (SSRF)

Why wrong: SSRF makes the server send requests, not execute commands.

SQL injection

Why wrong: SQLi targets database queries, not file uploads.

Cross-site request forgery (CSRF)

Why wrong: CSRF tricks a user into performing actions; it doesn't involve server-side backdoor files.

DB Browser for SQLite

Why wrong: 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 wrong: 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 wrong: 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.

Azure Monitor Metrics

Why wrong: Azure Monitor Metrics stores only numerical time-series data (e.g., failed sign-in counts, CPU load) that is pre-aggregated and sampled. It does not retain individual authentication events, so it lacks the raw details needed to investigate a specific user's sign-in, including IP addresses, timestamps, and failure reasons. While you might see a metric spike in failed sign-ins, you cannot drill down to the underlying log entries, making it unsuitable as a source for sign-in investigation.

Azure Activity Logs

Why wrong: Azure Activity Logs (also known as the Azure Monitor activity log) capture control-plane events for Azure resources, such as resource creation, deletion, or configuration changes (e.g., 'create virtual machine' or 'update network security group'). They do not capture user authentication or sign-in events at all. Even though an attacker may later modify resources, the Activity Log would only show the resource-oriented operation after authentication, not the sign-in itself, so it cannot answer 'who signed in and did they succeed'.

Azure Security Center alerts

Why wrong: Azure Security Center (now part of Microsoft Defender for Cloud) generates high-level security alerts by correlating signals from multiple sources, including sign-in logs, but it does not expose the raw sign-in log entries. These alerts are derived, curated findings like 'impossible travel activity' or 'anonymous IP sign-in', which may omit the full set of user IPs, timestamps, and statuses required for a thorough forensic review. Relying solely on Security Center alerts would miss individual sign-in events that did not trigger a detection rule, making it incomplete for a user-level authentication investigation.

Audit log

Why wrong: Audit logs are security-focused records that capture events such as user authentications, privilege changes, and data access attempts, often for compliance purposes. However, they do not inherently record every transaction; their scope depends on configurable audit policies, and many database systems only log specific actions or queries that match predefined rules. Therefore, while an audit log can contain transaction information, it is not guaranteed to provide a complete, sequential record of every data modification.

Error log

Why wrong: Error logs record only exceptional conditions and system-level failures, such as internal errors, failed startup attempts, corrupted table events, or connection problems. They are not designed to track successful data manipulation operations like INSERT, UPDATE, or DELETE statements. Since normal transactions do not generate error entries, an error log fails to provide a record of each transaction and is therefore unsuitable for complete transaction logging.

Slow query log

Why wrong: Slow query logs are performance-tuning utilities that only record statements whose execution time exceeds a configurable threshold, such as long_query_time in MySQL. Fast-running transactions are completely omitted, and even slow SELECT statements may be logged, meaning the log is not a complete or accurate representation of all data modifications. Its purpose is to identify bottlenecks, not to provide a transactional audit trail, so it cannot satisfy the requirement of recording every transaction.

Cross-site scripting

Why wrong: Wrong because the logged payload lacks HTML or JavaScript context; XSS requires injecting executable script that is reflected or rendered in the browser, and the payload contains only path traversal sequences with no script tags, event handlers, or encoded JavaScript. The IIS log shows a request for a directory-like resource rather than a parameter being echoed, and nothing in the request indicates a browser-side script execution vector.

SQL injection

Why wrong: Wrong because the log entry contains no SQL metacharacters or keywords such as a single quote, UNION, SELECT, OR 1=1, or a semicolon, which are necessary for SQL injection in the URI or POST body. A path traversal attempt uses ../ sequences in the URL path, not query-string syntax that would reach a database query, and there is no accompanying SQL error or delay signature to suggest an injection attempt against the backend.

Remote code execution

Why wrong: Wrong because the HTTP 404 status indicates that the requested file or script was not found, so no server-side executable was invoked and no code ran on the target. Remote code execution would require evidence of a successful exploit against a vulnerable parser or command injection point, but this log only shows a failed request for a directory path with no output, no status code like 200, and no subsequent behavior indicating a shell or command was executed.

VPC Flow Logs

Why wrong: VPC Flow Logs capture only IP traffic metadata at the elastic network interface level, recording fields such as source/destination IP addresses, ports, protocol, packets, and bytes for allowed or rejected network flows. They do not log the identity of the AWS principal, the API operation name, or user agent, so they cannot reveal which user invoked a specific cloud API call or the origin of that API request in terms of IAM credentials.

Amazon Inspector findings

Why wrong: Amazon Inspector is a vulnerability management service that performs automated security assessments of workloads, scanning for software vulnerabilities (CVEs), unintended network exposure, and deviations from security best practices. Its findings are asset-centric and describe security weaknesses or compliance failures, not audit records of API activities. Consequently, Inspector cannot provide the caller identity or source IP for cloud management API calls, which is what a forensic analyst needs to attribute actions.

AWS Config

Why wrong: AWS Config primarily tracks configuration changes to AWS resources over time, maintaining a resource inventory and configuration history, and can assess compliance against custom or managed rules. While it can tell you what resource attribute changed (e.g., a security group rule was modified) and sometimes which API call caused it via integrated CloudTrail events, it does not independently capture the source IP address, IAM user/role, or user agent of the API requester. Its core purpose is configuration state and compliance, not a detailed trail of API call origin.

Inability to collect memory dumps

Why wrong: 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 wrong: 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 wrong: 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.

The DKIM signature hash

Why wrong: The DKIM signature hash is not part of the Received header chain; it is carried in the DKIM-Signature header field using tags like bh= and b=. While it provides cryptographic authentication of the message body and selected headers, it does not reveal routing metadata. To locate it, an investigator must parse the DKIM-Signature header, not the trace headers that show server relays.

The sender's email client version

Why wrong: The sender's email client version is not recorded in the Received headers. User agents typically identify themselves in an optional X-Mailer header (e.g., 'Microsoft Outlook 16.0'), but this header is not added by mail servers and can be omitted or spoofed. Received headers, by contrast, contain MTA software details and connection parameters, not the sender's desktop or webmail client version.

The subject line of the email

Why wrong: The Subject line is a message header that describes content, but it is not included in the Received header trace. Received headers are added by each SMTP server as the message is relayed, and they contain transport-level information, not content metadata. Moreover, the Subject may be rewritten by mailing lists or client-side rules, so it is not a reliable artifact for analyzing the server-to-server delivery path.

Abnormal HTTP methods like OPTIONS or TRACE

Why wrong: OPTIONS and TRACE are HTTP methods used for server capability discovery and diagnostics. While attackers may use them for reconnaissance or to exploit cross-site tracing vulnerabilities, they are not a reliable indicator of webshell activity because webshells typically rely on GET or POST requests that carry command parameters. The presence of OPTIONS or TRACE alone does not suggest a webshell is present.

High volume of traffic from a single IP

Why wrong: A high volume of traffic from a single IP address is a generic symptom of many attack patterns, including port scanning, denial-of-service, or credential stuffing. Webshell usage, in contrast, often produces only a small number of targeted requests from the attacker's IP, because the attacker is executing commands through the compromised page. Thus, while volume might warrant investigation, it is not a specific indicator of a webshell.

Frequent 404 errors for non-existent pages

Why wrong: Frequent 404 errors are typical results of directory brute-forcing, vulnerability scanning, or users following stale links, and they occur continuously across both benign and malicious traffic. A web shell, once uploaded, resides at a specific path and would generate successful responses (200) when invoked, not a stream of missing-page errors. Therefore, an abundance of 404s is not evidence of webshell compromise.

Cross-site scripting (XSS)

Why wrong: XSS typically involves script tags or JavaScript in the request, not SQL syntax.

Remote file inclusion

Why wrong: RFI uses URLs to include remote files, not SQL syntax.

Path traversal

Why wrong: Path traversal uses '../' sequences to access files outside web root.

Message-ID

Why wrong: 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 wrong: 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 wrong: 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.

docker commit

Why wrong: docker commit is for creating a new image from a container's current state, capturing the writable layer on top of the base image as a new image in the local image store. It preserves image metadata, history, and configuration, so the result is still a Docker image, not a flat filesystem archive. Unlike docker export, it does not produce a standalone tar of the container's filesystem and requires docker load or a registry push to move it elsewhere.

docker cp

Why wrong: docker cp copies individual files or directories between a container and the host filesystem using the container:path syntax. It is designed for selective file retrieval or injection, not for producing a complete snapshot of the container's filesystem. Even if you copy the entire root directory, the output is a copied directory tree, not a single portable tar archive, and it may not preserve every filesystem attribute such as hard links or extended metadata the way export does.

docker save

Why wrong: docker save serializes a Docker image into a tar archive, including all its layers, tags, and image configuration, for use with docker load. It operates on an image name or ID, not on a running or stopped container, so any changes stored in the container's writable layer are absent from the saved artifact. To capture runtime modifications, you would first need docker commit to freeze the container as a new image, whereas docker export directly gives you the modified filesystem.

A SQL injection script

Why wrong: This artifact cannot be a SQL injection script because it contains no SQL syntax and performs no database interaction. SQL injection scripts exploit flawed query construction by submitting crafted input to a web application's database layer; they rarely exist as an uploaded file on the target server. The discovered file instead accepts HTTP parameters and passes them to OS command execution functions, which is the hallmark of a web shell, not a SQL-based attack tool.

A file upload vulnerability exploit

Why wrong: A file upload vulnerability exploit is the technique or tool that subverts upload validation to place an arbitrary file, whereas the discovered artifact is the file placed by such an exploit. In other words, the webshell is the payload, not the exploit itself. Identifying it as a file-upload exploit confuses the attack stage with the malicious entity found on the server; the artifact's own behavior, executing commands via HTTP, distinguishes it.

A backdoor trojan

Why wrong: Calling this a backdoor trojan is technically misleading because a trojan is usually a standalone executable or appended payload that creates a covert channel, whereas the artifact is a server-side script running inside the web server process. It does function as a backdoor, but the term is too broad to capture the specific HTTP-request-based, parameter-driven command execution mechanism. The precise classification for a script that offers an interactive command line over HTTP is 'web shell'.

sourceIPAddress

Why wrong: `sourceIPAddress` records the IP address from which the request was made, but it does not reveal the IAM principal. An IP can be shared by multiple users (e.g., behind NAT, a bastion host, or VPC endpoint) and can be spoofed or represent an AWS service, so it cannot reliably attribute the action to a specific identity.

eventSource

Why wrong: `eventSource` identifies the AWS service that the API call targeted (e.g., `ec2.amazonaws.com`, `s3.amazonaws.com`), not the user who invoked it. While useful for understanding which service's APIs were called during an incident, it provides no information about the IAM user, role, or account that performed the action, and thus cannot answer 'who did this?'.

requestParameters

Why wrong: `requestParameters` contains the input parameters of the API request (such as bucket names, object keys, or instance IDs), which describe the specific resource acted upon. This helps answer 'what did they access?' but says nothing about the caller's identity. Even a full request body without the principal context leaves the actor unknown, so it is not the field for identity resolution.

Wireshark

Why wrong: Wireshark is a network protocol analyzer that captures and decodes packets in transit, such as SMTP, IMAP, and HTTP traffic. It is not designed to parse the internal structure of a Microsoft Outlook PST file, which is a proprietary database of emails, calendar items, and attachments stored on disk. Even if a network stream contained an email, Wireshark would show the raw wire format — not the PST's internal B-tree, node, and block layout. Therefore, it is fundamentally unsuitable for extracting mail items from a PST artifact.

EmailTracker

Why wrong: EmailTracker is a specialized tool for analyzing email headers after an email has been extracted; it traces the email's routing path through Received headers, identifies originating IP addresses, and performs geolocation. It does not parse the layered PST structure (which includes a header, node database, block database, and MAPI property trees) to enumerate folders and messages. For forensic extraction of complete emails, attachments, and metadata from a PST, a dedicated parser like Aid4Mail is required. EmailTracker is only a follow-up for header analysis once messages are already exported.

Sleuth Kit

Why wrong: The Sleuth Kit is a suite of command-line utilities for file system and disk forensics — it examines disk images, recovers deleted files, and parses metadata from file systems like NTFS and ext4. A PST file is merely an individual data file residing within a file system; Sleuth Kit can locate or carve the PST from unallocated space, but it cannot interpret the PST's internal database format, such as the folder hierarchy, message objects, or attachment records. Without understanding the PST's proprietary B-tree indexing, the tool cannot reveal emails or their metadata, making it a generic file system tool rather than an email parser.