T1543.002 - Creating and Modifying System Processes: Systemd

Tactic: Persistence, Priv Esc

Platform: Linux

Privileges required: user, root


For any adversary seeking to compromise a system, persistence and privilege escalation are key techniques that can help to buy more time, grant future options and assist in the execution of malicious payloads.

In the case of T1543.002, systemd is the software suite that is abused in order to help an attacker achieve his/her goals.

A system and service manager for Linux, it fulfills the same combined duties of wininit.exe and services.exe from a Windows system.

From the diagram over the page we can see that systemd is just one of a number of system daemons running above the kernel alongside logind, D-Bus-daemon and more.

These daemons run as background processes, often as child processes of the ‘init’ or initialization process (PID1) which is the first process that initializes during the OS boot.

Since 2010, more recent Linux distributions have incorporated newer init versions including launchd, systemd and OpenRC.

For more details about the early origins of the suite, you can refer to this April 2010 blog post named ‘Rethinking PID1’: Rethinking PID1.


Inside systemd, there are a number of of smaller programs, services and libraries to be aware of including:

Within systemd, there are also units.

These are any entities managed by systemd which can manage services, sockets, devices, mountpoints, swap files, partitions and more.

Ultimately, a unit is an object that can carry out a number of different tasks.

In Linux, we can type ‘systemctl -t help’ to list the 11 available unit types as seen below:

$systemctl -t help
Unit Types

These units encapsulate objects that are needed for system boot and maintenance.

Of course with this uniformity comes the possibility for an adversary to take advantage as we will see soon.

Within the file system, there are numerous locations where systemd unit files can be found.

In order of precedence these are:

  1. /etc/systemd/service
  2. /run/systemd/system
  3. /usr/lib/systemd/system

In all three of these locations, unit files (.service) can be placed for future payload execution either upon startup or at a repeatable interval.

We will now walk through an example procedure that you can follow to create your own custom unit file for persistence:

  1. Prepare an executable to use as part of a custom service (this can be a custom-script or an executable piece of software)

In our example we are using a python script (.py)

Note: ensure that the script is made executable using chmod+x

  1. Create a unit file in /etc/systemd/service and grant necessary permissions

$touch /etc/systemd/system/example.service

$chmod 664 /etc/systemd/system/example.service

Note: commands will need to be executed as root

  1. Open the example.service file in a text editor of your choice for configuration

Example text editors include nano or vim.

In our example below, the malicious script ‘’ has been placed in the ‘ExecStart’ header section for execution when the service starts.

Example Service File

There are many different [Unit], [Service] and [Install] options that can be included in a unit file. To learn more visit this guide from Redhat.

  1. Reload and start the service file

$systemctl daemon-reload
$systemctl enable example.service

Now when the service file is enabled by systemctl, the python script will run and the ‘Restart=always’ addition will ensure that the script has persistence.

For more information on systemd visit:

Case study: Exaramel

One example of a malware that has leveraged systemd for persistence in systems is the backdoor Exaramel.

A form of trojan, backdoor malware can show up in a number of different forms and seeks to bypass normal authentication procedures.

Exaramel is one such example of a backdoor that has versions for Windows and Linux and is written in the programming language Go.

Additional techniques that Exaramel can carry out include but aren’t limited to:

In the case of Exaramel, if root privileges aren’t possible to obtain, then crontab is utilized for persistence instead of systemd.

The APT group Sandworm, known to have been behind the December 2015 Ukraine power grid cyberattack and the 2017 NotPetya outbreak, are also said to have used Exaramel.

For further reading on Exaramel visit:

We use cookies to improve your experience. By using our site, you agree to our Privacy Policy.