Finding why an incident happened at its root helps you stop it from happening again. Root cause analysis is the focused process of uncovering the underlying factors that set off the incident, digging beyond the visible symptoms to identify what failed or allowed the event to occur. By pinpointing the true causes, you can implement corrective actions that address the system or process weaknesses, reducing the chance of recurrence. Forensic analysis, while important, concentrates on reconstructing events and gathering evidence after an incident, often for accountability or legal purposes, rather than preventing future occurrences. Risk assessment evaluates potential threats and vulnerabilities to inform mitigation priorities, not specifically the cause of a past incident. Business continuity planning focuses on keeping operations running and recovering from disruptions, not diagnosing why the incident happened in the first place.

Capturing and inspecting raw frames with a visual, protocol-level breakdown is what this is about. Wireshark provides a graphical interface to capture packets from a network interface and then dissect every frame into a detailed protocol stack. You can see each packet’s metadata (time, source, destination, protocol), drill into the fields of Ethernet, IP, TCP/UDP, and many other protocols, and view both the decoded interpretation and the raw byte values. It also supports live captures, post-capture analysis, powerful display filters, stream reassembly, and exporting captures for later review. This combination of live capturing and in-depth, GUI-based analysis makes Wireshark the right tool for examining raw network frames. In contrast, tcpdump and Windump are command-line packet sniffers, and Netcat is a simple data transfer utility, not a protocol analyzer with a GUI.

Beaconing patterns in traffic—where a compromised host checks in with a remote controller at regular, periodic intervals—and DNS query anomalies are classic signs of Command-and-Control activity. The regular beaconing shows an automated beacon to a distant server, which is how an attacker maintains control over the compromised host. DNS anomalies strengthen this indication because many C2 setups use DNS as a covert channel, sending unusual or high-frequency DNS requests, or lookups to suspicious or generated domains to carry instructions or exfiltrate data without obvious HTTP traffic. Together, these patterns point to a controlled channel rather than normal user activity. Regular user authentication attempts can occur in legitimate scenarios and don’t necessarily indicate a C2 channel. High volume inbound web traffic from trusted domains can be legitimate for services like content delivery or partner access, not typically C2. Isolated internal traffic with no external connections suggests no external control channel, which argues against C2 activity.

Understanding the difference between SIEM and SOAR is about contrasting what each platform does in security operations. SIEM is about detection and monitoring: it collects, normalizes, and correlates log data from across the environment to surface security alerts and provide visibility. SOAR centers on automation and response: it orchestrates actions across tools, runs playbooks, and manages incidents and case workflows to respond to threats. The option that pairs SIEM with SOAR best captures this distinction because it directly references both sides—the detection/monitoring function versus the automated response and orchestration function. The other choices don’t address this difference: clock synchronization is about timing, vulnerability analysis focuses on assessing weaknesses, and listing artifacts/tools is unrelated to how these two platforms differ in operation.