How it works
Execution establishes a command channel and a way to survive reboot. Evasion ranges from familiar-looking software, through kernel and firmware modification that outlives reimaging, to abusing legitimate administrative tools so no malicious file exists to detect.
Three depths of the same goal
Everything in this article serves one objective: remain on the system, and remain unseen. They differ in how deep they go and what it costs to remove them.
A backdoor or remote access trojan is the ordinary case — a program that persists through a scheduled task, service or startup entry and provides a command channel. It is a file on disk, which makes it detectable and removable.
A rootkit or bootkit operates below the tools looking for it, modifying kernel components or firmware so the system reports a state that is not true. Because it loads before or beneath the operating system, it can survive reinstallation.
Living-off-the-land inverts the problem: nothing malicious is installed at all. The attacker uses the administrative tools already present and trusted, so file-based detection has nothing to find.
Living off the land
This is the dominant technique in competent intrusions, for a simple reason: signed, legitimate, expected tools do not trigger antivirus, and their presence is not suspicious.
Scripting hosts, remote management utilities, package installers, certificate tools and archive utilities can all download, execute, persist and exfiltrate. Every one of them is genuinely needed by administrators, so removing them is not an option.
Detection therefore has to move from what runs to how it runs. A scripting host launched by a document, invoked with encoded arguments, contacting an unfamiliar host, is the same binary doing something it never does legitimately. That requires process-chain and command-line logging rather than file scanning — and it requires that logging to be enabled in advance, because it cannot be reconstructed afterwards.
Below the operating system
Firmware and bootloader implants are rarer and disproportionately serious, because they defeat the standard recovery assumption. Reinstalling the operating system removes everything except the component that loads before it.
Secure Boot and measured boot are the meaningful controls, verifying each stage before handing control onward and attesting the result. Where they are enabled and monitored, this class of implant is substantially harder; where firmware updates are unmanaged, it remains viable.
The response implication is blunt: if firmware compromise is genuinely suspected, reimaging is not remediation. Reflashing from trusted media, or replacing hardware, is.
Finding persistence
Persistence is finite. There are only so many places a program can register itself to run again, which makes enumeration a practical exercise rather than a hunt.
- Baseline scheduled tasks, services, startup entries and autoruns, then alert on additions rather than reviewing the whole list.
- Watch for beaconing — regular outbound intervals to one destination are the signature of a command channel and survive encryption of the payload.
- Restrict egress. A backdoor that cannot reach its operator is inert, and outbound restrictions are often easier to justify than inbound ones.
- Verify boot integrity where the platform supports attestation, and treat validation failures as incidents rather than noise.
- Alert on administrative tooling used by accounts that never otherwise administer anything.
Also known as
What defenders may observe
- Unexpected persistence entries or scheduled tasks
- Rare outbound destinations, or regular beaconing intervals
- Signed or familiar software behaving abnormally
- Boot or kernel integrity validation failing
- Persistence surviving a normal reimage
- Administrative tools running with unusual parents, arguments or network access
Prevention and mitigation
- Allow-list trusted software and verify provenance
- Enable Secure Boot and measured boot; monitor firmware integrity
- Constrain interpreters and administrative tooling to those who need them
- Log script blocks and full process chains, not just file writes
- Restrict egress so a command channel has nowhere to go
- Rebuild from trusted media, and reflash firmware where implantation is suspected
Initial response priorities
- Isolate affected systems without destroying volatile evidence.
- Activate the incident-response and continuity plans.
- Scope initial access, persistence, lateral movement and affected identities before recovery.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.