Create or Modify System Process: Systemd Service

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.[1] 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).[2]

Inside the .service unit files, the following directives are used to execute commands:[3]

  • 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.[4][5][6]

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).[7][8]

ID: T1543.002
Sub-technique of:  T1543
Platforms: Linux
Contributors: Emad Al-Mousa, Saudi Aramco; Ruben Groenewoud (@RFGroenewoud); Tim (Wadhwa-)Brown; Tony Lambert, Red Canary
Version: 1.6
Created: 17 January 2020
Last Modified: 24 October 2025

Procedure Examples

ID Name Description
C0034 2022 Ukraine Electric Power Attack

During the 2022 Ukraine Electric Power Attack, Sandworm Team configured Systemd to maintain persistence of GOGETTER, specifying the WantedBy=multi-user.target configuration to run GOGETTER when the system begins accepting user logins.[9]

S0401 Exaramel for Linux

Exaramel for Linux has a hardcoded location under systemd that it uses to achieve persistence if it is running as root.[10][11]

S0410 Fysbis

Fysbis has established persistence using a systemd service.[12]

S1198 Gomir

Gomir creates a systemd service named syslogd for persistence.[13]

S0601 Hildegard

Hildegard has started a monero service.[14]

S0192 Pupy

Pupy can be used to establish persistence using a systemd service.[15]

S1222 RIFLESPINE

RIFLESPINE can create a systemd service file for execution.[16]

G0106 Rocke

Rocke has installed a systemd service script to maintain persistence.[4]

S1078 RotaJakiro

Depending on the Linux distribution and when executing with root permissions, RotaJakiro may install persistence using a .service file under the /lib/systemd/system/ folder.[17]

G1015 Scattered Spider

Scattered Spider has run SYSTEMD_UNIT_PATH="/lib/systemd/system/teleport.service to establish persistence for the Teleport remote access tool.[18]

S0663 SysUpdate

SysUpdate can copy a script to the user owned /usr/lib/systemd/system/ directory with a symlink mapped to a root owned directory, /etc/ystem/system, in the unit configuration file's ExecStart directive to establish persistence and elevate privileges.[19]

G0139 TeamTNT

TeamTNT has established persistence through the creation of a cryptocurrency mining system service using systemctl.[20][21]

Mitigations

ID Mitigation Description
M1033 Limit Software Installation

Restrict software installation to trusted repositories only and be cautious of orphaned software packages.

M1026 Privileged Account Management

The creation and modification of systemd service unit files is generally reserved for administrators such as the Linux root user and other users with superuser privileges.

M1022 Restrict File and Directory Permissions

Restrict read/write access to systemd unit files to only select privileged users who have a legitimate need to manage system services.

M1018 User Account Management

Limit user access to system utilities such as systemctl to only users who have a legitimate need.

Detection Strategy

ID Name Analytic ID Analytic Description
DET0253 Detection of Systemd Service Creation or Modification on Linux AN0701

Detects the creation or modification of .service unit files in system/user-level directories, combined with execution of systemctl, service, or dynamically created drop-ins via systemd generators. Detects persistence by analyzing the ExecStart path, file entropy, and symlink usage, especially when paired with execution from /tmp, /dev/shm, or unmounted volumes.

References