How Malware Persists and Hides
Malware that survives a reboot and hides from the administrator is far more dangerous than a one-shot payload, so persistence and stealth are core to how it is built. Persistence means securing automatic re-execution; hiding means evading the eye of both the user and the tools looking for it.
This topic teaches the persistence and hiding techniques a defender must know in order to find what is already there — because eradication (Chapter 11) that misses the persistence mechanism just restarts the incident on the next reboot.
Persistence Mechanisms
Malware secures re-execution through known autostart locations: services, scheduled tasks and cron, registry run keys, startup folders, hijacked legitimate programs, and — deepest — boot or firmware footholds. The defensive value is that these locations are a finite, enumerable list, so a hunt or a forensic examination checks each one, and a new autostart entry is a high-value detection.
Rootkits and Hiding from the OS
A user-mode rootkit hooks APIs to hide files and processes; a kernel-mode rootkit alters the operating system itself, so even the administrator's own tools lie about what is running. This is why trustworthy detection sometimes needs an outside vantage — offline analysis or memory forensics — because a compromised system cannot be trusted to report on itself.
Process Injection and Living in Memory
Injecting into a legitimate process — hollowing, DLL injection — lets malware run under a trusted name with no malicious file on disk, defeating file scanning and blending into normal telemetry. A web browser making an outbound connection is normal; the same browser process spawning a shell is not, which is why baselining normal process behavior is what makes injection stand out.
Hunting Persistence on Meridian
A concrete defensive sweep enumerates the standard autostart and injection locations on a host, and compares them against a known-good baseline so the intruder's implant stands out as the anomaly. Anti-forensic touches — timestomping to fake file times, clearing logs — are themselves tells, because legitimate software rarely does them, and recognizing them is part of the forensic work in Chapter 11.
- Cleaning the visible payload but missing the persistence mechanism, so the malware returns on the next reboot or beacon.
- Trusting on-host tools against a kernel rootkit that is lying to them, instead of using memory forensics or an offline vantage.
- Not baselining normal autostart and process state, so an injected or persisted implant has nothing to stand out against.
- Ignoring memory-only and injected malware because file scanning comes up clean.
- Overlooking anti-forensic tells — timestomping, cleared logs — that are themselves high-fidelity signals.
- Enumerate and monitor the known persistence locations continuously; a new autostart entry is a high-value detection.
- Baseline known-good processes and autostarts so injection and persistence show up as anomalies (Chapter 10).
- Use memory forensics and offline or known-good analysis when a host may be lying (a suspected rootkit).
- Ensure full eradication removes persistence, not just the running payload (Chapter 11).
- Alert on anti-forensic behavior like log clearing and timestomping, which legitimate software rarely does.
Knowledge Check
Why can't you always trust a host's own tools to detect a kernel rootkit?
- It alters the OS itself, so those tools report false information
- The host's own built-in analysis tools are almost always outdated
- Kernel rootkits simply delete all of the analysis tools
- On-host tools are unable to read the filesystem at all
Why is a new autostart entry a high-value detection?
- Persistence lives in known spots, so a new entry is suspect
- Autostart entries are effectively impossible to enumerate
- Only computer viruses ever make use of autostart entries
- Autostart entries on a host are always stored encrypted
Why does eradication that removes only the running payload often fail?
- The persistence remains, so the malware returns on the next reboot
- The running payload cannot actually be removed from the host at all
- Removing the running payload always corrupts the host's OS
- Payloads simply regenerate themselves out of nothing
You got correct