Wazuh SIEM/XDR Home Lab Project

Overview

This project demonstrates the end-to-end deployment and configuration of a comprehensive Security Operations Center (SOC) using the open-source Wazuh SIEM/XDR platform. The goal was to build a multi-machine virtual lab to simulate and defend against real-world security threats. This involved extensive troubleshooting of networking, service configurations, and rule logic to create a stable, fully functional security monitoring environment that follows the full security lifecycle: from proactive defense to real-time detection and automated incident response.

---

Lab Architecture

The lab was built using Oracle VirtualBox and consists of four virtual machines on a dual-homed network (a NAT Network for inter-VM communication and a Host-Only network for management):

• Wazuh Server: Ubuntu Server running the central Wazuh manager, indexer, and dashboard.
• Windows Endpoint: A Windows 11 Pro machine acting as a corporate workstation.
• Linux Endpoint: An Ubuntu Server, acting as a company server.
• Attacker Machine: A Kali Linux instance used to simulate threats.

_

---

Core Capabilities Demonstrated

1. Advanced Endpoint Monitoring with Sysmon

I enhanced endpoint visibility on the Windows agent by integrating Sysmon. This allowed for the detection of granular system activity often missed by standard logging. To simulate a high-fidelity detection for a common threat vector, I authored a custom rule to generate a high-priority alert whenever PowerShell was executed.

View Custom Rule (local_rules.xml)

<!-- Custom rule to force alert on PowerShell start -->
<group name="sysmon,">
 <rule id="100500" level="12">
   <if_group>sysmon_event1</if_group>
   <field name="win.eventdata.image" type="pcre2">(?i)powershell\.exe</field>
   <description>Sysmon - Suspicious Process: PowerShell execution detected</description>
   <group>pci_dss_10.6.1,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_AU.6,nist_800_53_SI.4,tsc_CC7.2,tsc_CC7.3,</group>
 </rule>
</group>

2. Proactive Vulnerability Detection

To protect critical assets, I configured File Integrity Monitoring (FIM) to provide instant alerts for unauthorized file modifications. After initial troubleshooting revealed a persistent configuration sync issue, I successfully pivoted to a direct, local configuration on the agent's ossec.conf file to monitor the user's home directory.

View FIM Configuration (Linux Agent ossec.conf)

<!-- FIM - Real-time monitoring of user's home directory -->
<syscheck>
  <directories check_all="yes" realtime="yes">/home/arthur</directories>
</syscheck>

3. Real-Time File Integrity Monitoring (FIM)

To protect critical assets, I configured File Integrity Monitoring (FIM) to provide instant alerts for unauthorized file modifications. After initial troubleshooting revealed a persistent configuration sync issue, I successfully pivoted to a direct, local configuration on the agent. The test was conducted by creating a new file in the monitored /home/arthur directory, which immediately triggered the FIM alert. This demonstrated not only the ability to configure FIM but also to adapt and solve complex, real-world troubleshooting challenges.

4. Threat Intelligence Integration with VirusTotal

I integrated the Wazuh server with the VirusTotal API. This automatically checks the hash of any new file detected by FIM against VirusTotal's database of known malware, transforming a low-context FIM alert into an actionable, high-confidence security event.

View VirusTotal Integration (Server ossec.conf)

<!-- VirusTotal Integration -->
<integration>
  <name>virustotal</name>
  <api_key>YOUR_API_KEY_HERE</api_key> <!-- API key hidden for security -->
  <group>syscheck</group>
  <alert_format>json</alert_format>
</integration>

---

Grand Finale: The Automated Kill Chain

This final demonstration showcases a complete, automated "Detect and Respond" workflow using a classic brute-force attack scenario. I configured an Active Response to automatically block the source IP of an attacker after multiple failed SSH login attempts.

View Active Response Configuration (Server ossec.conf)

<!-- Active Response - Block IP on multiple failed logins -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>2502</rules_id>
  <timeout>600</timeout>
</active-response>

The Scenario: An attacker (Kali Linux) attempts to gain access to the Linux-WebServer by launching an SSH brute-force attack.

1. The Attack (Before): The attacker has full connectivity and can successfully ping the target machine.

2. Detection and Response: Wazuh's log analysis engine detects the multiple failed SSH login attempts from the same source IP, triggering a Level 10 alert (Rule ID 2502). This alert immediately triggers a pre-configured Active Response rule, which executes the firewall-drop script on the target agent to block the attacker's IP address.

3. The Result (After): The attacker's IP is now blocked at the firewall level on the Linux-WebServer. All further connection attempts from the attacker fail.

This successful demonstration proves the lab's capability to not only detect threats in real-time but to automatically neutralize them without human intervention, completing the full security lifecycle.

Future Improvements

This lab provides a strong foundation for further expansion. Future work could include:

Integrating a SOAR platform like Shuffle or TheHive to automate ticketing and case management.

Expanding to the cloud by deploying a Wazuh agent on an AWS EC2 instance.

Developing more complex attack chains involving lateral movement and data exfiltration to test more advanced detection rules.