标签：#wazuh

Not three percent. Three techniques. The four chains you would most want to catch — discovery, collection, exfiltration, C2 — produced zero alerts between them. I want to be precise about what that number is and is not, because the number is easy to misread in both directions. What it is A default install. Stock rules, no Sysmon, no ScriptBlock logging, no tuning. We replayed 24 techniques and counted how many produced an alert a human would see. Denominator: 24. Numerator: 3. What it is not It is not a claim that Wazuh is a bad SIEM. It is a claim that a default SIEM is close to blind, and that most of the detection you think you bought is configuration you have not done yet. The same technique, three SIEMs T1110.001 (brute force) is the one technique we have run end-to-end on all three platforms. SIEM Setup Result MTTD Wazuh 4.14.2 SSH brute force, 20+ failed logins, custom rule 100113 ALERTED ×2, coverage 100% 25s / 45s IBM QRadar CE 7.3.3 hydra, 50 SSH login attempts against a live victim host ALERTED ~4s Splunk Enterprise winsrv01 , 12× EventCode 4625 — events replayed into Splunk, not generated by a live attack ALERTED 0s Read the third row differently from the first two. Wazuh and QRadar were measured against a real attack on a real host: hydra and a live SSH brute force, with the alert coming back out of the platform. The Splunk row is a real Splunk Enterprise, a real detection-as-code rule, and a real query — but the 4625 events were replayed in rather than produced by an attack we ran. That makes it a valid test of the connector and the rule. It is not a test of Splunk's ingest path, and we are not going to let it read as one. 🔴 Do not read this table as a race either. The three numbers are not comparable and we are not going to pretend they are. Splunk's 0s is not Splunk being six times faster than QRadar — it is Windows 4625 events already sitting in the index before the clock started, while the Wazuh figure includes agent-to-manager-to-indexer propagati

Introduction Setting up a SIEM sounds simple until you have to prove that it is actually seeing what you think it is seeing. For this project, I added Wazuh and Sysmon monitoring to an Atomic Red Team workstation, then used safe attack simulations to trace activity from the Windows endpoint into the SIEM. Two of my experiments produced clear, matching evidence in Sysmon and Wazuh. A third showed something equally useful: Sysmon recorded the activity locally, but I could not find a matching Wazuh alert. That gap taught me that installing a logging tool is only the beginning. Detection coverage has to be tested, not assumed. My name is Christopher Bontempi, and I am transitioning into cybersecurity because I enjoy problem-solving, continuous learning, and figuring out how systems fit together. This is my first contribution to the cybersecurity community. I hope it helps another beginner see how a collection of logs can become a useful story about what happened on a system. Setup Adding ART Workstation to Wazuh I chose ART Workstation for this project because it already had Atomic Red Team installed. That gave me a safe Windows endpoint where I could generate controlled activity without changing the Active Directory server. From the Wazuh dashboard on Blue-Team Workstation, I generated a Windows agent deployment for the Wazuh manager at 10.170.0.99 . I named the agent ARTWorkstation and assigned it to the default and Windows_Servers groups. On ART Workstation, I ran Wazuh’s generated installer command from an elevated PowerShell window, then started the service: NET START WazuhSvc Wazuh showed ARTWorkstation as active with agent ID 008 and IP address 10.160.0.100 . At that point, I knew the endpoint could communicate with the SIEM, but I still needed useful Windows telemetry to validate the rest of the project. Installing Sysmon and forwarding its logs Next, I downloaded Sysmon and Neo23x0’s sysmonconfig-export.xml baseline configuration. I installed Sysmon64 from an e

Most "I built a home SOC" posts show you the pretty dashboard and stop there. This one is about what happened after the dashboard loaded — because that's where the real learning was. 🖥️ The setup Three Mac Minis, one control machine, all Ubuntu. Mac Mini 1 runs the Wazuh manager, indexer, and dashboard — the security monitoring core. Mac Mini 2 handles AWS IAM permission scanning (Cloudsplaining, ScoutSuite). Mac Mini 3 is a documentation hub plus a custom vulnerability-intelligence pipeline pulling from the NVD API and NIST's CPRT compliance framework data. A fourth machine, my daily driver, orchestrates all three over SSH. Today's goal: get every machine reporting into Wazuh, so I'd have real, fleet-wide visibility — not just a single monitored box. 🐛 Bug #1: the silent feed stall After installing the Wazuh agent on Mac Mini 3, vulnerability scanning just... sat there. The log showed Initiating update feed process and then nothing. No error, no timeout, no progress. I ruled things out methodically: DNS resolved fine, curl could reach Wazuh's CTI feed endpoint and complete a full TLS handshake, disk space was nowhere close to full, and there were no stale lock files sitting around. Every individual piece of the pipeline worked in isolation — but the feed download itself never completed. The actual fix: upgrade Wazuh from 4.14.5 to 4.14.6. A newer point release fixed whatever was silently stalling the content-updater module. Once upgraded, the feed downloaded, decompressed, and the scanner came alive within minutes. Lesson: when every individual network/system check passes but a specific module still won't progress, check for a version-specific bug before going deeper down the debugging rabbit hole. 🔒 Bug #2: locking myself out with fail2ban Mid-troubleshooting, my control machine's SSH connection to Mac Mini 3 started getting flatly refused — no prompt, no error, just Connection refused. Ping worked fine. Every other port responded. Just port 22, silently dead. fai