T1543.002 Elastic Security · Elastic

Detect Systemd Service in Elastic Security

Adversaries may create or modify systemd services to repeatedly execute malicious payloads as part of persistence. Systemd is the default initialization system on many Linux distributions. Adversaries create new .service unit files or modify existing ones, placing them in /etc/systemd/system/, /lib/systemd/system/, or user-level ~/.config/systemd/user/ directories. The ExecStart, ExecStartPre, ExecReload, and ExecStop directives within service files execute commands when services start, reload, or stop. Threat actors including TeamTNT, Rocke, and Scattered Spider have leveraged systemd services for persistence and privilege escalation.

MITRE ATT&CK

Tactic
Persistence Privilege Escalation
Technique
T1543 Create or Modify System Process
Sub-technique
T1543.002 Systemd Service
Canonical reference
https://attack.mitre.org/techniques/T1543/002/

Elastic Detection Query

Elastic Security (Elastic)
eql
any where
  (event.category == "file" and event.type in ("creation","change") and
   file.path : ("/etc/systemd/system/*","/lib/systemd/system/*","/usr/lib/systemd/system/*",
                "/run/systemd/system/*","*/.config/systemd/user/*") and
   file.extension == "service" and
   not process.name : ("dpkg","rpm","apt","yum","systemd","systemctl","ansible*","puppet*","chef*")) or
  (event.category == "process" and event.type == "start" and
   process.name == "systemctl" and
   process.args : ("enable","start","daemon-reload") and
   process.parent.name : ("bash","sh","dash","zsh","python*","perl","ruby","curl","wget"))
high severity high confidence

Detects suspicious systemd service file creation and systemctl enable commands from unexpected parent processes on Linux.

Data Sources

Linux Endpoint File EventsLinux Process Events

Required Tables

logs-endpoint.events.file-*logs-endpoint.events.process-*

False Positives & Tuning

  • Package managers (apt, yum, dnf, rpm) installing legitimate software that includes systemd service units
  • System administrators manually creating or modifying service files for legitimate infrastructure automation
  • Configuration management tools (Ansible, Chef, Puppet, SaltStack) deploying service configurations
  • Docker or container runtime installations that register systemd services
  • Development environments where developers create test services locally
Download portable Sigma rule (.yml)

Other platforms for T1543.002


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Create Malicious Systemd Service for Persistence

    Expected signal: Auditd SYSCALL=openat with path=/etc/systemd/system/df00tech-test.service and flags indicating file creation. Subsequent systemctl daemon-reload, enable, and start executions visible in auditd EXECVE records. MDE DeviceFileEvents shows FileCreated action for the .service file. DeviceProcessEvents shows systemctl invocations by root.

  2. Test 2User-Level Systemd Service Persistence (Non-Root)

    Expected signal: File creation event for ~/.config/systemd/user/df00tech-user-test.service. Auditd records systemctl --user daemon-reload, enable, start. MDE DeviceFileEvents shows FileCreated with the user's home directory path. The initiating process AccountName matches the non-root test user.

  3. Test 3Systemd Service Mimicking Legitimate Service Name

    Expected signal: Auditd and MDE file creation event for /etc/systemd/system/syslogd.service. The IsSuspiciousName flag in the KQL detection should evaluate to true based on the 'syslogd' service name match. DeviceProcessEvents shows systemctl enable syslogd.service.

  4. Test 4Systemd Generator for Dynamic Service Creation

    Expected signal: File creation event for the generator script in /usr/local/lib/systemd/system-generators/. Subsequent daemon-reload execution triggers the generator, creating a .service file in /run/systemd/generator/. Auditd records the EXECVE of the generator script during daemon-reload. The generated service file appears in a systemd-controlled temporary directory.

Unlock Pro Content

Get the full detection package for T1543.002 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections