How can security teams detect systemd timers?

What to look for in systemd timer persistence

systemd timers are useful because they can blend into normal host operations while still giving an attacker durable execution. The key is to inspect the timer unit and its paired service together, then ask whether the schedule, unit path, and command line make sense for that host. Suspicious timers often stand out because they exist where admins do not usually manage services, or because they trigger on boot or very short intervals.

A timer by itself is not enough to judge intent. The service it launches is usually where the malicious behaviour appears, such as a script in a writable directory, a downloader, a reverse shell, or a binary with a misleading name. When the timer repeatedly starts that service without an obvious business reason, treat it as a persistence mechanism rather than a harmless scheduler.

For broader persistence hunting, it helps to compare timer findings against the rest of the host’s autostart surface, because adversaries often mix systemd timers with other startup mechanisms to increase resilience. NHIMG’s Persistence Techniques Guide covers the common places where persistence hides, including systemd timers, and is a useful reference when you need to pivot from one suspicious unit to related artefacts.

How to validate whether a timer is legitimate or suspicious

Start by checking where the unit files live and whether they were created or modified recently. Native system units usually have stable paths and owners, while attacker-controlled units often appear in writable locations or in locations that are unusual for that host role. The next check is the schedule itself: a timer that fires at boot, every minute, or at another oddly aggressive cadence deserves attention if the business service does not need that behaviour.

Then inspect the ExecStart command and the service dependencies. Legitimate services usually launch predictable binaries with clear purpose, while malicious ones often invoke shell wrappers, fetch remote content, hide behind generic names, or rely on environment-specific paths that do not belong in a service context. If the service points at a script under /tmp, a user-writable home directory, or another mutable location, the timer is doing more than routine maintenance.

Detection is stronger when you correlate the timer with surrounding host activity. File creation events, package changes, new cron entries, unusual outbound traffic, and repeated failures or restarts around the same time can show whether the unit was deployed for persistence or simply misconfigured. A single suspicious timer may be enough to justify triage, but the surrounding context is what tells you whether it is an attack path.

Which unit properties and runtime clues matter most

The most useful clues are the ones that reveal how the timer is being used operationally, not just whether it exists. Look at the unit’s owner, file permissions, timestamps, the exact schedule, the service it triggers, and whether the timer is enabled to start at boot. If a timer is set to run even when the user is absent or the host is idle, that can be a deliberate attempt to guarantee execution.

Also check whether the service is named to resemble a legitimate package or daemon while actually launching something unrelated. Attackers often rely on trust in familiar naming patterns, so the name alone should never be treated as evidence of legitimacy. The combination of suspicious pathing, unexpected timing, and an opaque command line is what turns a normal configuration into a detection finding.

When you need a structured way to map the behaviour you see to known attacker techniques, MITRE ATT&CK Enterprise Matrix is useful for correlating timer-based persistence with broader adversary tradecraft. For teams that want a practical detection baseline, SANS Security Resources is a good companion for incident handling and host investigation workflows.

Practitioner Guidance

What to prioritise: Triage timers that start at boot, repeat frequently, or invoke scripts from writable paths before spending time on benign-looking scheduled maintenance. Those patterns are the ones most likely to represent durable execution rather than admin automation.

What to verify: Confirm the unit file origin, the service payload, and the last modification time, then compare them to your software inventory and change records. If the timer was not introduced through a known deployment path, assume the service content matters more than the timer name.

Decision rule: If the timer launches a command from a user-writable or temporary location, treat it as suspicious even if the unit name appears normal. If the service is in a trusted system path but the command line downloads or stages additional code, escalate for compromise review rather than simple cleanup.

Practitioner takeaway: The strongest signal is not “a timer exists”, it is “a timer repeatedly drives untrusted execution under a normal-looking unit name”, so investigate the launched service and execution path first.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?