Create or Modify System Process: Systemd Service

Adversaries may create or modify systemd services to repeatedly execute malicious payloads as part of persistence. The systemd service manager is commonly used for managing background daemon processes (also known as services) and other system resources.[1][2] Systemd is the default initialization (init) system on many Linux distributions starting with Debian 8, Ubuntu 15.04, CentOS 7, RHEL 7, Fedora 15, and replaces legacy init systems including SysVinit and Upstart while remaining backwards compatible with the aforementioned init systems.

Systemd utilizes configuration files known as service units to control how services boot and under what conditions. By default, these unit files are stored in the /etc/systemd/system and /usr/lib/systemd/system directories and have the file extension .service. Each service unit file may contain numerous directives that can execute system commands:

  • ExecStart, ExecStartPre, and ExecStartPost directives cover execution of commands when a services is started manually by 'systemctl' or on system start if the service is set to automatically start.
  • ExecReload directive covers when a service restarts.
  • ExecStop and ExecStopPost directives cover when a service is stopped or manually by 'systemctl'.

Adversaries have used systemd functionality to establish persistent access to victim systems by creating and/or modifying service unit files that cause systemd to execute malicious commands at system boot.[3]

While adversaries typically require root privileges to create/modify service unit files in the /etc/systemd/system and /usr/lib/systemd/system directories, low privilege users can create/modify service unit files in directories such as ~/.config/systemd/user/ to achieve user-level persistence.[4]

ID: T1543.002
Sub-technique of:  T1543
Platforms: Linux
Permissions Required: User, root
CAPEC ID: CAPEC-550, CAPEC-551
Contributors: Tony Lambert, Red Canary
Version: 1.2
Created: 17 January 2020
Last Modified: 09 October 2020
Provided by LAYER 8

Procedure Examples

ID Name Description
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.[5][6]

S0410 Fysbis

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

S0601 Hildegard

Hildegard has started a monero service.[8]

S0192 Pupy

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

G0106 Rocke

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

G0139 TeamTNT

TeamTNT has established persistence through the creation of a cryptocurrency mining system service.[10]

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

ID Data Source Data Component
DS0017 Command Command Execution
DS0022 File File Creation
File Modification
DS0009 Process Process Creation
DS0019 Service Service Creation
Service Modification

Systemd service unit files may be detected by auditing file creation and modification events within the /etc/systemd/system, /usr/lib/systemd/system/, and /home//.config/systemd/user/ directories, as well as associated symbolic links. Suspicious processes or scripts spawned in this manner will have a parent process of ‘systemd’, a parent process ID of 1, and will usually execute as the ‘root’ user.

Suspicious systemd services can also be identified by comparing results against a trusted system baseline. Malicious systemd services may be detected by using the systemctl utility to examine system wide services: systemctl list-units -–type=service –all. Analyze the contents of .service files present on the file system and ensure that they refer to legitimate, expected executables.

Auditing the execution and command-line arguments of the 'systemctl' utility, as well related utilities such as /usr/sbin/service may reveal malicious systemd service execution.

References