Cron and Systemd Timer Persistence

Cron and systemd timer persistence in Linux

Cron and systemd timers are two common Linux scheduling mechanisms that attackers abuse to survive reboot and relaunch malicious code at predictable intervals. Because they are legitimate operating-system features, their persistence can blend in with normal administrative automation until defenders inspect the job definitions, execution paths, and ownership context.

Persistence through scheduling is dangerous because it creates repeated execution without requiring an interactive login or a visible startup shortcut. A malicious job can point to a script in a writable directory, invoke an unexpected binary, or chain into another mechanism that restores access after cleanup.

In practice, the key question is not whether a scheduled task exists, but whether it is expected, authorized, and consistent with the host's normal automation footprint. A new timer, an altered cron entry, or a modified unit file can be the only clue that a compromise has been made durable.

How cron and systemd timers are used for persistence

Cron persists through user crontabs, system crontabs, and periodic directories such as hourly or daily job locations. Systemd timers persist through timer units paired with service units, making the scheduled action appear like ordinary service orchestration rather than classic malware startup abuse.

Attackers prefer these mechanisms because they are reliable, low-friction, and often overlooked during routine reviews. They can trigger on boot, on a fixed interval, or after a delay, which lets malware re-establish command channels, re-drop payloads, or re-run cleanup suppression routines.

Both mechanisms are especially effective when the referenced script, command, or service is already trusted by operators. A timer that launches a helper script in a shared directory can look legitimate even when the script content has been replaced or the file path was added only after compromise.

What defenders should inspect

Review the full schedule surface, not just the obvious per-user crontab. That means checking system crontabs, cron directories, and systemd timer units together with the scripts and binaries they launch, because persistence often lives in the referenced payload rather than the schedule entry itself.

Look for recent file creation, permission changes, unusual ownership, and jobs that call interpreters such as shell, Python, or PowerShell wrappers in places where those tools are not normally used. Correlate timer creation or modification with authentication events, privilege changes, package installs, and any unexpected outbound activity.

The most useful review is comparative. A schedule entry may be technically valid but still suspicious if it was added outside the normal change window, points to a hidden path, or appears on a host that should not run that class of automation. Persistence Techniques Guide is the broader map for the attacker persistence patterns that cron and timers belong to.

Why this persistence technique is hard to remove

Scheduled-job persistence is resilient because it separates execution from initial access. Even if the original foothold is removed, the schedule can restore the payload, rebuild the implant, or reintroduce a compromised service account flow when the next interval fires.

It is also hard to notice when the scheduled action looks like normal maintenance. On Linux estates, cron and systemd timers are common administrative tools, so malicious use often hides in plain sight until defenders connect the schedule to an unexpected script, binary, or privilege shift.

The defensive challenge is compounded when the job references shared paths, writable directories, or scripts with weak integrity controls. In those cases, the schedule itself may remain unchanged while the launched content is silently replaced, which makes post-removal verification as important as initial cleanup.

Practitioner Guidance

What to watch for: Treat any new or altered cron entry, timer unit, or referenced script as a persistence candidate until you can tie it to an approved change. The most important judgement is whether the schedule and the launched content both belong in the host's normal operating profile.

Practitioner note: A clean schedule file does not prove a clean host. If a malicious binary or script was already planted, the timer may simply be the mechanism that keeps bringing it back, so removal must include the job definition, the payload, and any supporting privilege changes.

Related resources from NHI Mgmt Group

• What breaks when malicious Python packages install persistence through cron, .pth files, and shell startup hooks?
• What is the difference between cron jobs and systemd timers for scheduled Linux tasks?
• Systemd Persistence
• Systemd User Timer