From SIEM to SOC: layered detection around Wazuh

Context

The company, a distribution business of about twenty people, runs on Windows Server, Active Directory, a perimeter firewall and Microsoft 365. Each machine kept its logs to itself: nothing collected or correlated them.

An attack often combines modified files, unusual traffic and movement to other machines; seen in isolation, each step looks harmless. Hence several detection layers, with three constraints: no software cost, detect without blocking, and validate every module on the real infrastructure.

What I did

1. Build a dedicated SIEM serverAn Ubuntu Server 22.04 LTS VM on Hyper-V (8 vCPUs, 32 GB of RAM), with an address fixed from the design stage: every agent and Syslog stream points to it.
2. Monitor the machinesReal-time integrity monitoring of sensitive files, endpoint configuration checked against CIS benchmarks, and Auditd on the SIEM itself, the most sensitive target.
3. Listen to the networkSuricata as a passive IDS, with 50,682 Emerging Threats Open rules enabled: it observes without blocking while normal traffic is learned.
4. Set up a decoyOpenCanary simulates services that look attractive to an attacker, on its own isolated VM. Nobody has a reason to connect to it: its events raise a level-13 alert out of 15.
5. Repair MITRE ATT&CK taggingIt had never worked: two failures stacked up. After reinstalling the manager, it is active, without losing any rules or integrations.

See technical details

Server. 400 GB of disk. Ubuntu Server 22.04 LTS is the platform the Wazuh vendor tests first, with five years of support. Manager, indexer (OpenSearch) and dashboard are installed together by the official script; the admin password, shown once, is stored in a dedicated vault.

Machines. File integrity monitoring (FIM) in real time rather than periodic scans, with report_changes: the alert includes the details of the change. Configuration assessment (SCA) runs every twelve hours; with no consolidated view, I read each agent's score through the REST API, with a JWT token. On the SIEM, Auditd watches commands run by privileged accounts, access to the Wazuh configuration and the local firewall rules. The server's other protections are covered in a separate project.

Bash · Wazuh REST API

# 1. Get a JWT token (password masked)
TOKEN=$(curl -sk -u wazuh:'********' -X POST \
  'https://localhost:55000/security/user/authenticate' \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["data"]["token"])')

# 2. SCA score of one agent (here 001), then the same request for each active agent
curl -sk -H "Authorization: Bearer $TOKEN" 'https://localhost:55000/sca/001?pretty=true'

Network. Suricata in multi-threaded af-packet mode. Among the disabled rules: industrial protocols (Modbus, DNP3), irrelevant here. A badly tuned IPS can cut legitimate traffic; switching to blocking, on a few well-understood rules, would only come later. To validate the chain end to end, a simulated SSH scan alert triggered Wazuh rule 86601 (“ET SCAN Potential SSH Scan”, level 3, ET signature 2001219).

Wazuh · ossec.conf

<ossec_config>
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>
</ossec_config>

Decoy. Its own VM, so that an attacker trying to break out of it does not land on the tool that watches everything else; a dedicated machine is also more convincing. The rule fires as soon as an event contains “opencanary”.

Wazuh · local_rules.xml

<group name="local,">
  <!-- Root rule: local parent, produces no alert -->
  <rule id="100001" level="0">
    <match>.</match>
    <description>Regle racine locale.</description>
  </rule>

  <!-- Any trace from the decoy: level-13 alert -->
  <rule id="100002" level="13">
    <if_sid>100001</if_sid>
    <match>opencanary</match>
    <description>OpenCanary: Intrusion detectee sur le honeypot</description>
  </rule>
</group>

MITRE, failure 1: the Wazuh interface stops responding

Problem

Web interface frozen, dashboards unreachable. Run in the foreground, the analysis engine showed that the day's archive file belonged to root instead of wazuh: it refused to start.

Fix

Recursive ownership fix on the Wazuh logs: API, interface and engine came back immediately.

MITRE, failure 2: the reference database will not rebuild

Problem

Detection worked, but no alert was tagged. The internal MITRE database was corrupted; deleting it did not rebuild it, and extracting it from the package only gave an empty, uncompiled shell.

Fix

Reinstalled the manager, whose official post-install scripts compile this database; Wazuh was updated along the way. An SSH brute-force test, reported by a Windows agent, confirmed the tagging.

The incident

Results

An HTTP request to the decoy makes the alert appear in under 30 seconds. It detects connections to itself, not every lateral movement, and a legitimate inventory tool may touch it: each alert is triaged before any response.

The first CIS measurement of the Windows endpoints gave 28 to 29%, the score expected without hardening GPOs. Each failed check points to the GPO that fixes it: a work list. Wazuh's PCI DSS and GDPR dashboards map alerts to requirements: useful to prepare an audit, without proving compliance.

Later, the Active Directory audit added the domain controllers' advanced auditing to the SIEM, and a homelab cyber range (in French) showed what a firewall → SIEM chain lets through.

What I would improve

• Plan a mirror port (SPAN) on the core switch from the design stage: an IDS only detects the traffic it is shown.
• Track fleet coverage from day one, “active agents / inventoried machines”, to know what the SIEM cannot see.
• Add active response step by step, starting with the decoy: observe which legitimate tools touch it, then temporarily block the source address.

Skills

• Layered detection architecture
• Wazuh SIEM administration
• Network detection with Suricata
• Decoys and alert triage
• Troubleshooting in production
• MITRE ATT&CK and CIS Benchmarks