{
  "id": 5260068,
  "title": "Hands-On SIEM Detection: Building, Breaking, and Auditing a Wazuh Lab Environment",
  "url": "https://urgent.news/2026/09/03/hands-on-siem-detection-building-breaking-and-auditing-a-wazuh-lab",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-03T05:35:48.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/catalog346/hands-on-siem-detection-building-breaking-and-auditing-a-wazuh-lab-environment-4imd"
  },
  "original_language": "en",
  "account": "In a recent report, cybersecurity enthusiast Joseph shares his experience building, breaking, and auditing a Wazuh laboratory environment. He likens the process to preparing a surface for painting, emphasizing the importance of proper logging pipelines and configurations to ensure visibility and discover lost telemetry.\n\nJoseph set up a containerized instance of Damn Vulnerable Web Application (DVWA) running on port 8080 of a host server, monitored by a Wazuh agent. While standard agent installations only capture system logs, Joseph modified the deployment to bind-mount the container’s internal Apache logs directly to the host filesystem at /var/log/dvwa/. He created the host-side log directory, verified the container logs were mapping, and updated the agent configuration to append a custom localfile collection block.\n\nAfter applying the configuration, Joseph generated test traffic on DVWA and expected events to populate in the Wazuh Dashboard. However, no events appeared. He discovered the mistake was setting the directory permissions to a restrictive 700 while operating under root privileges, denying read access to the log file. By updating the permissions to 755 for the directory and 644 for the log files, Wazuh began receiving live Apache access events from the container.\n\nJoseph conducted three experiments to evaluate Wazuh's detection capabilities:\n1. Network reconnaissance and web scanning: He executed an Nmap service scan and a Nikto web vulnerability scan from an external host. Apache logs captured rapid request bursts and scanner User-Agent headers, triggering Wazuh Rules 31101 (Web server 400 error codes) and 31108 (Vulnerability scanner activity).\n2. Command injection and kernel process audit: He submitted a command injection payload through DVWA, returning system account details for the www-data user. While Apache logs recorded the POST request, querying system audit logs via ausearch yielded zero hits, highlighting a boundary between web logs and host-level audit logs due to container namespace isolation.\n3. Post-exploitation persistence via scheduled tasks: He simulated persistence by appending a scheduled task to /etc/crontab. Wazuh detected the modification to /etc/crontab, demonstrating its ability to identify post-exploitation activity.\n\nThrough these experiments, Joseph demonstrated the importance of proper logging configurations in SIEM environments and how they can uncover critical telemetry. He hopes this write-up will help others build and audit their own detection labs, emphasizing the need for thorough preparation and attention to detail, much like quality painting.",
  "summary": "What happens when a web server captures an attack in its access logs, but the underlying host system remains completely blind to the actual commands being run? Setting up a Security Information and Event Management (SIEM) platform is not just about turning on a tool and watching a dashboard. It is about engineering true visibility and discovering where critical telemetry gets lost. In this post,…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}