How should I use these Network and Cloud Forensics practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Network and Cloud Forensics questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Network and Cloud Forensics domain.

CHFI · topic practice

Network and Cloud Forensics practice questions

This domain covers collecting and analyzing evidence from networks and cloud environments: packet capture, volatile data, virtual machine memory acquisition, and cloud audit logs. Questions test forensically sound procedures, what artifacts each source yields, and how to preserve evidence so it stays admissible. Expect scenario items on PCAP analysis, cloud log anomalies, and proper order of volatility.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

20 questionsDomain: Network and Cloud Forensics

Practice 10 questions Browse domain →

What the exam tests

What to know about Network and Cloud Forensics

Be able to select the right tool and method for capturing network or cloud evidence while preserving integrity. The single most important thing: follow the order of volatility and document chain of custody, because improperly captured or unhashed evidence is easily challenged and excluded.

Extracting IPs, ports, protocols, and payloads from PCAP files using Wireshark or tcpdump filters

Capturing volatile network data with tools like tcpdump, Wireshark, and NetFlow before it is lost

Acquiring virtual machine memory in cloud environments using hypervisor snapshots or memory capture tools

Reviewing cloud provider audit logs such as AWS CloudTrail for unauthorized access and credential misuse

Watch out for

Common Network and Cloud Forensics exam traps

▸Assuming a PCAP contains full application content when traffic was encrypted, so only metadata like IPs and ports is recoverable
▸Treating a live VM snapshot as a memory dump; snapshots capture disk state, not necessarily volatile RAM contents
▸Pulling cloud logs without preserving chain of custody or hashing, weakening admissibility of the evidence later

Practice set

Network and Cloud Forensics questions

20 questions · select your answer, then reveal the explanation

Question 1hardmultiple choice

Read the full Network and Cloud Forensics explanation →

A forensic analyst is investigating a network breach and finds that the attacker used a technique that bypasses Network Access Control (NAC). Which of the following methods is commonly used to evade 802.1X authentication?

Trap 1: VLAN hopping using double tagging

VLAN hopping via double tagging is incorrect for this scenario because the attack exploits an improperly configured trunk port to send frames with two 802.1Q tags, causing the switch to forward them into an unintended VLAN. It targets network segmentation and VLAN isolation, but it operates after an endpoint has already gained admission to the LAN; it does not alter the 802.1X/NAC authentication process itself. Thus it cannot bypass the authentication requirement.

Trap 2: DNS tunneling to exfiltrate data

DNS tunneling is wrong because it is a data exfiltration and command-and-control technique that embeds payloads within DNS queries and responses to slip through egress filtering. While DNS is often allowed through firewalls, the tunnel establishes an encoded or encrypted channel only after the attacker already has a foothold on an authenticated host or network segment. It does not authenticate the attacker to the NAC/802.1X edge and therefore cannot be used to bypass the initial access control.

Trap 3: ARP poisoning to redirect traffic

ARP poisoning is incorrect because it manipulates the IP-to-MAC mapping in the target's ARP cache by sending forged ARP replies, placing the attacker in the middle of the traffic flow on the same broadcast domain. This is a post-admission, Layer 2 man-in-the-middle attack that assumes the attacker is already connected to the authenticated switching port or VLAN; it does not modify the 802.1X or MAC-based authentication state. Consequently, ARP poisoning cannot bypass the NAC's port-based authentication, unlike MAC spoofing.

Study all Network and Cloud Forensics common traps →

A
MAC address spoofing
MAC address spoofing is correct because many 802.1X implementations enable MAC Authentication Bypass (MAB) or trust the device's MAC address as the Layer 2 identity for NAC port control. An attacker who clones an authorized device's MAC address (e.g., using macchanger or NIC driver settings) can trick the authenticator into treating the rogue device as legitimate, thereby gaining authenticated network access without valid user credentials. This directly bypasses the NAC/802.1X authentication decision.
B
VLAN hopping using double tagging
Why it fails: VLAN hopping via double tagging is incorrect for this scenario because the attack exploits an improperly configured trunk port to send frames with two 802.1Q tags, causing the switch to forward them into an unintended VLAN. It targets network segmentation and VLAN isolation, but it operates after an endpoint has already gained admission to the LAN; it does not alter the 802.1X/NAC authentication process itself. Thus it cannot bypass the authentication requirement.
C
DNS tunneling to exfiltrate data
Why it fails: DNS tunneling is wrong because it is a data exfiltration and command-and-control technique that embeds payloads within DNS queries and responses to slip through egress filtering. While DNS is often allowed through firewalls, the tunnel establishes an encoded or encrypted channel only after the attacker already has a foothold on an authenticated host or network segment. It does not authenticate the attacker to the NAC/802.1X edge and therefore cannot be used to bypass the initial access control.
D
ARP poisoning to redirect traffic
Why it fails: ARP poisoning is incorrect because it manipulates the IP-to-MAC mapping in the target's ARP cache by sending forged ARP replies, placing the attacker in the middle of the traffic flow on the same broadcast domain. This is a post-admission, Layer 2 man-in-the-middle attack that assumes the attacker is already connected to the authenticated switching port or VLAN; it does not modify the 802.1X or MAC-based authentication state. Consequently, ARP poisoning cannot bypass the NAC's port-based authentication, unlike MAC spoofing.

Full breakdown with real-world context →

Question 2hardmultiple choice

Read the full Network and Cloud Forensics explanation →

An organization uses a cloud-based SIEM to collect logs from multiple sources. The investigator notices gaps in the log data for a critical system during the incident timeframe. What is the MOST likely cause?

Trap 1: Network latency delayed log delivery

Network latency introduces end-to-end delay between log generation and ingestion, but reliable transports such as TCP/TLS with buffered agents guarantee eventual delivery. Even if logs arrive seconds or minutes late, they retain their original timestamps and are still searchable, so the SIEM shows a delayed event, not an absent one. A true gap in coverage would require total loss or rejection of messages, which simple network latency does not cause.

Trap 2: Log rotation policy deleted logs prematurely

A log rotation policy typically deletes or archives the oldest log files based on age or size, affecting historical records from the earliest period rather than carving out a specific window mid-incident. If rotation occurred before forwarding, the SIEM would miss the oldest data, not a random gap, and if forwarding already happened, deletion on the source has no effect on the SIEM. Premature rotation can cause data loss, but it cannot explain a narrow, time-localized absence of logs that aligns with clock-time gaps.

Trap 3: The system's log level was set to ERROR only

Setting the log level to ERROR only suppresses informational, warning, and debug events, which drastically reduces volume but does so uniformly across all time periods. The system would continue to generate error-level entries throughout the incident, so any gap in the SIEM would reflect the absence of those lower-severity logs, not a specific hole in a timeline. A uniform reduction in verbosity cannot produce a single, isolated discontinuity in log coverage; it changes the entire character of the data, not a particular interval.

Study all Network and Cloud Forensics common traps →

A
Network latency delayed log delivery
Why it fails: Network latency introduces end-to-end delay between log generation and ingestion, but reliable transports such as TCP/TLS with buffered agents guarantee eventual delivery. Even if logs arrive seconds or minutes late, they retain their original timestamps and are still searchable, so the SIEM shows a delayed event, not an absent one. A true gap in coverage would require total loss or rejection of messages, which simple network latency does not cause.
B
Log rotation policy deleted logs prematurely
Why it fails: A log rotation policy typically deletes or archives the oldest log files based on age or size, affecting historical records from the earliest period rather than carving out a specific window mid-incident. If rotation occurred before forwarding, the SIEM would miss the oldest data, not a random gap, and if forwarding already happened, deletion on the source has no effect on the SIEM. Premature rotation can cause data loss, but it cannot explain a narrow, time-localized absence of logs that aligns with clock-time gaps.
C
Time drift between the system and the SIEM
Time drift between the system and the SIEM means the source device and the collector disagree on the current time, so events are stamped with timestamps that are skewed relative to the SIEM's clock. During correlation, the SIEM may place events outside the queried timeframe, causing them to appear missing, out of order, or duplicated, especially in a spike-and-drop incident timeline. NTP misconfiguration, unsynchronized virtual machines, or a device that reverts to a wrong local time can create precisely the kind of 'gap' an investigator sees when filtering on a strict time range.
D
The system's log level was set to ERROR only
Why it fails: Setting the log level to ERROR only suppresses informational, warning, and debug events, which drastically reduces volume but does so uniformly across all time periods. The system would continue to generate error-level entries throughout the incident, so any gap in the SIEM would reflect the absence of those lower-severity logs, not a specific hole in a timeline. A uniform reduction in verbosity cannot produce a single, isolated discontinuity in log coverage; it changes the entire character of the data, not a particular interval.

Full breakdown with real-world context →

Question 3easymulti select

Read the full Network and Cloud Forensics explanation →

Which TWO of the following are common challenges in cloud forensics?

Trap 1: All cloud environments provide the same forensic capabilities

This is incorrect because cloud forensic capabilities are not standardized; they vary drastically across providers. Some providers offer comprehensive APIs, detailed audit logs, and native forensic imaging, while others provide only basic exports or limited event history. Even within one provider, capabilities differ by service model (IaaS vs. SaaS) and subscription tier, so assuming uniform functionality is unfounded.

Trap 2: Easier evidence acquisition compared to traditional forensics

Cloud forensics faces more challenges than traditional forensics, not fewer — investigators depend on the provider's tooling and APIs for acquisition, and jurisdictional data spread adds legal complexity that has no equivalent in a device sitting in front of you.

Trap 3: Physical access to the hard drive is always available

This is wrong because cloud infrastructure is remote, virtualized, and often shared among tenants, making physical seizure of a hard drive practically impossible. Investigators would need legal authorization across multiple jurisdictions and the provider's cooperation just to locate the exact physical media, let alone access it. In practice, cloud forensics relies on logical acquisition methods such as API-based snapshots or storage layer copies, not on direct physical examination.

Study all Network and Cloud Forensics common traps →

A
Jurisdictional and legal issues due to data stored in multiple regions
This is a correct challenge because cloud providers often replicate data across multiple data centers in different countries, making a single investigation subject to conflicting legal frameworks. For example, the EU's GDPR restricts cross-border data transfers, while the US CLOUD Act can compel disclosure, forcing investigators to navigate international mutual legal assistance treaties before accessing evidence. This jurisdictional complexity can significantly delay or even block forensic acquisition.
B
All cloud environments provide the same forensic capabilities
Why it fails: This is incorrect because cloud forensic capabilities are not standardized; they vary drastically across providers. Some providers offer comprehensive APIs, detailed audit logs, and native forensic imaging, while others provide only basic exports or limited event history. Even within one provider, capabilities differ by service model (IaaS vs. SaaS) and subscription tier, so assuming uniform functionality is unfounded.
C
Reliance on the cloud provider's APIs for data acquisition
This is a correct challenge because investigators cannot physically access cloud storage and must instead rely on provider-controlled APIs for data acquisition. These APIs often impose rate limits, lack certain metadata fields, and require broad permissions, which can hinder the completeness and authenticity of collected evidence. Additionally, API responses may be dynamically generated snapshots rather than raw disk images, adding a layer of abstraction that complicates forensic analysis.
D
Easier evidence acquisition compared to traditional forensics
Why it fails: Cloud forensics faces more challenges than traditional forensics, not fewer — investigators depend on the provider's tooling and APIs for acquisition, and jurisdictional data spread adds legal complexity that has no equivalent in a device sitting in front of you.
E
Physical access to the hard drive is always available
Why it fails: This is wrong because cloud infrastructure is remote, virtualized, and often shared among tenants, making physical seizure of a hard drive practically impossible. Investigators would need legal authorization across multiple jurisdictions and the provider's cooperation just to locate the exact physical media, let alone access it. In practice, cloud forensics relies on logical acquisition methods such as API-based snapshots or storage layer copies, not on direct physical examination.

Full breakdown with real-world context →

Question 4mediummulti select

Read the full Network and Cloud Forensics explanation →

Which THREE of the following are essential steps in network forensic investigation?

Trap 1: Conduct interviews with all network users

Interviews with users solicit subjective accounts, but network forensics must rest on objective, machine-generated evidence such as packet captures, firewall logs, and NetFlow records. Human recollections are prone to error and cannot replace the need to inspect actual timestamped network artifacts, so conducting interviews with all users is not technically an essential network forensic step.

Trap 2: Perform a bit-for-bit copy of all hard drives

Performing a bit-for-bit copy of hard drives is a core step in disk forensics, but it does not capture the dynamic, transient data that characterizes network evidence such as packets, sockets, and routing state. Even imaging a network device's disk would miss live traffic and ephemeral connection contexts, so it is not an essential step in network forensics.

Study all Network and Cloud Forensics common traps →

A
Conduct interviews with all network users
Why it fails: Interviews with users solicit subjective accounts, but network forensics must rest on objective, machine-generated evidence such as packet captures, firewall logs, and NetFlow records. Human recollections are prone to error and cannot replace the need to inspect actual timestamped network artifacts, so conducting interviews with all users is not technically an essential network forensic step.
B
Create a timeline of network events
Constructing a timeline of network events is essential because it correlates timestamps from disparate sources — packet captures, authentication logs, proxy logs, and IDS alerts — into a coherent sequence. A normalized timeline lets investigators reconstruct the intrusion chain, identify lateral movement, and distinguish root cause from effect, which is foundational to network forensic analysis.
C
Secure the network to prevent further damage
Securing the network, including isolating compromised systems and tightening firewall rules, is a prerequisite for preserving volatile evidence and halting ongoing attacker activity. Without containment, packet buffers and connection state tables can be overwritten and the current evidence set can be contaminated, making later forensic reconstruction unreliable; it is therefore an essential preservation step.
D
Perform a bit-for-bit copy of all hard drives
Why it fails: Performing a bit-for-bit copy of hard drives is a core step in disk forensics, but it does not capture the dynamic, transient data that characterizes network evidence such as packets, sockets, and routing state. Even imaging a network device's disk would miss live traffic and ephemeral connection contexts, so it is not an essential step in network forensics.
E
Capture network packets using a sniffer
Capturing network packets with a sniffer is essential because traffic on the wire is extremely volatile and is destroyed the moment the investigation begins unless it is collected in real time. Tools like tcpdump or Wireshark in promiscuous mode, deployed via taps or SPAN ports, preserve the actual data exchanged between hosts, making packet capture the foundation of network forensic evidence.

Full breakdown with real-world context →

Question 5hardmulti select

Read the full Network and Cloud Forensics explanation →

Which TWO of the following are effective methods for detecting a man-in-the-middle attack on a network?

Trap 1: Analyze DNS amplification traffic

DNS amplification is a reflection-based attack that exploits open recursive resolvers to flood a victim with UDP traffic, causing denial of service. Such volumetric traffic analysis is suited for detecting DDoS attacks, not the targeted, often low-noise identity-spoofing of a man-in-the-middle. In MITM scenarios, the attacker does not need to saturate bandwidth; instead they intercept and modify individual packets. Therefore, analyzing DNS amplification traffic is ineffective for MITM detection.

Trap 2: Implement port knocking for access control

Port knocking is a covert access control mechanism where a server only opens a port after receiving a predefined sequence of connection attempts. It is an authentication-enforcement technique, not a detection technique; it cannot observe or alert on an ongoing man-in-the-middle attack. Even with port knocking in place, an attacker who gains access or intercepts traffic remains undetected. Thus it is not an effective method for detecting MITM.

Trap 3: Detect ICMP flood attacks

An ICMP flood attack, such as a ping flood or Smurf attack, aims to exhaust system resources or saturate network bandwidth; it is a denial-of-service technique. Its detection relies on volume thresholds and resource monitoring, not on verifying the identity or integrity of a communication path. A MITM does not typically generate a measurable flood; it silently sits in the data path. Therefore, detecting ICMP floods is irrelevant to MITM detection.

Study all Network and Cloud Forensics common traps →

A
Analyze DNS amplification traffic
Why it fails: DNS amplification is a reflection-based attack that exploits open recursive resolvers to flood a victim with UDP traffic, causing denial of service. Such volumetric traffic analysis is suited for detecting DDoS attacks, not the targeted, often low-noise identity-spoofing of a man-in-the-middle. In MITM scenarios, the attacker does not need to saturate bandwidth; instead they intercept and modify individual packets. Therefore, analyzing DNS amplification traffic is ineffective for MITM detection.
B
Check for SSL certificate mismatches
In a typical MITM attack on TLS, the attacker presents a forged certificate because they cannot possess the genuine private key, causing certificate mismatches such as wrong hostname, untrusted CA, or broken chain. Monitoring these mismatches—through certificate pinning, CAA records, or proper chain validation—can reliably reveal interception attempts. Since a valid certificate cannot be forged without the key, this is a strong and effective MITM detection method.
C
Implement port knocking for access control
Why it fails: Port knocking is a covert access control mechanism where a server only opens a port after receiving a predefined sequence of connection attempts. It is an authentication-enforcement technique, not a detection technique; it cannot observe or alert on an ongoing man-in-the-middle attack. Even with port knocking in place, an attacker who gains access or intercepts traffic remains undetected. Thus it is not an effective method for detecting MITM.
D
Monitor for ARP cache poisoning
ARP cache poisoning directly corrupts the IP-to-MAC mapping on a victim's machine, allowing the attacker to receive frames destined for the gateway or another host. By monitoring ARP tables for duplicates, sudden mapping changes, or unusual MAC addresses—using tools like Arpwatch—an analyst can spot an active MITM interception on a local network. This focuses on layer-2 trust and is a precise, practical detection method.
E
Detect ICMP flood attacks
Why it fails: An ICMP flood attack, such as a ping flood or Smurf attack, aims to exhaust system resources or saturate network bandwidth; it is a denial-of-service technique. Its detection relies on volume thresholds and resource monitoring, not on verifying the identity or integrity of a communication path. A MITM does not typically generate a measurable flood; it silently sits in the data path. Therefore, detecting ICMP floods is irrelevant to MITM detection.

Full breakdown with real-world context →

Question 6hardmultiple choice

Read the full Network and Cloud Forensics explanation →

An investigator finds the above IAM policy attached to an S3 bucket. What is the security concern?

Exhibit

Refer to the exhibit.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

Trap 1: The resource does not include all objects

This is incorrect because the resource ARN in the policy ends with '/*', which is the S3 wildcard for all objects within the bucket. An ARN of arn:aws:s3:::bucket-name/* explicitly matches every object key in that bucket, so there is no missing object coverage. If the ARN were only arn:aws:s3:::bucket-name without the slash and asterisk, it would refer just to the bucket container itself.

Trap 2: The policy version is outdated

The Version element 2012-10-17 is the current, stable version of the AWS IAM policy language, released in 2012 and still the recommended version for all new policies. The older 2008-10-17 lacks support for newer condition context keys and cross-account principal features, but using 2012-10-17 does not make a policy invalid or outdated. Therefore, this cannot be the reason the bucket is publicly readable.

Trap 3: The policy allows anyone to write objects to the bucket

This is not correct because the statement's Action only lists s3:GetObject, which maps to the read operation for an S3 object. Granting write access would require s3:PutObject, s3:DeleteObject, or s3:PutObjectAcl; none of those appears in the policy. The distinction between read and write actions is fundamental, and a policy that only allows reading cannot be used by an attacker to upload or modify objects.

Study all Network and Cloud Forensics common traps →

A
The resource does not include all objects
Why it fails: This is incorrect because the resource ARN in the policy ends with '/*', which is the S3 wildcard for all objects within the bucket. An ARN of arn:aws:s3:::bucket-name/* explicitly matches every object key in that bucket, so there is no missing object coverage. If the ARN were only arn:aws:s3:::bucket-name without the slash and asterisk, it would refer just to the bucket container itself.
B
The policy version is outdated
Why it fails: The Version element 2012-10-17 is the current, stable version of the AWS IAM policy language, released in 2012 and still the recommended version for all new policies. The older 2008-10-17 lacks support for newer condition context keys and cross-account principal features, but using 2012-10-17 does not make a policy invalid or outdated. Therefore, this cannot be the reason the bucket is publicly readable.
C
The bucket is publicly accessible to read objects
This is correct. Setting Principal to '*' in a bucket policy instructs AWS to apply the statement to every possible principal, including unauthenticated anonymous users, not just AWS accounts in your organization. Combining that with the s3:GetObject action and no Condition block grants universal read access to users who know (or can guess) the object URL, making the bucket's objects publicly readable.
D
The policy allows anyone to write objects to the bucket
Why it fails: This is not correct because the statement's Action only lists s3:GetObject, which maps to the read operation for an S3 object. Granting write access would require s3:PutObject, s3:DeleteObject, or s3:PutObjectAcl; none of those appears in the policy. The distinction between read and write actions is fundamental, and a policy that only allows reading cannot be used by an attacker to upload or modify objects.

Full breakdown with real-world context →

Question 7hardmultiple choice

Read the full Network and Cloud Forensics explanation →

You are a forensic investigator for a healthcare organization that uses a hybrid cloud model. Your team receives an alert that a large amount of protected health information (PHI) was exfiltrated from an AWS S3 bucket to an external IP address. The organization uses AWS CloudTrail for API logging and VPC Flow Logs for network traffic. The incident occurred between 02:00 and 03:00 UTC. Upon reviewing CloudTrail logs, you see that the bucket policy was modified at 01:55 UTC to allow public read access, and then a series of GetObject requests from an IP address in a foreign country occurred. The VPC Flow Logs show outbound traffic from the bucket's VPC to that IP. The bucket policy change was made using the root user credentials of the AWS account. The organization has multi-factor authentication (MFA) enabled for all users, including root. However, the CloudTrail log for the policy change does not indicate MFA usage. You need to determine the most likely root cause of the breach. Which of the following is the most plausible explanation?

Trap 1: The bucket policy was automatically modified by an AWS service

Amazon S3 bucket policies are only mutated when an explicit PutBucketPolicy or DeleteBucketPolicy API call is made, and every such call requires an authenticated principal; AWS services do not periodically alter customer resource policies. If the CloudTrail event shows a root principal with a compromised credential, it was an authenticated human/attacker action, not a service-generated change. A service would have emitted an event with an AWS service principal, not Root.

Trap 2: An insider with IAM permissions made the change using a legitimate…

An insider using normal IAM permissions would appear in CloudTrail with userIdentity.userName, an accessKeyId, and an ARN of the form arn:aws:iam::<account>:user/<name>; this event instead shows arn:aws:iam::<account>:root with no IAM session context. Root and IAM users are distinct principals, so no legitimate IAM session could produce a Root userIdentity. The absence of MFA and anomalous source IP also contradicts a vetted insider session.

Trap 3: The CloudTrail logs are inaccurate and the policy change was not…

CloudTrail logs are not arbitrarily inaccurate; the management event PutBucketPolicy is captured and the S3 GetBucketPolicy call now returns the modified policy, confirming the change actually occurred. CloudTrail also provides digest files to detect tampering, and no digest validation failure or log gap was noted. Rejecting valid logs without evidence would be unsupported, especially when the exposed policy directly matches the reconstructed attack.

Study all Network and Cloud Forensics common traps →

A
The root user's credentials were compromised and used to modify the bucket policy
CloudTrail recorded this change as a PutBucketPolicy event whose userIdentity.type is Root and whose sessionContext shows no MFA, indicating the account root sign-in was used. Root credentials are not intended for day-to-day access, and an authentication event outside the organization's IP range with no MFA is classic credential theft. The attacker then rewrote the bucket policy to grant unintended access, enabling data exposure.
B
The bucket policy was automatically modified by an AWS service
Why it fails: Amazon S3 bucket policies are only mutated when an explicit PutBucketPolicy or DeleteBucketPolicy API call is made, and every such call requires an authenticated principal; AWS services do not periodically alter customer resource policies. If the CloudTrail event shows a root principal with a compromised credential, it was an authenticated human/attacker action, not a service-generated change. A service would have emitted an event with an AWS service principal, not Root.
C
An insider with IAM permissions made the change using a legitimate session
Why it fails: An insider using normal IAM permissions would appear in CloudTrail with userIdentity.userName, an accessKeyId, and an ARN of the form arn:aws:iam::<account>:user/<name>; this event instead shows arn:aws:iam::<account>:root with no IAM session context. Root and IAM users are distinct principals, so no legitimate IAM session could produce a Root userIdentity. The absence of MFA and anomalous source IP also contradicts a vetted insider session.
D
The CloudTrail logs are inaccurate and the policy change was not made
Why it fails: CloudTrail logs are not arbitrarily inaccurate; the management event PutBucketPolicy is captured and the S3 GetBucketPolicy call now returns the modified policy, confirming the change actually occurred. CloudTrail also provides digest files to detect tampering, and no digest validation failure or log gap was noted. Rejecting valid logs without evidence would be unsupported, especially when the exposed policy directly matches the reconstructed attack.

Full breakdown with real-world context →

Question 8hardmultiple choice

Read the full Network and Cloud Forensics explanation →

During a forensic investigation of a cloud environment, a forensic analyst discovers that the virtual machine (VM) used by a suspect was terminated three days prior. The cloud provider offers snapshots, backups, and instance metadata. Which of the following is the BEST course of action to recover forensic evidence?

Trap 1: Examine CloudTrail logs for disk contents.

AWS CloudTrail is an API audit service that records control-plane and data-plane events such as who called CreateSnapshot or RunInstances, along with request parameters and metadata. It never captures the raw file system blocks, directory entries, or disk contents of an EBS volume, so logs cannot reveal deleted files or user data. CloudTrail is useful for establishing a timeline of actions, not for extracting disk evidence.

Trap 2: Access the VM’s operating system via the cloud console’s serial…

The cloud console's serial console (e.g., EC2 Serial Console) provides a text-based terminal to a running instance, primarily for troubleshooting boot, network, or kernel issues; it is not enabled by default and requires the instance to be in the running state. A terminated instance has no hypervisor-attached serial port available, and even if you accessed it, you would only see a command shell, not a block-level forensic image. It also cannot be used to recover deleted files without altering the live system.

Trap 3: Use SSH credentials from the investigation to connect to the…

SSH requires a running instance with a reachable network endpoint; a terminated EC2 instance has been deprovisioned, its underlying compute and network resources released, and by default its root EBS volume is deleted unless a snapshot or different termination protection was configured. Therefore, the SSH connection would fail at the TCP/IP layer. Even on a live host, SSH would give interactive shell access that writes to the file system, making it unsuitable for a sterile forensic acquisition.

Study all Network and Cloud Forensics common traps →

A
Examine CloudTrail logs for disk contents.
Why it fails: AWS CloudTrail is an API audit service that records control-plane and data-plane events such as who called CreateSnapshot or RunInstances, along with request parameters and metadata. It never captures the raw file system blocks, directory entries, or disk contents of an EBS volume, so logs cannot reveal deleted files or user data. CloudTrail is useful for establishing a timeline of actions, not for extracting disk evidence.
B
Access the VM’s operating system via the cloud console’s serial console.
Why it fails: The cloud console's serial console (e.g., EC2 Serial Console) provides a text-based terminal to a running instance, primarily for troubleshooting boot, network, or kernel issues; it is not enabled by default and requires the instance to be in the running state. A terminated instance has no hypervisor-attached serial port available, and even if you accessed it, you would only see a command shell, not a block-level forensic image. It also cannot be used to recover deleted files without altering the live system.
C
Use SSH credentials from the investigation to connect to the terminated instance.
Why it fails: SSH requires a running instance with a reachable network endpoint; a terminated EC2 instance has been deprovisioned, its underlying compute and network resources released, and by default its root EBS volume is deleted unless a snapshot or different termination protection was configured. Therefore, the SSH connection would fail at the TCP/IP layer. Even on a live host, SSH would give interactive shell access that writes to the file system, making it unsuitable for a sterile forensic acquisition.
D
Restore the VM from a recent snapshot or backup provided by the cloud provider.
Snapshots or automated backups preserve a point-in-time, block-level copy of the EBS volume independent of the now-terminated instance. The correct forensic procedure is to restore that snapshot to a new EBS volume, attach it to an isolated analysis instance, and mount it read-only (or image it with dd or a tool like FTK Imager) before hashing and inspecting the contents. This preserves the integrity of the original evidence and lets you recover deleted files without altering the source data.

Full breakdown with real-world context →

Question 9easymultiple choice

Read the full Network and Cloud Forensics explanation →

A forensic investigator needs to capture network traffic from a SPAN port on a switch to analyze an ongoing compromise. Which tool should the investigator use to collect the full packet capture (pcap) for later analysis?

Trap 1: NetFlow

NetFlow exports aggregated metadata about IP flows (e.g., source/destination IPs, ports, protocol, packet/byte counts) rather than the actual packet contents. A forensic investigator needing to reconstruct malware payloads or extract artifacts from the raw data stream would find NetFlow insufficient because it lacks payload bytes and can only confirm that traffic occurred, not what it contained.

Trap 2: nmap

nmap is a network discovery and vulnerability scanning tool that probes hosts by sending crafted packets and analyzing responses to identify open ports, services, and OS fingerprints. It does not operate as a passive packet sniffer; any traffic it generates is from its own scans, and it offers no ability to capture or store raw frames from the wire for later forensic analysis.

Trap 3: Wireshark

Wireshark is a graphical protocol analyzer that can capture packets, but its GUI and on-the-fly dissection make it inefficient and resource-heavy for headless or long-duration capture on a forensic target. tcpdump is the preferred command-line utility for raw full-packet capture to pcap format because it writes directly to disk with minimal overhead, while Wireshark is better suited for interactive post-capture analysis.

Study all Network and Cloud Forensics common traps →

A
NetFlow
Why it fails: NetFlow exports aggregated metadata about IP flows (e.g., source/destination IPs, ports, protocol, packet/byte counts) rather than the actual packet contents. A forensic investigator needing to reconstruct malware payloads or extract artifacts from the raw data stream would find NetFlow insufficient because it lacks payload bytes and can only confirm that traffic occurred, not what it contained.
B
nmap
Why it fails: nmap is a network discovery and vulnerability scanning tool that probes hosts by sending crafted packets and analyzing responses to identify open ports, services, and OS fingerprints. It does not operate as a passive packet sniffer; any traffic it generates is from its own scans, and it offers no ability to capture or store raw frames from the wire for later forensic analysis.
C
Wireshark
Why it fails: Wireshark is a graphical protocol analyzer that can capture packets, but its GUI and on-the-fly dissection make it inefficient and resource-heavy for headless or long-duration capture on a forensic target. tcpdump is the preferred command-line utility for raw full-packet capture to pcap format because it writes directly to disk with minimal overhead, while Wireshark is better suited for interactive post-capture analysis.
D
tcpdump
tcpdump is a libpcap-based command-line packet sniffer that captures raw full packets (including layer 2 through application payloads) and writes them in pcap format, making it ideal for forensic traffic capture on live systems. Its headless design and low overhead allow it to run continuously on a compromised host without a GUI, and its filter syntax enables precise collection of relevant traffic while minimizing data volume.

Full breakdown with real-world context →

Question 10mediummultiple choice

Read the full Network and Cloud Forensics explanation →

A cloud forensic analyst is tasked with preserving evidence from an AWS S3 bucket that may contain malicious files. The bucket is publicly accessible, and the analyst wants to create a forensically sound copy. Which method BEST ensures integrity and chain of custody?

Trap 1: Download each object via the AWS Management Console and compute…

Manually downloading each object through the AWS Management Console and computing SHA256 hashes with external tools is a brittle forensic process. The console offers no built-in integrity verification, and any single corrupted download or user error (e.g., mistyping a file path or running the wrong hash) breaks the chain of custody without detection. It also does not scale to buckets with many objects, unlike an automated CLI command, and it fails to leverage the native checksum metadata that S3 can validate.

Trap 2: Use the AWS CLI cp command recursively without any flags.

Running an unmodified recursive 'cp' command in the AWS CLI copies object bytes but does not perform a checksum comparison after the transfer to confirm the local files are bit-for-bit identical to the source. Without a checksum verification flag, the copy relies on the network stack and size comparison alone, which can miss silent data corruption or incomplete writes. The '--checksum-mode' option (or explicit S3 managed checksum parameters) is needed to force the CLI to compute and compare hashes, making this a weak integrity-preservation practice.

Trap 3: Generate a presigned URL for the bucket and use wget to download…

A presigned URL grants temporary HTTP access to a specific S3 object, and using wget to fetch it only saves the bytes as received, with no cryptographic verification against the cloud object's stored checksums. To copy an entire bucket you would have to generate thousands of individual presigned URLs, manually handle pagination, and still have no way to prove each download matches what S3 holds. This approach is also unsuitable for forensics because wget's progress output and any interrupted downloads can leave artifacts that require independent validation.

Study all Network and Cloud Forensics common traps →

A
Download each object via the AWS Management Console and compute SHA256 hashes manually.
Why it fails: Manually downloading each object through the AWS Management Console and computing SHA256 hashes with external tools is a brittle forensic process. The console offers no built-in integrity verification, and any single corrupted download or user error (e.g., mistyping a file path or running the wrong hash) breaks the chain of custody without detection. It also does not scale to buckets with many objects, unlike an automated CLI command, and it fails to leverage the native checksum metadata that S3 can validate.
B
Use the AWS CLI cp command recursively without any flags.
Why it fails: Running an unmodified recursive 'cp' command in the AWS CLI copies object bytes but does not perform a checksum comparison after the transfer to confirm the local files are bit-for-bit identical to the source. Without a checksum verification flag, the copy relies on the network stack and size comparison alone, which can miss silent data corruption or incomplete writes. The '--checksum-mode' option (or explicit S3 managed checksum parameters) is needed to force the CLI to compute and compare hashes, making this a weak integrity-preservation practice.
C
Generate a presigned URL for the bucket and use wget to download all files.
Why it fails: A presigned URL grants temporary HTTP access to a specific S3 object, and using wget to fetch it only saves the bytes as received, with no cryptographic verification against the cloud object's stored checksums. To copy an entire bucket you would have to generate thousands of individual presigned URLs, manually handle pagination, and still have no way to prove each download matches what S3 holds. This approach is also unsuitable for forensics because wget's progress output and any interrupted downloads can leave artifacts that require independent validation.
D
Use the AWS CLI sync command with the --checksum-mode flag to verify integrity during transfer.
The AWS CLI's 'sync' command combined with '--checksum-mode ENABLED' is a robust preservation method because it compares not just file sizes and modification times but also hash values (e.g., SHA256 or CRC64) to ensure the local copy exactly matches the S3 object. After transferring data, sync performs a checksum validation, so any bit rot in the AWS connection or local storage is detected and corrected. In newer CLI releases you can also set '--checksum-algorithm SHA256' to generate the same hash you will use for your evidence verification, giving you an auditable record of the transfer.

Full breakdown with real-world context →

Question 11hardmulti select

Read the full Network and Cloud Forensics explanation →

Which TWO of the following are valid techniques for collecting volatile network evidence from a live system during incident response?

Trap 1: Using route print to view the IP routing table.

The IP routing table is persistent kernel state that determines how packets will be forwarded, but it does not reflect the dynamic, active connections of a live session. A route print snapshot changes only when routes are added, removed, or altered by routing protocols or manual configuration, making it far less volatile than connection-level or packet-level evidence. It is configuration-oriented rather than activity-oriented, so it is not a primary source for recovering evidence of an ongoing or recent network communication.

Trap 2: Using ipconfig /displaydns to view the DNS resolver cache.

The DNS resolver cache stores the results of previous hostname resolution queries, including IP addresses, as maintained by the DNS Client service. This cache reveals which domain names have been resolved recently and to what addresses, but it is a historical byproduct of name resolution, not a live record of current TCP/UDP connections. Because the data is derived from earlier application requests and can persist after the actual connection ends, it lacks the real-time, connection-relation quality needed for direct proof of active network activity.

Trap 3: Running arp -a to view the ARP table.

The ARP table maps IP addresses to MAC addresses for immediate-neighbor devices on a local subnet, and while it is volatile memory state, it only shows the last-known data-link layer association. Many ARP entries are stale or are added even after a single broadcast or a failed connection attempt, so the table is not indicative of the existence or state of actual TCP/UDP network flows. It can corroborate which hosts were on the local segment, but it cannot show connections, ports, sessions, or traffic payloads, making it weaker than connection or packet capture evidence.

Study all Network and Cloud Forensics common traps →

A
Using route print to view the IP routing table.
Why it fails: The IP routing table is persistent kernel state that determines how packets will be forwarded, but it does not reflect the dynamic, active connections of a live session. A route print snapshot changes only when routes are added, removed, or altered by routing protocols or manual configuration, making it far less volatile than connection-level or packet-level evidence. It is configuration-oriented rather than activity-oriented, so it is not a primary source for recovering evidence of an ongoing or recent network communication.
B
Using ipconfig /displaydns to view the DNS resolver cache.
Why it fails: The DNS resolver cache stores the results of previous hostname resolution queries, including IP addresses, as maintained by the DNS Client service. This cache reveals which domain names have been resolved recently and to what addresses, but it is a historical byproduct of name resolution, not a live record of current TCP/UDP connections. Because the data is derived from earlier application requests and can persist after the actual connection ends, it lacks the real-time, connection-relation quality needed for direct proof of active network activity.
C
Running arp -a to view the ARP table.
Why it fails: The ARP table maps IP addresses to MAC addresses for immediate-neighbor devices on a local subnet, and while it is volatile memory state, it only shows the last-known data-link layer association. Many ARP entries are stale or are added even after a single broadcast or a failed connection attempt, so the table is not indicative of the existence or state of actual TCP/UDP network flows. It can corroborate which hosts were on the local segment, but it cannot show connections, ports, sessions, or traffic payloads, making it weaker than connection or packet capture evidence.
D
Running netstat -an to view active TCP/UDP connections.
Netstat -an enumerates the current TCP and UDP endpoint sockets, including listening ports, established connections, and connection states, directly from the kernel's socket table. Because this table is updated in kernel memory and changes as connections open and close, it constitutes volatile evidence of live network activity at a specific moment. Capturing this output immediately is critical since every established session vanishes once the process exits or the network stack is torn down, preserving an instant snapshot of the machine's network communications.
E
Executing tcpdump -i eth0 -w capture.pcap to capture live packets.
Executing tcpdump -i eth0 -w capture.pcap stores a raw copy of actual frames traversing the network interface, preserving both packet headers and payloads for later forensic analysis. The absence of persistent storage of network traffic means that any data not captured in real-time is permanently lost once the packets pass, making live packet capture one of the most volatile and time-sensitive evidence collection techniques. This method is a direct form of network evidence that can reconstruct the exact data exchange, unlike tables or caches that only imply metadata.

Full breakdown with real-world context →

Question 12easymulti select

Read the full Network and Cloud Forensics explanation →

During a cloud forensic investigation of an AWS EC2 instance, which TWO sources should be preserved to capture volatile data before instance termination?

Trap 1: VPC flow logs

VPC Flow Logs are wrong because they only record network traffic metadata — IP addresses, ports, protocols, and packet accept/reject decisions — captured in CloudWatch Logs. They are non-volatile and persist independently of the instance, but they contain none of the in-memory or file-system evidence needed to recover passwords, process memory, or deleted data from the EC2 instance itself.

Trap 2: S3 server access logs

S3 server access logs are wrong because they are object-level audit records for requests made to Amazon S3 buckets, not for the EC2 instance's memory or disk. These logs are stored as objects in another S3 bucket and remain non-volatile, but they only show who accessed which S3 object and when, providing no visibility into the EC2 instance's volatile memory or its local file system.

Trap 3: AWS CloudTrail logs

AWS CloudTrail logs are wrong because they record management-plane API calls such as EC2 instance launches, terminations, and console logins, and are stored persistently in CloudTrail. They are valuable for reconstructing administrative actions and the timeline of the instance's lifecycle, but they cannot recover the instance's memory contents, on-disk data, or userland processes, making them irrelevant as a direct source of volatile forensic evidence.

Study all Network and Cloud Forensics common traps →

A
Memory dump of the instance
A memory dump is correct because it captures the raw contents of the instance's RAM, including running processes, open network connections, loaded kernel modules, encryption keys, and other volatile artifacts that vanish the moment the instance is stopped or terminated. In AWS, no native API can retrieve a live memory dump from a running EC2 instance, so you must use a pre-installed agent or hypervisor-based technique; without it, this data is permanently lost.
B
VPC flow logs
Why it fails: VPC Flow Logs are wrong because they only record network traffic metadata — IP addresses, ports, protocols, and packet accept/reject decisions — captured in CloudWatch Logs. They are non-volatile and persist independently of the instance, but they contain none of the in-memory or file-system evidence needed to recover passwords, process memory, or deleted data from the EC2 instance itself.
C
Disk snapshot (EBS snapshot)
An EBS snapshot is correct because it captures the full file system and raw block-level state of the instance's virtual disks, including file remnants, unallocated space, and application data. It is a persistent, non-volatile copy that can be taken before termination to preserve disk-based evidence, though it does not capture RAM contents such as active encryption keys or running process state.
D
S3 server access logs
Why it fails: S3 server access logs are wrong because they are object-level audit records for requests made to Amazon S3 buckets, not for the EC2 instance's memory or disk. These logs are stored as objects in another S3 bucket and remain non-volatile, but they only show who accessed which S3 object and when, providing no visibility into the EC2 instance's volatile memory or its local file system.
E
AWS CloudTrail logs
Why it fails: AWS CloudTrail logs are wrong because they record management-plane API calls such as EC2 instance launches, terminations, and console logins, and are stored persistently in CloudTrail. They are valuable for reconstructing administrative actions and the timeline of the instance's lifecycle, but they cannot recover the instance's memory contents, on-disk data, or userland processes, making them irrelevant as a direct source of volatile forensic evidence.

Full breakdown with real-world context →

Question 13hardmultiple choice

Read the full Network and Cloud Forensics explanation →

You are investigating a network breach at a financial institution. The perimeter firewall logs show an inbound connection from IP 203.0.113.5 to the internal web server (192.168.1.10) on TCP port 443 at 02:34:12 UTC. At 02:34:15, an outbound connection from the web server to an external IP 198.51.100.20 on TCP port 80 is logged. Simultaneously, a network intrusion detection system (NIDS) detected a SQL injection payload in the inbound HTTP request. The web server's access logs show a successful login to the admin panel at 02:34:18 from the same external IP 203.0.113.5. The database server (192.168.1.20) logs show a query execution at 02:34:20 that exported customer records. The company uses a jump box for administrative access, and all admin sessions are logged. The jump box logs show no activity during the incident. The web server hosts a public-facing application and is in a DMZ. The database server is in the internal network, with a firewall rule allowing only the web server to connect to it on TCP port 3306. Which course of action is MOST appropriate to determine the root cause and scope?

Trap 1: Immediately isolate the web server from the network to prevent…

Immediate network isolation of the web server is premature because it can destroy volatile evidence, including memory resident malware, active network connections, and cached data that exists only in RAM. A proper live response protocol requires capturing a forensic memory image and performing analysis before any power loss or network disruption. Additionally, the scenario does not establish that malware exists; the breach may be purely application-level via SQL injection, so isolating the server could also alert the attacker and hinder log correlation.

Trap 2: Check the NTP logs to see if the timestamps are accurate, as the…

NTP logs only confirm whether system clocks are synchronized; they have no direct relevance to SQL injection detection or payload identification. Time-based SQL injection is a blind technique that relies on inducing delays to infer database responses, but the scenario already indicates a successful attack with an outbound HTTP connection, which is not characteristic of a blind time-based attack. Checking NTP would not help determine which records were queried or whether they were exfiltrated, making it a pointless detour.

Trap 3: Extract and analyze the full packet capture from the firewall to…

Analyzing the full firewall packet capture, especially if encrypted, would consume significant time and resources and may not reveal the exfiltrated data if it was transmitted in plaintext over the outbound HTTP connection on port 80. The SQL injection payload is already known from server logs, so the investigation should focus on correlating logs to understand data scope rather than re-deriving the attack vector. Furthermore, encrypted traffic analysis requires key material that is unlikely to be available from the firewall capture, and pcap analysis alone cannot confirm which database records were actually exfiltrated.

Study all Network and Cloud Forensics common traps →

A
Correlate the database server logs with the web server logs to identify which records were queried and verify if they were exfiltrated via the outbound HTTP connection.
Correlating the database server logs with the web server logs reconstructs the exact SQL queries executed and maps each query to the corresponding HTTP request by session ID and timestamp. This allows you to identify precisely which records were returned in the query results and then verify, against the observed outbound HTTP connection, that those same records were transmitted out of the network. The HTTP response payload should match the database query output, confirming exfiltration and establishing the true scope of data loss.
B
Immediately isolate the web server from the network to prevent further data exfiltration, then perform memory forensics to find any malware.
Why it fails: Immediate network isolation of the web server is premature because it can destroy volatile evidence, including memory resident malware, active network connections, and cached data that exists only in RAM. A proper live response protocol requires capturing a forensic memory image and performing analysis before any power loss or network disruption. Additionally, the scenario does not establish that malware exists; the breach may be purely application-level via SQL injection, so isolating the server could also alert the attacker and hinder log correlation.
C
Check the NTP logs to see if the timestamps are accurate, as the attack may be a time-based SQL injection.
Why it fails: NTP logs only confirm whether system clocks are synchronized; they have no direct relevance to SQL injection detection or payload identification. Time-based SQL injection is a blind technique that relies on inducing delays to infer database responses, but the scenario already indicates a successful attack with an outbound HTTP connection, which is not characteristic of a blind time-based attack. Checking NTP would not help determine which records were queried or whether they were exfiltrated, making it a pointless detour.
D
Extract and analyze the full packet capture from the firewall to identify the SQL injection payload and any encrypted traffic.
Why it fails: Analyzing the full firewall packet capture, especially if encrypted, would consume significant time and resources and may not reveal the exfiltrated data if it was transmitted in plaintext over the outbound HTTP connection on port 80. The SQL injection payload is already known from server logs, so the investigation should focus on correlating logs to understand data scope rather than re-deriving the attack vector. Furthermore, encrypted traffic analysis requires key material that is unlikely to be available from the firewall capture, and pcap analysis alone cannot confirm which database records were actually exfiltrated.

Full breakdown with real-world context →

Question 14mediumdrag order

Read the full Network and Cloud Forensics explanation →

Drag and drop the steps to create a forensic timeline using the Sleuth Kit (TSK) and log2timeline into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: First, use log2timeline to parse the disk image

This is incorrect because log2timeline requires input data such as a body file or other logs; it cannot be run first without prior data collection. Also, file listing and inode extraction should precede timeline parsing.

Trap 2: First, use ils to extract inode information

Running ils before fls reverses the required dependency: ils can extract inode records from a disk image, but without fls's directory listing you lack the path-to-inode associations that give those inodes context. A timeline built from inode-only entries would show metadata events but fail to correlate them with filenames or directory locations, making the output significantly less useful for investigation. The proper order is fls first, so that inode numbers are tied to actual file system objects before ils is invoked, and then the MAC timestamps can be collected and parsed.

Trap 3: First, use mac-robber to collect MAC timestamps

This is incorrect because using mac-robber first is acceptable for MAC times, but log2timeline should be run after all data collection, not before fls and ils. Skipping file listing and inode extraction before log2timeline results in an incomplete timeline.

Study all Network and Cloud Forensics common traps →

A
First, use fls to list files and directories. Second, use ils to extract inode information. Third, use mac-robber to create a body file with MAC timestamps. Fourth, use log2timeline to parse the body file and generate a timeline.
The correct sequence begins with fls to enumerate the file system and establish the mapping between inode numbers and file paths. Next, ils reads inode metadata from those enumerated objects, providing creation, modification, and access timestamps along with ownership and permissions. mac-robber then walks the target directory or image and consolidates these MAC times into a body file in the standardized mactime format. Finally, log2timeline parses that body file and transforms the timestamped records into a unified, browsable chronological timeline for forensic analysis.
B
First, use log2timeline to parse the disk image. Second, use mac-robber to collect MAC timestamps. Third, use fls to list files. Fourth, use ils to get inode details.
Why it fails: This is incorrect because log2timeline requires input data such as a body file or other logs; it cannot be run first without prior data collection. Also, file listing and inode extraction should precede timeline parsing.
C
First, use ils to extract inode information. Second, use fls to list files. Third, use mac-robber to create a body file. Fourth, use log2timeline to parse.
Why it fails: Running ils before fls reverses the required dependency: ils can extract inode records from a disk image, but without fls's directory listing you lack the path-to-inode associations that give those inodes context. A timeline built from inode-only entries would show metadata events but fail to correlate them with filenames or directory locations, making the output significantly less useful for investigation. The proper order is fls first, so that inode numbers are tied to actual file system objects before ils is invoked, and then the MAC timestamps can be collected and parsed.
D
First, use mac-robber to collect MAC timestamps. Second, use log2timeline to parse. Third, use fls to list files. Fourth, use ils to get inode details.
Why it fails: This is incorrect because using mac-robber first is acceptable for MAC times, but log2timeline should be run after all data collection, not before fls and ils. Skipping file listing and inode extraction before log2timeline results in an incomplete timeline.

Full breakdown with real-world context →

Question 15mediummatching

Read the full Network and Cloud Forensics explanation →

Match each forensic artifact to its location in Windows (typical).

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

C:\Windows\Prefetch

C:\Windows\System32\winevt\Logs

C:\$Recycle.Bin

C:\Windows\System32\config

C:\Users\[user]\AppData\Local\Microsoft\Windows\Explorer

Trap 1: Registry SAM hive: C:\Windows\System32\config\SYSTEM

The SYSTEM hive at C:\Windows\System32\config\SYSTEM is a separate registry file that stores hardware profiles, device drivers, memory management settings, and the ControlSet hierarchy—it does not contain user account data. The SAM hive's resident location is the sibling file SAM in the same directory and holds user credentials; referring to SYSTEM as the SAM location would send an examiner to an entirely different hive with no password artifacts. This misidentification frequently leads to zero recovered logons in investigations unless corrected early.

Trap 2: Prefetch files: C:\Windows\Temp

C:\Windows\Temp serves as a scratch area for Windows Installer, servicing scripts, and third-party utilities, containing random .tmp files and setup logs rather than structured execution history. Unlike Prefetch's .pf files, which include file hashes and last-run times, Temp content is transient and lacks the forensic metadata used to correlate running executables. A system where Prefetch files appear under Temp would indicate an anomalous disposition, possibly from an artifact deletion or anti-forensic tool, because the Windows prefetcher design fixes its folder to C:\Windows\Prefetch.

Study all Network and Cloud Forensics common traps →

A
Prefetch files: C:\Windows\Prefetch
The Prefetch directory, C:\Windows\Prefetch, holds .pf files created when applications execute, caching their initial code and file paths to accelerate future launches. Each .pf file records the executable name, run count, and last run timestamp, making it a cornerstone artifact for reconstructing program execution history during a forensic analysis. Because the folder requires administrative access, its presence and contents are highly probative for establishing user activity on Windows 10 and 11 systems.
B
Registry SAM hive: C:\Windows\System32\config\SAM
The SAM (Security Accounts Manager) hive is a registry database file physically located at C:\Windows\System32\config\SAM and mounts under HKEY_LOCAL_MACHINE\SAM. It stores the native local user account names, RID values, groups, and hashed password credentials (NT hash and LM hash on older builds), which examiners extract for offline credential auditing. This location is distinct from SYSTEM, which houses boot configuration and driver metadata, so mixing them up voids legitimate password analysis.
C
Windows Event Logs: C:\Windows\System32\winevt\Logs
Windows Event Logs are persisted as .evtx files in the directory C:\Windows\System32\winevt\Logs, with Security, System, Application, and custom channels all stored there. These binary files record high-value events such as 4624 (successful logon), 4625 (failed logon), and 7045 (service installation), enabling detailed timeline reconstruction. The winevt directory replaces the older C:\Windows\System32\config\*.evt structure used in Windows XP and prior versions, a critical distinction when searching for legacy artifacts.
D
Recycle Bin: C:\$Recycle.Bin
The modern Recycle Bin occupies a hidden directory named $Recycle.Bin at the volume root, so on a typical system drive it resolves to C:\$Recycle.Bin, containing a distinct subfolder per user SID. Each deleted item appears as an $R data stream holding the file contents and an $I metadata stream that stores the original path and deletion timestamp. This structure permits forensic recovery of deleted files and proves the user deliberately removed them via the GUI rather than through a command-line delete that bypasses the bin.
E
Registry SAM hive: C:\Windows\System32\config\SYSTEM
Why it fails: The SYSTEM hive at C:\Windows\System32\config\SYSTEM is a separate registry file that stores hardware profiles, device drivers, memory management settings, and the ControlSet hierarchy—it does not contain user account data. The SAM hive's resident location is the sibling file SAM in the same directory and holds user credentials; referring to SYSTEM as the SAM location would send an examiner to an entirely different hive with no password artifacts. This misidentification frequently leads to zero recovered logons in investigations unless corrected early.
F
Prefetch files: C:\Windows\Temp
Why it fails: C:\Windows\Temp serves as a scratch area for Windows Installer, servicing scripts, and third-party utilities, containing random .tmp files and setup logs rather than structured execution history. Unlike Prefetch's .pf files, which include file hashes and last-run times, Temp content is transient and lacks the forensic metadata used to correlate running executables. A system where Prefetch files appear under Temp would indicate an anomalous disposition, possibly from an artifact deletion or anti-forensic tool, because the Windows prefetcher design fixes its folder to C:\Windows\Prefetch.

Full breakdown with real-world context →

Question 16mediummultiple choice

Read the full Network and Cloud Forensics explanation →

A forensic investigator is analyzing a compromised Linux web server. The server's network interface was in promiscuous mode, and a full packet capture was running via tcpdump when the attacker exfiltrated data over HTTPS. The investigator needs to determine the exact bytes transferred during the exfiltration session. Which artifact from the packet capture will BEST provide this information?

Trap 1: The TCP sequence and acknowledgment numbers

Sequence and acknowledgment numbers are used to track byte ordering and reliability, not to reveal payload content directly. While they help detect retransmissions and gaps, they do not provide the actual bytes transferred. An investigator needs the reassembled stream to see the data, so relying solely on these numbers would fail to answer the question about exact bytes exfiltrated.

Trap 2: The DNS query log associated with the session

DNS query logs reveal domain name resolutions, which can identify command-and-control or exfiltration destinations, but they do not contain the transferred payload. The question asks for the exact bytes transferred, and DNS logs only show metadata about name lookups. They are useful for attribution but cannot reconstruct the HTTPS session content or volume.

Trap 3: The IP header total length field of each packet

The IP total length field indicates the size of each individual IP packet, not the cumulative application data transferred. It includes IP and TCP headers, so summing these values overestimates the actual payload bytes. It also cannot account for retransmissions or out-of-order delivery, making it unsuitable for determining the exact exfiltrated data volume or content in this scenario.

Study all Network and Cloud Forensics common traps →

A
The reassembled TCP stream payload
Reassembling the TCP stream reconstructs the application-layer data exchanged between client and server, including the encrypted HTTPS payload. Since the capture began before the TLS session, the investigator can extract the exact ciphertext bytes transferred. This directly answers how many bytes were exfiltrated and preserves the byte-level evidence needed for reporting, even though the content remains encrypted without the session keys.
B
The TCP sequence and acknowledgment numbers
Why it fails: Sequence and acknowledgment numbers are used to track byte ordering and reliability, not to reveal payload content directly. While they help detect retransmissions and gaps, they do not provide the actual bytes transferred. An investigator needs the reassembled stream to see the data, so relying solely on these numbers would fail to answer the question about exact bytes exfiltrated.
C
The DNS query log associated with the session
Why it fails: DNS query logs reveal domain name resolutions, which can identify command-and-control or exfiltration destinations, but they do not contain the transferred payload. The question asks for the exact bytes transferred, and DNS logs only show metadata about name lookups. They are useful for attribution but cannot reconstruct the HTTPS session content or volume.
D
The IP header total length field of each packet
Why it fails: The IP total length field indicates the size of each individual IP packet, not the cumulative application data transferred. It includes IP and TCP headers, so summing these values overestimates the actual payload bytes. It also cannot account for retransmissions or out-of-order delivery, making it unsuitable for determining the exact exfiltrated data volume or content in this scenario.

Full breakdown with real-world context →

Question 17hardmulti select

Read the full Network and Cloud Forensics explanation →

A forensic analyst is investigating a security incident in a Microsoft Azure environment. The organization suspects that an attacker used compromised credentials to access an Azure virtual machine and exfiltrate data. The analyst needs to collect evidence from Azure that can show authentication events and network traffic related to the VM. Which TWO Azure sources should the analyst prioritize for this investigation? (Choose two.)

Trap 1: Azure Advisor recommendations

Azure Advisor offers best-practice recommendations for cost, security, and performance, but it is not an audit or logging source. It does not record authentication events or network flows, so it cannot help identify compromised credentials or exfiltration traffic. Using Advisor would be irrelevant to the forensic investigation of the incident.

Trap 2: Azure Service Health notifications

Azure Service Health provides information about Azure platform outages and maintenance, not tenant-specific security events. It does not log user authentication or network traffic from a VM. Therefore, it is not a useful source for investigating a compromised credential incident or data exfiltration in this Azure environment.

Trap 3: Azure Cost Management exports

Azure Cost Management exports provide billing and usage data, not security event details. They might show increased resource consumption but cannot reveal authentication events or network traffic patterns. Relying on cost data would misdirect the investigation because it lacks the granularity and context needed to trace attacker activity or data exfiltration in this scenario.

Study all Network and Cloud Forensics common traps →

A
Azure Advisor recommendations
Why it fails: Azure Advisor offers best-practice recommendations for cost, security, and performance, but it is not an audit or logging source. It does not record authentication events or network flows, so it cannot help identify compromised credentials or exfiltration traffic. Using Advisor would be irrelevant to the forensic investigation of the incident.
B
Network Watcher flow logs
Network Watcher flow logs record IP traffic metadata for network security groups, including source and destination IPs, ports, and whether traffic was allowed or denied. They can show outbound connections from the VM to external IPs, indicating potential data exfiltration. These logs are essential for understanding network-level activity during the incident.
C
Azure Service Health notifications
Why it fails: Azure Service Health provides information about Azure platform outages and maintenance, not tenant-specific security events. It does not log user authentication or network traffic from a VM. Therefore, it is not a useful source for investigating a compromised credential incident or data exfiltration in this Azure environment.
D
Azure Activity Log
The Azure Activity Log records subscription-level control plane operations, including who started, stopped, or modified a VM, and when. It can reveal suspicious actions like a VM being started by an unusual user or a network security group rule being altered. For authentication events, it captures Microsoft Entra ID sign-in activity if integrated, helping trace compromised credentials used to manage the VM.
E
Azure Cost Management exports
Why it fails: Azure Cost Management exports provide billing and usage data, not security event details. They might show increased resource consumption but cannot reveal authentication events or network traffic patterns. Relying on cost data would misdirect the investigation because it lacks the granularity and context needed to trace attacker activity or data exfiltration in this scenario.

Full breakdown with real-world context →

Question 18easymultiple choice

Read the full Network and Cloud Forensics explanation →

A forensic investigator is examining a PCAP file collected from a network tap. The investigator notices a large number of TCP SYN packets sent to various ports on a single target IP address, with no corresponding SYN-ACK responses. Which type of activity does this pattern MOST likely indicate?

Trap 1: UDP fragmentation attack

UDP fragmentation attacks involve malformed UDP packets with overlapping fragments, not TCP SYN packets. The scenario explicitly describes TCP SYN packets, so UDP-related attacks are irrelevant. This option confuses protocols and attack types, and would not explain the observed TCP SYN traffic without responses.

Trap 2: ARP spoofing

ARP spoofing involves forged ARP messages to associate an attacker's MAC address with a legitimate IP, enabling man-in-the-middle attacks. It does not generate TCP SYN packets or floods. The PCAP shows TCP SYN traffic, so ARP spoofing is unrelated to this pattern and would not produce the described evidence.

Trap 3: TCP port scanning

Port scanning typically involves SYN packets to multiple ports, but it often receives SYN-ACK for open ports or RST for closed ports. A complete lack of SYN-ACK responses across many ports suggests either a filtered target or a flood, not standard scanning. Port scanning is usually reconnaissance, not a high-volume attack, so this pattern is more indicative of a SYN flood.

Study all Network and Cloud Forensics common traps →

A
UDP fragmentation attack
Why it fails: UDP fragmentation attacks involve malformed UDP packets with overlapping fragments, not TCP SYN packets. The scenario explicitly describes TCP SYN packets, so UDP-related attacks are irrelevant. This option confuses protocols and attack types, and would not explain the observed TCP SYN traffic without responses.
B
ARP spoofing
Why it fails: ARP spoofing involves forged ARP messages to associate an attacker's MAC address with a legitimate IP, enabling man-in-the-middle attacks. It does not generate TCP SYN packets or floods. The PCAP shows TCP SYN traffic, so ARP spoofing is unrelated to this pattern and would not produce the described evidence.
C
TCP port scanning
Why it fails: Port scanning typically involves SYN packets to multiple ports, but it often receives SYN-ACK for open ports or RST for closed ports. A complete lack of SYN-ACK responses across many ports suggests either a filtered target or a flood, not standard scanning. Port scanning is usually reconnaissance, not a high-volume attack, so this pattern is more indicative of a SYN flood.
D
TCP SYN flood attack
A SYN flood sends numerous TCP SYN packets to a target without completing the three-way handshake, often from spoofed sources. The absence of SYN-ACK responses is consistent with the target either being overwhelmed or the packets being spoofed. This pattern is a classic denial-of-service attack aimed at exhausting connection state resources, matching the observed PCAP evidence.

Full breakdown with real-world context →

Question 19easymultiple choice

Read the full Network and Cloud Forensics explanation →

An investigator needs to capture network traffic from a live network segment without altering the traffic flow. Which technique should they use?

Trap 1: Enable NetFlow on the router and capture flows

NetFlow on a router exports aggregated flow records—source and destination IPs, ports, protocol, and byte/packet counts—rather than the raw frames and payloads needed for packet-level forensics. It also only observes traffic routed through that specific router, missing switch-local communications between hosts on the same VLAN, and its sampling-based architecture cannot guarantee the full capture required for legal evidence.

Trap 2: Deploy an ARP spoofing tool to redirect traffic

ARP spoofing actively forges ARP replies to poison the victim's and gateway's ARP caches, redirecting traffic through the investigator's machine as a man-in-the-middle. This changes the actual forwarding topology, can cause dropped or delayed frames, and risks triggering switch protections like Dynamic ARP Inspection or port security—plus the diverted traffic is modified in transit, which taints the evidence's integrity.

Trap 3: Set the NIC to promiscuous mode on the forensic workstation

Setting the NIC to promiscuous mode merely instructs the host adapter to accept all frames that arrive on its physical link, but a switch forwards only frames destined to the workstation's own MAC address, plus broadcasts and multicasts. Since each switch port is an isolated collision domain, traffic between other hosts on the same switch never reaches this interface, so promiscuous mode alone captures nothing beyond the host's own traffic; a TAP, SPAN port, or inline device is required to obtain a copy of neighbor traffic.

Study all Network and Cloud Forensics common traps →

A
Enable NetFlow on the router and capture flows
Why it fails: NetFlow on a router exports aggregated flow records—source and destination IPs, ports, protocol, and byte/packet counts—rather than the raw frames and payloads needed for packet-level forensics. It also only observes traffic routed through that specific router, missing switch-local communications between hosts on the same VLAN, and its sampling-based architecture cannot guarantee the full capture required for legal evidence.
B
Configure a SPAN port on the switch
Configuring a SPAN (Switched Port Analyzer) port on the switch copies ingress and egress frames from specified source ports or VLANs to a designated monitor port, where a forensic workstation can record full packets without altering the original traffic path. This non-intrusive mirroring preserves switch performance and avoids introducing latency or dropping frames, making it the standard method for lawful network capture at Layer 2.
C
Deploy an ARP spoofing tool to redirect traffic
Why it fails: ARP spoofing actively forges ARP replies to poison the victim's and gateway's ARP caches, redirecting traffic through the investigator's machine as a man-in-the-middle. This changes the actual forwarding topology, can cause dropped or delayed frames, and risks triggering switch protections like Dynamic ARP Inspection or port security—plus the diverted traffic is modified in transit, which taints the evidence's integrity.
D
Set the NIC to promiscuous mode on the forensic workstation
Why it fails: Setting the NIC to promiscuous mode merely instructs the host adapter to accept all frames that arrive on its physical link, but a switch forwards only frames destined to the workstation's own MAC address, plus broadcasts and multicasts. Since each switch port is an isolated collision domain, traffic between other hosts on the same switch never reaches this interface, so promiscuous mode alone captures nothing beyond the host's own traffic; a TAP, SPAN port, or inline device is required to obtain a copy of neighbor traffic.

Full breakdown with real-world context →

Question 20mediummultiple choice

Read the full Network and Cloud Forensics explanation →

During a cloud forensics investigation, the investigator discovers that the cloud provider uses shared storage for multiple tenants. Which challenge is MOST likely to arise when acquiring a forensic image?

Trap 1: Physical acquisition of the storage device is required

In cloud environments, physical acquisition is not a forensic requirement because the underlying storage is abstracted by virtualization and multi-tenancy. Investigators can acquire evidence through logical means, such as snapshotting a virtual disk, exporting a cloud image, or using the provider's storage APIs. The fact that storage is shared does not force physical access; the hypervisor or storage backend presents a consistent logical view. Thus, this option is incorrect.

Trap 2: No API access to the storage system

The availability of API access to a cloud storage system is a function of the provider's service model, access controls, and contractual cooperation, not a consequence of shared storage. Most major providers offer forensic-friendly APIs or SDKs for enumerating and retrieving objects, and investigators often use these for logical acquisition. Shared physical media does not eliminate or obstruct these API endpoints, so this is not a challenge specific to multi-tenant storage. Therefore, this option is not correct.

Trap 3: Inability to decrypt data at rest

Decrypting data at rest is a general forensic obstacle that applies whether storage is dedicated or shared, because it depends on the encryption strategy (e.g., server-side vs. client-side) and the availability of keys. Cloud yields key-management services that can be leveraged, and investigators may obtain keys from the tenant. Shared storage does not inherently alter the decryption process, as encryption operates on logical volumes or objects regardless of physical media sharing. Hence, it is not a challenge unique to shared storage.

Study all Network and Cloud Forensics common traps →

A
Physical acquisition of the storage device is required
Why it fails: In cloud environments, physical acquisition is not a forensic requirement because the underlying storage is abstracted by virtualization and multi-tenancy. Investigators can acquire evidence through logical means, such as snapshotting a virtual disk, exporting a cloud image, or using the provider's storage APIs. The fact that storage is shared does not force physical access; the hypervisor or storage backend presents a consistent logical view. Thus, this option is incorrect.
B
No API access to the storage system
Why it fails: The availability of API access to a cloud storage system is a function of the provider's service model, access controls, and contractual cooperation, not a consequence of shared storage. Most major providers offer forensic-friendly APIs or SDKs for enumerating and retrieving objects, and investigators often use these for logical acquisition. Shared physical media does not eliminate or obstruct these API endpoints, so this is not a challenge specific to multi-tenant storage. Therefore, this option is not correct.
C
Inability to decrypt data at rest
Why it fails: Decrypting data at rest is a general forensic obstacle that applies whether storage is dedicated or shared, because it depends on the encryption strategy (e.g., server-side vs. client-side) and the availability of keys. Cloud yields key-management services that can be leveraged, and investigators may obtain keys from the tenant. Shared storage does not inherently alter the decryption process, as encryption operates on logical volumes or objects regardless of physical media sharing. Hence, it is not a challenge unique to shared storage.
D
Data commingling with other tenants
Data commingling with other tenants is the core challenge, as shared storage causes multiple organizations' data to occupy the same physical media, including potentially unallocated or leftover blocks. A forensic acquisition from such media may inadvertently capture another tenant's data, creating privacy, legal, and chain-of-custody complications. Investigators must employ careful isolation techniques, such as acquiring only the specific virtual disk or object while documenting that surrounding media contains unrelated data. This makes tenant-to-tenant isolation the primary difficulty in multi-tenant cloud forensics.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Network and Cloud Forensics sessions

Start a Network and Cloud Forensics only practice session

Every question in these sessions is drawn from the Network and Cloud Forensics domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Network and Cloud Forensics questions →Mixed CHFI session

Frequently asked questions

What does the CHFI exam test about Network and Cloud Forensics?: Be able to select the right tool and method for capturing network or cloud evidence while preserving integrity. The single most important thing: follow the order of volatility and document chain of custody, because improperly captured or unhashed evidence is easily challenged and excluded.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Network and Cloud Forensics questions in a focused session?: Yes — the session launcher on this page draws every question from the Network and Cloud Forensics domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other CHFI topics?: Use the topic links above to move to related areas, or go back to the CHFI question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the CHFI exam covers. They are not copied from any real exam or dump site.

Network and Cloud Forensics only

10 questions 20 questions 30 questions 50 questions

Mixed CHFI session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All CHFI questions Network and Cloud Forensics domain overview CHFI exam guide

Exam traps to avoid

▸Assuming a PCAP contains full application content when traffic was encrypted, so only metadata like IPs and ports is recoverable
▸Treating a live VM snapshot as a memory dump; snapshots capture disk state, not necessarily volatile RAM contents
▸Pulling cloud logs without preserving chain of custody or hashing, weakening admissibility of the evidence later

Network and Cloud Forensics practice questions

What to know about Network and Cloud Forensics

Common Network and Cloud Forensics exam traps

Network and Cloud Forensics questions

A forensic analyst is investigating a network breach and finds that the attacker used a technique that bypasses Network Access Control (NAC). Which of the following methods is commonly used to evade 802.1X authentication?

An organization uses a cloud-based SIEM to collect logs from multiple sources. The investigator notices gaps in the log data for a critical system during the incident timeframe. What is the MOST likely cause?

Which TWO of the following are common challenges in cloud forensics?

Which THREE of the following are essential steps in network forensic investigation?

Which TWO of the following are effective methods for detecting a man-in-the-middle attack on a network?

An investigator finds the above IAM policy attached to an S3 bucket. What is the security concern?

Exhibit

A forensic investigator needs to capture network traffic from a SPAN port on a switch to analyze an ongoing compromise. Which tool should the investigator use to collect the full packet capture (pcap) for later analysis?

A cloud forensic analyst is tasked with preserving evidence from an AWS S3 bucket that may contain malicious files. The bucket is publicly accessible, and the analyst wants to create a forensically sound copy. Which method BEST ensures integrity and chain of custody?

Which TWO of the following are valid techniques for collecting volatile network evidence from a live system during incident response?

During a cloud forensic investigation of an AWS EC2 instance, which TWO sources should be preserved to capture volatile data before instance termination?

Drag and drop the steps to create a forensic timeline using the Sleuth Kit (TSK) and log2timeline into the correct order.

Match each forensic artifact to its location in Windows (typical).

A forensic investigator is examining a PCAP file collected from a network tap. The investigator notices a large number of TCP SYN packets sent to various ports on a single target IP address, with no corresponding SYN-ACK responses. Which type of activity does this pattern MOST likely indicate?

An investigator needs to capture network traffic from a live network segment without altering the traffic flow. Which technique should they use?

During a cloud forensics investigation, the investigator discovers that the cloud provider uses shared storage for multiple tenants. Which challenge is MOST likely to arise when acquiring a forensic image?

Track your progress over time

Start a Network and Cloud Forensics only practice session

Related CHFI topic practice pages

Computer Forensics Investigation Process practice questions

Computer Forensics Fundamentals and Process practice questions

Application, Email and Cloud Forensics practice questions

Mobile and Malware Forensics practice questions