Wazuh 5.0 "System service started" alerts from sysstat-collect, and the post-filter that drops everything else

A post-filter keeps what it matches

This is the part that can cost you data, so it comes first. We created a post-filter in the standard space, then pushed two events through the manager's engine: one sshd line and one sudo line. We counted what reached wazuh-events-v5-*. Two runs, one per filter, through the local ingest socket:

The filter that "matches sshd" did not drop sshd. It kept sshd and dropped the sudo event, which it did not mention at all. A filter written as contains($service.name, 'sysstat-collect') would keep the sysstat events and drop every other event the manager receives. To drop something, the check has to say NOT.

Nothing warns you. The filter passes the engine's validation, and the manager log shows only a normal reload line ([Orchestrator] Hot swapped namespace).

IDX=http://localhost:9200   # your indexer. Ours had the security plugin off: plain HTTP, no login.
CURL="curl -s"              # normal install: CURL="curl -sk -u admin:YOUR_PASSWORD" and IDX=https://...

$CURL "$IDX/_cat/indices/wazuh-threatintel-rules*?h=index"    # ours: wazuh-threatintel-rules-a
$CURL "$IDX/wazuh-threatintel-rules-a/_search?size=2" -H 'Content-Type: application/json' \
  -d '{"query":{"terms":{"document.id":["653da773-9e1b-5f39-a662-e5fafe3b1516","1e9dc454-ce81-5df4-a95b-2ab4d8bde5d3"]}}}' \
  | python3 -m json.tool | grep -E '"title"|"modified"|sysstat|filter_benign'

$CURL -XPOST "$IDX/_plugins/_content_manager/logtest/detection" -H 'Content-Type: application/json' -d '{
  "space": "standard",
  "integration": "7f21dc98-7e96-579d-89bd-5e2cb6e51801",
  "input": { "event": { "action": "service-started", "category": ["host"] },
             "service": { "name": "sysstat-collect.service" } }
}'

$CURL "$IDX/wazuh-threatintel-policies-a/_search?size=10&_source=space.name,document.filters,user_overrides" | python3 -m json.tool

Why it happens

Both rules have the same shape:

condition: selection and not filter_benign_services
selection:
  event.action: [ service-started ]        # service-stopped in the second rule
  event.category|contains: host
filter_benign_services:
  service.name|contains: [ fprintd, geoclue, spice-vdagentd, fwupd-refresh, setvtrgb,
    systemd-localed, systemd-timedated, NetworkManager-dispatcher, modprobe, dmesg,
    packagekit, systemd-tmpfiles-clean, user-runtime-dir ]

Any service that starts or stops and is not on those 13 names matches. According to #40801, the default sysstat-collect.service on Ubuntu 24 and 26 runs every 10 minutes, so it matches every time it runs; we did not run sysstat ourselves. Both rules are level informational, tagged attack.t1543.

In 5.0 these rules live in the indexer, in the standard space that Wazuh ships and updates. You cannot change them in place. We tried to update the "started" rule through the content manager API and got:

Rule with ID '653da773-9e1b-5f39-a662-e5fafe3b1516' is not in draft space.

The request in #40801 is for Wazuh to add sysstat-collect to the list. When we checked on 28 October it was open, with no reply.

How to drop the sysstat events (tested, with one gap)

Create a post-filter in the standard space that keeps every event except a sysstat-collect start or stop:

$CURL -XPOST "$IDX/_plugins/_content_manager/filters" -H 'Content-Type: application/json' -d '{
  "space": "standard",
  "resource": {
    "name": "filter/drop-sysstat-collect/0",
    "metadata": { "title": "Drop sysstat-collect service start/stop events", "author": "you",
                  "description": "Benign timer service, see wazuh/wazuh#40801",
                  "references": [], "documentation": "" },
    "enabled": true,
    "type": "post-filter",
    "check": "NOT (contains($service.name, '"'"'sysstat-collect'"'"') AND (string_equal($event.action, '"'"'service-started'"'"') OR string_equal($event.action, '"'"'service-stopped'"'"')))"
  }
}'

(The '"'"' pieces put a single quote inside the shell's single-quoted body. The check the engine stores is NOT (contains($service.name, 'sysstat-collect') AND (string_equal($event.action, 'service-started') OR string_equal($event.action, 'service-stopped'))).)

• The reply is the new filter's ID. It was added to the standard policy's filters by itself, and to the wazuh-user-overrides registry, and the manager reloaded about 40 seconds later (look for Hot swapped namespace in the manager log).
• Run it once. We ran it twice by accident and got two identical filters with different IDs; the API does not refuse a duplicate name. Run check 3 before you add one.
• Then check that other events still arrive. Count recent events by process.name before and after. event.original is not indexed in 5.0, so you cannot search for a raw line:

$CURL "$IDX/wazuh-events-v5-*/_search?size=0" -H 'Content-Type: application/json' -d '{
  "query": { "range": { "@timestamp": { "gte": "now-5m" } } },
  "aggs": { "p": { "terms": { "field": "process.name", "missing": "(none)" } } } }'

With this filter on, our sshd and sudo test events were both indexed, and both produced findings about a minute later.

The gap: we did not see the filter drop a real sysstat event, because our lab could not produce one (see limits). What we did measure is that a NOT filter dropped the event it matched (the table above) and that this exact check kept events it does not match.

To remove it: $CURL -XDELETE "$IDX/_plugins/_content_manager/filters/FILTER_ID" -H 'Content-Type: application/json' -d '{"space":"standard"}'

Trade-off: a post-filter drops the event itself, not only the alert. Those sysstat start and stop events will not be in wazuh-events-v5-* either. If you need them kept for audit, this is the wrong tool. We did not test any way to suppress only the finding.

What we measured

Wazuh manager 5.0.0-rc1 (commit aff7a0b) and one indexer node, OpenSearch 3.6.0, security plugin off, our test containers, 28 October 2026. Times are UTC.

Rule test (logtest/detection)

Filter test (events through the engine)

Each run: one line sshd[...]: Server listening on 0.0.0.0 port 222xx. (the system-auth decoder maps it to service-started) and one sudo line, pushed into the manager's engine through its local ingest socket (engine-ingest-http.sock, POST /events/enriched). We waited for the manager to reload after each filter change, then counted documents in wazuh-events-v5-* by process.name from the time of the push.

We removed every test filter afterwards; the standard policy's filters list was empty again.