1. Home
  2. Techniques
  3. Enterprise
  4. Create or Modify System Process
  5. Systemd Service

Create or Modify System Process: Systemd Service

ID Name
T1543.001 Launch Agent
T1543.002 Systemd Service
T1543.003 Windows Service
T1543.004 Launch Daemon
T1543.005 Container 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: 12 May 2026
Version Permalink

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]
S9043 Mini Shai-Hulud

Mini Shai-Hulud has created .service files using Systemd on victim Linux hosts to establish persistence.[15][16][17]
S0192 Pupy

Pupy can be used to establish persistence using a systemd service.[18]
S1222 RIFLESPINE

RIFLESPINE can create a systemd service file for execution.[19]
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.[20]
G1015 Scattered Spider

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

Shai-Hulud has stopped systemd-resolved in order to manipulate DNS and firewalls.[22]
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.[23]
G1056 TeamPCP

TeamPCP has used the systemd user service for malware persistence in targeted environments.[24]
S9041 TeamPCP Cloud Stealer

TeamPCP Cloud Stealer can create a systemd unit to execute a python script for persistence.[25][26][24]
G0139 TeamTNT

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

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

  1. Linux man-pages. (2014, January). systemd(1) - Linux manual page. Retrieved April 23, 2019.
  2. Tony Lambert. (2022, November 13). ATT&CK T1501: Understanding systemd service persistence. Retrieved March 20, 2023.
  3. Free Desktop. (n.d.). systemd.service — Service unit configuration. Retrieved March 20, 2023.
  4. Anomali Labs. (2019, March 15). Rocke Evolves Its Arsenal With a New Malware Family Written in Golang. Retrieved April 24, 2019.
  5. airwalk. (2023, January 1). A guide to backdooring Unix systems. Retrieved May 31, 2023.
  6. Rapid7. (2016, June 22). Service Persistence. Retrieved April 23, 2019.
  7. Ruben Groenewoud. (2024, August 20). Linux Detection Engineering - A primer on persistence mechanisms. Retrieved March 18, 2025.
  8. Pepe Berba. (2022, February 7). Hunting for Persistence in Linux (Part 5): Systemd Generators. Retrieved April 8, 2025.
  9. Ken Proska, John Wolfram, Jared Wilson, Dan Black, Keith Lunden, Daniel Kapellmann Zafra, Nathan Brubaker, Tyler Mclellan, Chris Sistrunk. (2023, November 9). Sandworm Disrupts Power in Ukraine Using a Novel Attack Against Operational Technology. Retrieved March 28, 2024.
  10. Cherepanov, A., Lipovsky, R. (2018, October 11). New TeleBots backdoor: First evidence linking Industroyer to NotPetya. Retrieved November 27, 2018.
  11. ANSSI. (2021, January 27). SANDWORM INTRUSION SET CAMPAIGN TARGETING CENTREON SYSTEMS. Retrieved March 30, 2021.
  12. Doctor Web. (2014, November 21). Linux.BackDoor.Fysbis.1. Retrieved December 7, 2017.
  13. Symantec Threat Hunter Team. (2024, May 16). Springtail: New Linux Backdoor Added to Toolkit. Retrieved January 17, 2025.
  14. Chen, J. et al. (2021, February 3). Hildegard: New TeamTNT Cryptojacking Malware Targeting Kubernetes. Retrieved April 5, 2021.
  1. McCarthy, R., Cohen, A., and Read, B. (2026, May 12). Mini Shai-Hulud Strikes Again: TanStack + more npm Packages Compromised. Retrieved July 16, 2026.
  2. Hunt.io. (2026, May 14). How TeamPCP's Python Toolkit Survives a C2 Takedown: FIRESCALE, GitHub, and the Victim's Own Account. Retrieved July 16, 2026.
  3. Flashpoint. (2026, May 28). The Mini Shai-Hulud Worm and the New Era of CI/CD Exploitation. Retrieved July 16, 2026.
  4. Nicolas Verdier. (n.d.). Retrieved January 29, 2018.
  5. Punsaen Boonyakarn, Shawn Chew, Logeswaran Nadarajan, Mathew Potaczek, Jakub Jozwiak, and Alex Marvi. (2024, June 18). Cloaked and Covert: Uncovering UNC3886 Espionage Operations. Retrieved September 24, 2024.
  6. Alex Turing, Hui Wang. (2021, April 28). RotaJakiro: A long live secret backdoor with 0 VT detection. Retrieved June 14, 2023.
  7. Mandiant Incident Response. (2025, July 23). From Help Desk to Hypervisor: Defending Your VMware vSphere Estate from UNC3944. Retrieved October 13, 2025.
  8. Socket Research Team. (2025, November 24). Shai Hulud Strikes Again (v2). Retrieved April 9, 2026.
  9. Daniel Lunghi. (2023, March 1). Iron Tiger’s SysUpdate Reappears, Adds Linux Targeting. Retrieved March 20, 2023.
  10. McCarthy, R., Haughom, J., Read, B. (2026, March 23). KICS GitHub Action Compromised: TeamPCP Strikes Again in Supply Chain Attack. Retrieved July 1, 2026.
  11. McCarthy, R. (2026, March 20). Trivy Compromised: Everything You Need to Know about the Latest Supply Chain Attack. Retrieved July 1, 2026.
  12. Aqua Team. (2026, April 1). Update: Ongoing Investigation and Continued Remediation. Retrieved July 1, 2026.
  13. Fiser, D. Oliveira, A. (n.d.). Tracking the Activities of TeamTNT A Closer Look at a Cloud-Focused Malicious Actor Group. Retrieved September 22, 2021.
  14. Darin Smith. (2022, April 21). TeamTNT targeting AWS, Alibaba. Retrieved August 4, 2022.