Detect it by monitoring registry writes to autorun locations and comparing changes against approved software and logon persistence baselines. Alert on new or modified values that start programs at sign-in, especially when written by unusual processes or users. Correlate the change with process creation, script activity, and subsequent outbound connections to identify persistence attempts.
How registry run key changes become a persistence signal
registry run keys matter because they are one of the simplest ways to make software start automatically at logon. From a detection perspective, the key question is not only whether a value changed, but whether the change creates a new autorun path, replaces an existing one, or redirects execution to an unexpected binary, script, or command line.
A useful detection model treats registry writes as part of a broader persistence chain. A run key change is more suspicious when it is paired with a process that should not normally edit autoruns, a user context that lacks administrative purpose, or a timestamp that lines up with other staging activity such as script execution, file drops, or new scheduled tasks.
Persistence Techniques Guide is the most direct navigation path for understanding how run keys fit into logon persistence alongside related techniques such as services, scheduled tasks, WMI subscriptions, and startup folders.
What changes security teams should watch for
Monitoring should focus on the specific registry locations that Windows uses for autorun behavior, then compare writes against an approved baseline of known software and expected logon entries. The most valuable detections are usually not raw registry edits by themselves, but new or modified values that point to unfamiliar executables, scripts, shortcuts, or helper components.
Context matters as much as content. A benign software installer can legitimately create a run key, while a short-lived script host, office application, archive utility, or remote management tool writing to an autorun location is more interesting. The detection should preserve the full write context, including the process tree, command line, user, host, and parent-child relationship, so analysts can separate software setup from persistence activity.
Correlating registry change events with nearby process creation and subsequent network activity makes the signal stronger. If a new run key appears and the same host soon starts beaconing outbound, that pattern is often more actionable than a registry alert in isolation.
How to reduce noise and improve confidence
Baseline-driven detection works best when it reflects real workstation and server build patterns, not an abstract default image. Teams should maintain separate baselines for standard endpoints, administrative workstations, service hosts, and development systems, because each population has different expected autoruns and different tolerance for change.
MITRE D3FEND Guide is useful here because it connects registry key creation and modification to defensive techniques such as process lineage analysis, script execution analysis, and outbound traffic filtering. That combination helps turn a noisy registry event into a higher-confidence persistence finding.
It also helps to distinguish write activity from effective persistence. Some changes are transient, partially reverted, or written to non-persistent locations by software installers and update mechanisms. The important question is whether the value survives into a logon condition that actually alters startup behavior.
Risk and Threat Considerations
Run keys are attractive because they provide low-friction persistence with minimal ceremony and often blend into routine software behavior. Attackers use them to survive reboots, resume payload execution at user logon, and maintain access without needing a service install or task scheduler entry.
Failure mechanism: A malicious or abused process writes a new autorun value, or modifies an existing one, so a payload launches automatically at sign-in and inherits the user’s session context.
Impact: The persistence can enable repeated execution, credential theft, follow-on payload delivery, and continued command-and-control communication even after the initial intrusion is noticed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.001 — Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder | Directly covers registry run key persistence being detected. |
| T1059 — Command and Scripting Interpreter | Script-based persistence often accompanies suspicious run key modification. | |
| T1105 — Ingress Tool Transfer | Outbound reach-back after autorun changes helps confirm active persistence use. | |
| Recommendation — Map run key writes to T1547.001 and alert on suspicious logon autoruns. Correlate autorun changes with script execution and parent process lineage. Hunt for outbound connections after registry autorun changes. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Registry persistence detection depends on collecting and reviewing change telemetry. |
| Recommendation — Log registry autorun changes and review them against approved baselines. | ||
| NIST CSF 2.0 | DE.CM-08 — Monitoring for Unauthorized Connections | Correlating autorun changes with outbound traffic improves detection confidence. |
| Recommendation — Correlate persistence alerts with network monitoring for suspicious egress. | ||
Practitioner Guidance
What to verify: Confirm the full chain, not just the registry write. The strongest alert is one where the write target is an autorun location, the writer is unusual for that host, and the resulting command points to an unexpected binary or script path.
Decision rule: If the new value launches at logon and the writer is not part of an approved installer, management tool, or known software update path, treat it as potential persistence until proven otherwise. If the value only changes a benign application setting, keep it lower priority.
What practitioners underestimate: The detection value often comes from correlation, not the registry event alone. Pair the autorun change with process lineage, script telemetry, logon activity, and outbound connections so analysts can decide quickly whether the change is administrative, accidental, or adversarial.
Practitioner takeaway: The goal is to detect persistence intent early, before the new autorun entry becomes a stable foothold, and the best evidence is a suspicious run key write that lines up with executable launch and network reach-back.