Wazuh

What it watches

• File-integrity changes (FIM) — a config, binary, or sensitive file modified
• Suspicious process execution — a shell spawned from Office, a new SUID binary
• Authentication events — failed + successful logins, sudo, new admin
• Rootkit + anomaly detections from the built-in rulesets
• Software-inventory drift across the fleet

MITRE ATT&CK coverage

Tactics this connector gives CyberCLI visibility into.

Every matrix-covered event_type on the passthrough lane — pinned by the engine's coverage matrix. The right column shows the operator-friendly phrase the dashboard renders. High-severity AI-lane signals are summarized in What it watches above (Warden + Herald handle those); the rest take the substrate's passthrough lane (no AI tokens burned).

What it helps you catch

Wazuh ships a normalized alert per security event — login failures, integrity changes, firewall blocks, vulnerability findings. The 17 fields we read tell us what fired (rule_id, rule_level, description), where (agent, location, srcip), who (srcuser, dstuser), what MITRE technique it maps to (mitre), and the raw evidence. Every field is operator-readable in the CYCON view — nothing is hidden behind an embedding.

{
  "timestamp": "2026-05-11T18:21:14.000+0000",
  "rule": {
    "id": "5710",
    "level": 10,
    "description": "Attempt to login using a non-existent user",
    "groups": [
      "syslog",
      "authentication_failed",
      "invalid_login"
    ],
    "mitre": {
      "id": [
        "T1110"
      ],
      "tactic": [
        "Credential Access"
      ]
    }
  },
  "agent": {
    "id": "001",
    "name": "hal6000"
  },
  "manager": {
    "name": "wazuh-manager"
  },
  "id": "1778523290.42",
  "decoder": {
    "name": "sshd"
  },
  "data": {
    "srcip": "203.0.113.42",
    "srcuser": "chris@bladeglobal.com"
  },
  "location": "/var/log/auth.log",
  "full_log": "May 11 18:21:14 hal6000 sshd[12345]: Invalid user chris@bladeglobal.com from 203.0.113.42 port 51842"
}

Field count + sample event auto-derived from src/cybercli/connectors/wazuh/vector.vrl at build time. Numbers update the moment the engine's parser changes — no drift.

Close more of the kill chain

Wazuh covers 10 of 14 ATT&CK tactics. Pair it with these to widen coverage:

UniFi Pro

+2 new tactics

Avanan Pro

+2 new tactics

CrowdStrike Pro

+2 new tactics

How to connect

1. 1 Install the Wazuh manager + deploy agents to your hosts (one-liner below).
2. 2 In CyberCLI, point the connector at your Wazuh indexer/API endpoint + credentials (stored in the vault, never in config).
3. 3 Run `cybercli onboard wazuh` — it validates the connection and starts the event stream.
4. 4 Confirm events are flowing via the substrate receipt in the dashboard's Connectors panel.

curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh && sudo bash wazuh-install.sh -a

Pre-flight

1. 1

   Wazuh Manager has at least one enrolled agent reporting

   CyberCLI polls the manager API for alerts — if no agents are enrolled, you'll connect cleanly but see zero events forever, which reads as a broken connector. Enrol at least the local host as a smoke-test agent before onboarding.

   /var/ossec/bin/agent_control -l   # lists enrolled agents (run on the manager)

2. 2

   Manager API is reachable from the CyberCLI host on 55000/tcp

   The Manager API (port 55000) is what CyberCLI polls. NOT the Indexer (9200) and NOT the Dashboard (443) — those are separate services. All-in-one deploys bind all three; if you've split the manager onto its own host, make sure 55000 is the one CyberCLI can reach.

   curl -k -u <user>:<pass> https://<manager>:55000/   # expect JSON {error: 0}

3. 3

   API user with read-only role exists (don't use admin)

   CyberCLI only needs read access for the polling lane. Wazuh's default 'wazuh' user has admin rights — giving CyberCLI those keys is a needless blast-radius if the credential ever leaks. Create a dedicated read-only user via the Wazuh dashboard before onboarding.

Configure

1. 1

   Create a read-only API user in Wazuh

   Wazuh Dashboard → Server Management → Security → Users → Create user

   Make a dedicated user for CyberCLI rather than reusing the master 'wazuh' account. Assign the built-in `readonly` role — sufficient for the alerts + agent-list + group-list endpoints CyberCLI polls. Save the username + password; you'll paste them in the next step.

   Username

   cybercli-readonly

   Or whatever you prefer; pick something obvious in audit logs.

   Password

   <strong unique value>

   Will be stored in CyberCLI's vault (chmod 600 + master-key encrypted).

   Roles

   readonly

   DO NOT assign the administrator role; readonly is enough.

   Important

   Don't reuse the master 'wazuh' user. If that credential leaks, an attacker can add/remove agents and modify rule configs. Read-only contains the blast.

2. 2

   Run the CyberCLI onboarding command

   On your CyberCLI host

   The onboarding flow prompts for the manager URL + credentials, validates the connection, stores the credentials in the vault, and starts the poller. The first poll runs immediately so you should see events within the manager's alert cadence.

   command

   cybercli onboard wazuh

   Manager URL

   https://<manager-host>:55000

   55000 = manager API. NOT 9200 (indexer) or 443/9443 (dashboard).

   Username

   cybercli-readonly

   The dedicated user from step 1.

   Password

   <paste at prompt>

   Never typed in clear; vault-stored on save.

   Verify TLS

   yes (or no for self-signed lab deploys)

   Default Wazuh installs self-signed — answer 'no' only if you trust the network path. Production: install a real cert + answer yes.

3. 3

   Confirm the connector shows healthy in the dashboard

   CyberCLI Dashboard → Connectors

   After ~30 seconds the Wazuh row should show a green health indicator + last-poll timestamp + non-zero events-today (assuming agents are reporting). If health is yellow, the poller is up but no alerts are arriving — check the agent fleet on the manager side.

4. 4

   (Optional) Speed up FIM cadence on test agents

   Manager → /var/ossec/etc/ossec.conf → <syscheck>

   Wazuh agents run file-integrity checks every 12 hours by default. For smoke-testing the connector you can drop this to 1 hour temporarily — but DO NOT leave it short in production (cpu cost on the agent fleet).

   <frequency>

   3600

   Seconds. Default is 43200 (12h). Revert after testing.

   <scan_on_start>

   yes

   Forces a scan on agent restart — useful to see FIM events flow during onboarding without waiting for the natural cadence.

   Why this

   Newcomers onboard the connector, see the health indicator go green, then stare at the dashboard for an hour waiting for an event. Speeding up FIM on a test agent + tripping a sentinel file (touch ~/.wazuh-test-file) produces a visible signal in under 10 minutes.

Verify

1. 1

   Confirm the manager API is reachable + creds work

   curl -k -u cybercli-readonly:<pwd> https://<manager>:55000/security/user/authenticate

   You should see

   {"data": {"token": "ey..."}, "error": 0}

   If this fails

   401 = wrong creds. 404 = wrong path or wrong port (you might be hitting the dashboard instead of the manager). Connection refused = manager not running or firewall blocking. Verify with `systemctl status wazuh-manager` on the manager host.

2. 2

   Trigger an event to confirm signals flow

   touch /etc/wazuh-fim-test && sleep 60   # on an FIM-monitored path

   You should see

   New file detected: /etc/wazuh-fim-test  (or similar agent log line)

   If this fails

   If FIM scan_on_start is off + frequency is at default, you can wait 12 hours. Speed up the cadence (step 4 above) or trigger an auth event instead (ssh in + out — produces an event in seconds).

3. 3

   Confirm CyberCLI sees the signal

   cybercli signals list --connector wazuh --limit 5

   You should see

   Recent Wazuh signals — count: 5

   If this fails

   If signals stay at 0 but the connector is healthy: the manager IS emitting alerts but CyberCLI's poller hasn't caught up. Check `cybercli doctor` for poller-cursor lag and `sudo journalctl -u cybercli` for connector errors.

Pitfalls (what bit us so it doesn't bite you)

Troubleshoot

FAQ

Go deeper