Wazuh: The Complete Gold-Standard Tutorial

Zero to Intermediate | Theory + Hands-on Labs + Real-World Security Monitoring

Stable version: 4.14.8
Level: Beginner → Intermediate
Last verified: 11 October 2026
Primary lab OS: Ubuntu 24.04 LTS

This course teaches you how to use Wazuh from scratch, including deployment, endpoint monitoring, threat detection, vulnerability assessment, incident investigation, and security automation.

The tutorials are built around a single working lab, so you progressively develop a functional security monitoring environment rather than completing unrelated demonstrations.

Version verification: Wazuh 4.14.8 was released on September 23, 2026, and is the latest stable release verified in the official release listings. Wazuh 5.0 remains in beta, so this guide uses the stable 4.x architecture and commands.

1. Learning plan and tutorial sequence

Total study plan

Total: 180 minutes

Theory target

Theory: 55 minutes

Practical target

Practical: 125 minutes

#	Tutorial	Duration
1	Introduction to Wazuh	10 min
2	Security and Log Monitoring Fundamentals	10 min
3	Wazuh Architecture and Working	15 min
4	Wazuh Installation and Setup	25 min
5	Wazuh Agent Installation and Management	15 min
6	Log Collection, Monitoring, and Alerts	20 min
7	Wazuh Rules, Decoders, and Detection Engineering	20 min
8	File Integrity Monitoring (FIM)	15 min
9	Security Configuration Assessment and Vulnerability Detection	20 min
10	Threat Hunting and Security Investigation	10 min
11	Active Response and Security Integrations	15 min
12	End-to-End Security Monitoring Mini Lab	5 min
	Total	180 min

The 3-hour schedule is an accelerated practical lesson. Completing every optional cross-platform installation, deeper exercise, and troubleshooting scenario in this reference guide will require additional study time.

Lab prerequisites

Requirement	Recommended setup
Wazuh server	Ubuntu 24.04 LTS VM
Server resources	4 vCPU, 8 GiB RAM, 50 GB storage
Monitored endpoint	A second Ubuntu VM
Optional endpoints	Windows 11 and macOS
Connectivity	Private network between server and agents
Access	Administrator or `sudo` privileges
Basic utilities	SSH client, Bash, curl, text editor
Browser	Modern browser supporting HTTPS

Wazuh officially recommends the server resources shown above for its all-in-one quickstart deployment with 1–25 agents.

For consistency, the tutorials use these example addresses:

Wazuh server: 192.168.56.10
Ubuntu monitored endpoint: 192.168.56.20

These are example private network addresses, not addresses discovered on your equipment. Replace them with your actual lab addresses.

Tutorial 1 — Introduction to Wazuh

10 minutes | Fundamentals

1.1 What is Wazuh?

Wazuh is an open-source security monitoring platform combining two important security disciplines:

SIEM — Security Information and Event Management

Collects, analyzes, stores, and correlates security events from multiple systems, helping security teams identify suspicious activity.

XDR — Extended Detection and Response

Combines security telemetry from different environments to help detect, investigate, and respond to potential threats.

For example, imagine an organization has 100 Linux servers, 50 Windows systems, and multiple cloud workloads. Without a centralized security monitoring system, administrators would need to inspect different machines and logs separately.

Wazuh provides a central location to understand what is happening.

1.2 Why is Wazuh needed?

Consider this scenario:

An attacker attempts to access a Linux server using SSH.

The server may record unsuccessful authentication attempts in system logs, but an administrator might not notice those entries immediately.

Wazuh can collect authentication events, analyze them against predefined security rules, and create alerts for suspicious authentication activity.

flowchart TD
    A["Suspicious activity on endpoint"] --> B["Security event generated"]
    B --> C["Wazuh agent collects event"]
    C --> D["Wazuh server analyzes event"]
    D --> E{"Detection rule matched?"}
    E -->|Yes| F["Generate security alert"]
    E -->|No| G["No alert from this rule"]
    F --> H["Investigate in dashboard"]
    H --> I["Decide on response"]

Notice that Wazuh does not automatically prevent every threat. Detection depends on available telemetry, enabled monitoring capabilities, rules, configuration, and any response mechanisms you deliberately configure.

1.3 Main features of Wazuh

Feature	Purpose	Example
Log analysis	Identify suspicious events	Failed SSH logins
File Integrity Monitoring	Detect file changes	Modified application configuration
Vulnerability Detection	Discover potentially vulnerable software	Installed package affected by a CVE
Security Configuration Assessment	Identify insecure settings	Weak SSH configuration
Threat detection	Match events against threat patterns	Repeated authentication failures
Active Response	Execute defined response actions	Block a source IP
System inventory	Track endpoint software and system details	Installed applications
Compliance support	Provide security monitoring evidence	CIS-related checks

1.4 Wazuh vs traditional monitoring

Aspect	Traditional monitoring	Wazuh
Primary focus	Health and availability	Security visibility and detection
Common metrics	CPU, RAM, disk, latency	Authentication, integrity, vulnerabilities, security events
Typical question	Is the server healthy?	Is suspicious activity occurring?
Detection method	Thresholds and health checks	Rules, decoders, security assessments
Main users	Operations, SREs	SOC, security, DevSecOps

Tools such as Prometheus and Datadog can also collect logs and offer security capabilities, but traditional infrastructure monitoring and security investigation have different primary objectives.

1.5 Wazuh vs Falco

Wazuh and Falco complement one another in many environments.

Wazuh	Falco
Broad endpoint and security-event monitoring	Primarily runtime behavior detection
Log-based threat analysis	Syscall, kernel-event, and plugin-based monitoring
FIM, SCA, vulnerability inventory	Runtime detection rules
Centralized security investigation	Runtime-focused security alerts
Suitable for servers, endpoints, and cloud	Particularly useful for Linux and Kubernetes workloads

A practical DevSecOps architecture can use Falco for runtime threat detection and Wazuh for centralized investigation and other security capabilities.

1.6 What Wazuh cannot guarantee

Wazuh is not a complete replacement for antivirus, endpoint prevention, vulnerability remediation tools, firewalls, or human incident response.

It cannot reliably detect activity it has no visibility into, and a generated alert does not necessarily prove that a security incident occurred.

Practical exercise: Identify three events on a Linux server that security monitoring should detect, such as repeated login failures, unexpected configuration modifications, and a vulnerable software package.

Knowledge check

Q: Is Wazuh primarily a performance monitoring system?

A: No. Its primary purpose is security monitoring, detection, investigation, and response.

Q: Is installing Wazuh equivalent to automatically securing a server?

A: No. Wazuh provides visibility and controls, but the operating system, network, applications, and security processes still require appropriate hardening.

Tutorial 2 — Security and Log Monitoring Fundamentals

10 minutes | Foundational Linux and security knowledge

2.1 Important security terminology

Before installing Wazuh, understand these terms.

Term	Meaning
Event	Something that happened on a system
Log	Recorded information about an event
Alert	An event that a detection mechanism identifies as noteworthy
Incident	A security occurrence requiring investigation or response
IOC	Indicator of Compromise, such as a suspicious hash or domain
CVE	Common Vulnerabilities and Exposures identifier
CVSS	Common Vulnerability Scoring System
False positive	Benign activity incorrectly identified as suspicious
False negative	Harmful activity that detection mechanisms fail to flag

2.2 Where Linux security events originate

Common Linux logging sources include:

Source	Information
`/var/log/auth.log`	Authentication activity on systems using this file
`/var/log/syslog`	General system events when configured
`journalctl`	Logs collected by systemd-journald
`/var/log/audit/audit.log`	Linux Audit subsystem events when configured
Application logs	Web-server, database, and application-specific events

The availability of specific files depends on the Linux distribution and logging services installed. For example, a minimal Ubuntu installation may use journald without providing a traditional /var/log/auth.log.

Practical: inspect Linux authentication-related events

On an Ubuntu lab machine:

# Display OS information
cat /etc/os-release

# Show recent journal events
sudo journalctl -n 30 --no-pager

# Show available SSH-service journal events
sudo journalctl -u ssh -n 20 --no-pager

# Check whether a traditional authentication log exists
sudo test -f /var/log/auth.log && \
  sudo tail -n 20 /var/log/auth.log

Expected result: You should see timestamped system or SSH events if those services have produced journal records.

A missing /var/log/auth.log is not automatically a security or installation problem.

2.3 Understand a sample security event

Example:

Oct 11 12:00:00 web01 sshd[1234]:
Failed password for invalid user demo
from 192.0.2.15 port 52210 ssh2

Meaning:

Field	Interpretation
Timestamp	When the event occurred
Host	`web01`
Process	`sshd`
PID	`1234`
Action	Failed authentication
Username	`demo`
Source IP	`192.0.2.15`

A single failed login can be normal. Repeated failures, multiple targeted accounts, or suspicious source behavior may warrant investigation.

2.4 Windows security events

Windows provides event logs through Windows Event Viewer.

Important example event IDs:

Event ID	Meaning
4624	Successful logon
4625	Failed logon
4688	Process creation, when configured for auditing
4720	User account created
1102	Security audit log cleared

On Windows, open PowerShell as Administrator:

# Examine the latest five failed-logon events
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625
} -MaxEvents 5

This may return no matching events if no relevant activity was recorded.

2.5 Introduction to MITRE ATT&CK

MITRE ATT&CK is a framework used to describe adversary behavior.

A simple example is credential brute forcing.

Tactic: Credential Access
Technique: Brute Force
Technique ID: T1110

Wazuh rules can include MITRE ATT&CK mappings to provide additional investigation context.

Practical exercise: Find a failed authentication event and identify its timestamp, username, source IP, and system.

Knowledge check

Q: What is the difference between a log and an alert?

A: A log records an event. An alert indicates that an event or pattern matched defined detection criteria.

Q: Does a CVE mean that a vulnerability has been exploited?

A: No. A CVE identifies a publicly recognized vulnerability; exploitation requires separate evidence.

Tutorial 3 — Wazuh Architecture and Working

15 minutes | Components, data flow, and networking

3.1 Main architecture

Wazuh contains an endpoint agent and three central components.

flowchart TB
    subgraph Endpoints["Monitored endpoints"]
        L["Linux agent"]
        W["Windows agent"]
        M["macOS agent"]
    end
    subgraph Central["Wazuh platform"]
        S["Wazuh server / manager"]
        F["Filebeat"]
        I["Wazuh indexer"]
        D["Wazuh dashboard"]
        S --> F
        F -->|"TLS"| I
        I <-->|"Search queries"| D
        D <-->|"REST API"| S
    end
    L -->|"Events"| S
    W -->|"Events"| S
    M -->|"Events"| S

This architecture is verified against the current Wazuh documentation.

3.2 Understand each component

Wazuh Agent

Installed on an endpoint to collect and report security telemetry.

It supports functions such as log collection, file integrity monitoring, security configuration checks, and system inventory.

Wazuh Server / Manager

The central detection and management component.

Responsibilities include receiving events, processing decoders, evaluating rules, generating alerts, managing agents, and initiating configured responses.

Filebeat

A forwarding component bundled with the Wazuh server installation.

It sends security alert data to the indexer.

Wazuh Indexer

Stores and indexes security information so it can be searched and analyzed efficiently.

Wazuh Dashboard

The browser-based interface for investigating alerts, managing agents, reviewing vulnerabilities, inspecting security configuration results, and visualizing data.

3.3 How Wazuh processes an event

A typical security event follows this sequence:

Something happens on a monitored endpoint.
The endpoint generates an event or log.
The Wazuh agent collects relevant data.
The Wazuh manager receives the event.
A decoder attempts to understand its structure.
Rules evaluate whether the event meets detection conditions.
When appropriate, Wazuh produces an alert.
Filebeat forwards the alert for indexing.
The indexer stores the information.
The dashboard allows an analyst to investigate.

Later tutorials reproduce this complete process.

3.4 Important Wazuh ports

Port	Protocol	Purpose
1514	TCP	Agent-to-manager event communication
1515	TCP	Agent enrollment
1516	TCP	Manager-cluster communication
55000	TCP	Wazuh server API
9200	TCP	Indexer API
443	TCP	Dashboard HTTPS
514	UDP/TCP	Optional Syslog collection

These are default ports, and some services are disabled or unnecessary depending on the deployment.

In our lab, only the agent communication and enrollment ports need to be reachable from monitored endpoints. The dashboard should be accessible only from an authorized administration network.

Do not expose the Wazuh indexer or management APIs directly to the public internet.

3.5 Agent-based vs agentless monitoring

Agent-based monitoring runs software directly on the monitored endpoint.

Agentless monitoring gathers information without installing a native Wazuh agent on the source. For example, network equipment can send Syslog events to a central collector.

Agent-based monitoring usually provides richer host-level telemetry. Agentless approaches are useful when installing an agent is impractical or unsupported.

3.6 Deployment architectures

Deployment	Description	Recommended for
All-in-one	All central components share one server	Training and small environments
Distributed	Central components run on separate hosts	Higher resource requirements
Multi-node	Clustered managers/indexers	Scale and higher availability

This course uses all-in-one deployment to keep setup and troubleshooting approachable.

Practical exercise: Draw the route followed by an SSH authentication event from its origin to the Wazuh dashboard.

Knowledge check

Q: Which component evaluates detection rules?

A: The Wazuh manager.

Q: Which component stores indexed security data?

A: The Wazuh indexer.

Q: Which port does an agent normally use for event communication?

A: TCP port 1514.

Tutorial 4 — Wazuh Installation and Setup

25 minutes | Hands-on installation

4.1 Learning objectives

By the end of this tutorial, you will know how to install a single-node Wazuh deployment, access the dashboard, verify services, and identify common installation problems.

Quick Installation and Configuration

Platform	Central Wazuh components	Recommended approach
Ubuntu Linux	Native installation supported	Official installation assistant
Windows	Not a native Windows server installation	Linux VM or Docker Desktop
macOS	Not a native macOS server installation	Linux VM; Docker-based alternatives require compatibility verification

The main walkthrough uses an Ubuntu VM. The next tutorial provides native Wazuh agent installation commands for Ubuntu, Windows, and macOS.

4.2 Prepare the Ubuntu server

On your Wazuh server VM, open a Bash terminal.

Check the operating system and resources:

# Display operating system information
cat /etc/os-release

# Check architecture
uname -m

# Check available memory
free -h

# Check available disk space
df -h

# Check available processors
nproc

# Check the server IP
hostname -I

Expected baseline:

Ubuntu 24.04 LTS
x86_64 or ARM64 architecture supported by your deployment
At least 8 GiB RAM
Four CPU cores
Approximately 50 GB storage allocated

Install the required download tools:

sudo apt update

sudo apt install -y \
  curl \
  ca-certificates \
  nano

4.3 Download the installation assistant

The official all-in-one installation process is documented in Wazuh Quickstart.

Run:

# Create a dedicated installation directory
mkdir -p ~/wazuh-install

cd ~/wazuh-install

# Download the official 4.14 installer
curl -fsSLO \
  https://packages.wazuh.com/4.14/wazuh-install.sh

# Verify that the script was downloaded
ls -lh wazuh-install.sh

Before running a downloaded installation script with elevated privileges, inspect it and verify its origin.

# Inspect the beginning of the installer
head -n 40 wazuh-install.sh

# Display the installation assistant options
bash wazuh-install.sh --help

For production installations, use your organization’s normal package integrity and installation approval process.

4.4 Install Wazuh

Run the assisted all-in-one installation:

cd ~/wazuh-install

sudo bash ./wazuh-install.sh -a

The -a option deploys the central components using the all-in-one installation method.

This includes:

Wazuh manager
Filebeat
Wazuh indexer
Wazuh dashboard

A successful installation provides dashboard access information resembling:

INFO: --- Summary ---
INFO: You can access the web interface:
https://<SERVER_IP>

User: admin
Password: <GENERATED_PASSWORD>

INFO: Installation finished.

The password will be generated by your actual installation. Never use an example password as a real deployment credential.

4.5 Verify the installation

Run these commands on the server:

# Check that the central services are active
sudo systemctl is-active \
  wazuh-manager \
  wazuh-indexer \
  wazuh-dashboard \
  filebeat

# Check Wazuh version
sudo /var/ossec/bin/wazuh-control info -v

# Check manager processes
sudo /var/ossec/bin/wazuh-control status

Expected version for this tutorial:

v4.14.8

Check listening network ports:

sudo ss -ltnp | grep -E \
  ':1514|:1515|:443|:9200|:55000'

A missing port may indicate a service is not running, is configured differently, or is bound to a different interface. Not every listed port must be publicly reachable.

4.6 Access the Wazuh dashboard

From your computer, open:

https://192.168.56.10

Use the generated admin credentials.

Because the installation uses a self-signed certificate by default, your browser may display a certificate warning. For a private training environment, you can verify the certificate and proceed according to your lab policy. Production systems should use properly trusted certificates.

After logging in, explore:

Agents management — Monitored endpoints and groups
Threat hunting — Security alerts and searches
File Integrity Monitoring — File changes
Configuration Assessment — Security baselines
Vulnerability Detection — Vulnerable software inventory

Dashboard navigation may vary slightly with the installed release.

4.7 Network configuration

The monitored Ubuntu agent needs to reach the Wazuh server on TCP 1514 and 1515.

On the Wazuh server, first check whether UFW is enabled:

sudo ufw status verbose

If UFW is already active, allow the specific agent address:

sudo ufw allow from 192.168.56.20 \
  to any port 1514 proto tcp

sudo ufw allow from 192.168.56.20 \
  to any port 1515 proto tcp

Ensure that an authorized administrator can access HTTPS port 443. Do not enable or reset a firewall blindly on a remotely managed machine; it could interrupt your existing connection.

For cloud deployments, equivalent restrictions may need to be configured in cloud security groups or network firewalls.

4.8 Windows and macOS alternatives

The beginner-friendly cross-platform option is to run the central Wazuh server in a Linux virtual machine.

Wazuh also provides an official OVA virtual appliance for compatible x86_64 virtualization environments. Its current appliance uses Amazon Linux 2023 with Wazuh 4.14.8.

For a container-based laboratory on a compatible Docker host, the official pinned deployment is:

# Requires Git, Docker Engine/Desktop,
# Docker Compose, and sufficient resources

git clone \
  https://github.com/wazuh/wazuh-docker.git \
  -b v4.14.8

cd wazuh-docker/single-node

# Generate lab certificates
docker compose \
  -f generate-indexer-certs.yml \
  run --rm generator

# Start the single-node Wazuh stack
docker compose up -d

# Inspect container status
docker compose ps

# Review initialization logs
docker compose logs --tail=100

On a native Linux Docker host or WSL2, the indexer may additionally require:

sudo sysctl -w vm.max_map_count=262144

The Docker instructions are documented for supported Linux and Windows hosts. Native macOS Docker compatibility for this exact deployment was not established by the retrieved vendor installation guide, so treat a Linux VM as the validated choice on a Mac. The Docker stack may use demonstration credentials; replace default credentials before allowing access beyond an isolated lab.

4.9 Troubleshooting installation problems

Problem	Likely cause	Diagnostic action
Installer fails	Unsupported OS or missing resources	`cat /etc/os-release`, `free -h`, `df -h`
Dashboard unavailable	Service stopped or network restriction	`systemctl status wazuh-dashboard`
Indexer fails	Insufficient RAM or configuration issue	`journalctl -u wazuh-indexer -n 100`
Cannot authenticate	Incorrect credentials	Retrieve credentials from installation archive
Connection refused	Wrong address or blocked port	`ss -ltnp`, firewall rules

Inspect installation logs with:

sudo journalctl \
  -u wazuh-manager \
  -n 100 \
  --no-pager

Other services can be inspected by replacing wazuh-manager with their corresponding service name.

4.10 Rollback

If this is a disposable VM, restoring a snapshot or deleting the lab VM is the cleanest rollback.

The installation assistant also supports uninstalling Wazuh using -u, but this can remove the Wazuh installation and associated local data. Use that option only after confirming that no data must be retained.

Exercise: Install Wazuh, verify all four central services, and log in to the dashboard.

Knowledge check

Q: What does the all-in-one deployment include?

A: Wazuh manager, Filebeat, indexer, and dashboard.

Q: Why should production deployments restrict the indexer API?

A: It provides access to sensitive indexed security information and administrative functionality.

Tutorial 5 — Wazuh Agent Installation and Management

15 minutes | Endpoint deployment and enrollment

5.1 Learning objectives

You will install a Wazuh agent, connect it to the manager, verify communication, and understand agent groups.

An agent is a lightweight service installed on an endpoint. It gathers security information and communicates with the Wazuh manager.

The preferred lab configuration is a separate Ubuntu endpoint.

5.2 Quick Installation — Ubuntu Linux

Execute on the Ubuntu agent VM at 192.168.56.20, not on the Wazuh server.

Step 1: Install prerequisites

sudo apt update

sudo apt install -y \
  curl \
  gnupg \
  ca-certificates

Step 2: Import the repository signing key

curl -fsSL \
  https://packages.wazuh.com/key/GPG-KEY-WAZUH \
  | sudo gpg --dearmor \
      -o /usr/share/keyrings/wazuh.gpg

sudo chmod 644 /usr/share/keyrings/wazuh.gpg

Use the fingerprint information published by the vendor to validate signing-key provenance when preparing a production deployment.

Step 3: Add the Wazuh repository

echo \
  "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | sudo tee /etc/apt/sources.list.d/wazuh.list

sudo apt update

Step 4: Install and register the agent

sudo env WAZUH_MANAGER="192.168.56.10" \
  apt-get install -y wazuh-agent

WAZUH_MANAGER identifies the manager the agent should contact.

For reproducible production deployments, pin the agent package version to the approved version. An agent version should not be newer than its Wazuh manager.

Step 5: Enable the agent service

sudo systemctl daemon-reload

sudo systemctl enable wazuh-agent

sudo systemctl start wazuh-agent

Step 6: Verify

sudo systemctl is-active wazuh-agent

sudo /var/ossec/bin/wazuh-control info -v

sudo tail -n 30 /var/ossec/logs/ossec.log

Expected service state:

active

Check network access:

nc -zv 192.168.56.10 1514
nc -zv 192.168.56.10 1515

If nc is unavailable, install netcat-openbsd or use another TCP connectivity test.

5.3 Quick Installation — Windows

On your Windows endpoint, open PowerShell as Administrator.

Download the official versioned MSI installer:

$Installer = Join-Path $env:TEMP `
    "wazuh-agent-4.14.8-1.msi"

$Url = "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.8-1.msi"

Invoke-WebRequest `
    -Uri $Url `
    -OutFile $Installer

Install and enroll:

$Arguments = @(
    "/i"
    "`"$Installer`""
    "/qn"
    'WAZUH_MANAGER="192.168.56.10"'
)

$Process = Start-Process `
    -FilePath "msiexec.exe" `
    -ArgumentList $Arguments `
    -Wait `
    -PassThru

$Process.ExitCode

An MSI exit code of 0 indicates success. Other codes should be investigated before continuing.

Start and verify the Windows service:

Start-Service WazuhSvc

Get-Service WazuhSvc

Test-NetConnection `
  -ComputerName 192.168.56.10 `
  -Port 1514

Inspect the agent version and log:

$AgentPath = "C:\Program Files (x86)\ossec-agent"

& "$AgentPath\wazuh-control.exe" info -v

Get-Content "$AgentPath\ossec.log" -Tail 30

Official reference:

5.4 Quick Installation — macOS

On macOS, open Terminal.

Determine whether the Mac uses Intel or Apple silicon:

uname -m

Typical results:

arm64 — Apple silicon
x86_64 — Intel

Apple silicon

cd ~/Downloads

curl -fLO \
  https://packages.wazuh.com/4.x/macos/wazuh-agent-4.14.8-1.arm64.pkg

printf "WAZUH_MANAGER='192.168.56.10'\n" \
  | sudo tee /tmp/wazuh_envs

sudo installer \
  -pkg wazuh-agent-4.14.8-1.arm64.pkg \
  -target /

Intel Mac

cd ~/Downloads

curl -fLO \
  https://packages.wazuh.com/4.x/macos/wazuh-agent-4.14.8-1.intel64.pkg

printf "WAZUH_MANAGER='192.168.56.10'\n" \
  | sudo tee /tmp/wazuh_envs

sudo installer \
  -pkg wazuh-agent-4.14.8-1.intel64.pkg \
  -target /

Start the agent using the vendor’s LaunchDaemon:

sudo launchctl bootstrap \
  system \
  /Library/LaunchDaemons/com.wazuh.agent.plist

Verify:

sudo /Library/Ossec/bin/wazuh-control info -v

sudo /Library/Ossec/bin/wazuh-control status

sudo tail -n 30 /Library/Ossec/logs/ossec.log

If macOS reports that the service is already bootstrapped, inspect its current state rather than registering it repeatedly.

Depending on the monitored sources and macOS privacy protections, additional permissions may be necessary.

Official reference:

5.5 Verify enrolled agents on the server

Return to the Wazuh server.

sudo /var/ossec/bin/agent_control -l

Illustrative output:

Wazuh agent_control. List of available agents:

ID: 000, Name: wazuh-server, Active/Local
ID: 001, Name: ubuntu-agent, Active

The agent ID and hostname will depend on your environment.

From the browser, open Agents management → Summary and confirm that your Ubuntu endpoint is active.

Available statuses include Active, Pending, Disconnected, and Never connected.

5.6 Agent groups

Agent groups allow multiple endpoints to receive common configurations.

For example:

Group	Typical endpoints
Linux	Ubuntu and other Linux servers
Windows	Windows workstations and servers
macOS	Mac devices
WebServers	Application and web servers
DatabaseServers	Database systems

Create a group:

# Run on Wazuh server
sudo /var/ossec/bin/agent_groups \
  -a -g Linux -q

List groups:

sudo /var/ossec/bin/agent_groups -l

Assign an enrolled agent to the group, using its actual ID:

sudo /var/ossec/bin/agent_groups \
  -a -i 001 -g Linux

Verify membership:

sudo /var/ossec/bin/agent_groups \
  -s -i 001

The group configuration is stored under:

/var/ossec/etc/shared/Linux/agent.conf

This mechanism supports centralized settings, such as common log paths, FIM monitoring policies, and other supported agent configurations.

5.7 Agent troubleshooting

Symptom	Diagnostic step	Possible fix
Agent not connected	Test 1514/TCP	Correct routing or firewall
Enrollment failure	Test 1515/TCP	Check enrollment service
Wrong manager	Inspect agent `ossec.conf`	Correct manager address
Agent starts then stops	Check `ossec.log`	Resolve reported configuration errors
Older manager version	Compare component versions	Use a compatible agent version

A common reason an agent cannot connect is a blocked port or incorrect manager address.

Exercise: Connect an Ubuntu agent, verify Active status, create a Linux agent group, and assign that agent to it.

Knowledge check

Q: Can Wazuh agents run on Windows and macOS?

A: Yes.

Q: Does an active agent status prove every security feature is functioning?

A: No. Each feature must be configured and validated separately.

Tutorial 6 — Log Collection, Monitoring, and Alerts

20 minutes | Hands-on telemetry collection

6.1 Learning objectives

You will understand log collection, configure a monitored log file, investigate system events, and prepare a custom security event for rule testing.

6.2 Understand log collection

The Wazuh agent uses its Logcollector functionality to read supported local log sources.

Common log sources include:

Linux authentication and system logs
Windows Event Logs
macOS system logs
Web-server logs
Application-specific text and JSON logs

A typical agent configuration lives at:

Linux:   /var/ossec/etc/ossec.conf
Windows: C:\Program Files (x86)\ossec-agent\ossec.conf
macOS:   /Library/Ossec/etc/ossec.conf

6.3 Collect Linux journald events

On Ubuntu, Wazuh supports the following agent configuration:

<localfile>
  <location>journald</location>
  <log_format>journald</log_format>
</localfile>

This is normally included in the default Linux agent configuration. Check before adding another copy.

On your Ubuntu agent:

sudo grep -n -A3 -B2 \
  '<location>journald</location>' \
  /var/ossec/etc/ossec.conf

If it is missing, back up the configuration and add the block inside <ossec_config>:

sudo cp -a /var/ossec/etc/ossec.conf \
  /var/ossec/etc/ossec.conf.bak

sudo nano /var/ossec/etc/ossec.conf

Restart the agent only if you changed the configuration:

sudo systemctl restart wazuh-agent

6.4 Generate a harmless system event

Execute on the Ubuntu agent:

logger -t wazuh-training \
  "Training event: system monitoring test"

Verify the event in journald:

sudo journalctl \
  -t wazuh-training \
  -n 10 \
  --no-pager

This confirms the event reached journald.

It does not by itself prove that a Wazuh detection rule generated an alert.

Important distinction: Log collection and alert generation are different stages. Events may be collected successfully without producing visible security alerts.

6.5 Create a dedicated application log

We will use this file throughout the remaining tutorials:

/var/log/wazuh-lab.log

On the Ubuntu agent:

# Create a clean lab log file
sudo install \
  -o root \
  -g adm \
  -m 0640 \
  /dev/null \
  /var/log/wazuh-lab.log

Add the following block inside the existing <ossec_config> in /var/ossec/etc/ossec.conf:

<localfile>
  <location>/var/log/wazuh-lab.log</location>
  <log_format>syslog</log_format>
</localfile>

Edit carefully and do not delete existing configuration blocks.

Restart and verify:

sudo systemctl restart wazuh-agent

sudo systemctl is-active wazuh-agent

sudo tail -n 30 /var/ossec/logs/ossec.log

This tells Wazuh to monitor the specified file for Syslog-formatted messages.

6.6 Generate a synthetic failed-authentication event

Execute on the Ubuntu agent:

printf '%s\n' \
  "Oct 11 12:00:00 ubuntu-agent wazuh-lab: AUTH_FAIL username=alice srcip=192.0.2.15" \
  | sudo tee -a /var/log/wazuh-lab.log

Verify:

sudo tail -n 5 /var/log/wazuh-lab.log

Expected final log entry:

Oct 11 12:00:00 ubuntu-agent wazuh-lab: AUTH_FAIL username=alice srcip=192.0.2.15

This is deliberately synthetic, not evidence of an actual attack. The source IP belongs to a documentation-only address range.

In the next tutorial, we will create a decoder and detection rule that recognize this event.

6.7 Explore the Wazuh alert files

On the Wazuh server:

# Human-readable alert log
sudo tail -n 30 \
  /var/ossec/logs/alerts/alerts.log

# Structured JSON alerts
sudo tail -n 5 \
  /var/ossec/logs/alerts/alerts.json

The manager writes matching alerts here. Raw event archiving is a separate, configurable capability and should not be assumed to contain every collected event unless configured appropriately.

6.8 Understand alert severity

Wazuh rules use severity levels from 0 through 16.

As a practical interpretation:

Level	General significance
0	Suppressed or ignored alert
1–3	Low-level activity
4–6	Low to moderate
7–9	Potentially important
10–12	High priority
13–16	Very high severity

These are working guidelines, not a universal risk-scoring standard. A rule’s configured level and surrounding context must both be considered.

6.9 Log troubleshooting

If your application event is missing:

Confirm that the original file exists.
Confirm that new content was appended after log collection began.
Inspect the agent configuration for the correct path and format.
Check that the agent service is running.
Confirm manager connectivity.
Verify the detection rule using wazuh-logtest.
Check the manager’s alert output and indexing services.

Exercise: Generate three distinct synthetic log entries and confirm that they appear in the application log. Then inspect existing security alerts through the dashboard.

Knowledge check

Q: Why might a collected event not appear in Threat Hunting?

A: It may not match an alert-generating rule, or there may be a forwarding or indexing problem.

Q: What file controls Wazuh agent log collection on Ubuntu?

A: /var/ossec/etc/ossec.conf.

Tutorial 7 — Wazuh Rules, Decoders, and Detection Engineering

20 minutes | Intermediate detection engineering

This is one of the most important lessons in the course because it explains how security events become meaningful security alerts.

7.1 Learning objectives

You will understand decoders, built-in rules, custom detection rules, rule severity, validation, and false-positive reduction.

You will also build a working detection rule for the synthetic event introduced in Tutorial 6.

7.2 What is a decoder?

A decoder extracts information from a raw event so Wazuh can understand its structure.

Example log:

Oct 11 12:00:00 ubuntu-agent wazuh-lab: AUTH_FAIL username=alice srcip=192.0.2.15

A decoder can extract:

program_name = wazuh-lab
dstuser      = alice
srcip        = 192.0.2.15

The result is structured information that Wazuh rules can use.

7.3 What is a Wazuh rule?

A rule determines whether a security event meets specified conditions.

For example:

A failed authentication attempt occurs.
The event was produced by a particular application.
The source IP has appeared repeatedly.
The event contains fields of interest.

A matching rule can generate an alert with its own ID, description, severity level, and group classification.

7.4 Important Wazuh configuration files

All paths below refer to the Wazuh server.

File	Purpose
`/var/ossec/etc/rules/local_rules.xml`	Custom detection rules
`/var/ossec/etc/decoders/local_decoder.xml`	Custom log decoders
`/var/ossec/ruleset/rules/`	Vendor-supplied detection rules
`/var/ossec/ruleset/decoders/`	Vendor-supplied decoders
`/var/ossec/etc/ossec.conf`	Main server configuration

Wazuh recommends using custom rule IDs between 100000 and 120000, and preserving your own rules separately from vendor-supplied rules that may be replaced during upgrades.

7.5 Hands-on: create a custom decoder

On the Wazuh server, first back up the existing decoder file.

cd /var/ossec/etc/decoders

sudo cp -a local_decoder.xml \
  local_decoder.xml.bak

If the file is absent, create it first and ensure the Wazuh manager can read it.

Open:

sudo nano \
  /var/ossec/etc/decoders/local_decoder.xml

Append the following definitions without deleting existing decoders:

<decoder name="wazuh-lab">
  <program_name>^wazuh-lab$</program_name>
</decoder>

<decoder name="wazuh-lab">
  <parent>wazuh-lab</parent>
  <regex type="pcre2">AUTH_FAIL username=([A-Za-z0-9_-]+) srcip=([0-9.]+)</regex>
  <order>dstuser,srcip</order>
</decoder>

The parent decoder identifies the wazuh-lab application.

The child decoder extracts a username and source IP address. The expression is intentionally simple for training; production decoders should validate input formats more carefully.

The use of a parent decoder and PCRE2 expression follows Wazuh’s supported custom decoder syntax.

7.6 Hands-on: create a custom detection rule

Back up the rules file:

sudo cp -a \
  /var/ossec/etc/rules/local_rules.xml \
  /var/ossec/etc/rules/local_rules.xml.bak

Edit it:

sudo nano \
  /var/ossec/etc/rules/local_rules.xml

Append this rule group:

<group name="wazuh_lab,authentication_failed,">
  <rule id="100100" level="7">
    <decoded_as>wazuh-lab</decoded_as>
    <description>Lab authentication failure for $(dstuser) from $(srcip)</description>
    <group>authentication_failed,</group>
  </rule>
</group>

Explanation:

Attribute	Purpose
`id="100100"`	Unique custom rule identifier
`level="7"`	Alert severity
`decoded_as`	Matches events processed by the custom decoder
`description`	Human-readable alert message
`dstuser`, `srcip`	Fields extracted from the event
`group`	Helps classify the alert

7.7 Test the decoder and rule

Use the official rule-testing utility on the Wazuh server:

sudo /var/ossec/bin/wazuh-logtest

Paste:

Oct 11 12:00:00 ubuntu-agent wazuh-lab: AUTH_FAIL username=alice srcip=192.0.2.15

You should see results organized into three phases.

Expected key values, provided the configuration matches successfully:

Phase 1: Pre-decoding
program_name: wazuh-lab

Phase 2: Decoding
name: wazuh-lab
dstuser: alice
srcip: 192.0.2.15

Phase 3: Rule matching
id: 100100
level: 7

The displayed output is illustrative, not a captured execution result.

If Wazuh does not match the decoder, check the exact program_name, raw log format, regular expression, and decoder file contents.

wazuh-logtest evaluates decoding and rules in a test session. It does not establish that the actual endpoint is successfully delivering events.

7.8 Apply the detection rule

Validate server detection configuration:

sudo /var/ossec/bin/wazuh-analysisd -t

Fix any reported errors before proceeding.

Restart the manager:

sudo systemctl restart wazuh-manager

Now return to the Ubuntu agent and produce a new event:

printf '%s %s wazuh-lab: AUTH_FAIL username=alice srcip=192.0.2.15\n' \
  "$(date '+%b %e %T')" \
  "$(hostname -s)" \
  | sudo tee -a /var/log/wazuh-lab.log

On the manager:

sudo grep -n -C6 '100100' \
  /var/ossec/logs/alerts/alerts.log \
  | tail -n 35

You should find a rule 100100 alert if log collection, decoding, detection, and communication are working.

Then open Wazuh Dashboard → Threat Hunting and search:

rule.id:100100

Choose a time range that includes the generated event.

7.9 Intermediate example: detect repeated failures

A single failed authentication attempt may not be particularly serious.

Five attempts from the same source IP within two minutes are potentially more interesting.

Append this additional rule inside the same custom rule group:

<rule id="100101"
      level="12"
      frequency="5"
      timeframe="120">
  <if_matched_sid>100100</if_matched_sid>
  <same_srcip />
  <description>Repeated lab authentication failures from one source IP</description>
  <group>authentication_failed,brute_force,</group>
</rule>

This demonstrates event correlation using:

frequency — Number of matching events
timeframe — Evaluation period, in seconds
if_matched_sid — Previously matched rule
same_srcip — Repeated source IP

The precise frequency-counter behavior and matching should be confirmed with wazuh-logtest using repeated events in the same test session.

Save the file, run configuration validation, and restart the manager.

Generate several test events from the same source IP and look for the correlation alert.

7.10 False-positive reduction

Detection engineering requires more than writing rules.

For each new rule, evaluate:

What specific behavior does it detect?
Is that behavior always suspicious?
What legitimate activity might produce the same event?
What evidence confirms the intended activity?
Does the severity level reflect the actual risk?
Can alert frequency or scope be adjusted safely?

A rule triggering repeatedly is not automatically a better rule.

Troubleshooting: If wazuh-logtest succeeds but the dashboard shows no alert, investigate the agent collection path, service connectivity, manager alert file, indexer, and chosen time range.

Exercise: Change the custom rule severity from 7 to 9, validate the configuration, generate another event, and confirm the new alert level.

Knowledge check

Q: What is the difference between a decoder and a rule?

A: A decoder extracts event fields. A rule evaluates event data against detection conditions.

Q: Which utility should you use to test a Wazuh detection rule?

A: wazuh-logtest.

Tutorial 8 — File Integrity Monitoring (FIM)

15 minutes | Hands-on file security monitoring

8.1 Learning objectives

You will learn how File Integrity Monitoring works and detect file creation, modification, and deletion.

FIM is useful for identifying unexpected changes to critical files.

For example, a security team may want to know when:

A web-server configuration changes.
An application configuration is modified.
A critical executable is replaced.
A sensitive configuration file is deleted.

FIM can detect changes, but it does not automatically establish whether those changes were malicious.

8.2 How FIM works

flowchart TD
    A["Select files or directories"] --> B["Create monitoring baseline"]
    B --> C["File attributes or content change"]
    C --> D["Wazuh detects the change"]
    D --> E["Create and forward FIM event"]
    E --> F["Investigate file change"]

Wazuh can compare attributes such as file size, modification time, ownership, permissions, and cryptographic hashes.

On Linux and Windows, Wazuh supports real-time directory monitoring. On macOS, use supported scheduled FIM scanning rather than assuming the Linux/Windows real-time option is available.

8.3 Hands-on: create a monitored directory

On the Ubuntu agent:

sudo mkdir -p /opt/wazuh-lab

Create the initial file:

printf 'mode=development\n' \
  | sudo tee /opt/wazuh-lab/settings.conf

Verify:

sudo ls -la /opt/wazuh-lab

sudo sha256sum \
  /opt/wazuh-lab/settings.conf

Record the original hash.

8.4 Configure FIM

Edit the Ubuntu agent configuration:

sudo nano /var/ossec/etc/ossec.conf

Find the existing <syscheck> block and add the following directory entry inside it:

<directories realtime="yes" check_all="yes">/opt/wazuh-lab</directories>

The relevant portion of the configuration should resemble:

<syscheck>
  <disabled>no</disabled>

  <!-- Preserve the existing FIM configuration -->

  <directories realtime="yes" check_all="yes">/opt/wazuh-lab</directories>
</syscheck>

Do not replace the existing configuration with this shortened illustration.

Validate and restart:

sudo /var/ossec/bin/wazuh-syscheckd -t

sudo systemctl restart wazuh-agent

Allow the initial FIM scan and monitoring baseline to complete before testing modifications.

8.5 Test 1: modify an existing file

On the Ubuntu agent:

printf 'mode=production\n' \
  | sudo tee /opt/wazuh-lab/settings.conf

sudo sha256sum \
  /opt/wazuh-lab/settings.conf

The new hash should differ from the original because the file contents changed.

Open Wazuh Dashboard → File Integrity Monitoring.

Look for a modified-file event associated with:

/opt/wazuh-lab/settings.conf

8.6 Test 2: create a new file

printf 'created by training lab\n' \
  | sudo tee /opt/wazuh-lab/new-file.txt

Expected behavior: Wazuh should detect the addition once the monitored directory’s baseline and real-time monitoring are active.

8.7 Test 3: delete a file

sudo rm /opt/wazuh-lab/new-file.txt

Because this is a disposable file created specifically for the lab, deleting it is safe.

Inspect the FIM events again and look for a deletion event.

8.8 Windows and macOS equivalents

For Windows, create a test directory:

New-Item `
  -ItemType Directory `
  -Force `
  -Path "C:\WazuhLab"

Add the following inside the Windows agent’s existing <syscheck> block:

<directories realtime="yes">C:\WazuhLab</directories>

Then restart the Windows Wazuh service.

For macOS, create:

sudo mkdir -p /Users/Shared/wazuh-lab

Add to the macOS agent’s <syscheck> block:

<directories>/Users/Shared/wazuh-lab</directories>

Then restart the macOS agent and inspect changes after a scheduled FIM scan.

8.9 Real-world FIM scenarios

Scenario	What to monitor
Linux configuration tampering	Selected files under `/etc`
Web-server changes	Nginx or Apache configuration
Application security	Sensitive deployment configuration files
Windows persistence	Selected startup locations and Registry entries
Critical software	Important executables and scripts

Be careful with highly active directories. Monitoring massive or frequently changing file trees can produce unnecessary overhead and alerts.

Also avoid displaying sensitive file contents or differences from files containing secrets.

Exercise: Modify, create, and delete files in /opt/wazuh-lab, and identify the corresponding events.

Knowledge check

Q: What can FIM detect?

A: Changes in monitored files, directories, and supported attributes.

Q: Does changing a file prove malicious activity?

A: No. Investigation must establish whether the change was expected or unauthorized.

Tutorial 9 — Security Configuration Assessment and Vulnerability Detection

20 minutes | Security posture and vulnerability management

This tutorial covers two related but different Wazuh capabilities.

9.1 Understand the difference

Capability	Primary question
Security Configuration Assessment (SCA)	Is the system configured securely?
Vulnerability Detection	Is installed software affected by known vulnerabilities?

For example, SSH password authentication may be configured insecurely even if no known software vulnerability is present.

Conversely, a properly hardened server may still run a package with a known CVE.

Both capabilities matter.

9.2 Security Configuration Assessment fundamentals

SCA examines operating system or application configuration against predefined policies.

Wazuh includes security policies, many based on CIS benchmarks, and evaluates whether the configured checks pass or fail.

Example checks may cover:

Password policy
SSH security settings
File and directory permissions
Unnecessary services
Operating system hardening
Security logging configuration

9.3 Verify SCA configuration

On the Ubuntu agent:

sudo grep -n -A12 '<sca>' \
  /var/ossec/etc/ossec.conf

A configuration may resemble:

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
</sca>

This is an illustrative partial block. Keep the policy configuration and other settings installed with your Wazuh agent.

Confirm that SCA is enabled, then inspect the installed policies:

sudo ls -lh /var/ossec/ruleset/sca/

Different operating systems include different policy files.

For Linux, Wazuh stores default SCA policies under /var/ossec/ruleset/sca.

9.4 Review SCA results in the dashboard

Open:

Endpoint security → Configuration Assessment

Select your monitored Ubuntu endpoint and an available policy.

Review:

Policy name
Number of passed checks
Number of failed checks
Check descriptions
Check results
Remediation recommendations

Example learning scenario:

Control: SSH root login must be restricted

Desired state:
Direct root SSH access should be restricted
according to the organization's security policy.

Assessment:
Inspect the effective SSH daemon configuration.

Verify the effective SSH configuration on Ubuntu:

sudo sshd -T 2>/dev/null \
  | grep -i '^permitrootlogin'

If SSH server software is not installed, the command may be unavailable. Do not install or change SSH simply to create an insecure setting.

An actual SCA finding depends on the installed policy and the current endpoint configuration.

9.5 How to use SCA results

For each failed check:

Read the complete policy requirement.
Determine whether it applies to the system.
Assess the change’s impact.
Apply the change using normal change-management procedures.
Re-run the relevant assessment.
Confirm the expected result without disrupting services.

Avoid modifying critical security settings on production machines simply to improve an assessment score.

SCA identifies potential security configuration issues; remediation is a separate action.

9.6 Vulnerability Detection fundamentals

Wazuh’s Vulnerability Detection capability uses endpoint software inventory together with its Cyber Threat Intelligence (CTI) vulnerability data.

The workflow is:

flowchart TD
    A["Wazuh agent"] --> B["Syscollector gathers software inventory"]
    B --> C["Wazuh manager"]
    D["Wazuh CTI vulnerability data"] --> C
    C --> E["Correlate packages and affected versions"]
    E --> F["Vulnerability inventory"]
    F --> G["Review, prioritize, and remediate"]

Wazuh uses Syscollector inventory and vulnerability intelligence to identify potentially affected software packages. It does not require you to exploit a vulnerability to determine that the package version is reported as affected.

9.7 Verify vulnerability detection settings

On the Wazuh server:

sudo grep -n -A5 \
  '<vulnerability-detection>' \
  /var/ossec/etc/ossec.conf

The documented default configuration includes:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

These settings control whether vulnerability detection is enabled, whether vulnerability inventory is indexed, and how frequently vulnerability intelligence is refreshed.

9.8 Verify Syscollector on the agent

On the Ubuntu agent:

sudo grep -n -A18 \
  '<wodle name="syscollector">' \
  /var/ossec/etc/ossec.conf

Check that inventory collection is enabled.

Important settings include:

<disabled>no</disabled>
<scan_on_start>yes</scan_on_start>
<packages>yes</packages>
<os>yes</os>

Do not create a duplicate Syscollector configuration block if an existing one is present.

9.9 Review vulnerability results

Open Wazuh Dashboard → Vulnerability Detection.

Review:

Field	Meaning
CVE ID	Identifies the vulnerability
Severity	Indicates assessed impact
Affected package	Installed software potentially affected
Installed version	Version found on the endpoint
Affected asset	Endpoint requiring investigation
Remediation information	Available mitigation or upgrade guidance

Results depend on inventory collection, CTI synchronization, package applicability, and indexing health. An empty inventory immediately after installation does not necessarily mean that the endpoint is free of vulnerabilities.

9.10 Practical vulnerability investigation

On Ubuntu, inspect locally installed packages:

dpkg-query -W \
  -f='${binary:Package} ${Version}\n' \
  | head -n 30

Choose a package already reported in your Wazuh vulnerability inventory.

Then:

Open the corresponding CVE record.
Review affected version ranges.
Confirm the installed package version.
Check vendor-specific security advisories.
Identify any patched backports that may affect applicability.
Determine whether an update is necessary.
Document the remediation decision.

For production systems, prioritize vulnerability remediation using exploitability, asset exposure, business criticality, vendor status, and compensating controls—not CVSS severity alone.

9.11 SCA and vulnerability troubleshooting

Problem	What to check
No SCA policies shown	Agent policy files, SCA enablement, initial scan
No vulnerabilities shown	Syscollector, CTI reachability, indexing
Old package inventory	Inventory scan interval and synchronization
Incorrect vulnerability finding	Vendor advisories and package version details
Dashboard data missing	Indexer and Wazuh manager health

Useful agent-side diagnostic command:

sudo tail -n 100 /var/ossec/logs/ossec.log

Useful server-side diagnostic command:

sudo journalctl \
  -u wazuh-manager \
  -n 100 \
  --no-pager

Exercise: Select one failed SCA check and one vulnerability finding, if any exist, and prepare a brief remediation explanation. Do not intentionally weaken the server to manufacture a failure.

Knowledge check

Q: What is the difference between SCA and Vulnerability Detection?

A: SCA evaluates configuration security. Vulnerability Detection correlates software inventory with known vulnerability information.

Q: Does a high CVSS score automatically establish that a specific endpoint is exploitable?

A: No. You must assess the actual software, configuration, exposure, and mitigating controls.

Tutorial 10 — Threat Hunting and Security Investigation

10 minutes | Intermediate security analysis

10.1 Learning objectives

You will learn to search alerts, investigate related events, interpret security findings, and document investigation results.

Threat hunting is the process of proactively examining security telemetry to identify potentially malicious behavior that may not yet have been confirmed as an incident.

This is different from simply reading alerts as they arrive.

10.2 Understand the investigation process

flowchart TD
    A["Identify suspicious event"] --> B["Review source and severity"]
    B --> C["Identify affected endpoint"]
    C --> D["Search related events"]
    D --> E["Review context and evidence"]
    E --> F{"Evidence of malicious activity?"}
    F -->|Yes| G["Escalate and contain"]
    F -->|No| H["Document benign or unconfirmed activity"]

10.3 Explore Threat Hunting

Open the Wazuh dashboard and navigate to:

Threat intelligence → Threat Hunting

Select a time range covering your training events.

Filter by your custom rule:

rule.id:100100

Open a matching alert and inspect its fields.

Important fields include:

Field	Purpose
`timestamp`	When the alert occurred
`agent.name`	Endpoint reporting the event
`rule.id`	Detection rule identifier
`rule.level`	Severity level
`rule.description`	Human-readable detection
`data.srcip`	Source IP if extracted by the decoder
`data.dstuser`	Username if extracted by the decoder
`full_log`	Original event, where available

An illustrative investigation record might look like:

Rule ID: 100100
Severity: 7
Agent: ubuntu-agent

Event:
Lab authentication failure for alice
from 192.0.2.15

Classification:
Controlled training simulation

Recommended response:
No containment required

The classification is important: this event was intentionally generated as part of the tutorial.

10.4 Correlate related events

Now generate several training events on the Ubuntu agent:

for user in alice bob charlie; do
  printf '%s %s wazuh-lab: AUTH_FAIL username=%s srcip=192.0.2.15\n' \
    "$(date '+%b %e %T')" \
    "$(hostname -s)" \
    "$user"
done | sudo tee -a /var/log/wazuh-lab.log

Investigate the resulting alerts.

Ask:

Did the events come from the same source IP?
Were multiple accounts targeted?
Were events generated within a short period?
Did the higher-severity correlation rule trigger?
Was there any successful authentication after the failures?
Is the source trusted, known, or expected?

The final two questions cannot be answered conclusively from the synthetic authentication-failure events alone. Additional telemetry would be needed.

10.5 Connect findings to MITRE ATT&CK

Repeated attempts to guess credentials may be associated with MITRE ATT&CK technique T1110 (Brute Force).

However, mapping an alert to ATT&CK is contextual classification, not proof that the adversary performed that technique.

You can review MITRE mappings available on built-in Wazuh rules and use them to understand the tactics and techniques a rule is designed to detect.

10.6 Create a simple investigation report

Field	Example
Finding	Repeated synthetic authentication failures
Detected by	Wazuh custom rules
Affected endpoint	Ubuntu lab agent
Source IP	192.0.2.15
Severity	As assigned by the matching rule
Evidence	Relevant event logs and rule IDs
Classification	Authorized simulation
Action	Document and close training investigation

A real security investigation should also capture the detection time, analyst, evidence references, business impact, containment actions, and decision rationale.

10.7 Common investigation mistakes

Do not assume that every alert is malicious.

Avoid drawing conclusions from one event without context, confusing the source IP with the actual identity of an attacker, or taking disruptive action before confirming the affected system and incident severity.

Exercise: Investigate three synthetic authentication alerts and write a five-line incident summary explaining why they should be classified as training activity.

Knowledge check

Q: What is the purpose of threat hunting?

A: To proactively identify suspicious behavior by analyzing available telemetry and related evidence.

Q: Is a high-severity alert proof of compromise?

A: No. Severity helps prioritization, but investigation is required.

Tutorial 11 — Active Response and Security Integrations

15 minutes | Security automation

11.1 Learning objectives

You will understand Active Response, configure an automated action, test it without blocking network access, and explore basic Wazuh integrations.

11.2 What is Active Response?

Wazuh Active Response executes a defined script or command when specified security conditions occur.

Possible actions include:

Recording a security response
Blocking an IP address
Disabling an account
Triggering an external workflow
Restarting a service where appropriate

Automated responses are useful, but incorrectly configured responses can interrupt legitimate activity.

Wazuh supports stateless one-time responses and stateful responses that reverse an action after a configured timeout.

11.3 Understand Active Response configuration

Two main elements define the response.

A <command> block identifies the executable to run.

An <active-response> block defines when and where it runs.

For example:

<command>
  <name>example-response</name>
  <executable>example-response.py</executable>
  <timeout_allowed>no</timeout_allowed>
</command>

And:

<active-response>
  <disabled>no</disabled>
  <command>example-response</command>
  <location>local</location>
  <rules_id>100100</rules_id>
</active-response>

local means the response executes on the agent that generated the matching alert.

11.4 Hands-on: create a harmless Active Response

Rather than modifying firewall rules, this lab will automatically record a response in the agent’s Active Response log whenever rule 100100 fires.

This demonstrates end-to-end automation without network disruption.

Step 1: Create the response script

On the Ubuntu agent:

sudo nano \
  /var/ossec/active-response/bin/wazuh-lab-notify.py

Add the complete script:

#!/usr/bin/env python3

import json
import sys
from datetime import datetime, timezone

LOG_FILE = "/var/ossec/logs/active-responses.log"

def main():
    try:
        message = json.loads(sys.stdin.readline())
    except (json.JSONDecodeError, ValueError):
        return 1

    if message.get("command") != "add":
        return 0

    alert = (
        message.get("parameters", {})
        .get("alert", {})
    )

    rule = alert.get("rule", {})
    data = alert.get("data", {})

    rule_id = rule.get("id", "unknown")
    src_ip = data.get("srcip", "unknown")

    timestamp = datetime.now(
        timezone.utc
    ).isoformat()

    with open(
        LOG_FILE,
        "a",
        encoding="utf-8"
    ) as log_file:
        log_file.write(
            f"{timestamp} "
            f"wazuh-lab-notify: "
            f"rule_id={rule_id} "
            f"srcip={src_ip}\n"
        )

    return 0


if __name__ == "__main__":
    sys.exit(main())

The script implements Wazuh’s stateless Active Response approach: read JSON from standard input, check for the add command, extract alert information, and perform a one-time action.

Step 2: Set permissions

sudo chown root:wazuh \
  /var/ossec/active-response/bin/wazuh-lab-notify.py

sudo chmod 750 \
  /var/ossec/active-response/bin/wazuh-lab-notify.py

Validate the Python syntax:

sudo python3 -m py_compile \
  /var/ossec/active-response/bin/wazuh-lab-notify.py

Restart the agent:

sudo systemctl restart wazuh-agent

Step 3: Test the script independently

This verifies that the script can process a simulated Active Response JSON message before Wazuh invokes it.

On the Ubuntu agent:

printf '%s\n' \
  '{"command":"add","parameters":{"alert":{"rule":{"id":"100100"},"data":{"srcip":"192.0.2.15"}}}}' \
  | sudo /var/ossec/active-response/bin/wazuh-lab-notify.py

Inspect:

sudo tail -n 10 \
  /var/ossec/logs/active-responses.log

If this succeeds, you should see a wazuh-lab-notify entry.

This verifies the standalone script, not yet the complete Wazuh response integration.

Step 4: Register the command on the server

On the Wazuh server:

sudo cp -a /var/ossec/etc/ossec.conf \
  /var/ossec/etc/ossec.conf.pre-active-response

sudo nano /var/ossec/etc/ossec.conf

Inside the existing <ossec_config> element, add:

<command>
  <name>wazuh-lab-notify</name>
  <executable>wazuh-lab-notify.py</executable>
  <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
  <disabled>no</disabled>
  <command>wazuh-lab-notify</command>
  <location>local</location>
  <rules_id>100100</rules_id>
</active-response>

Do not remove the other Active Response definitions already present in the file.

Validate detection-related configuration:

sudo /var/ossec/bin/wazuh-analysisd -t

Restart the Wazuh manager:

sudo systemctl restart wazuh-manager

Step 5: Trigger the response

On the Ubuntu agent, append a new event:

printf '%s %s wazuh-lab: AUTH_FAIL username=testuser srcip=192.0.2.15\n' \
  "$(date '+%b %e %T')" \
  "$(hostname -s)" \
  | sudo tee -a /var/log/wazuh-lab.log

Inspect the agent-side response log:

sudo tail -n 20 \
  /var/ossec/logs/active-responses.log

Expected outcome:

The agent collects the event.
The server decoder identifies the event.
Rule 100100 generates an alert.
Wazuh invokes the configured response on the agent.
The Python script records the response.

If the response doesn’t execute, inspect the manager and agent ossec.log files and confirm the rule ID actually fired.

11.5 Understand automated IP blocking

Wazuh includes a firewall-drop Active Response script on supported Linux systems.

The following example is based on the vendor’s SSH brute-force demonstration:

<active-response>
  <disabled>no</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5763</rules_id>
  <timeout>180</timeout>
</active-response>

This is a reference configuration, not an instruction to enable blocking on your existing machines.

Rule 5763 represents a built-in SSH brute-force detection scenario. A corresponding firewall-drop command definition and suitable firewall tooling must also be present.

Before testing such a response in a dedicated lab, verify that you have console access, the appropriate firewall backend, a reversible timeout, and an independent management connection.

For production systems, also implement exceptions for trusted administration addresses and test the rollback behavior.

11.6 Security integrations

Wazuh can integrate with other tools to support security operations.

Integration	Example purpose
Slack or team messaging	Send selected security notifications
Jira or incident management	Track investigations and remediation
Threat intelligence	Enrich findings with external reputation data
AWS	Collect supported cloud security and audit telemetry
Docker and Kubernetes	Monitor supported container and host security events
APIs and automation	Query agents and manage security configuration

Integrations differ in supported versions and configuration requirements. Some require additional scripts, credentials, permissions, or collectors.

11.7 Basic Wazuh API demonstration

Wazuh exposes a REST API for management and automation.

To avoid placing administrator passwords in a command, use the dashboard’s authenticated Server management → Dev Tools interface.

Execute a read-only request:

GET /agents?limit=10

The response provides information about available agents.

For production automation, create an appropriately restricted account or API integration identity rather than using unrestricted administrator credentials.

11.8 Production best practices

For Active Response and integrations:

Use least-privilege identities and restrict which systems can execute response commands.
Protect webhook URLs, API tokens, and integration credentials.
Avoid automatically disabling accounts or blocking network access based on weak detections.
Test responses in staging before production.
Log every automated action.
Define ownership, escalation, and rollback procedures.
Review noisy or frequently triggered automation.
Restrict and audit changes to response scripts.

Exercise: Generate an event that triggers your harmless Active Response script and verify the resulting agent-side log entry.

Knowledge check

Q: What does location=local mean in an Active Response configuration?

A: The action runs on the monitored agent associated with the triggering event.

Q: What is the difference between stateless and stateful responses?

A: A stateless response performs a one-time action. A stateful response supports reversing or stopping the action after a specified timeout.

Tutorial 12 — End-to-End Security Monitoring Mini Lab

5 minutes | Final integrated exercise

12.1 Objective

Your final task is to connect everything learned in the previous tutorials into one functioning security monitoring workflow.

By this point, the environment should already contain:

A running Wazuh server and dashboard
An enrolled Ubuntu agent
A monitored application log
Custom decoder wazuh-lab
Custom detection rule 100100
File Integrity Monitoring
SCA and vulnerability inventory
A harmless Active Response script

12.2 Final architecture

flowchart TD
    A["Ubuntu monitored endpoint"] --> B["Generate synthetic authentication event"]
    B --> C["Wazuh Logcollector"]
    C -->|"TCP 1514"| D["Wazuh manager"]
    D --> E["Custom decoder"]
    E --> F["Rule 100100"]
    F --> G["Security alert"]
    G --> H["Filebeat and indexer"]
    H --> I["Wazuh dashboard"]
    G --> J["Active Response"]
    J --> K["Write response log on Ubuntu endpoint"]
    I --> L["Investigate and document"]

12.3 Execute the final lab

Step 1 — Confirm agent connectivity

On the Wazuh server:

sudo /var/ossec/bin/agent_control -l

Confirm that the Ubuntu agent is Active.

Step 2 — Generate a security event

On the Ubuntu agent:

printf '%s %s wazuh-lab: AUTH_FAIL username=finaltest srcip=192.0.2.25\n' \
  "$(date '+%b %e %T')" \
  "$(hostname -s)" \
  | sudo tee -a /var/log/wazuh-lab.log

Step 3 — Verify alert generation

On the Wazuh server:

sudo tail -n 50 \
  /var/ossec/logs/alerts/alerts.log

Find the alert associated with your synthetic event and confirm its rule ID, severity, username, and source IP.

If the optional repeated-failure correlation rule becomes the final match, inspect rule 100101 as well.

Step 4 — Verify automated response

On the Ubuntu agent:

sudo tail -n 20 \
  /var/ossec/logs/active-responses.log

Look for your custom response log entry.

If the correlation rule is superseding rule 100100 during repeated testing, adjust the authorized lab Active Response configuration to match the intended rule IDs and retest.

Step 5 — Investigate and explain

In the dashboard:

Open Threat Hunting.
Find the latest matching alert.
Identify the monitored endpoint.
Review the raw log and extracted fields.
Explain why the detection rule matched.
Confirm the response, if configured.
Classify the event as an authorized training simulation.

You have now completed the complete event-to-detection-to-response workflow.

12.4 Final acceptance checklist

[ ] Wazuh server and dashboard are running
[ ] Ubuntu agent is enrolled and active
[ ] System or application logs are being collected
[ ] Custom decoder extracts the expected fields
[ ] Custom rule generates the expected alert
[ ] File creation or modification generates an FIM event
[ ] SCA results and vulnerability inventory have been reviewed
[ ] Security alert can be investigated in the dashboard
[ ] Harmless Active Response has been tested
[ ] Training event and investigation are documented

Troubleshooting Reference

Use this diagnostic sequence when a Wazuh lab does not work.

Symptom	Diagnostic command	What to resolve
Manager not responding	`systemctl status wazuh-manager`	Service errors or configuration
Agent disconnected	`agent_control -l` on server	Agent status and connectivity
Enrollment failing	`nc -zv SERVER_IP 1515`	Routing, firewall, enrollment
No events collected	`wazuh-logcollector -t` on agent	Log path and collection configuration
Decoder not matching	`wazuh-logtest` on server	Program name or regex
Custom rule not loading	`wazuh-analysisd -t` on server	Invalid rule or decoder configuration
FIM not detecting	`wazuh-syscheckd -t` on agent	Baseline, directory, scan settings
No dashboard alerts	Check manager alerts and indexer	Detection vs indexing problem
Vulnerability inventory empty	Check Syscollector and manager logs	Inventory and CTI processing
Active Response not running	Inspect `ossec.log` and response log	Script, permissions, command, rule ID

For every fix, confirm success at the component where the failure originated before retrying the complete workflow. The official Wazuh configuration-validation reference documents the relevant daemon test commands.

Lab cleanup and rollback

Once the exercises are complete, either preserve a VM snapshot or remove the training-specific changes.

On the Ubuntu agent, inspect the temporary files before deleting them:

sudo ls -la /opt/wazuh-lab

sudo ls -l /var/log/wazuh-lab.log

If they contain only disposable training data:

sudo rm -r -- /opt/wazuh-lab

sudo rm -- /var/log/wazuh-lab.log

Remove the corresponding lab-specific <localfile> and FIM directory entries from the agent configuration.

On the Wazuh server, remove only the tutorial’s custom decoder, rules, and Active Response definitions when they are no longer needed. Validate the configuration and restart the affected services. Remove the custom response script from the agent after disabling its configuration.

Do not overwrite entire configuration files from backups if unrelated changes have been made since those backups were created.

What to learn after this 3-hour course

Once you can independently complete the lab, the next areas to study are:

Advanced subject	Why it matters
Wazuh manager clustering and indexer HA	Production availability and scaling
Wazuh API and automation	Programmatic administration
Advanced detection engineering	Rules, correlations, false-positive tuning
Threat intelligence integrations	Enriched security investigations
AWS security monitoring	CloudTrail, GuardDuty, and other supported security telemetry
Container and Kubernetes monitoring	Workload and host security
Security data retention and index management	Cost, performance, and compliance
SIEM incident-response workflows	Operationalizing detections and escalation

Official documentation and references

All version-specific installation methods and core configuration concepts were checked against these Wazuh resources:

Reference	What it covers
Wazuh 4.14.8 Release Notes	Verified stable release
Quickstart	All-in-one installation and resources
Architecture	Components, data flow, and ports
Agent Installation	Linux, Windows, and macOS deployments
Testing Rules and Decoders	Detection validation
File Integrity Monitoring	File monitoring
Security Configuration Assessment	Hardening policy assessments
Vulnerability Detection	Software vulnerability inventory
Active Response	Automated response
Wazuh API	Integrations and automation

Final learning outcome

After studying all 12 tutorials and completing the labs, you should be able to build a small Wazuh deployment, onboard endpoints, collect security events, develop and test basic detection rules, monitor file changes, review security posture and vulnerabilities, investigate alerts, and implement a safe automated response.

This establishes a practical beginner-to-intermediate foundation in Wazuh. It does not yet make the deployment production-ready; that requires additional work on reliability, certificates, identity management, data retention, scaling, detection quality, and incident-response operations.

Verification limitation: The installation methods, command interfaces, and configuration concepts were checked against official Wazuh documentation current to October 11, 2026. The complete lab was not executed against a live Wazuh installation in this conversation. Sample outputs represent expected behavior, and the custom training decoder, rules, and response should be validated in your own isolated environment before broader use.

rajeshkumar