Security service stopped
A systemd unit that provides logging, endpoint monitoring, or host firewalling was stopped.
What it detects
A systemd unit that provides logging, endpoint monitoring, or host firewalling was stopped. Turning off the thing that would have recorded the intrusion is usually the step immediately before the part the attacker did not want recorded, and it is the reason the rest of the timeline goes quiet.
The unit name comes from the unit= field inside the SERVICE_STOP record's nested msg='...', so this fires on the audit daemon's own account of the stop rather than on a command line that may never have been captured.
MITRE ATT&CK mapping
False positives and triage
Almost every one of these units is stopped legitimately during a package upgrade, an agent version rollout, or a maintenance window — the stop is real, the intent is not malicious. Separate them by:
* What else ran at that moment. A stop framed by apt/dnf/yum activity, or followed within seconds by a matching start of the same unit, is an upgrade. * Who stopped it. A stop with a login uid behind it, from an interactive session, is a person; a stop from a package transaction is a machine. * Whether it came back. A security agent stopped and never restarted is the case that matters, whatever the reason given.
Do NOT tune this by removing units from the list because they are noisy in your estate — a noisy unit is one an attacker can stop without anyone noticing. Suppress the specific maintenance windows and the config-management account instead.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/linux/security_service_stopped.yaml, licensed under the Apache License 2.0.
id: linux.defense_evasion.security_service_stopped
version: 1.0.0
status: stable
severity: high
confidence: 0.7
platforms: [linux]
mitre_techniques: [T1489, T1562.001, T1562.004]
description: |
A systemd unit that provides logging, endpoint monitoring, or host firewalling was
stopped. Turning off the thing that would have recorded the intrusion is usually
the step immediately before the part the attacker did not want recorded, and it is
the reason the rest of the timeline goes quiet.
The unit name comes from the `unit=` field inside the SERVICE_STOP record's nested
`msg='...'`, so this fires on the audit daemon's own account of the stop rather
than on a command line that may never have been captured.
match:
event_action: service_stopped
service_name_contains_any:
- auditd
- rsyslog
- syslog
- journald
- osquery
- sysmon
- falcon
- crowdstrike
- carbonblack
- cbagent
- mdatp
- wazuh
- ossec
- filebeat
- splunk
- fluentd
- td-agent
- suricata
- snort
- fail2ban
- clamav
- firewalld
- ufw
- nftables
- iptables
- apparmor
- auditbeat
false_positive_guidance: |
Almost every one of these units is stopped legitimately during a package upgrade,
an agent version rollout, or a maintenance window — the stop is real, the intent is
not malicious. Separate them by:
* What else ran at that moment. A stop framed by `apt`/`dnf`/`yum` activity, or
followed within seconds by a matching start of the same unit, is an upgrade.
* Who stopped it. A stop with a login uid behind it, from an interactive session,
is a person; a stop from a package transaction is a machine.
* Whether it came back. A security agent stopped and never restarted is the case
that matters, whatever the reason given.
Do NOT tune this by removing units from the list because they are noisy in your
estate — a noisy unit is one an attacker can stop without anyone noticing. Suppress
the specific maintenance windows and the config-management account instead.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.