How do you detect malicious systemd service creation on Linux?

What malicious systemd service creation looks like in practice

Malicious service creation usually shows up as a new or modified unit file that is not part of normal administration, especially when the service is built to survive reboot and execute payloads automatically. The most important clue is not just that a service exists, but whether its contents, pathing, and startup behaviour fit the host’s normal operational profile.

Look closely at whether the unit launches from a writable directory, pulls in an unusual script wrapper, or uses a binary that does not belong to the expected package set. Service definitions that hide behind generic names, obscure descriptions, or atypical execute paths deserve priority review because systemd makes persistence easy once a unit is enabled or started.

Because persistence is the goal, the Persistence Techniques Guide is the most direct internal reference for understanding how service-based persistence fits into a broader host-persistence pattern. It helps separate ordinary service management from attacker tradecraft that uses boot-time execution and long-lived footholds.

Which file, process, and boot-time signals matter most

Detection is strongest when you correlate file-system change, service metadata, and runtime process lineage. A newly created unit file, a recently edited drop-in, or an enabled service with no operational change ticket is more meaningful when it also spawns a shell, script interpreter, downloader, or secondary payload from a location that should not normally be executable.

Review the unit file for ExecStart, ExecStartPre, ExecReload, and related directives that point to user-writable paths, temporary directories, or chained commands. Also check whether the service runs as an unexpected user, starts at boot without business justification, or repeatedly restarts after failure, because those patterns often indicate persistence or a failed attempt to stay resident.

Process ancestry matters here. A suspicious systemd service usually leaves a lineage that is easy to explain on paper but hard to justify operationally: a parent unit process spawning a shell, then a network-capable child, then a payload or lateral movement tool. That lineage is often more valuable than the service name itself.

For exposure triage, the Attack Surface Management Guide is useful because it reinforces the need to inventory unexpected services and distinguish sanctioned daemons from untracked persistence points. The same asset-discovery mindset that finds exposed services externally also helps find suspicious services locally.

At the control level, NIST Cybersecurity Framework 2.0 aligns well because this is a detection and response problem centered on identifying anomalous configuration changes, establishing normal host behaviour, and responding quickly to persistence indicators.

How to separate legitimate administration from malicious persistence

Start from context, not from the unit name. A service is more suspicious when it appears outside a deployment window, lacks change control evidence, references paths owned by non-administrative users, or exists on a host that should not host custom daemons at all. On Linux fleets with strong baselines, the question is often whether the service belongs to the host image, not whether it merely works.

Validate the service file itself, not just the running process. A benign-looking process can be launched by a unit whose drop-in or override file quietly adds persistence, modifies restart behaviour, or changes the execution user. Also check whether the unit is system-wide or per-user, because per-user persistence can be overlooked when teams only watch traditional system service directories.

When the service is tied to suspicious enablement, bootstrap behaviour, or startup reach, MITRE ATT&CK Enterprise Matrix is a strong external reference for mapping the behaviour to known persistence and execution patterns. It gives analysts a common language for distinguishing service creation from the broader attack path that follows it.

Practitioner Guidance

What to verify: Confirm the unit file path, timestamp, owning account, enabled state, and executable target before you trust the service as legitimate. If the file lives in an unusual location or the command line points to a writable directory, treat it as a higher-priority review than a normal service inventory item.

Decision rule: If the service can survive reboot, launches from an untrusted path, or runs under an account that has no clear operational need, prioritise containment and review of adjacent host activity before deciding whether the file is merely misconfiguration. The persistence property is what makes the finding materially important.

What practitioners underestimate: The unit file is only part of the evidence. The highest-value signal is often the combination of service creation, enablement, and process lineage, because that combination tells you whether the change is a normal admin action or an attacker’s attempt to establish durable execution.

Practitioner takeaway: Treat unexpected systemd services as a persistence investigation, not a standalone file check, and anchor your decision on whether the unit creates durable, explainable execution on the host.

Related resources from NHI Mgmt Group

• How do you detect malicious scheduled task creation on Windows?
• How do you detect malicious shell scripts in Linux profile folders?
• What are common vulnerabilities associated with service accounts in AI deployments?
• How should teams reduce risk from malicious npm package installs?