Linux malware can survive a reboot by arranging to start through a systemd service, run on a schedule through cron or a systemd timer, or load as a kernel module. Services and schedulers leave configuration you can inspect in user space; kernel modules run with kernel-level privilege and can make observations from the affected system less trustworthy. An unfamiliar entry is a lead to investigate, not proof that a host is infected.
How can malware start again after a Linux reboot?
Persistence means arranging for code or a command to run again after an event such as a reboot, a scheduled time, or a user session starting. On many distributions, systemd runs as PID 1 during boot, starts and supervises user-space services, and can also run separate managers for logged-in users. Cron and systemd timers schedule commands or units; a malicious kernel module uses a more privileged route by loading code into the kernel.
These mechanisms differ in when they run, what privilege they can use, and how much confidence to place in local inspection. Their paths and defaults vary with distribution, init system, package, and version.
| Mechanism | Scope | Trigger | Execution and inspection implications | Missed schedule behavior |
|---|---|---|---|---|
| systemd service | System services or user-manager services | Activation through boot dependencies, targets, or other unit relationships; a user service may be activated within its user-manager context | Runs a configured process under the unit’s execution context. Unit files, drop-ins, enablement links, and the executable path are inspectable in user space. | Not a scheduled job; it starts when activated by its configured relationships. |
| cron job | A user’s crontab runs as that account; system-wide cron formats can specify a user | Configured time and date schedule | Runs the specified command under the applicable account. Inspect the schedule, referenced files, ownership, permissions, and provenance. | Catch-up behavior is implementation-dependent; the reviewed cron documentation does not establish a universal behavior. |
| systemd timer | Can activate a system or user unit, according to its configuration | Configured timer schedule; the timer activates a named unit | Timer and activated-unit configuration can be inspected in user space. If Unit= is omitted, the default target is a same-named service. |
With Persistent=true on a calendar timer, systemd can run missed work after downtime. |
| Kernel module | Kernel-wide execution context | Loaded by an arrangement that can cause it to load at startup | Runs inside the kernel and may hide or alter results reported by ordinary user-space inspection. | Not a scheduled task; persistence depends on the module-loading arrangement. |
No single mechanism is established as universally more common or more stealthy. The useful question is what configuration changed, what code it starts, and whether that activity fits the host’s expected operation.
#1 Best Overall
How do systemd services persist across boot?
A systemd unit is plain-text configuration describing a service or another managed resource. A service’s command, dependencies, and activation relationships affect what runs and when. The unit’s [Install] section is acted on when it is enabled: systemd uses that information to create links that connect the unit to startup targets or other units. A service may therefore be pulled into startup through dependencies and symlinks, not just because its main file looks suspicious. See the systemd unit manual and systemd service manual.
Inspect the full effective configuration, not only one unit file. Relevant changes can be in a main unit, a drop-in that modifies it, an enablement link, or—less commonly—a generator that creates unit configuration. Review system and user units, enabled and active state, dependencies, and links under target .wants or .requires directories. Then trace each service command to the executable or script it invokes.
Rank #2
Names that imitate familiar services, commands or scripts in temporary or user-writable locations, unexpected execution accounts, and unrelated changes to a legitimate service deserve scrutiny. MITRE ATT&CK describes systemd service persistence under T1543.002; its detection guidance emphasizes correlating unit changes with unusual process behavior during boot. These are investigation leads, not standalone proof.
How do I check cron jobs and systemd timers?
Review cron schedules and their commands
Cron runs a command according to a time-and-date schedule. A user’s crontab runs commands as that crontab’s owner; a system-wide crontab can include a separate user field. The reviewed cron implementation checks /etc/crontab, /etc/cron.d/, /var/spool/cron, and /etc/anacrontab. These are an inspection checklist for that implementation, not guaranteed paths on every distribution. The crontab(5) and cron(8) manuals describe the relevant ownership and format distinctions.
For each entry, read the actual command and follow any referenced script or executable. Establish which account runs it, check file ownership and permissions, review modification history and provenance, and compare the schedule with the host’s expected duties. An unexplained account, non-standard interval, or unexpected command is more informative when correlated with a recent file change or unusual process activity. MITRE ATT&CK’s scheduled-task technique, T1053, also calls attention to schedule changes paired with unusual users or intervals.
Inspect systemd timers separately
A systemd timer activates a named unit. If the timer omits Unit=, it defaults to a service with the same name. A timer is therefore not just another name for a service: it supplies the schedule, while the activated unit defines the work.
Rank #4
For a calendar timer configured with Persistent=true, systemd records its last trigger and can run missed work after the machine has been powered down. That catch-up behavior applies to missed scheduled work; it is not the same as a service configured to start every time the system boots. Check both the timer and the unit it activates.
Can a Linux rootkit survive a reboot?
Yes. A malicious loadable kernel module can be arranged to load at startup and continue its activity after a reboot. Kernel modules extend kernel functionality and can be loaded or unloaded without rebooting. Because module code runs in kernel context, a compromised module may hide artifacts or tamper with information reported by ordinary tools; that possibility makes host-local observations less conclusive, but it does not mean every rootkit hides every trace.
The Linux kernel’s “Building External Modules” documentation explains that external modules are built against artifacts for the relevant kernel and gives /lib/modules/<kernel_release>/updates/ as a default installation directory. Distribution and package conventions can differ. A file ending in .ko, an unfamiliar module name, or an unexpected file in a module directory is not by itself evidence of malware. Check its provenance against trusted package records or known-good records for the matching kernel.
MITRE ATT&CK’s T1547.006 page includes Drovorub and REPTILE as examples associated with kernel-module persistence. The framework identifies restricting module loading and limiting privileged access as mitigation areas. If kernel-level compromise is plausible, corroborate local findings with trusted offline examination or external telemetry rather than relying only on reports from the affected host.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How do I investigate malware that starts on boot?
Use an evidence-led sequence. Record what you find before changing configuration, and adapt paths and expectations to the distribution, init system, kernel, and account scope on the machine.
- Establish the host context. Record the distribution, kernel version, init system, relevant user or session scope, and incident timing. These details determine which configuration locations and startup behavior are plausible.
- Map systemd activation. Inventory system and user services, their enabled and active state, unit contents, drop-ins, dependencies, and relevant target links. Trace each configured command to the executable or script, then establish its owner, package or other source, permissions, and modification history.
- Review scheduled execution. Examine system and per-user cron schedules and systemd timers. Read invoked commands and scripts, identify the execution account, and compare timing and file history with expected administrative or package activity.
- Check module inventory and files. Review the running module inventory and module files for the kernel version in use. Validate provenance against trusted package data or known-good records. If kernel compromise is plausible, treat host-local module listings and file reports as potentially unreliable.
- Correlate independent evidence. Compare configuration changes with process activity at boot or timer execution, logs, network activity, package history, and external telemetry. A name, timestamp, or file’s presence alone does not establish maliciousness.
- Contain and preserve evidence when warranted. Follow the organization’s incident process if evidence indicates compromise. Removing one startup entry does not demonstrate that a host is clean; more than one persistence mechanism may be present.
What makes a startup entry suspicious?
Judge an artifact by context and behavior rather than appearance alone. Ask who created or owns it, whether a package or administrator can account for it, what executable it launches, what privileges it receives, and whether its timing and resulting activity fit the system’s role. An unfamiliar service, cron entry, timer, or module can be legitimate; a familiar name can also conceal an unrelated change. Correlation among configuration history, execution behavior, and independent records is stronger evidence than any one clue.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
