T1569.003 · threatengine.sh

Home/ATT&CK Technique/Systemctl

ATT&CK Technique

Systemctl

T1569.003 · execution

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.

Linux

▸

Atomic Tests

Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.

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

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

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

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

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

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

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

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

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

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

shlinuxEnumerate All systemd Services Using systemctl

Enumerates all systemd services and their current states using systemctl list-units and systemctl list-unit-files. Adversaries may enumerate running and enabled services to identify targets for hijacking, understand the host environment, map installed security tooling, or identify gaps in monitoring coverage. Service enumeration is a common reconnaissance step during post-exploitation and may precede service hijacking or masquerading activity. This test does not require elevation as service listing is available to unprivileged users on most Linux systems.

systemctl list-units --type=service --all
systemctl list-unit-files --type=service

shelevatedlinuxEnable systemd Service for Persistence with Auto-Restart

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.

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

shelevatedlinuxMasquerade Malicious Service as Legitimate System Service

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.

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

▣

Mitigations

MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.

M1018User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies.

Enforcing the Principle of Least Privilege

Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted.
Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions. Implementing Strong Password Policies.
Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse.
Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks. Managing Dormant and Orphaned Accounts.
Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits.
Use Case: Eliminates dormant accounts that could be exploited by attackers. Account Lockout Policies.
Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes.
Use Case: Mitigates automated attack techniques that rely on repeated login attempts. Multi-Factor Authentication (MFA) for High-Risk Accounts.
Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics.
Use Case: Prevents unauthorized access, even if credentials are stolen. Restricting Interactive Logins.
Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions.
Use Case: Protects sensitive accounts from misuse or exploitation.

Tools for Implementation Built-in Tools

Microsoft Active Directory (AD): Centralized account management and RBAC enforcement.
Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools

Okta: Centralized user provisioning, MFA, and SSO integration.
Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM)

CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

◈

Detection Coverage

0/6 layers

Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).

Behavioral / log (Sigma) none

Analytics (MITRE CAR) none

Runtime / container (Falco) none

File / malware (YARA) none

Network (Suricata/Snort) none

Vuln scan (Nuclei) none

Intelligence Graph · click any node to traverse

CVETechnique ActorTool Family

drag to reposition · click any node to traverse · button top-right enlarges

External lookups - second-class, for what we don’t hold ourselves

MITRE ATT&CK Atomic Red Team car (MITRE)

Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities

Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs

Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures

Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1

About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service

threatengine.sh · Open-source threat intelligence platform · 100+ authoritative sources · Every fact traces to its origin