tfMITRE ATT&CK sub-technique

Systemctl T1569.003

Tactic: Execution
Platform: Linux
Version: 1.0
Created: 18 March 2025
Last modified: 15 April 2025

Adversaries may abuse systemctl to execute commands or programs. Systemctl is the primary interface for systemd, the Linux init system and service manager. Typically invoked from a shell, Systemctl can also be integrated into scripts or applications.

ReconResource DevInitial AccessExecutionPersistencePriv EscStealthDef ImpairmentCred AccessDiscoveryLateral MoveCollectionC2ExfiltrationImpact

Threat groups45th pct

Threat groups45th percentile · 55% of ATT&CK techniques have more threat groups attributed.

CampaignsNone recorded

CampaignsNone recorded · 54% of ATT&CK techniques have none either.

Tools & malware44th pct

Tools & malware44th percentile · 56% of ATT&CK techniques have more tools implementing them.

Detection rulesNone recorded

Detection rulesNone recorded · 33% of ATT&CK techniques have none either.

Systemctl MITRE reference T1569.003

45th pctamong all ATT&CK techniques for number of groups

1 group has been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.

TeamTNTG0139 ↗

Has created system services to execute cryptocurrency mining software.1

created 2021-10-011 reference

All 1 groups for this technique

1 software entry is documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.

CanisterWormS9042 ↗

Has used executed systemctl --user daemon-reload to reload systemd, then enables and starts the malicious service.1

created 2026-07-24MALWAREcarried by 1 group

All 1 software entries for this technique

Offense vs defense T1569.003

Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.

Systemctl detection strategy DET0073

MITRE names one behaviour worth catching for this technique and breaks it into 1 analytic, one per platform. Each carries the log sources it needs and the fields you tune per environment.

Detection Strategy for System Services: Systemctl

Enterprise

1 platform

AN0200 · Linux

Abuse of systemctl to execute commands or manage systemd services. Defender perspective: correlate suspicious service creation or modification with execution of systemctl subcommands such as start, enable, or status. Detect cases where systemctl is used to load services from unusual locations (e.g., /tmp, /dev/shm) or where new service units are created outside of expected administrative workflows.

Log sources

The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.

Data component	Name	Channel
Process CreationDC0032	auditd:EXECVE	systemctl spawning managed processes
Service CreationDC0060	auditd:CONFIG_CHANGE	creation or modification of systemd services
File ModificationDC0061	auditd:SYSCALL	open/write of .service unit files
Command ExecutionDC0064	auditd:EXECVE	execution of systemctl with subcommands start, stop, enable, disable

Tunable fields

MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.

Field	What you tune
MonitoredPaths	Paths to monitor for service unit files, typically /etc/systemd/system and /usr/lib/systemd/system. Adversaries may use uncommon locations such as /tmp.
SuspiciousSubcommands	Focus on systemctl subcommands start, enable, or daemon-reload when used outside expected change windows.
CorrelationWindow	Time window to correlate service file modification with subsequent systemctl execution.

User Account ManagementM1018

Limit user access to systemctl to only users who have a legitimate need.

Tests8Executorssh 8Need elevation7 of 8Have prerequisites8Have cleanup8Platformslinux

Test

Platform

Executor

Elevation

Prereqs

Cleanup

Ref

Create and Enable a Malicious systemd Service Unit

linux

Required

Yes

Creates a new systemd service unit file in /etc/systemd/system/ and enables it using systemctl enable followed by systemctl start. Adversaries commonly abuse this workflow to establish persistence or execute arbitrary commands under the context of systemd. This simulates the full attacker workflow: writing the unit file, reloading the systemd daemon, enabling the service to survive reboots, and starting it immediately. This is consistent with techniques observed in ransomware precursor activity and post-exploitation frameworks targeting Linux infrastructure.

Input arguments

Name	Type	Default	Description
service_name	string	atomic-test	Name of the malicious service to create
command_to_run	string	/bin/bash -c "echo atomictest > /tmp/atomic_service_output.txt"	Command the service will execute

Attack command

echo "[Unit]" > /etc/systemd/system/#{service_name}.service
echo "Description=Atomic Test Service" >> /etc/systemd/system/#{service_name}.service
echo "After=network.target" >> /etc/systemd/system/#{service_name}.service
echo "" >> /etc/systemd/system/#{service_name}.service
echo "[Service]" >> /etc/systemd/system/#{service_name}.service
echo "ExecStart=#{command_to_run}" >> /etc/systemd/system/#{service_name}.service
echo "Restart=on-failure" >> /etc/systemd/system/#{service_name}.service
echo "" >> /etc/systemd/system/#{service_name}.service
echo "[Install]" >> /etc/systemd/system/#{service_name}.service
echo "WantedBy=multi-user.target" >> /etc/systemd/system/#{service_name}.service
systemctl daemon-reload
systemctl enable #{service_name}.service
systemctl start #{service_name}.service
systemctl status #{service_name}.service

Cleanup command

systemctl stop #{service_name}.service 2>/dev/null || true
systemctl disable #{service_name}.service 2>/dev/null || true
rm -f /etc/systemd/system/#{service_name}.service
systemctl daemon-reload
rm -f /tmp/atomic_service_output.txt

Prerequisite

systemctl must be available on the system

Check

if [ -x "$(command -v systemctl)" ]; then exit 0; else exit 1; fi

Satisfy

echo "systemctl is not available. Ensure systemd is running on this system."

Prerequisite

The test must be run as root or with sudo privileges

Check

if [ "$(id -u)" -eq 0 ]; then exit 0; else exit 1; fi

Satisfy

echo "This test requires root privileges. Run as root or use sudo."

Prerequisite

/etc/systemd/system/ directory must exist and be writable

Check

if [ -d "/etc/systemd/system" ] && [ -w "/etc/systemd/system" ]; then exit 0; else exit 1; fi

Satisfy

echo "/etc/systemd/system/ does not exist or is not writable. Ensure systemd is installed."

GUID1b4afa9f-e4aa-4495-8a75-f2773e774d4a

Create systemd Service Unit from /tmp (Unusual Location)

linux

Required

Yes

Creates a systemd service unit file in /tmp and loads it using systemctl start with an absolute path. Adversaries may write service unit files to world-writable directories such as /tmp to avoid triggering alerts on new file creation in standard service directories, or to execute payloads transiently without permanently installing a service. Loading a service unit from an arbitrary path rather than a standard systemd directory is unusual behaviour that should be detectable by monitoring systemctl command arguments.

Input arguments

Name	Type	Default	Description
service_path	path	/tmp/atomic_tmp.service	Full path to the service file to be written in /tmp
command_to_run	string	/bin/bash -c "id > /tmp/atomic_tmp_output.txt"	Command the service will execute

Attack command

echo "[Unit]" > #{service_path}
echo "Description=Atomic Tmp Service" >> #{service_path}
echo "" >> #{service_path}
echo "[Service]" >> #{service_path}
echo "ExecStart=#{command_to_run}" >> #{service_path}
echo "" >> #{service_path}
echo "[Install]" >> #{service_path}
echo "WantedBy=multi-user.target" >> #{service_path}
systemctl link #{service_path}
systemctl start $(basename #{service_path})
systemctl status $(basename #{service_path})

Cleanup command

systemctl stop $(basename #{service_path}) 2>/dev/null || true
rm -f #{service_path}
rm -f /tmp/atomic_tmp_output.txt

Prerequisite

systemctl must be available on the system

Check

if [ -x "$(command -v systemctl)" ]; then exit 0; else exit 1; fi

Satisfy

echo "systemctl is not available. Ensure systemd is running on this system."

Prerequisite

/tmp must exist and be writable

Check

if [ -d "/tmp" ] && [ -w "/tmp" ]; then exit 0; else exit 1; fi

Satisfy

echo "/tmp does not exist or is not writable on this system."

Prerequisite

The test must be run as root or with sudo privileges

Check

if [ "$(id -u)" -eq 0 ]; then exit 0; else exit 1; fi

Satisfy

echo "This test requires root privileges. Run as root or use sudo."

GUIDdc521d9a-2316-4be9-9640-95cbcf4ed0f8

Create systemd Service Unit from /dev/shm (Unusual Location)

linux

Required

Yes

Creates a systemd service unit file in /dev/shm and loads it using systemctl. /dev/shm is a memory-backed filesystem that is world-writable on most Linux systems and does not persist across reboots, making it particularly attractive to adversaries seeking to execute transient payloads while evading file-based forensic detection. This technique has been observed in post-exploitation scenarios where attackers deliberately avoid writing to disk-backed locations to limit forensic artefacts.

Input arguments

Name	Type	Default	Description
service_path	path	/dev/shm/atomic_shm.service	Full path to the service file to be written in /dev/shm
command_to_run	string	/bin/bash -c "whoami > /tmp/atomic_shm_output.txt"	Command the service will execute

Attack command

echo "[Unit]" > #{service_path}
echo "Description=Atomic SHM Service" >> #{service_path}
echo "" >> #{service_path}
echo "[Service]" >> #{service_path}
echo "ExecStart=#{command_to_run}" >> #{service_path}
echo "" >> #{service_path}
echo "[Install]" >> #{service_path}
echo "WantedBy=multi-user.target" >> #{service_path}
systemctl link #{service_path}
systemctl start $(basename #{service_path})
systemctl status $(basename #{service_path})

Cleanup command

systemctl stop $(basename #{service_path}) 2>/dev/null || true
rm -f #{service_path}
rm -f /tmp/atomic_shm_output.txt

Prerequisite

systemctl must be available on the system

Check

if [ -x "$(command -v systemctl)" ]; then exit 0; else exit 1; fi

Satisfy

echo "systemctl is not available. Ensure systemd is running on this system."

Prerequisite

/dev/shm must exist and be writable

Check

if [ -d "/dev/shm" ] && [ -w "/dev/shm" ]; then exit 0; else exit 1; fi

Satisfy

echo "/dev/shm does not exist or is not writable on this system."

Prerequisite

The test must be run as root or with sudo privileges

Check

if [ "$(id -u)" -eq 0 ]; then exit 0; else exit 1; fi

Satisfy

echo "This test requires root privileges. Run as root or use sudo."

GUID60b58a36-ba3a-4690-b360-8ae78e646396

Modify Existing systemd Service to Execute Malicious Command

linux

Required

Yes

Creates a service unit file that initially runs a benign command, then modifies the ExecStart directive using sed to substitute a malicious command before reloading and restarting the service. Adversaries may hijack existing services to blend in with normal service activity and avoid triggering detections focused solely on new service creation. This technique reflects the tradecraft observed in more sophisticated intrusions where blending into existing process trees is a priority over creating net-new services.

Input arguments

Name	Type	Default	Description
service_name	string	atomic-modify-test	Name of the service to create and then modify for the test
malicious_command	string	/bin/bash -c "echo hijacked > /tmp/atomic_hijack_output.txt"	Malicious command to substitute into ExecStart

Attack command

echo "[Unit]" > /etc/systemd/system/#{service_name}.service
echo "Description=Legitimate Looking Service" >> /etc/systemd/system/#{service_name}.service
echo "" >> /etc/systemd/system/#{service_name}.service
echo "[Service]" >> /etc/systemd/system/#{service_name}.service
echo "ExecStart=/bin/true" >> /etc/systemd/system/#{service_name}.service
echo "" >> /etc/systemd/system/#{service_name}.service
echo "[Install]" >> /etc/systemd/system/#{service_name}.service
echo "WantedBy=multi-user.target" >> /etc/systemd/system/#{service_name}.service
systemctl daemon-reload
sed -i 's|ExecStart=.*|ExecStart=#{malicious_command}|' /etc/systemd/system/#{service_name}.service
systemctl daemon-reload
systemctl start #{service_name}.service
systemctl status #{service_name}.service

Cleanup command

systemctl stop #{service_name}.service 2>/dev/null || true
systemctl disable #{service_name}.service 2>/dev/null || true
rm -f /etc/systemd/system/#{service_name}.service
systemctl daemon-reload
rm -f /tmp/atomic_hijack_output.txt

Prerequisite

systemctl must be available on the system

Check

if [ -x "$(command -v systemctl)" ]; then exit 0; else exit 1; fi

Satisfy

echo "systemctl is not available. Ensure systemd is running on this system."

Prerequisite

sed must be available on the system

Check

if [ -x "$(command -v sed)" ]; then exit 0; else exit 1; fi

Satisfy

apt-get install -y sed 2>/dev/null || yum install -y sed 2>/dev/null || echo "Could not install sed automatically."

Prerequisite

The test must be run as root or with sudo privileges

Check

if [ "$(id -u)" -eq 0 ]; then exit 0; else exit 1; fi

Satisfy

echo "This test requires root privileges. Run as root or use sudo."

Prerequisite

/etc/systemd/system/ directory must exist and be writable

Check

if [ -d "/etc/systemd/system" ] && [ -w "/etc/systemd/system" ]; then exit 0; else exit 1; fi

Satisfy

echo "/etc/systemd/system/ does not exist or is not writable."

GUID17e8c01b-3222-4591-a6bf-1131bff5406d

Execute Command via Transient systemd Service (systemd-run)

linux

Required

Yes

Uses systemd-run to execute a command as a transient systemd service without creating a persistent unit file on disk. Adversaries may use systemd-run to execute arbitrary commands under the context of systemd while bypassing controls that monitor for new unit file creation, since transient services exist only in memory for their lifetime. This is a particularly stealthy technique as it leaves minimal on-disk artefacts and the service disappears from systemctl list-units once execution completes.

Input arguments

Name	Type	Default	Description
unit_name	string	atomic-transient	Name of the transient systemd unit to create
command_to_run	string	/bin/bash -c "id > /tmp/atomic_transient_output.txt"	Command to execute as a transient service

Attack command

systemd-run --unit=#{unit_name} --wait #{command_to_run}
systemctl status #{unit_name}.service 2>/dev/null || echo "Transient service has already completed and exited."

Cleanup command

systemctl stop #{unit_name}.service 2>/dev/null || true
rm -f /tmp/atomic_transient_output.txt

Prerequisite

systemd-run must be available on the system

Check

if [ -x "$(command -v systemd-run)" ]; then exit 0; else exit 1; fi

Satisfy

echo "systemd-run is not available. Ensure systemd is installed and up to date."

Prerequisite

The test must be run as root or with sudo privileges

Check

if [ "$(id -u)" -eq 0 ]; then exit 0; else exit 1; fi

Satisfy

echo "This test requires root privileges. Run as root or use sudo."

GUID200c1183-ceb7-42cb-8867-1e90dafd8a22

Enumerate All systemd Services Using systemctl

linux

—

Yes

Enable systemd Service for Persistence with Auto-Restart

linux

Required

Yes

Creates a payload script and a systemd service unit that executes it, then enables the service to survive reboots using systemctl enable. The service is configured with Restart=always to automatically restart on failure, mimicking the persistence mechanism used by adversaries deploying backdoors or beacons on Linux hosts. This technique is consistent with observed post-exploitation tradecraft where adversaries establish a foothold that survives reboots and self-heals after interruption, complicating incident response and remediation efforts.

Input arguments

Name	Type	Default	Description
payload_path	path	/tmp/atomic_payload.sh	Path to the payload script that the service will execute
service_name	string	atomic-persist	Name of the persistence service to create

Attack command

echo "[Unit]" > /etc/systemd/system/#{service_name}.service
echo "Description=Atomic Persistence Service" >> /etc/systemd/system/#{service_name}.service
echo "After=network.target" >> /etc/systemd/system/#{service_name}.service
echo "" >> /etc/systemd/system/#{service_name}.service
echo "[Service]" >> /etc/systemd/system/#{service_name}.service
echo "ExecStart=#{payload_path}" >> /etc/systemd/system/#{service_name}.service
echo "Restart=always" >> /etc/systemd/system/#{service_name}.service
echo "RestartSec=10" >> /etc/systemd/system/#{service_name}.service
echo "" >> /etc/systemd/system/#{service_name}.service
echo "[Install]" >> /etc/systemd/system/#{service_name}.service
echo "WantedBy=multi-user.target" >> /etc/systemd/system/#{service_name}.service
systemctl daemon-reload
systemctl enable #{service_name}.service
systemctl start #{service_name}.service
systemctl status #{service_name}.service

Cleanup command

systemctl stop #{service_name}.service 2>/dev/null || true
systemctl disable #{service_name}.service 2>/dev/null || true
rm -f /etc/systemd/system/#{service_name}.service
rm -f /etc/systemd/system/multi-user.target.wants/#{service_name}.service
systemctl daemon-reload
rm -f #{payload_path}
rm -f /tmp/atomic_persist_output.txt

Prerequisite

systemctl must be available on the system

Check

if [ -x "$(command -v systemctl)" ]; then exit 0; else exit 1; fi

Satisfy

echo "systemctl is not available. Ensure systemd is running on this system."

Prerequisite

The test must be run as root or with sudo privileges

Check

if [ "$(id -u)" -eq 0 ]; then exit 0; else exit 1; fi

Satisfy

echo "This test requires root privileges. Run as root or use sudo."

Prerequisite

/etc/systemd/system/ directory must exist and be writable

Check

if [ -d "/etc/systemd/system" ] && [ -w "/etc/systemd/system" ]; then exit 0; else exit 1; fi

Satisfy

echo "/etc/systemd/system/ does not exist or is not writable."

Prerequisite

Payload script must exist at the specified path

Check

if [ -f "#{payload_path}" ]; then exit 0; else exit 1; fi

Satisfy

echo '#!/bin/bash' > #{payload_path}
echo 'echo persistent >> /tmp/atomic_persist_output.txt' >> #{payload_path}
chmod +x #{payload_path}

GUID681931c5-b9f2-410d-9489-5893b3c0ecf6

Masquerade Malicious Service as Legitimate System Service

linux

Required

Yes

Creates a systemd service with a name and description closely resembling a legitimate system service to blend in with normal service activity. Adversaries may deliberately choose service names similar to well-known system services such as systemd-networkd, cron, or ssh to evade detection from analysts reviewing service lists or automated alerting on service names. This masquerading technique is particularly effective in environments where detection relies on service name allowlists or manual review of systemctl list-units output rather than behavioural analysis of service unit file contents and ExecStart paths.

Input arguments

Name	Type	Default	Description
command_to_run	string	/bin/bash -c "echo masquerade > /tmp/atomic_masquerade_output.txt"	Command the masquerading service will execute
masquerade_name	string	systemd-network-helper	Service name designed to closely mimic a legitimate system service

Attack command

echo "[Unit]" > /etc/systemd/system/#{masquerade_name}.service
echo "Description=Network connectivity helper service" >> /etc/systemd/system/#{masquerade_name}.service
echo "After=network.target" >> /etc/systemd/system/#{masquerade_name}.service
echo "Before=network-online.target" >> /etc/systemd/system/#{masquerade_name}.service
echo "" >> /etc/systemd/system/#{masquerade_name}.service
echo "[Service]" >> /etc/systemd/system/#{masquerade_name}.service
echo "ExecStart=#{command_to_run}" >> /etc/systemd/system/#{masquerade_name}.service
echo "Restart=on-failure" >> /etc/systemd/system/#{masquerade_name}.service
echo "RestartSec=5" >> /etc/systemd/system/#{masquerade_name}.service
echo "" >> /etc/systemd/system/#{masquerade_name}.service
echo "[Install]" >> /etc/systemd/system/#{masquerade_name}.service
echo "WantedBy=multi-user.target" >> /etc/systemd/system/#{masquerade_name}.service
systemctl daemon-reload
systemctl start #{masquerade_name}.service
systemctl status #{masquerade_name}.service

Cleanup command

systemctl stop #{masquerade_name}.service 2>/dev/null || true
systemctl disable #{masquerade_name}.service 2>/dev/null || true
rm -f /etc/systemd/system/#{masquerade_name}.service
systemctl daemon-reload
rm -f /tmp/atomic_masquerade_output.txt

Prerequisite

systemctl must be available on the system

Check

if [ -x "$(command -v systemctl)" ]; then exit 0; else exit 1; fi

Satisfy

echo "systemctl is not available. Ensure systemd is running on this system."

Prerequisite

The test must be run as root or with sudo privileges

Check

if [ "$(id -u)" -eq 0 ]; then exit 0; else exit 1; fi

Satisfy

echo "This test requires root privileges. Run as root or use sudo."

Prerequisite

/etc/systemd/system/ directory must exist and be writable

Check

if [ -d "/etc/systemd/system" ] && [ -w "/etc/systemd/system" ]; then exit 0; else exit 1; fi

Satisfy

echo "/etc/systemd/system/ does not exist or is not writable."

Prerequisite

Chosen masquerade service name must not already exist as a real service

Check

if ! systemctl list-unit-files --type=service | grep -q "^#{masquerade_name}.service"; then exit 0; else exit 1; fi

Satisfy

echo "A service named #{masquerade_name} already exists. Change the masquerade_name input argument to avoid conflicts."

GUIDc7a07d63-3636-43f2-9467-ffd5c1fae6c7

Tests from Atomic Red Team (MIT licence) · technique definition

Systemctl detections T1569.003

No detection rules are mapped to this technique yet.

None recorded— 33% of ATT&CK techniques have none either

Drag headers to reorder | Drag edges to resize

Loading detections...

Select	Title	Description	Category	Status	Event	Product	MITRE ATT&CK	CVEs	Severity	Author	Created	Updated	ID	Refs