Network and Cloud Forensics practice questions

Physical acquisition of the storage device is required

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

No API access to the storage system

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

Inability to decrypt data at rest

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

VLAN hopping using double tagging

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

DNS tunneling to exfiltrate data

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

ARP poisoning to redirect traffic

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

Wait until normal business hours to capture traffic

Why wrong: Network traffic is ephemeral; delaying capture until normal business hours risks losing the very packets that document the incident, such as active sessions, DNS queries, or C2 beaconing that occurred during the suspected compromise window. Volatile evidence requires immediate acquisition because buffers, kernel packet queues, and switch port buffers overwrite continuously. Capturing later may also capture unrelated baseline traffic rather than the malicious activity, contaminating the evidentiary narrative.

Only record summary logs from the firewall

Why wrong: Firewall summary logs typically contain connection-level metadata (source/destination IP, ports, timestamps, and byte counts) but discard the packet payloads and application-layer data needed to reconstruct an exploit, extract a malware sample, or prove data exfiltration. Without full packet content, an investigator cannot inspect TCP stream reassembly, HTTP requests, or encrypted payloads that the firewall may only see as opaque sessions. Logs also depend on retention policies and may be incomplete or overwritten before collection.

Use a dedicated forensic workstation with a write blocker

Why wrong: A write blocker is designed for forensic acquisition of block-based storage media to prevent inadvertent writes during disk imaging; network interfaces are not block devices, and attaching a write blocker to a packet capture setup has no functional effect on capturing frames. Moreover, relying on a fixed forensic workstation may be less portable and could interfere with network tapping. The correct network evidence approach uses a dedicated capture interface in promiscuous mode with hashing afterward, not a storage-imaging write blocker.

Log into the VM and use a tool to create a crash dump

Why wrong: Logging directly into the VM and triggering a crash dump invokes the guest OS's bugcheck (e.g., NMI or KeBugCheck) pathway, which forces a system restart or enters a special crash state and writes a large hibernation/crash file to disk. This procedure intentionally halts processes, flushes caches, and appends kernel data to storage, thereby altering volatile memory state in ways that destroy the original evidence context — making it an invasive and inherently non-forensically-sound acquisition method.

Copy the virtual disk file (.vmdk) and extract memory from it

Why wrong: The .vmdk virtual disk file contains only the non-volatile storage contents (filesystem, sectors, and deleted blocks) that persist when the VM is powered off; it does not contain a representation of the VM's RAM address space. Since memory is volatile and separate from the virtual disk, copying the .vmdk yields only disk artifacts, and attempting to extract memory from it would be impossible because RAM contents are never written there — any pagefile or hibernation remnants would be stale and incomplete evidence, not a true memory capture.

Use a live forensic tool inside the VM to capture memory

Why wrong: Installing and running a live memory-capture tool inside the guest OS alters the very memory you are trying to preserve, as the tool's executable, loaded libraries, and process allocations occupy pageframes and modify kernel structures. Furthermore, the hypervisor provides no guarantee that a compromised or untrusted guest kernel hasn't subverted the tool's data, so the resulting capture lacks forensic integrity and does not reflect the pristine state of RAM before the tool executed.

Network latency delayed log delivery

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

Log rotation policy deleted logs prematurely

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

The system's log level was set to ERROR only

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

Operating system version of the source host

Why wrong: The operating system version of the source host is not stored in any network packet header or standard payload; it is a property of the host's local environment. Although an analyst might infer the OS family/version through TCP TTL values, window size, or HTTP User-Agent headers, this is heuristic fingerprinting, not a direct recovery of data from the capture. Unless the source intentionally transmits this information (e.g., an application querying OS info), the precise OS version cannot be extracted from PCAP traffic alone.

Registry data of the destination host

Why wrong: Registry data is a Windows-specific local database that stores hardware and software configuration for the destination host; it exists only on the host's disk and is not part of normal network communication. Network packets carry application-layer messages (e.g., HTTP, DNS), not the internal system state of the receiving machine. Even if a remote registry access protocol like WinRM/RPC is in use, the PCAP would only contain the transmitted registry values, not the full registry hive, making it an unreliable artifact for this scenario.

Disk partition table of the sending computer

Why wrong: The disk partition table is a low-level data structure written to the master boot record or GPT area of the physical disk, and it is never sent across the network during ordinary operations. In contrast to network traffic, partition metadata is accessed by the OS through block I/O and only leaves the host if an entire disk image is deliberately shared (e.g., for forensic duplication). Therefore, a PCAP capture of a network conversation will not contain any partition table information, as it is not part of the transmitted packet payload.

Contact law enforcement for cybercrime investigation

Why wrong: Contacting law enforcement at this stage is premature and can jeopardize the investigation. Legal referral is appropriate only after internal technical verification confirms that the activity is malicious, the scope is understood, and digital evidence has been legally preserved. Premature reporting risks violating jurisdictional thresholds or tipping off the adversary, and it bypasses the internal incident response workflow where attribution and impact are still unconfirmed.

Change the password of the root account

Why wrong: Changing the root account password is an invasive containment measure that can alert the adversary and destroy volatile forensic evidence such as active session tokens, kernel memory artifacts, or attacker-modified configuration files. In cloud environments, credential rotation may also break dependent services or logging pipelines, causing the loss of critical audit trail data. The password should be rotated only after evidence has been captured and a documented incident response plan authorizes credential remediation.

Immediately revoke the root access keys

Why wrong: Immediately revoking root access keys is a reactive action based on unconfirmed suspicion; it may lock out legitimate users, break automation, and cause an availability incident if the access was actually authorized. Revoking keys also destroys the ability to continue passive monitoring of the attacker's behavior, which is often necessary to determine entry point and dwell time. The proper sequence is to first validate the activity through log correlation, preserve forensic artifacts, and only then apply least-privilege containment measures under a formal IR decision.

NULL scan

Why wrong: A NULL scan sends TCP packets with no TCP flags set at all—the control bits are all zeroed out, making the packet look like a malformed or empty handshake segment. According to RFC 793, closed ports should reply with a RST to such a packet while open ports should drop it, but many modern operating systems deviate from this behavior, making the scan unreliable. From an analyst's perspective, NULL scans are just as anomalous as Xmas scans, but the signature is the complete absence of flags, not the presence of multiple unusual flags.

SYN scan

Why wrong: A SYN scan sets only the SYN flag, which is the first step of a normal TCP three-way handshake, so it mimics legitimate connection requests and is the most common scanning method. Because the scanner never completes the handshake (it sends a RST after a SYN-ACK), it is often called a half-open scan, and it leaves a trace in system logs as connection attempts but may not create full TCP sessions. For an IDS, SYN scans are indicated by a high volume of SYN packets without corresponding SYNs in return, but the individual packets themselves are not unusual in their flag combination.

ACK scan

Why wrong: An ACK scan sends TCP packets with only the ACK flag set, which is normally used as part of an established connection's acknowledgments; an unsolicited ACK packet is not a connection request at all. Its purpose is to probe firewall rulesets: a reachable port will typically respond with a RST, while a filtered port gives no reply, so it helps map ACLs rather than determine open ports. The single ACK flag distinguishes it from Xmas, and unlike SYN, it never initiates a connection attempt, making it a passive fingerprinting technique.

All cloud environments provide the same forensic capabilities

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

Easier evidence acquisition compared to traditional forensics

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

Physical access to the hard drive is always available

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

Conduct interviews with all network users

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

Perform a bit-for-bit copy of all hard drives

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

Analyze DNS amplification traffic

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

Implement port knocking for access control

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

Detect ICMP flood attacks

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

The gateway is unreachable

Why wrong: A gateway that is unreachable would not populate an ARP table entry for 192.168.1.1; successful ARP resolution requires the gateway to respond at Layer 2. The exhibit shows a resolved entry for the gateway, indicating that ARP requests to it were answered, so the gateway is clearly reachable. Additionally, gateway unreachability would manifest as an incomplete ARP entry or a timeout error, not as multiple IP addresses mapping to a single attacker-controlled MAC address.

Duplicate IP addresses on the network

Why wrong: Duplicate IP addresses on a network produce the opposite of the observed pattern: two different MAC addresses would be associated with the same IP address, causing an ARP cache conflict and possible rejection of late ARP replies. In contrast, the exhibit shows multiple IP addresses (including the gateway and hosts) sharing one identical MAC address, which is the hallmark of a single host spoofing many IPs. A genuine duplicate IP scenario would also trigger gratuitous ARP or DAD (Duplicate Address Detection) warnings, not a consistent one-MAC-to-many-IP mapping.

MAC address filtering is enabled

Why wrong: MAC address filtering is a Layer 2 port security feature that either permits or denies frames based on the source MAC address; it does not modify the IP-to-MAC mappings stored in a host's ARP cache. If filtering were enabled and blocking certain frames, hosts would still resolve ARP from allowed devices, but the exhibit shows a single MAC claiming multiple IPs, which is not a side effect of any filtering mechanism. Furthermore, MAC filtering typically prevents unknown devices from joining the network at the switch port level, not cause a legitimate host's ARP table to be overwritten with identical MAC entries for every IP.

The resource does not include all objects

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

The policy version is outdated

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

The policy allows anyone to write objects to the bucket

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

Man-in-the-middle attack

Why wrong: A man-in-the-middle attack would leave distinct traces such as ARP cache poisoning (duplicate MAC addresses for a single IP), unexpected SSL/TLS certificate validation failures, or interception of credentials via a rogue gateway. The exhibit shows no such protocol-level redirection, DNS poisoning, or spoofed addressing; it only displays repeated SSH authentication failures. Without evidence of traffic interception or credential eavesdropping, classifying this as MITM is unsupported.

SQL injection attack

Why wrong: SQL injection attacks exploit web application input fields by injecting malicious SQL syntax, often producing distinctive HTTP request patterns containing encoded characters, UNION clauses, or database error messages in the response. The exhibit is clearly from an SSH daemon log, not a web server log, and the entries show authentication failures rather than HTTP queries. There are no SQL statements, query strings, or database output anomalies, so this is not an SQL injection attack.

Denial of Service attack

Why wrong: A denial-of-service attack seeks to exhaust resources or disrupt availability, typically via high-volume traffic like SYN floods, ICMP floods, or connection floods that overwhelm the target. The log excerpt shows a systematic sequence of SSH login failures from one source IP, which is low-bandwidth and does not indicate service unavailability, resource exhaustion, or network saturation. Repeated failed logins without a spike in traffic or downtime fail to meet the criteria for a DoS attack.

The bucket policy was automatically modified by an AWS service

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

An insider with IAM permissions made the change using a legitimate session

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

The CloudTrail logs are inaccurate and the policy change was not made

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

The antivirus software deleted the malicious files before the image was taken

Why wrong: Antivirus deletion would be documented in the AV console and local logs, including quarantine records and event IDs. Even if it purged the malware, that activity would create a clear audit trail, making the absence of files an evidentiary clue rather than a mystery. Additionally, forensic imaging would still capture deleted data remnants such as alternate data streams or file system slack, so the complete absence of any malicious file on the image contradicts a simple AV-removal explanation.

The hard drive was reimaged before the forensic image was taken

Why wrong: Reimaging a hard drive overwrites the file system with a fresh OS image, destroying all prior data, including any malware. If this had occurred, the forensic image would show an entirely new installation with no user artifacts, yet the breach investigation found evidence of an attack elsewhere — whereas proper protocol requires imaging the original drive immediately after isolation, before any destructive step. The presence of post-isolation evidence and intact original filesystem metadata disproves reimaging.

The RAT uses a rootkit to hide its files

Why wrong: Rootkits operate by hooking system calls or kernel APIs to conceal files from the OS, but they do not erase the data from the storage medium. Forensic examiners can bypass these hooks by using raw disk reads, signature scans, and file carving, which expose hidden files that do exist. Since the disk image in this case contains no hidden malicious executable whatsoever, a rootkit-based RAT cannot be the explanation.

Examine CloudTrail logs for disk contents.

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

Access the VM’s operating system via the cloud console’s serial console.

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

Use SSH credentials from the investigation to connect to the terminated instance.

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

NetFlow

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

nmap

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

Wireshark

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

Download each object via the AWS Management Console and compute SHA256 hashes manually.

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

Use the AWS CLI cp command recursively without any flags.

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

Generate a presigned URL for the bucket and use wget to download all files.

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

Using route print to view the IP routing table.

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

Using ipconfig /displaydns to view the DNS resolver cache.

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

Running arp -a to view the ARP table.

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