Loading AttackTrace...
Loading AttackTrace...
Systemd Service (T1543.002) is a MITRE ATT&CK technique associated with Persistence, Privilege Escalation . Adversaries may create or modify systemd services to repeatedly execute malicious payloads as part of persistence.
Systemd Service (T1543.002) is a MITRE ATT&CK technique associated with Persistence, Privilege Escalation. Adversaries may create or modify systemd services to repeatedly execute malicious payloads as part of persistence.
Attackers use Systemd Service because it provides a reliable way to advance their objective within the Persistence, Privilege Escalation tactic, often with a favorable balance of impact versus detectability on Linux environments. Defenders should assess this behavior in the context of the affected platform and adjacent activity rather than treating it as a standalone indicator.
Adversaries may create or modify systemd services to repeatedly execute malicious payloads as part of persistence. Systemd is a system and service manager commonly used for managing background daemon processes (also known as services) and other system resources.(Citation: Linux man-pages: systemd January 2014) Systemd is the default initialization (init) system on many Linux distributions replacing legacy init systems, including SysVinit and Upstart, while remaining backwards compatible.
Systemd utilizes unit configuration files with the .service file extension to encode information about a service's process. By default, system level unit files are stored in the /systemd/system directory of the root owned directories (/). User level unit files are stored in the /systemd/user directories of the user owned directories ($HOME).(Citation: lambert systemd 2022)
Inside the .service unit files, the following directives are used to execute commands:(Citation: freedesktop systemd.service)
ExecStart, ExecStartPre, and ExecStartPost directives execute when a service is started manually by systemctl or on system start if the service is set to automatically start.ExecReload directive executes when a service restarts.ExecStop, ExecStopPre, and ExecStopPost directives execute when a service is stopped.Adversaries have created new service files, altered the commands a .service file’s directive executes, and modified the user directive a .service file executes as, which could result in privilege escalation. Adversaries may also place symbolic links in these directories, enabling systemd to find these payloads regardless of where they reside on the filesystem.(Citation: Anomali Rocke March 2019)(Citation: airwalk backdoor unix systems)(Citation: Rapid7 Service Persistence 22JUNE2016)
The .service file’s User directive can be used to run service as a specific user, which could result in privilege escalation based on specific user/group permissions.
Systemd services can be created via systemd generators, which support the dynamic generation of unit files. Systemd generators are small executables that run during boot or configuration reloads to dynamically create or modify systemd unit files by converting non-native configurations into services, symlinks, or drop-ins (i.e., Boot or Logon Initialization Scripts).(Citation: Elastic Security Labs Linux Persistence 2024)(Citation: Pepe Berba Systemd 2022)
No universal command represents Systemd Service. Capture the exact command line, arguments, parent process, account, host, and execution time from the investigated environment; do not operationalize unverified examples.
| Event ID | Log Channel | What It Indicates |
|---|---|---|
| Not universally applicable | Validate platform coverage | This technique may not produce a Windows event; use telemetry native to the affected platform. |
| Sysmon Event ID | Name | Why It's Relevant Here |
|---|---|---|
| Environment-specific | Validate configured telemetry | Use process, network, file, registry, DNS, or image-load telemetry only when relevant and enabled. |
No MITRE detection guidance published for this technique.
Relevant ATT&CK Data Sources: N/A
A universal Sigma rule would create unreliable results because this technique has no single guaranteed observable. Build detection logic from a documented behavior and supported data source, scope it to the affected platform, and validate it against benign administrative activity before deployment.
Start with the data sources named in the detection section. Scope searches by asset, identity, and time window; correlate the primary behavior with preceding access and subsequent actions. A portable query is intentionally not provided where the technique lacks a universal schema or observable.