Overview
The defensive priority for persistence is detection — finding the mechanisms an attacker may have installed. This lesson covers detecting persistence.
Learning objectives
- Explain how persistence is detected.
- Identify where to look for persistence indicators.
- Connect detection to baselines and monitoring.
Core concept
Detecting persistence means identifying unauthorized mechanisms that maintain access, by looking for anomalies against a known-good baseline. Key places to inspect (concept-level): auto-start locations (services, scheduled tasks, startup entries), account listings (new or modified accounts, especially privileged ones), authorized keys/credentials (unexpected additions enabling remote access), and modified system components. Detection relies on knowing what normal looks like — without a baseline, distinguishing malicious persistence from legitimate configuration is difficult.
How it works
The defender (or authorized tester in a detection exercise) compares the system's current state against the baseline of expected configuration: Are there scheduled tasks, services, or startup entries that are not part of the known-good set? Any accounts that administrators did not create, or unexpected privilege grants? Any added SSH keys or credentials enabling access? Any legitimate binaries/scripts modified to run attacker content? Each anomaly is a candidate persistence mechanism to investigate. Automated tools and monitoring (logs, integrity checks) aid this, but the core skill is anomaly recognition against a baseline — exactly the principle from the packet-analysis and monitoring lessons.
Practical example
In a detection exercise, the learner reviews a system and finds a scheduled task running an unfamiliar program from an unusual location, and an account not present in the administrators' records. Compared against the known-good baseline, both are anomalies — candidate persistence mechanisms. The learner flags them for investigation (and removal). Detection succeeded because a baseline existed to compare against; the unfamiliar task and account stood out as deviations, revealing potential persistence.
Cybersecurity relevance
Detecting persistence is essential to fully remediating a compromise — if persistence is missed, the attacker returns even after the initial access is closed. It is core to incident response and blue-team practice, relying on baselines, monitoring, and integrity checks (auto-start locations, accounts, keys, system files). This connects directly to the logs/monitoring lessons and the SOC path. Attackers try to blend persistence in with legitimate configuration, so a solid baseline and vigilant monitoring are what make detection possible. Detection precedes removal (cleanup).
Common mistakes
- Lacking a baseline, so persistence cannot be distinguished from legitimate config.
- Checking only some locations (e.g. services but not scheduled tasks, accounts, or keys).
- Closing initial access without hunting for persistence, letting the attacker return.
Key takeaways
- Detecting persistence means finding unauthorized access-maintaining mechanisms by spotting anomalies against a known-good baseline.
- Inspect auto-start locations (services, tasks, startup), account listings, added keys/credentials, and modified system components.
- Detection relies on baselines, monitoring, and integrity checks (anomaly recognition); missing persistence lets attackers return, so it is essential to full remediation.
Check your understanding
- Why is a known-good baseline essential for detecting persistence?
- Name three places to look for persistence indicators on a system.