Network + SIEM Correlation

One Attack, Two Perspectives

An attacker launches a SQL injection campaign against a web application running on linux-web-01. The attack is real, the tools are real, and both your network sensor and endpoint agent fire alerts. But each tool tells a fundamentally different part of the story.

What Suricata sees on the wire:

• HTTP requests with a sqlmap User-Agent string hitting the web server
• Suspicious URI patterns containing UNION SELECT, encoded payloads, and error-based injection strings
• Minutes later, an outbound connection from the web server to an external IP on a non-standard port — C2 beaconing at regular intervals
• DNS queries to exfil.badactor.com with unusually long subdomain labels — encoded data being tunneled out

What Wazuh sees on the host:

• Apache error logs spiking with 500 status codes and SQL syntax errors
• A new file appearing in /var/www/html/uploads/ — a web shell
• sudo commands executed by the www-data user, which should never have elevated privileges
• A new systemd service registered, pointing to a binary in /tmp/
• File integrity monitoring (FIM) alerts for modified /etc/passwd

Neither tool alone tells the complete story. Suricata knows the attack came from the network and data left via DNS tunneling, but it has no idea a web shell was dropped or that privilege escalation occurred on the host. Wazuh knows the host was compromised and a persistence mechanism was installed, but it cannot see the C2 beacon timing or the DNS exfiltration payload content.

Network detection tells you WHAT crossed the wire. Endpoint detection tells you WHAT HAPPENED on the host. Correlation tells you the FULL STORY.

Together, these two perspectives build the complete kill chain: initial access via SQL injection (Suricata), web shell deployment (Wazuh), privilege escalation (Wazuh), C2 establishment (Suricata), lateral movement (both), and data exfiltration (Suricata). That unified picture changes everything — the severity, the scope, and the urgency of the response.

What Each Source Uniquely Provides

Every detection source has blind spots. Understanding what each tool can and cannot see is the foundation of effective correlation. The following table maps common attack evidence to the detection source best positioned to capture it.

Click to enlarge

Correlation Keys — How to Link Events Across Tools

Suricata alerts live in EveBox. Wazuh alerts live in the Wazuh dashboard. They are separate systems with separate schemas, separate timestamps, and separate naming conventions. To link events across these tools, you need correlation keys — shared data points that appear in both systems and let you connect the dots.

Timestamp

The most fundamental correlation key. Events from the same attack cluster within a tight time window — typically minutes, not hours. If Suricata records a SQL injection attempt at 14:32:15 and Wazuh records a web server error at 14:32:18, those three seconds of difference strongly suggest the same event.

Time synchronization matters enormously here. Both Suricata and Wazuh should be synced to the same NTP source. In the CyberBlueSOC lab environment, all containers share the host clock, so timestamps align. In production environments, clock drift between sensors can make correlation significantly harder.

IP Address

The source IP in a Suricata alert matches the attacker's IP. The agent IP in a Wazuh alert identifies the target host. When Suricata shows SQL injection from 10.99.99.1 targeting 10.0.0.10, and Wazuh shows web server errors on the agent at 10.0.0.10, you have connected network and endpoint events for the same attack.

Hostname

IP addresses are numbers. Hostnames give context. The IP 10.0.0.10 becomes meaningful when you know it maps to linux-web-01. Mapping IPs to hostnames lets you connect Suricata network events (which reference IPs) to Wazuh agent events (which reference hostnames). Maintain a mapping table or use DNS reverse lookups to bridge the gap.

User Context

After correlating at the host level, the endpoint data reveals which user account was involved. Was it the www-data service account? A named administrator? A compromised user? User context is almost exclusively available from the endpoint — Suricata cannot tell you who was logged in when the connection was made.

ATT&CK Technique

Both Suricata rules and Wazuh rules can reference MITRE ATT&CK technique IDs. When a Suricata alert maps to T1190 (Exploit Public-Facing Application) and a Wazuh alert on the same host at the same time maps to T1059 (Command and Scripting Interpreter), those two technique IDs tell you the attacker has progressed from initial access to execution — even though the raw alert data looks completely different.

Building a Unified Timeline

The real power of correlation is the unified timeline — a single chronological view that weaves network and endpoint events into a coherent attack narrative. Here is the Operation Wire Tap scenario mapped across both detection sources:

Click to enlarge

The Correlation Workflow in Practice

Correlation is a structured process, not an intuition. Follow these steps every time you investigate a multi-source alert cluster:

Step 1 — Start with the highest-severity alert. Open EveBox or the Wazuh dashboard and find the alert with the highest severity or the most specific signature. A C2 beacon detection is a better starting point than a generic port scan.

Step 2 — Extract the correlation keys. From that alert, note the source IP, destination IP, timestamp, and any ATT&CK technique references. These are your search terms for the next step.

Step 3 — Search the other tool. If you started with a Suricata alert in EveBox, now search Wazuh for events from the same target host in the same time window (expand to +/- 15 minutes to account for clock differences and attack progression). If you started with Wazuh, search EveBox for network events involving the same IP.

Step 4 — Map matching events to ATT&CK techniques. For each correlated event, identify the ATT&CK tactic and technique. This transforms raw log data into a structured attack narrative.

Step 5 — Build the timeline in chronological order. Arrange all correlated events by timestamp, regardless of which tool generated them. The chronological sequence reveals the kill chain progression.

Step 6 — Identify gaps. Are there any kill chain stages missing from your timeline? If you see initial access and C2 but no exploitation or installation events, that does not mean those stages did not happen — it means your detection missed them. Note the gaps explicitly; they inform where detection coverage needs improvement.

Step 7 — Write the correlation summary for escalation. Document the unified timeline, the confidence level (how many correlation keys matched), the scope (which hosts are affected), and a recommended response action. This summary is what the L2 or L3 analyst and the incident commander will use to make decisions.

When Correlation Changes the Verdict

Single-source alerts are inherently ambiguous. Correlation eliminates that ambiguity by adding context from a second independent source. Here are three examples of how correlation transforms an analyst's assessment:

Example 1: Failed SSH Login

• Single source (Wazuh): A failed SSH login from an external IP on linux-web-01. Verdict: Low priority, probably an automated bot. Thousands of these appear daily on internet-facing servers.
• Correlated: The same external IP also triggered a port scan alert in Suricata 5 minutes earlier. Then a successful SSH login appears in Wazuh 2 minutes after the failed one. Then Wazuh reports a new service created on the host. Correlated verdict: Critical — active compromise in progress. Escalate immediately.

Example 2: DNS Query to Suspicious Domain

• Single source (Suricata): DNS query to a newly registered domain with high entropy in the name. Verdict: Possibly malicious, but could be a CDN subdomain or legitimate service. Medium priority.
• Correlated: Wazuh shows that the process making the DNS query is /tmp/.hidden/beacon, running under the www-data user on a web server that was flagged for a FIM alert 30 minutes ago. Correlated verdict: Confirmed C2 communication from a compromised host. Escalate with full timeline.

Example 3: Large Outbound Transfer

• Single source (Suricata): 500 MB transferred from an internal host to an external cloud storage IP over HTTPS. Verdict: Could be a legitimate backup or file upload.
• Correlated: Wazuh shows tar and gzip commands run on that host 10 minutes before the transfer, compressing /var/lib/postgresql/data/. The user was www-data, not an administrator. Correlated verdict: Data exfiltration of the production database. Critical escalation with forensic hold.

In each case, the single-source alert could reasonably be deprioritized or investigated at normal speed. The correlated evidence transforms the verdict from ambiguous to definitive, and the response from "when you get to it" to "drop everything."

What's Next

You now have the complete network detection toolkit: what NIDS captures and why it matters (Lesson 3.1), how Suricata rules work and how to read them (Lesson 3.2), protocol-level analysis for HTTP, DNS, and TLS (Lesson 3.3), DNS-specific threats and tunneling detection (Lesson 3.4), and cross-tool correlation that turns isolated alerts into a unified attack narrative (this lesson).

It is time to put it all into practice. In Lab 3.1 — Network Alert Triage, you will open EveBox and face 49 alert groups from the Operation Wire Tap attack. Categorize them by severity, find the false positives hiding among real threats, and escalate the critical ones. Then in Labs 3.2 through 3.4, you will read and interpret Suricata rules, hunt for DNS anomalies in live traffic, and build a unified timeline from both network and endpoint data — correlating exactly the way you learned in this lesson.

The wire is waiting.