CHFI Application, Email and Cloud Forensics Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Network packet captures from the container's virtual interface

  Why it's wrong here

  Relying on network packet captures from a container's virtual interface (veth pair) is usually impractical after the fact because traffic capture must be running before or during the incident; once the container stops or is removed, the interface is destroyed and any unrecorded packets are gone. Even if a packet capture existed, it would only expose network communications, leaving invisible local forensic evidence such as filesystem modifications, process creation, and container runtime control actions. This makes it a supplementary source, not a definitive artifact for confirming malicious activity.

• ✓

  Host system audit logs

  Why this is correct

  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

  Why this is correct

  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)

  Why this is correct

  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.

• ✗

  The Dockerfile used to build the image

  Why it's wrong here

  A Dockerfile is a build-time blueprint, not a runtime artifact, so it cannot prove what the container actually executed or what was changed after the image was built. It is often missing from disk, may not match the deployed image due to build contexts or ARG values, and can be retroactively modified to conceal malicious intent. Even a pristine-looking Dockerfile is weak evidence because malware can be injected at runtime via docker exec, mounted volumes, or environment variables, none of which leave traces in the file.

Go deeper

Related to this question