Systemd Persistence

What systemd persistence is for defenders

systemd persistence turns a Linux compromise into repeatable execution by embedding malicious behaviour in service units, drop-ins, or related startup configuration. The defender’s concern is not just that code ran once, but that it can relaunch after reboot, restart, or operational maintenance unless the unit definition, file ownership, and launch path are fully reviewed.

The practical security meaning is similar to other autostart techniques: persistence survives the moment of initial intrusion and gives an attacker a reliable re-entry path. On Linux estates, that makes service control, unit-file hygiene, and startup-path inventory part of the security baseline, not just system administration.

How systemd units become a persistence mechanism

systemd manages Linux services through unit files and related configuration, so an attacker who can write or alter those objects can often arrange automatic execution. In practice, persistence may be achieved by modifying an existing service, adding a new unit, abusing drop-in overrides, or pointing a legitimate service at a malicious binary or script.

This is dangerous because the malicious code does not need interactive user action after the initial foothold. A reboot, crash recovery, or admin restart can re-trigger the payload, and legitimate operations may accidentally keep the backdoor alive if the underlying service configuration is still trusted.

Service-based persistence is especially valuable to an intruder because it blends into normal host operations. If defenders only hunt for suspicious processes in memory or shells in login sessions, they can miss the real control point: the unit definition that instructs the system to launch the payload again.

What defenders should inspect on a compromised host

Exposure is usually determined by whether an attacker can modify service definitions, unit drop-ins, executable paths, or the files and directories those services depend on. That is why the review should combine host inventory, service listing, file ownership, and permission checks rather than looking only for obvious malware artifacts.

Good triage looks at which units changed, what command line they launch, whether the binary or script is expected, and whether the service is enabled to start at boot. If the host shows one suspicious unit, the wider question is whether other services, timers, or related autostart entries were also altered for fallback access.

For investigation depth, a Linux-focused Linux Forensics Guide is useful because it connects service persistence with journald, auditd, login records, and other artefacts that help reconstruct what happened on the host.

How this persistence pattern fits into attacker tradecraft

systemd persistence is one instance of the broader “create or modify system process” tactic, where the attacker abuses a trusted startup mechanism rather than dropping a standalone scheduled task or user-level autostart entry. The goal is durability: regain execution without needing to re-exploit the original weakness each time.

That same logic appears across Linux, Windows, and cloud-native systems. The mechanism differs, but the defender’s problem is consistent: a trusted management plane is being used as the launch authority for malicious code, which makes the malicious process look like ordinary operations unless configuration integrity is checked.

The same defensive lens applies to broader persistence tradecraft in the Persistence Techniques Guide, which helps place systemd unit abuse alongside other startup and logon mechanisms defenders need to inventory.

For technique-level mapping, the T1543 Create or Modify System Process Defensive Guide is the most direct internal reference because it covers systemd units, service accounts, and related persistence paths together.

Detection, removal, and post-incident review

Defenders should assume that removing the payload file alone may not end the compromise if the unit still points to it or if a drop-in recreates the launch condition. Cleanup needs to confirm the malicious unit, any companion override files, and any supporting service permissions have been removed or restored to a known-good state.

After remediation, review should verify whether the attacker used the service to access credentials, tokens, SSH keys, or other secrets stored on the host, because persistence often exists to preserve that broader access, not just to keep one process alive. If the service was created with privileged ownership, that review should also check for lateral movement and any changes made through the same administrative trust path.

For post-compromise understanding, the Identity Threat Detection and Response (ITDR) Guide helps connect persistence with account abuse, session abuse, and the response steps that matter when an attacker preserves access through trusted execution paths.

Related resources from NHI Mgmt Group

• Cron and Systemd Timer Persistence
• When does malware persistence become an NHI governance issue?
• How do security teams know if persistence has been established on a compromised AI node?
• How should security teams prevent unwanted persistence in Active Directory and Entra ID?