Attack Chain

1. An attacker gains initial access to a Linux system, often via exploitation of a vulnerable service, compromised credentials, or a successful phishing attempt.
2. After establishing a foothold, the attacker performs reconnaissance to understand the environment and identifies systemd-run as a potential tool for evading detection.
3. The attacker stages a malicious payload (e.g., a reverse shell script, a downloader for additional malware, or a credential harvesting tool) onto the compromised system, possibly in a temporary directory.
4. The attacker executes the malicious payload using systemd-run, typically with options like --user or --scope, to launch it as a transient systemd unit or scope, detaching it from the initiating process.
5. systemd-run acts as a proxy, launching the malicious command or script in the background, making it appear as a legitimate systemd-managed process.
6. The detached malicious payload executes, performing its intended actions such as establishing command and control, downloading further stages, escalating privileges, or exfiltrating data.
7. The attacker might configure persistence mechanisms within the transient unit definition or by other means, ensuring continued access even after the initial session ends.

Impact

If successful, attacks employing systemd-run for proxy execution can lead to significant compromises. Adversaries can execute arbitrary commands, establish covert persistence, download additional malicious tooling, or exfiltrate sensitive data without being easily detected through conventional process monitoring. The use of detached, transient units complicates forensic analysis and incident response by obfuscating the true origin and nature of the malicious processes. This can result in full system compromise, severe data breaches, unauthorized privilege escalation, or lateral movement across the network, making remediation challenging and prolonged.

Recommendation

• Deploy the Sigma rule "Detect Potential Proxy Execution via Systemd-run" in this brief to your SIEM and tune for your environment.
• When triggered by the Sigma rule, reconstruct the full process tree around the systemd-run event to determine which user, shell, script, service, or remote access session invoked it.
• Review the exact command passed through systemd-run, including flags such as --user, --scope, scheduling options, or custom unit names, to classify the spawned payload as expected or suspicious.
• Isolate any affected Linux host from the network immediately, and terminate the malicious systemd-run transient unit or scope along with any child processes it launched.
• Remove attacker persistence by deleting unauthorized unit files and drop-ins from /etc/systemd/system/, /run/systemd/transient/, /var/lib/systemd/, and affected users’ ~/.config/systemd/user/ directories.