Lab 2.4 — Hunt by Query

Lab Overview

The Scenario

Your SOC team received a threat intelligence report: "A threat actor group has been targeting organizations using a combination of SSH brute force, SQL injection, and privilege escalation via sudo abuse. They use automated tools (sqlmap) and encode their payloads in base64."

Your job is to write queries that would find this exact attack pattern in your Wazuh data — and you'll discover that the pre-loaded alerts match the description perfectly.

Part 1: Query Basics — Single-Field Searches

Understanding the Search Bar

The Wazuh Dashboard search bar (top of the Security Events page) accepts both Wazuh Query Language (WQL) and Lucene syntax. For this lab, we'll use Lucene syntax as it's the most common across SIEM platforms.

Query 1: Find All Brute Force Alerts

Start with the simplest possible query — searching a single field:

rule.id: 18152

Run this query. Record:

• How many results did you get?
• What agent(s) are involved?
• What time range do the events cover?

Query 2: Find All Events from a Specific Agent

agent.name: linux-web-01

Run this query. Record:

• Total number of alerts for this agent
• What is the highest severity alert?
• How many distinct rule.ids are present?

Query 3: Find All Critical Alerts

rule.level: >= 12

Run this query. Record:

• Total critical alerts across all agents
• Which agent has the most critical alerts?
• What rule descriptions appear?

Part 2: Multi-Field Queries — Combining Conditions

Understanding Boolean Operators

Hunt Query 1: External SSH Brute Force

The threat intel report mentions SSH brute force. Write a query that finds SSH authentication failures from external IPs on the Linux web server:

agent.name: linux-web-01 AND rule.groups: authentication_failed AND data.srcip: 185.220.101.42

Run this query and document:

HUNT QUERY #1: External SSH Brute Force
────────────────────────────────────────
Query:    agent.name: linux-web-01 AND rule.groups: authentication_failed AND data.srcip: 185.220.101.42
Results:  [count]
Agent(s): [list]
Time Span: [first event] to [last event]
Severity: [min] to [max]
Key Finding: [what does this tell you?]

Click to enlarge

Hunt Query 2: Successful Logon After Brute Force

Now find the indicator that the brute force SUCCEEDED — a successful logon from the same attacker network:

rule.id: 60106 AND data.win.eventdata.ipAddress: 91.234.99.87

Document your results using the same template.

Part 3: Advanced Query Techniques

Wildcards

Use * for partial matches:

data.srcuser: www*

This finds all events where the source user starts with "www" — catching www-data, www-admin, etc. Run this query to find the web shell sudo escalation events.

Nested Field Queries

Wazuh stores Windows event data in nested fields. To query them:

data.win.eventdata.targetUserName: Administrator AND data.win.system.eventID: 4625

This finds all failed logon attempts targeting the Administrator account specifically.

Hunt Query 3: SQL Injection Detection

The threat intel mentions sqlmap. Build a query to find SQL injection attempts:

rule.id: 31103

Then refine it to find only the POST-based injection (more dangerous):

rule.id: 31103 AND full_log: *POST*

Document your results. How does the POST payload differ from the GET payload?

Hunt Query 4: Privilege Escalation Chain

Find the sudo abuse mentioned in the threat intel:

data.srcuser: www-data AND rule.groups: syslog AND rule.groups: sudo

Document your results. List the commands in chronological order. What's the escalation path?

Hunt Query 5: Encoded Payload (C2 Communication)

The threat intel mentions base64-encoded payloads. Find the reverse shell:

rule.id: 100002 AND full_log: *base64*

Document your results. Copy the base64 string — you decoded this in Lab 2.1 if you completed it. What IP and port does the reverse shell connect to?

Part 4: Negative Queries — Filtering Out Noise

One of the most practical query skills is filtering OUT noise to see what remains.

Exercise: Remove Heartbeats

agent.name: linux-web-01 AND NOT rule.level: 3

Compare the result count with and without the NOT clause. What percentage of linux-web-01's alerts are informational?

Exercise: Focus on Unique Attackers

NOT data.srcip: 10.* AND rule.level: >= 8

Click to enlarge

This removes all internal IPs and shows only medium+ severity alerts from external sources. How many results remain? These are your highest-priority investigation targets.

Part 5: Build Your Threat Hunting Query Library

Using the 5 hunt queries you've built, create a formal library:

THREAT HUNTING QUERY LIBRARY
═══════════════════════════════
Environment: CyberBlue Lab (Wazuh)
Date Created: [today's date]
Analyst: [your name]

QUERY 1: SSH Brute Force Detection
  Syntax: agent.name: linux-web-01 AND rule.groups: authentication_failed AND data.srcip: 185.220.101.42
  Purpose: Detect external SSH brute force attempts
  Expected Results: Multiple failed auth events from known attacker IP
  Lab Results: [your count and findings]

QUERY 2: Brute Force Success Indicator
  Syntax: rule.id: 60106 AND data.win.eventdata.ipAddress: 91.234.99.87
  Purpose: Detect successful logon after previous failures
  Expected Results: At least 1 event showing attacker achieved access
  Lab Results: [your count and findings]

QUERY 3: SQL Injection via Automated Tool
  Syntax: rule.id: 31103 AND full_log: *POST*
  Purpose: Find POST-based SQL injection attempts (data exfiltration risk)
  Expected Results: Events with sqlmap user-agent and UNION SELECT payloads
  Lab Results: [your count and findings]

QUERY 4: Sudo Privilege Escalation
  Syntax: data.srcuser: www-data AND rule.groups: syslog AND rule.groups: sudo
  Purpose: Detect web service account escalating to root
  Expected Results: 3 events showing id → shadow read → full shell
  Lab Results: [your count and findings]

QUERY 5: Encoded C2 Payload
  Syntax: rule.id: 100002 AND full_log: *base64*
  Purpose: Find obfuscated command execution (reverse shells, downloaders)
  Expected Results: Base64-encoded bash reverse shell
  Lab Results: [your count and findings]

Deliverable Checklist

Before completing the lab, ensure you have:

• 5 Hunt Query Results — each with documented syntax, result counts, and key findings
• Boolean Operator Practice — at least 3 queries using AND, OR, or NOT
• Wildcard and Range Queries — at least 2 queries using * wildcards or range syntax
• Noise Filtering Results — before/after counts showing the impact of negative queries
• Threat Hunting Query Library — formal document with all 5 queries, purposes, and results

What's Next

In Lab 2.5 — Read the Rule, you'll go behind the scenes to understand the Wazuh rules that generate alerts. Instead of just querying alerts, you'll read the rule definitions that created them — understanding the logic, thresholds, and fields that determine what gets flagged and what gets missed.