Search & Correlation

From Dashboard to Investigation

In Lesson 2.3, you learned to read dashboards — spotting spikes, gaps, and anomalies at a glance. But when something catches your eye, you need to drill deeper. Searching is how you go from "something looks wrong" to "here's exactly what happened."

A SOC analyst's search ability is their most important technical skill. A fast analyst can write a query in 10 seconds, find the relevant events in 30, and have a hypothesis in 60. A slow analyst scrolls through pages of alerts hoping something jumps out. The difference is query literacy.

The 80/20 Rule of SOC Investigation: 80% of your investigation time should be spent reading and analyzing results, not writing queries. If you're spending more time constructing searches than reading results, you need to learn the query syntax better.

Click to enlarge

Search Syntax in Wazuh

Wazuh Dashboard uses OpenSearch as its backend, which supports two query syntaxes:

1. Lucene Query Syntax (the search bar) — quick, simple, used for fast filtering
2. OpenSearch Query DSL (Dev Tools) — JSON-based, powerful, used for complex queries

For daily analyst work, Lucene syntax in the search bar covers 90% of your needs. You'll use Query DSL when building automated searches or complex correlations.

Lucene Syntax Essentials

The search bar in Wazuh Security Events accepts Lucene query strings. Here are the patterns you'll use every day:

Time Range — The Most Important Filter

Every search should have a time constraint. Without it, you're searching all historical data, which is slow and returns noise from weeks ago.

The Investigation Query Toolkit

Here are the most common search queries a SOC analyst runs during investigations. Memorize these — you'll use them daily.

Query 1: All Activity on a Specific Host

agent.name:linux-web-01

Use this as your starting point when a host appears in a dashboard alert. Sort by timestamp to see the chronological story.

Query 2: High-Severity Alerts Only

rule.level:[10 TO 15]

Skip the noise and focus on what matters. Combine with a time range to see recent critical activity.

Query 3: Activity from a Specific Source IP

data.srcip:185.220.101.42

When you identify a suspicious IP, search for ALL events involving it — not just the alert that caught your attention. The attacker may have interacted with multiple systems.

Query 4: Failed Authentication Across All Systems

rule.groups:authentication_failed

This catches failed SSH logins, failed Windows logons, and any other authentication failure across all agents and log sources. It's broader than searching for a single rule ID.

Query 5: Specific Windows Event ID

data.win.system.eventID:4625 AND agent.name:WIN-SERVER-01

Drill into a specific Windows event type on a specific host. Change the event ID to investigate different activity types.

Query 6: File Integrity Changes

rule.groups:syscheck AND (syscheck.path:/etc/passwd OR syscheck.path:/etc/shadow)

Find all file integrity monitoring alerts for critical system files. Changes to these files almost always warrant investigation.

Query 7: Firewall Blocks to a Specific Port

rule.groups:firewall_drop AND data.dstport:445

Find all firewall events targeting a specific port. Port 445 (SMB) is a high-value target for lateral movement attempts.

Click to enlarge

Event Correlation: Connecting the Dots

Individual events tell you what happened. Correlation tells you why — by connecting related events across time, hosts, and log sources into a coherent narrative.

Correlation is the skill that separates L1 analysts (who process alerts) from L2 analysts (who investigate incidents). It's the ability to look at a failed login, a new service installation, and a file change and ask: "Are these related?"

The Three Dimensions of Correlation

Building a Correlation: The Attack Timeline

Let's walk through how an analyst correlates events during an investigation. Imagine your dashboard shows a spike in high-severity alerts on linux-web-01 at 06:25 UTC.

Step 1: Identify the trigger alert

agent.name:linux-web-01 AND rule.level:[10 TO 15]

You find rule 5551 (SSH brute force) fired at 06:25. Source IP: 185.220.101.42.

Step 2: Search for all activity from this IP

data.srcip:185.220.101.42

You discover this IP also appears in firewall logs (blocked SMB attempts on port 445) and earlier failed SSH attempts starting at 06:15. The attacker was probing before the brute force.

Step 3: Check what happened on the target host AFTER the brute force

agent.name:linux-web-01 AND timestamp:[06:25 TO 07:30]

You find:

• 06:30 — Successful SSH login (rule 5501) from a different internal IP (pivoted?)
• 06:35 — sudo to root (rule 5402)
• 06:37 — /etc/passwd modified (rule 550, syscheck)
• 06:40 — /etc/shadow modified (rule 550, syscheck)

Step 4: Build the narrative

Timeline: Reconnaissance (06:15) → Brute force (06:25) → Login (06:30) →
          Privilege escalation (06:35) → Account manipulation (06:37-06:40)

This is a complete attack chain — from initial probing to credential theft to persistence. Without correlation, each event looks like an isolated alert. Together, they tell the story of a compromise.

Click to enlarge

Cross-Source Correlation

The most powerful correlations connect events from different log sources. An attacker's actions leave traces across multiple systems — the SIEM is the only place where all those traces converge.

Example: Correlating Across Four Log Sources

Notice how the attacker's trail crosses firewall → SSH → authentication → file integrity → DNS — five different log sources, four different agents. No single log source tells the full story. Only by correlating across all of them do you see the complete picture.

Practical Correlation Techniques

Technique 1: Pivot Searching

Start with one indicator and "pivot" to find related events:

1. Start with an IP: data.srcip:185.220.101.42 — find all events from this IP
2. Pivot to the target host: agent.name:linux-web-01 — see everything that happened on that host
3. Pivot to the user: data.dstuser:root — see all activity for the targeted account
4. Pivot to the time window: Narrow to the 30-minute window around the incident

Each pivot reveals new connections and expands your understanding of the incident scope.

Technique 2: Baseline Comparison

Compare current activity against what's normal:

agent.name:linux-web-01 AND rule.id:5503

Run this for "Last 7 days" and note the average count. Then run it for "Last 24 hours." If today's count is 10x the average, the brute force campaign is real and recent.

Technique 3: Time Window Analysis

When you know the approximate incident time, create a tight window:

agent.name:linux-web-01 AND timestamp:[2026-02-15T06:00:00 TO 2026-02-15T07:00:00]

Sort by timestamp ascending. Read the events in order — this gives you the attack narrative in chronological sequence.

Exporting Search Results

Investigation findings need to be documented. Here's how to export from Wazuh:

Common Search Mistakes