Container started with a persistent restart policy

Siemphony@siemphonylowT1543.005unverified

Matches an auditd execve of the docker, podman or nerdctl client whose arguments set a container restart policy of always or unless-stopped, which is the mechanism this technique uses to make a container — and whatever it runs inside — come back on its own after every host reboot. The client list is authored for this rule: MITRE's technique text names docker and podman, and nerdctl is added here as the containerd client that accepts the same flag. The policy strings are MITRE's restartPolicy knob, populated here with both spellings the CLI accepts, equals-separated and space-separated, so a space-separated invocation is not silently missed. A `docker update --restart=always` against an already-running container matches the same selection, which is intended — it is the same persistence with one step fewer. Three limits are structural. The flag has to be on the command line: a `restart:` key in a compose file, a Podman Quadlet `.container` unit or a `podman generate systemd` wrapper sets exactly the same policy with no flag for this rule to see, and `docker compose up` does not match the client selection either, so declarative deployments are a blind spot. The Kubernetes half of AN1304 — DaemonSets, and pods pinned to a host with nodeSelector or nodeName — is invisible from here, because those settings live in a manifest that `kubectl apply -f` never places on the command line; catching them needs the Kubernetes audit log, which this brief does not offer. And the analytic's correlation of a container launch with a later privilege escalation inside MITRE's TimeWindow knob is a cross-event join lib/sigma cannot express, so this rule sees only the persistence half. The brief's second log source, systemd unit files, is not attempted: it carries no standardised Sigma field names, and inventing them would produce a rule that renders in four backends and matches nothing. Prerequisite: auditd does not record execve in a default install, so this rule returns zero rows until a rule such as `-a always,exit -F arch=b64 -S execve` is loaded, and zero rows reads as quiet when it actually means blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0473, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 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

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where ((FolderPath endswith "/docker" or FolderPath endswith "/podman" or FolderPath endswith "/nerdctl") and (ProcessCommandLine contains "--restart=always" or ProcessCommandLine contains "--restart always" or ProcessCommandLine contains "--restart=unless-stopped" or ProcessCommandLine contains "--restart unless-stopped"))

Splunk · SPL

Run this as a search.

index=* ((Image="*/docker" OR Image="*/podman" OR Image="*/nerdctl") AND (CommandLine="*--restart=always*" OR CommandLine="*--restart always*" OR CommandLine="*--restart=unless-stopped*" OR CommandLine="*--restart unless-stopped*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.executable) LIKE "*/docker" OR TO_LOWER(process.executable) LIKE "*/podman" OR TO_LOWER(process.executable) LIKE "*/nerdctl") AND (TO_LOWER(process.command_line) LIKE "*--restart=always*" OR TO_LOWER(process.command_line) LIKE "*--restart always*" OR TO_LOWER(process.command_line) LIKE "*--restart=unless-stopped*" OR TO_LOWER(process.command_line) LIKE "*--restart unless-stopped*"))

Wazuh · XML rule

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

<group name="sigma,linux,process_creation,">  <!-- 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="Image" type="pcre2">(?i)(/docker$|/podman$|/nerdctl$)</field>    <field name="CommandLine" type="pcre2">(?i)(--restart=always|--restart always|--restart=unless-stopped|--restart unless-stopped)</field>    <description>Container started with a persistent restart policy</description>    <mitre>      <id>T1543.005</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / linux
Level: low
Category: service_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 980679e3-9a2f-4164-8339-42879b80211a

ATT&CKT1543.005

T1543.005Container Service

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.

Lessonservice persistence

service persistenceAI draft — unreviewed

01 · What this rule detects

The rule catches a container being launched with a restart policy that survives a reboot — --restart=always or --restart=unless-stopped on a docker, podman or nerdctl command line. That flag is the persistence: whatever runs inside the container comes back on its own after the host restarts, without any entry in cron, systemd or a shell profile. It also matches docker update --restart=always against an already-running container, which is the same persistence one step shorter.

02 · Telemetry you need

Linux process creation, taken from auditd — the process_creation / linux logsource copied from the brief. The rule depends entirely on two fields, Image and CommandLine, and neither is free. auditd does not record execve in a default install, so nothing arrives until a rule such as -a always,exit -F arch=b64 -S execve is loaded. Raw auditd EXECVE records also carry arguments as a0, a1, a2… with no CommandLine field at all, so you need a pipeline that joins them — Auditbeat's process.command_line, or a Splunk auditd sourcetype that reconstructs one. Zero rows here means blind, not quiet.

03 · How the logic works

Two selections, ANDed. selection_client gates on Image|endswith against /docker, /podman and /nerdctl. MITRE's technique text names docker and podman; nerdctl is this rule's own addition, the containerd client that accepts the same flag. selection_policy gates on CommandLine|contains with four strings: --restart=always, --restart always, --restart=unless-stopped and --restart unless-stopped. The two policy values are MITRE's restartPolicy knob; the two spellings per value are the pipeline's own, so a space-separated invocation is not silently missed. Requiring both selections means a bare docker run never matches, and a restart flag typed at some other binary never matches either.

04 · Common false positives

Constantly, which is why the level is low. Long-lived service containers — reverse proxies, databases, brokers, monitoring and log-shipping agents — are started with exactly this flag because the runtime documentation recommends it for anything expected to survive a reboot. Configuration management makes it worse: an Ansible shell task, a cloud-init runcmd block or a Terraform remote-exec re-issues the identical line on every converge, so a fleet-wide run produces one match per host whether or not anything changed. Developer workstations and CI runners bring local stacks up by hand many times a day. The benign population and the malicious one have the same event shape.

05 · Detection maturity

tier_1: Lowest tier. This rule was derived from MITRE ATT&CK DET0473 and has never been executed against a single log line — no confirmed true positive, no measured false-positive rate, no proof the field mapping holds in your pipeline. Treat it as a scaffold: load it, look at what returns over a week, and only then decide what the level and the filters ought to be.

Tuning & false positivesexperimental · 4 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

Do not tune this by suppressing the flag. Tune by baselining the image and the invoking user, neither of which the rule filters today. MITRE's analytic AN1304 asks for the restart policy to be correlated with elevated host access or a privileged container context; the rule carries no privilege discriminator, so a rootless podman run looks identical to the rootful docker run that actually grants host escalation. Adding User on this logsource is the obvious first narrowing. Know the blind spots before you trust a quiet result: a restart: key in a compose file, a Podman Quadlet .container unit, or podman generate systemd all set the same policy with nothing on any command line, and docker compose up does not match the client selection either.

Declared by the author

Ordinary production operation, which is the loudest match by a wide margin and the reason the level is low. Long-lived service containers — reverse proxies, databases, message brokers, monitoring and log-shipping agents — are routinely started with an always or unless-stopped policy because the runtime documentation recommends exactly that for anything expected to survive a reboot.
Provisioning and configuration management re-issuing the same command on every converge. Ansible shell tasks, cloud-init runcmd blocks, Terraform remote-exec provisioners and hand-rolled deployment scripts run the identical docker run line each time they execute, so a fleet-wide converge produces one match per host regardless of whether anything actually changed.
An operator repairing a container that failed to come back after maintenance by running docker update with a restart policy against the existing container, which is a documented remediation and matches the same selection as the initial creation.
Developer workstations and CI runners bringing up local stacks by hand, where the same command with a restart flag may be typed or scripted many times a day and where auditd, if enabled at all, is usually enabled fleet-wide.

Noise check0 of 4 fired

Fires on none of the 4 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 4 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 T1543.005, evaluated against their process_creation events.

Share this rule

/u/siemphony/980679e3-9a2f-4164-8339-42879b80211a

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.

Container started with a persistent restart policy

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it