The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Linux malware can survive a reboot by arranging to start a systemd service, run a command through cron or a systemd timer, or load a malicious kernel module. The first two mechanisms are user-space configuration; a kernel module runs with kernel privileges and can make the compromised machine’s own reports less trustworthy. An unfamiliar startup entry is a lead to investigate, not proof of malware.
How do these persistence mechanisms differ?
Each mechanism gives code a way to run again after a restart or at a later time, but they differ in when they run, which account runs them, and how reliable local inspection is if the host is compromised.
| Mechanism | Scope and trigger | Execution and configuration | Downtime behavior and inspection limits |
|---|---|---|---|
| systemd service | May be system-wide or associated with a user manager. Starts when activated through boot targets, dependencies, or other unit relationships. | systemd supervises a process described by a plain-text unit; the unit’s command and related configuration determine what runs. Inspect unit files, drop-ins, enablement links, and the executable path. systemd.unit(5) and systemd.service(5) document unit configuration and services. | A service activated at boot can run after each boot. Its persistence does not depend on a missed schedule being caught up. Inspection remains in user space unless the host is compromised at a deeper level. |
| cron job | Can be per-user or system-wide. Runs commands according to a time-and-date schedule. | A user crontab runs commands as its owner; system-wide cron formats can specify a user. Check the crontab and the command or script it invokes. | Runs when its schedule is due, subject to the cron implementation and host availability. The reviewed implementation checks /etc/crontab, /etc/cron.d/, /var/spool/cron, and /etc/anacrontab; these are inspection examples, not guaranteed paths on every distribution. |
| systemd timer | Can activate a system or user unit according to a timer schedule. | A timer activates a named unit; if Unit= is absent, it defaults to a same-named service. Inspect the timer and the unit it activates. |
With Persistent=true on a calendar timer, systemd records the last trigger and can run missed work after downtime. That catch-up behavior is distinct from a service configured to start at every boot. |
| Kernel module | Typically system-level. A module may be loaded during startup through the host’s module-loading arrangements, but modules can also be loaded without rebooting. | Runs in kernel context, rather than as an ordinary user-space process. Module files and installation conventions are kernel-version- and distribution-dependent. | A compromised module may hide or tamper with user-space inspection results. Local output alone may not be reliable when kernel compromise is plausible. |
On many distributions, systemd runs as PID 1 during boot and maintains user-space services; separate user managers also run for logged-in users. Unit enablement is not simply a property of one file: enablement links, dependencies, drop-ins, and, less commonly, generators can affect activation. The [Install] section is acted on during enablement, while dependency relationships can connect units to startup targets. See MITRE ATT&CK’s systemd service technique page for the technique context.
How do I find malware that starts on boot in Linux?
Start by establishing what is normal for this machine. Paths and defaults depend on the distribution, init system, installed packages, and version; system-wide configuration and a logged-in user’s configuration are separate scopes. A service or job can be legitimate even if its name or location is unfamiliar, so investigate its provenance and behavior rather than treating one clue as a verdict.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
- Record the host context. Note the distribution, kernel version, init system, user and session scope, and the timing of the suspected incident. These details help distinguish expected package and administrator configuration from unexpected changes.
- Inventory systemd services and user services. Review active and enabled state, unit contents, drop-ins, dependencies, and relevant links beneath target
.wantsand.requiresdirectories. A service need not have an obvious enablement link in the location you first check if another dependency activates it. - Trace the command a unit runs. Follow the executable or script path referenced by the service configuration. Check its owner, permissions, package or other source, and modification history. Pay attention to new names that imitate familiar services, commands in temporary or user-writable locations, unexpected execution users, and unrelated changes to a legitimate unit. These are reasons to investigate, not proof of maliciousness.
- Correlate configuration changes with boot activity. Compare unit changes with process behavior during boot, logs, network activity, package history, and external telemetry. MITRE ATT&CK’s detection guidance recommends correlating systemd unit changes with outlier process behavior during boot.
How do I check cron jobs for malware?
Review both per-user schedules and system-wide cron configuration. A command in a user’s crontab runs under that crontab owner’s account; a system-wide cron file may specify a different user. Record the account that will run the command before judging what access it has.
- Inspect the relevant user crontabs and system cron locations used by the host. The reviewed implementation includes
/etc/crontab,/etc/cron.d/,/var/spool/cron, and/etc/anacrontab, but those paths are not a universal guarantee across distributions. - Read the complete command, then inspect any referenced script or executable. Check ownership, permissions, timestamps, provenance, and whether the file matches expected package or administrator activity.
- Compare the schedule and execution account with the host’s duties. An unexpected user, non-standard interval, or a schedule paired with unusual process behavior deserves closer review, but none establishes maliciousness on its own.
Also inspect systemd timers; checking cron alone misses that scheduler. A timer activates a unit, and Persistent=true on a calendar timer can cause a missed run to be caught up after the machine was off. It does not mean that every timer behaves like a service that starts on every boot.
Rank #2
Can a Linux rootkit survive a reboot?
Yes. Malware can arrange for a kernel module to load during startup, so rebooting does not necessarily remove it. A loadable module extends kernel functionality and may be loaded or unloaded without restarting the machine. Because its code runs in kernel context, a malicious module can interfere with what ordinary tools report; it need not hide every artifact for local results to be suspect.
Do not assume that every unfamiliar .ko file is malicious. External modules are built against the relevant kernel build artifacts, and the kernel’s kbuild documentation gives /lib/modules/<kernel_release>/updates/ as a default installation directory; distribution and package conventions can differ. Validate module provenance against trusted package records or known-good records for the matching kernel. ATT&CK’s kernel module and extension technique page includes Drovorub and REPTILE as examples associated with this kind of persistence.
If kernel-level compromise is plausible, preserve evidence and corroborate host-local findings using trusted offline methods or external telemetry. A kernel compromise can undermine the reliability of the very tools used to inspect it, so one local inventory should not be treated as conclusive.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What should you do if you find a suspicious startup artifact?
- Preserve context. Record the artifact’s location, relevant configuration, owner, timestamps, and the host and account scope. Avoid treating a name or timestamp alone as proof.
- Trace what it runs and who runs it. Follow service commands, cron commands, timer targets, and module provenance to their source and execution context.
- Correlate independent evidence. Compare configuration changes with process behavior, logs, network activity, package history, and telemetry that does not depend solely on the possibly compromised host.
- Contain and preserve evidence if compromise is indicated. Follow the organization’s incident-response process. Removing one startup entry does not establish that the host is clean; more than one persistence mechanism may coexist.
MITRE ATT&CK documents scheduled-task and service techniques as behaviors defenders can use to organize detection and investigation, not as a prevalence measure. The available technical references do not establish that any one of these mechanisms is universally more common or stealthier than the others.
Quick Recap
Best Value
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.
