T1569.003_systemctl

T1569.003 Systemctl

Sub-technique of: T1569

High-Level Description

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.

Adversaries may use systemctl to execute commands or programs as Systemd Services. Common subcommands include: systemctl start, systemctl stop, systemctl enable, systemctl disable, and systemctl status.

Kill Chain Phase

• Execution (TA0002)

Platforms: Linux

What to Check

• Identify if Systemctl technique is applicable to target environment
• Check Linux systems for indicators of Systemctl
• Verify mitigations are bypassed or absent (1 known mitigations)
• Assess detection coverage (1 detection strategies)

How to Test

Atomic Red Team Tests

The following tests are from Atomic Red Team and provide actionable ways to test this technique:

Atomic Test 1: Create and Enable a Malicious systemd Service Unit

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.

Supported Platforms: linux Elevation Required: Yes

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

Dependencies:

• systemctl must be available on the system
• The test must be run as root or with sudo privileges
• /etc/systemd/system/ directory must exist and be writable

Atomic Test 2: Create systemd Service Unit from /tmp (Unusual Location)

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.

Supported Platforms: linux Elevation Required: Yes

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})

Dependencies:

• systemctl must be available on the system
• /tmp must exist and be writable
• The test must be run as root or with sudo privileges

Atomic Test 3: Create systemd Service Unit from /dev/shm (Unusual Location)

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.

Supported Platforms: linux Elevation Required: Yes

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})

Dependencies:

• systemctl must be available on the system
• /dev/shm must exist and be writable
• The test must be run as root or with sudo privileges

Atomic Test 4: Modify Existing systemd Service to Execute Malicious Command

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.

Supported Platforms: linux Elevation Required: Yes

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

Dependencies:

• systemctl must be available on the system
• sed must be available on the system
• The test must be run as root or with sudo privileges
• /etc/systemd/system/ directory must exist and be writable

Atomic Test 5: Execute Command via Transient systemd Service (systemd-run)

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.

Supported Platforms: linux Elevation Required: Yes

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."

Dependencies:

• systemd-run must be available on the system
• The test must be run as root or with sudo privileges

Manual Testing

If Atomic Red Team tests are not applicable, manually verify the technique by:

1. Identify Attack Surface: Determine if the target environment is susceptible to Systemctl by examining the target platforms (Linux).

2. Assess Existing Defenses: Review whether mitigations for T1569.003 are in place. If defenses are absent or misconfigured, this technique may be exploitable.

3. Execute Test: Use tools and methods described in the MITRE ATT&CK page and external references below.

Remediation Guide

M1018 User Account Management

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

Detection

Detection Strategy for System Services: Systemctl

Risk Assessment

CWE Categories

References

• Red Hat Systemctl 2022
• Atomic Red Team - T1569.003
• MITRE ATT&CK - T1569.003