Systemctl invoked with a state-changing service subcommand

Siemphony@siemphonylowT1569.003unverified

Matches the execution leg of AN0200 on raw auditd: an EXECVE record whose argv[0] is `systemctl` and whose first argument is one of the subcommands that actually make a unit run or persist, rather than one of the many that only report state. MITRE's `SuspiciousSubcommands` knob names start, enable and daemon-reload; the list here is those three plus restart, reenable and link, added by the author because `systemctl link /tmp/evil.service` is the direct expression of the analytic's "services loaded from unusual locations". The logic stays inside one record on purpose. Raw auditd splits an execution across records — `exe`, `uid` and `auid` are on SYSCALL, the arguments on EXECVE — so a selection that gates the binary on `exe` and the subcommand on `a1` can never be true in a single event; matching argv[0] instead keeps both halves on the EXECVE record, and it is anchored with `endswith` because a shell passes the word as typed while a script usually passes `/usr/bin/systemctl`. Two gaps follow from auditd's positional arguments and should be assumed present rather than discovered later: an option placed before the subcommand, as in `systemctl --now enable x`, moves it to `a2` and this rule misses it, and Sigma has no way to say "any argument". The path-carrying form is not gated on either, because the unit path may land in `a2`, `a3` or later depending on options. The analytic's other legs are deliberately not used here: unit-file writes under /etc/systemd/system and /tmp are the mechanism ATT&CK models as T1543.002, and writing them under this technique would file another technique's observable behind the T1569.003 tag; the CONFIG_CHANGE leg records auditd's own ruleset changes, not systemd's. MITRE's `CorrelationWindow` knob, which joins a unit file write to the later systemctl call, needs a timeframe lib/sigma does not model. Prerequisite: auditd records no execve at all by default, so this rule returns zero rows until a rule such as `-a always,exit -F arch=b64 -S execve -k exec` is loaded, and zero rows reads as quiet when it actually means blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0073, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Splunk · SPL

Run this as a search.

index=* ((type="EXECVE" AND a0="*systemctl") AND (a1="start" OR a1="restart" OR a1="enable" OR a1="reenable" OR a1="link" OR a1="daemon-reload"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "execve" AND TO_LOWER(a0) LIKE "*systemctl") AND (TO_LOWER(a1) == "start" OR TO_LOWER(a1) == "restart" OR TO_LOWER(a1) == "enable" OR TO_LOWER(a1) == "reenable" OR TO_LOWER(a1) == "link" OR TO_LOWER(a1) == "daemon-reload"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)systemctl$</field>    <field name="a1" type="pcre2">(?i)(^start$|^restart$|^enable$|^reenable$|^link$|^daemon-reload$)</field>    <description>Systemctl invoked with a state-changing service subcommand</description>    <mitre>      <id>T1569.003</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"auditd"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: auditd / linux
Level: low
Category: lateral_movement_remote_exec
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 3fd7546e-d2d5-47cb-98fa-1088db6e9d9d

ATT&CKT1569.003

T1569.003Systemctl

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonlateral movement remote exec

lateral movement remote execAI draft — unreviewed

01 · What this rule detects

AN0200 describes abuse of systemctl to execute commands or manage systemd services, and names two discriminators: units loaded from unusual locations such as /tmp or /dev/shm, and service changes outside expected administrative workflows. This rule implements neither. What it actually matches is a state-changing systemctl subcommand — a scaffold for hunting, not an alert. Be honest about the gap, because the rule's own false-positive list makes it plain: package transactions, config-management convergence, deploys, cloud-init and a post-edit daemon-reload all produce exactly the event the technique produces, with nothing in the record separating them.

02 · Telemetry you need

product: linux / service: auditd, copied verbatim from AN0200. auditd records no execve at all by default, so this returns zero rows until a rule such as -a always,exit -F arch=b64 -S execve -k exec is loaded — and zero rows reads as quiet when it means blind. Three of four backends render it; Sentinel refuses, because no table is modelled for this logsource, and the refusal is recorded rather than worked around.

03 · How the logic works

Two selections, ANDed. selection_execve gates type: 'EXECVE' and a0|endswith: 'systemctl'. selection_subcommand matches a1 exactly against six values. The record shape is the interesting part. Raw auditd splits one execution across records: exe, uid and auid live on SYSCALL, the arguments on EXECVE. A selection gating the binary on exe and the subcommand on a1 therefore can never be true in a single event — it would validate clean, render in every backend, and never fire. Matching a0 keeps both halves on the same record. endswith is used because argv[0] is whatever the caller passed: the bare word from a shell, or the absolute /usr/bin/systemctl when a unit file, cron entry or program execs it directly. The six subcommands are start, restart, enable, reenable, link and daemon-reload. MITRE's SuspiciousSubcommands knob names three of those — start, enable and daemon-reload. The other three are the pipeline's own, added because systemctl link /tmp/evil.service is the direct expression of the analytic's "unusual locations" clause. Positional matching is where this rule bleeds. Sigma cannot say "any argument", so an option before the subcommand moves it to a2 and nothing matches. That is not a corner case: systemctl --now enable evil.service is the standard one-line install-and-start for a persistence unit, and systemctl --user enable is the variant needing no root. Both miss. The unit path is not gated at all, because it may land in a2, a3 or later. Two further bypasses are free and out of scope for any argv rule: systemd-run --unit=x /tmp/payload starts a transient unit with a0 of systemd-run, and a D-Bus StartUnit call to org.freedesktop.systemd1 runs no systemctl at all. Unit-file writes are T1543.002 and are deliberately left there.

04 · Common false positives

Everywhere. Package installation and upgrade lead: Debian postinst and RPM scriptlets call daemon-reload and start/enable for every unit a package ships, so each apt or dnf transaction produces several matches. Ansible, Puppet, Chef and Salt assert unit state by shelling out to systemctl on every run, matching per managed unit per host per run. Then deploys ending in systemctl restart <app>, cloud-init on first boot, and administrators reloading after a hand edit. level: low is the honest calibration.

05 · Detection maturity

tier_1: , and it stays there until it has been run against real data. Every claim above is reasoning about argv positions, not measurement.
tier_2: run read-only, count matches per host per day, and confirm the noise sources are the ones listed.
tier_3: ** correlate a unit-file write with the later systemctl call — MITRE's CorrelationWindow knob — which is the only shape that makes this signal mean something.

Tuning & false positivesexperimental · 5 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Add the discriminator the rule dropped, as a companion at level: high:
Close the option gap: a second block with the same six values on a2, and
Exclude your config-management and package tooling by auid/ppid from the

Declared by the author

Package installation and upgrade. Debian postinst and RPM scriptlets call systemctl daemon-reload and systemctl start/enable for every unit the package ships, so each apt, dnf or zypper transaction that touches a service produces several matches. On a patched estate this is the highest-volume benign source by a wide margin and is why this rule is low rather than medium.
Configuration management convergence. The Ansible systemd and service modules, Puppet service resources, Chef and Salt all assert unit state by shelling out to systemctl on every run, producing a match per managed unit per host per run whether or not anything changed.
Routine administration and deployment. Restarting a web server, database or agent after a configuration change is the ordinary way to apply it, and application deploy pipelines end with systemctl restart <app> on every release.
Host build and first boot: cloud-init, Kickstart and Packer scripts enabling and starting the units a role needs, which produces a burst of matches on every newly created machine.
Administrators reloading systemd after hand-editing a unit file, where systemctl daemon-reload is the documented and required next step.

Noise check0 of 5 fired

Fires on none of the 5 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 5 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1569.003, evaluated against their — events.

Share this rule

/u/siemphony/3fd7546e-d2d5-47cb-98fa-1088db6e9d9d

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Systemctl invoked with a state-changing service subcommand

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it