How to Hunt Threats With Splunk and Wazuh: A Practical SOC Analyst Guide

Threat hunting is not a single tool. It is a workflow that draws on multiple data sources, query languages, and investigative techniques simultaneously. Splunk and Wazuh are the two most commonly deployed open-source and enterprise SIEM platforms in SOC environments, and understanding how to use both is the practical skill set that separates entry-level analysts from Tier 2 investigators.

61% of organisations cite staffing as their top threat-hunting barrier. The analysts who close that gap fastest are the ones who practise with real tools on real data before they walk into a SOC environment for the first time. This guide covers what threat hunting with Splunk and Wazuh actually looks like, with the specific queries and techniques you need to build.

What Is the Difference Between Splunk and Wazuh?

Both are SIEM platforms. They serve different contexts and complement each other rather than compete.

Splunk is the enterprise standard. It ingests log data from across an entire organisation, indexes it, and makes it searchable through SPL (Search Processing Language). Splunk Enterprise Security adds correlation searches, risk-based alerting, and threat intelligence integration on top. It is the SIEM you will encounter most frequently in large enterprise and MSSP environments. Splunk's dominance in enterprise security operations is built on SPL: every investigation, detection, and dashboard in Splunk Enterprise Security is ultimately a search written in SPL.

Wazuh is the open-source alternative. It combines SIEM, XDR, and endpoint detection capability in a single deployable platform: a manager that receives logs, a set of built-in detection rules, file integrity monitoring, active response capability, and a dashboard built on the Elastic Stack. It is what you encounter in smaller organisations, home labs, and SOC training environments - and it is increasingly deployed alongside Splunk for endpoint-specific detection that Splunk's log ingestion does not cover natively.

In a combined deployment, Wazuh agents collect and pre-process endpoint data, and Wazuh alerts are forwarded to Splunk for correlation with other log sources. Understanding both is how you cover the full detection surface.

How Do You Hunt Threats in Splunk?

Threat hunting in Splunk is hypothesis-driven SPL. You form a hypothesis about attacker behaviour, translate it into a query that tests for evidence of that behaviour, and investigate what comes back.

The six SPL commands that cover the majority of SOC investigation and detection work are: stats (aggregate and count events by field values), eval (compute new fields and boolean expressions), rex (extract fields from unstructured text), transaction (group related events into sessions), lookup (enrich events with external data), and where (filter using eval-style boolean expressions). Mastering these six before learning the full SPL command set gives you the tools to handle 90% of real investigation scenarios.

Here are the hunt queries that matter most.

Hunting brute force authentication:

spl

index=auth sourcetype=*ssh* OR sourcetype=*windows* action=failure

| bucket _time span=5m

| stats count by src_ip, _time

| where count > 10

| sort -count

Buckets failed authentication events into 5-minute windows. More than 10 failures from the same source IP in 5 minutes is a brute force indicator.

Hunting lateral movement via Windows event logs:

spl

index=wineventlog EventCode=4624 Logon_Type=3

| stats count by src_ip, dest, user

| where count > 5

| sort -count

Event ID 4624 with Logon Type 3 is a network authentication. Multiple network logons from one source to multiple destinations in a short window indicates lateral movement.

Hunting suspicious PowerShell execution:

spl

index=wineventlog EventCode=4688 CommandLine="*-EncodedCommand*" OR CommandLine="*-NonInteractive*" OR CommandLine="*-WindowStyle Hidden*"

| table _time, host, user, CommandLine

| sort -_time

These PowerShell flags are consistently associated with malicious execution: encoded commands hide payload content, non-interactive and hidden window flags suppress any visible output.

Hunting C2 beaconing via DNS:

spl

index=dns

| bucket _time span=1h

| stats count by src_ip, query, _time

| where count > 50

| sort -count

High-frequency DNS queries to the same domain from the same source host are a classic C2 beaconing indicator. Fifty queries per hour is a conservative threshold - tune based on your environment's baseline.

As one practitioner noted: instead of reviewing the entire dataset, refine it step by step. Proper time scoping often makes the difference between efficient investigation and chaos. Always specify an explicit time range before expanding scope.

How Do You Hunt Threats in Wazuh?

Wazuh detection is rule-based. Each rule maps to a specific log pattern and fires an alert when that pattern appears in monitored data. Threat hunting in Wazuh means two things: reading and tuning existing rules, and writing new rules for behaviours the defaults do not cover.

Reading Wazuh alerts. Every Wazuh alert has a rule ID, a severity level (0 to 15), a description, and the raw log that triggered it. Severity 7 and above is where SOC attention should start. The Wazuh dashboard lets you filter by rule ID, agent (the source host), and time range.

Key rule categories for threat hunting:

• Rule group authentication_failures: Covers failed logins across SSH, Windows, and web applications. High volumes from the same source signal brute force.
• Rule group syscheck: File integrity monitoring. Any unexpected modification to system binaries, configuration files, or startup locations is a persistence indicator.
• Rule group rootcheck: Checks for known rootkit signatures and suspicious process behaviour.
• Rule group windows: Windows Security event detection covering logon events, process creation, privilege use, and service installation.

Writing a custom Wazuh rule for suspicious PowerShell parent-child relationships:

xml

<rule id="100200" level="12">

<if_sid>61603</if_sid>

<field name="win.eventdata.parentImage" type="pcre2">(?i)\\(winword|excel|outlook)\.exe</field>

<field name="win.eventdata.image" type="pcre2">(?i)\\powershell\.exe</field>

<description>Office application spawning PowerShell - possible macro execution</description>

<mitre>

<id>T1566.001</id>

</mitre>

</rule>

This fires when PowerShell is spawned by an Office application, a common macro-based malware execution pattern.

SOC analyst projects that create or tune Wazuh rules for suspicious parent-child process relationships, odd PowerShell command lines, or unusual persistence mechanisms, combined with dashboards that visualise events and drill into alerts, closely align with what enterprise EDR platforms like CrowdStrike, Microsoft Defender, and SentinelOne surface. Building this in a lab environment builds directly transferable skills.

How Does Wireshark Fit Into Threat Hunting?

Splunk and Wazuh operate on log data. Wireshark operates on packet data. They answer different questions.

SIEM logs tell you what happened at the operating system and application layer: which processes ran, which accounts authenticated, which files changed. Wireshark tells you what happened at the network layer: exactly what bytes were transmitted, how connections were established, and whether the traffic matches the protocol it claims to be.

Wireshark becomes essential in threat hunting when:

• A Splunk or Wazuh alert surfaces a suspicious outbound connection. The SIEM tells you a connection occurred. Wireshark tells you what was in it.
• DNS logs suggest C2 beaconing. Wireshark confirms whether the query volume, payload size, and interval are consistent with automated beaconing versus legitimate traffic.
• An alert suggests data exfiltration. Wireshark shows the exact bytes transferred, the destination, and whether the traffic is encrypted in a way that is consistent with the destination.

The practical workflow: Splunk identifies the suspicious host and time window. You pull a PCAP from that window (via network tap, Zeek, or Security Onion) and open it in Wireshark with the source IP filter applied. The SIEM and Wireshark together give you the full picture that neither provides alone.

The Core Hunt Techniques Reference Table

How Do You Practise These Skills Without a Live SOC Environment?

TryHackMe's SOC Level 1 path covers Splunk, Wazuh, and Wireshark in guided, hands-on lab rooms with real log data and pre-configured environments. You are not reading about SPL. You are writing queries against actual Windows event logs, actual network captures, and actual Wazuh alerts in a live environment that runs in your browser.

The Threat Hunting module extends this into hypothesis-driven investigation: forming a hunt hypothesis, selecting the right data sources, writing the queries, and documenting findings in professional format. Every room in both puts you inside the workflow described in this guide.

The most effective way to build speed with SPL specifically: practise with a specific query pattern until it is muscle memory, then move to the next. The analysts who are most effective in Splunk are not the ones who know the most SPL commands but the ones who have a library of proven patterns they can adapt quickly to new investigation scenarios. Build the library. The speed follows.

FAQ

What does a blue team do in cyber security? The blue team is the defensive side of a security operations function. Blue team analysts monitor networks and endpoints for threats, investigate alerts from SIEM platforms like Splunk and Wazuh, respond to confirmed incidents, and tune detection rules to improve coverage over time. The work spans alert triage at Tier 1 through deep forensic investigation at Tier 2 and above, threat hunting at senior levels, and detection engineering for the most experienced practitioners.

How do I practise log analysis for cyber security? Start with a SIEM platform and real log data. TryHackMe's SOC Level 1 path provides both: guided rooms with pre-loaded Windows event logs, network captures, and Splunk search environments. The specific skills to practise are: identifying which log sources contain evidence for a given hypothesis, writing queries that filter those logs down to the events you need, and reading event fields accurately enough to determine whether an alert is a true or false positive.

How do I use Wireshark for network analysis? Wireshark captures and dissects network traffic at packet level. The most important skill is filtering: use the display filter bar to narrow from millions of packets to the specific traffic you are investigating. Common useful filters: ip.addr == 10.10.10.5 to isolate a specific host, dns to view only DNS traffic, http.request to view only HTTP requests, tcp.flags.syn == 1 && tcp.flags.ack == 0 to see connection initiations. Follow a TCP stream (right-click any packet, select Follow > TCP Stream) to reconstruct the full conversation between two hosts. Use Statistics > Conversations to quickly identify the highest-volume connections in a capture.

What is the best way to practise network traffic analysis best practices? The most effective method is investigating real PCAP files from known attack scenarios. Pair Wireshark analysis with Zeek log review: Zeek transforms raw traffic into structured connection, DNS, HTTP, and SSL logs that are faster to query than reading individual packets. TryHackMe's network security monitoring content in the SOC Level 1 path provides guided practice across both tools against real attack traffic.