Detecting Persistence: A Blue-Team Hunting Guide

An intrusion is rarely a single moment. After an adversary gains a foothold, their first priority is to make sure they can return even if the machine reboots, the password changes, or the original entry point is closed. That capability is called persistence, and hunting for it is one of the highest-value activities a blue team performs. This guide takes a defensive stance: we describe the categories of persistence so you can recognize their traces, focus on the telemetry, Event IDs, and hunting workflows that reveal them, and finish with hardening. The aim is to teach detection and eradication, not to hand anyone a recipe for staying hidden. If you can find persistence reliably, you turn a lingering compromise into a contained incident.

What persistence is and why it matters#

Persistence is any mechanism that lets an adversary maintain access to a system across interruptions such as reboots, logoffs, or credential resets. In the MITRE ATT&CK framework it is tactic TA0003, and it sits at the heart of why intrusions become long-lived. The uncomfortable truth for defenders is that eradication fails whenever persistence is missed: you can remove the malware, rotate a password, and rebuild a service, but if the attacker left a scheduled task, a rogue account, or a modified startup entry, they simply walk back in. This is why incident response always includes a deliberate persistence hunt before a system is declared clean. Finding the initial payload is not the finish line; finding every foothold is.

The persistence mindset for defenders#

Effective hunting starts from a simple premise: an attacker who wants to survive a reboot must leave something behind that the operating system will execute automatically. That constraint is your advantage, because the set of places the OS looks for things to run is finite and well documented. Rather than chasing infinite possibilities, you enumerate the known autostart locations and ask, for each, whether what lives there is expected. The discipline is baselining: knowing what normal looks like so anomalies stand out. A scheduled task created at three in the morning by a user who never scripts, a service pointing at a binary in a temp folder, or a new local admin account are not subtle once you have a baseline to compare against.

Where persistence hides on Windows#

On Windows, defenders should routinely review a well-known set of autostart extensibility points. These include the Run and RunOnce registry keys, scheduled tasks, Windows services, startup folders, WMI event subscriptions, and abuse of legitimate mechanisms such as DLL search order or accessibility features. Account-based persistence matters just as much: newly created local or domain accounts, users added to privileged groups, and modified logon scripts. Tools such as Sysinternals Autoruns are built precisely to enumerate these locations, and pairing that with Sysmon telemetry gives you process creation, registry modification, and image-load visibility. The goal when reviewing each location is not to memorize every technique but to spot the entry that does not belong, then pivot to who created it and when.

Where persistence hides on Linux#

On Linux and Unix systems the autostart surface is different but equally enumerable. Cron jobs and systemd timers and units are common footholds, as are modified shell startup files such as profile and rc scripts, added SSH authorized keys, and new or altered service definitions. Attackers also abuse scheduled tasks that run as root and configuration files loaded at boot. Defensively you review these locations against a known baseline, watch for files with recent modification times that no change ticket explains, and monitor for the addition of SSH keys to accounts. Auditd and endpoint telemetry help by recording process execution and file changes, so that a cron entry appearing outside your deployment pipeline becomes a signal rather than a surprise you find weeks later.

Cloud and identity persistence#

Modern persistence is increasingly identity-based and lives above any single host. In cloud and SaaS environments, attackers seek durable access through new credentials rather than files: a fresh access key on a service principal, an added federation or trust relationship, an OAuth application granted broad delegated permissions, or a hidden mail-forwarding rule. Because these mechanisms are legitimate administrative features, they blend in unless you are watching the audit log. Hunt for newly created keys and app registrations, changes to role trust and federation, and consent grants to unfamiliar applications. The defensive principle mirrors the host world: enumerate the small set of places durable access can be planted, baseline what is expected, and treat any unexplained addition to identity as a potential foothold.

Detection signals and telemetry#

Persistence hunting is only as good as the telemetry underneath it. On Windows, security-relevant Event IDs are invaluable: 4698 records scheduled task creation, 7045 marks new service installation, 4720 shows account creation, and 4732 records a member added to a security-enabled group. Sysmon adds granular process creation, registry, and image-load events that catch techniques the default audit policy misses. On Linux, auditd and shell history provide equivalent visibility, and EDR platforms unify both worlds with behavioral detection. The most powerful signal, though, is comparison against a baseline: alert on the first-seen appearance of an autostart entry, a service pointing at an unusual path, or an account creation outside your provisioning process. Anomaly beats signature when adversaries live off the land.

A practical hunting workflow#

Turn the concepts into a repeatable routine. Begin by enumerating autostart locations across your fleet with tooling that reports registry run keys, scheduled tasks, services, and startup items, or their Linux and cloud equivalents. Next, baseline: diff the current state against a known-good snapshot or against the majority of similar hosts, because outliers are where you look first. Then enrich each candidate by asking who created it, when, from which account, and whether a corresponding change record exists. Correlate with process and authentication logs to build a timeline, and finally validate whether the entry is benign or malicious before acting. Document what you find so the next hunt starts from a better baseline, and feed confirmed patterns back into automated detections.

Mitigation and hardening#

Detection and prevention reinforce each other. Reduce the persistence surface by enforcing least privilege so that few accounts can create services, scheduled tasks, or new users in the first place. Require multi-factor authentication and monitor privileged group membership so account-based footholds are hard to plant and quick to notice. Centralize and protect logs in a location the attacker cannot edit, and enable the audit policies and Sysmon or auditd configuration that make persistence visible. Application allowlisting limits what can execute from autostart at all. In the cloud, constrain who can mint credentials and grant consent, and alert on trust and federation changes. Every control that narrows where durable access can be planted also shrinks the space you must hunt.

Common pitfalls#

Several mistakes let persistence survive. Responders eradicate the obvious payload and declare victory without enumerating autostart locations, so a scheduled task quietly re-establishes the intrusion. Teams hunt on the host but forget identity persistence in the cloud, leaving an access key that outlives the rebuild. Baselines are missing, so a malicious service is indistinguishable from a legitimate one at a glance. Telemetry is not configured, so the very Event IDs that would reveal a new task or account were never being recorded. And investigators find one foothold and stop, not realizing attackers commonly plant several for redundancy. The cure is a systematic hunt that covers hosts and identities, backed by baselines and complete telemetry, and a rule never to declare clean after finding just one.

Blue-team persistence checklist#

Use this as a hunting sequence. 1. Confirm audit policy, Sysmon or auditd, and log centralization are in place before you need them. 2. Enumerate Windows autostart points: run keys, scheduled tasks, services, startup folders, WMI subscriptions. 3. Enumerate Linux equivalents: cron, systemd, shell rc files, SSH keys. 4. Enumerate identity persistence: new keys, app registrations, trust and consent changes. 5. Baseline each against known-good or peer hosts and flag outliers. 6. Enrich with creator, timestamp, and change-record correlation. 7. Build a timeline from Event IDs 4698, 7045, 4720, 4732 and process logs. 8. Assume redundancy: keep hunting after the first find. 9. Remediate, then re-verify. 10. Feed confirmed patterns into automated detections.

FAQ: is finding one persistence mechanism enough to call a host clean?#

No, and assuming so is one of the most costly mistakes in incident response. Adversaries routinely plant multiple persistence mechanisms precisely so that removing one does not lock them out. If you find a malicious scheduled task, treat it as a signal to hunt harder, not as the end of the investigation, and enumerate every other autostart location on the host as well as identity-based persistence in any connected cloud. Build a full timeline of what the attacker did and when, because the persistence you find often points to the account and time window where other footholds were created. Declare a system clean only after a complete enumeration, not after the first hit.

FAQ: what telemetry should I prioritize if I have limited resources?#

If you must start small, prioritize the signals that reveal the most common footholds. On Windows, enable auditing for scheduled task creation, service installation, and account and group changes, which correspond to Event IDs 4698, 7045, 4720, and 4732, and deploy Sysmon for process and registry visibility. On Linux, enable auditd for process execution and monitor cron, systemd, and SSH authorized keys. In the cloud, capture the identity audit log and alert on new credentials and trust changes. Centralize all of this somewhere the attacker cannot alter. With those in place you cover a large fraction of real-world persistence, and you can expand coverage as resources allow.

Conclusion#

Persistence is what turns a brief intrusion into a long one, and hunting it is what turns a long one back into a contained incident. The defender's advantage is structural: the operating system and cloud platforms look for autostart items and durable credentials in a finite, documented set of places, so a disciplined hunt can cover them all. Enable the telemetry first, baseline what normal looks like, enumerate host and identity footholds, correlate creation events into a timeline, and never declare clean after a single find. Pair detection with least privilege and allowlisting so there are fewer places to plant a foothold in the first place. Done consistently, persistence hunting is the step that makes eradication real.