Wazuh integration

Noxen's SIEMExporter emits findings as NDJSON (newline-delimited JSON), which Wazuh's logcollector tails in json log format. The result is Noxen findings sitting alongside Wazuh's own HIDS, FIM, and rootcheck events in the same indexer — so you can correlate a fresh CVE on openssh-server with the SSH login anomaly Wazuh flagged half an hour earlier.

What gets exported

Each NDJSON line is one finding. Records share a common base (@timestamp, source, host, scan_started_at) plus a category discriminator and the category-specific fields. The five categories Noxen emits are cve, open_port, tls, http_header, and admin_surface. Sample CVE line:

{"@timestamp":"2026-05-27T03:14:00.123Z","category":"cve","cve_id":"CVE-2024-6387","cvss_score":8.1,"description":"A signal handler race condition in OpenSSH's server (sshd)…","host":"db-01.prod.example","matched_cpe":"cpe:2.3:a:openbsd:openssh:9.6:*:*:*:*:*:*:*","package_name":"openssh-server","package_version":"1:9.6p1-3ubuntu13.5","scan_started_at":"2026-05-27T03:14:00.123Z","severity":"critical","source":"noxen"}

Keys are sorted alphabetically per record so a diff between two exports surfaces real content changes rather than key-order churn. Optional global tags (env, region, tenant) apply to every record for downstream filtering — set them in Settings → SIEM export → Global tags.

Setup

In Noxen: Settings → SIEM export → Add destination. Pick a folder — for example, /var/ossec/logs/noxen/ on the Wazuh manager host, or a folder synced to the manager via Syncthing / rsync from the Mac running Noxen. Set the file pattern (e.g. noxen-{{date}}.ndjson).
Schedule the export. Either tick Run after every scan, or trigger it manually via File → Export → SIEM (NDJSON).
On the Wazuh side, add a <localfile> block to /var/ossec/etc/ossec.conf:
```
<localfile>
  <log_format>json</log_format>
  <location>/var/ossec/logs/noxen/*.ndjson</location>
</localfile>
```
Then restart the manager: systemctl restart wazuh-manager. Wazuh tails the file and decodes each line as a JSON event.

Decoder and rule scaffolding

Because Noxen's NDJSON already uses lowercase, underscore-separated keys, Wazuh's built-in JSON decoder handles ingest without a custom decoder file. Pin a rule on the severity and category fields to fire actionable alerts — for example, a Level-12 rule for any record where category == "cve" and severity == "critical". Match on data.source == "noxen" to scope the rule strictly to Noxen events.

Cross-correlation with Wazuh HIDS

Wazuh already tracks failed SSH logins, FIM events, and rootcheck anomalies on Linux hosts. Layering Noxen findings on top gives you: "this host has a critical OpenSSH CVE, and Wazuh logged 127 failed SSH attempts to it in the last hour." That kind of pivot is hard to do when CVE inventory lives in a separate tool — having both in the same indexer makes it trivial.

When alerts fire

NDJSON files are written on scan completion (or on demand). The pipeline latency from scan completion to Wazuh alert is whatever logcollector adds to the tail-and-decode loop — typically a second or two on a healthy manager.

What it doesn't do

No native push to Wazuh's API. Noxen writes NDJSON to disk; Wazuh reads it. There's no agent-side HTTP push.
No CVSS-to-Wazuh-level mapping. You decide which Wazuh rule levels Noxen severities map to — that's a policy call we leave to the operator.
No bidirectional sync. Wazuh's own events don't flow back into Noxen; the relationship is one-way.

SIEM export unlocks at the MSP tier ($149/month), which is also the right tier for anyone running Wazuh against multiple client fleets — see the MSP page for the multi-tenant catalog story. Other SIEM destinations are covered on the integrations hub.

See pricing →