| 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.
| 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 |
| 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.[8][9] |
| S0410 | Fysbis |
Fysbis has established persistence using a systemd service.[10] |
| S0601 | Hildegard | |
| S0192 | Pupy |
Pupy can be used to establish persistence using a systemd service.[12] |
| 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 |
| S0663 | SysUpdate |
SysUpdate can copy a script to the user owned |
| G0139 | TeamTNT |
TeamTNT has established persistence through the creation of a cryptocurrency mining system service using |
| 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 |
| ID | Data Source | Data Component | Detects |
|---|---|---|---|
| DS0017 | Command | Command Execution |
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: |
| DS0022 | File | File Creation |
Systemd service unit files may be detected by auditing file creation and modification events within the |
| File Modification |
Systemd service unit files may be detected by auditing file creation and modification events within the |
||
| DS0009 | Process | Process Creation |
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. |
| DS0019 | Service | Service Creation |
Monitor for new constructed systemd services to repeatedly execute malicious payloads as part of persistence. |
| Service Modification |
Analyze the contents of |