Security teams detect registry run keys and startup folder abuse by monitoring persistence locations for new or modified entries that launch binaries, scripts or shortcuts at logon. Review autorun changes, compare against approved software, and inspect parent-child process chains after user sign-in. Pay attention to paths pointing to temporary, user-writable or obscured locations.
How persistence abuse shows up in host telemetry
registry run keys and startup folder abuse is a persistence problem: the attacker is trying to make code launch automatically at logon, so detection should focus on change events in those startup locations rather than waiting for a visible payload. The most useful signal is not just that a path exists, but that it was newly created, modified, or pointed at an unusual binary, script, or shortcut after a sign-in event.
That makes the detection problem partly behavioral. A legitimate autorun entry usually follows an approved software pattern, consistent pathing, and an expected publisher or owner, while abuse often introduces a new launch point in a writable user area, a temp directory, or an obscured location that does not fit the host’s normal startup profile.
Inspecting the parent-child chain after user sign-in helps separate routine application startup from persistence activation. If a logon event is immediately followed by an unexpected process tree, especially one that originates from an autorun entry or a shortcut in a startup folder, you have a stronger indicator that the startup mechanism is being used as a launch vehicle.
What to monitor in registry and startup path detection
Detection works best when you monitor both the persistence location and the artifact it launches. For registry run keys, that means alerting on new values, changed command lines, renamed binaries, added arguments, and path changes that introduce user-writable or temporary locations. For startup folders, it means watching for new shortcuts, renamed links, and altered targets that silently redirect execution.
Good baselining matters because startup abuse often hides in volume. Compare current entries against an approved software inventory, then focus on outliers: unsigned or unfamiliar executables, script interpreters started from user space, and commands that reference hidden directories, unusual extensions, or encoded arguments. When an entry looks valid but its target does not, treat the target as the suspicious object, not just the registry value or shortcut itself.
The most reliable teams tie persistence monitoring to endpoint telemetry that can correlate file creation, registry modification, and process start events. That lets you see the full chain, from the change to the first execution, rather than only the final process. It also makes it easier to distinguish a one-time installer from a persistence mechanism that will keep reappearing at every logon.
How analysts confirm abuse and reduce false positives
Confirmation depends on context. A single autorun entry is not enough; you want to know who created it, when it appeared, what it launches, and whether that launch path aligns with expected software behavior. If the entry was created shortly before first use and the executable lives in a user-writable path, that combination is much more concerning than a long-standing startup item from a known application vendor.
Analysts should also check whether the same artifact appears across multiple hosts or only on one endpoint. Repeated use of the same startup path, shortcut name, or command structure can indicate a pattern of persistence tradecraft, while a one-off change may be administrative or application-driven. The key is to validate the change against software ownership, deployment history, and the host’s normal baseline before deciding whether it is malicious.
For deeper hunting, look at adjacent indicators such as recent downloads, script execution, suspicious file drops, and follow-on network activity after logon. Startup abuse often works as an activation stage, so the autorun entry is only part of the story. If the launched process immediately reaches out to external infrastructure, injects into another process, or creates more persistence, the startup location was likely used to reestablish access.
Risk and Threat Considerations
Registry run keys and startup folders are attractive because they survive reboot and blend into normal user activity, which makes them a low-friction persistence path for intruders. The main risk is not just initial execution, but durable re-entry after cleanup, especially when the startup target lives in a path that users or malware can modify without admin approval.
Failure mechanism: An attacker plants or alters an autorun entry so the system launches malicious code at every sign-in, often from a writable directory or a disguised shortcut that looks routine to casual review.
Impact: The compromise becomes sticky, enabling repeated execution, credential theft, staging for lateral movement, and faster re-compromise if the original malware is removed but the persistence point remains.
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 NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547 — Boot or Logon Autostart Execution | Registry run keys and startup folders are classic boot/logon persistence mechanisms. |
| Recommendation — Map autorun changes to T1547 and hunt for persistence activation after logon. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Detecting autorun abuse depends on reviewing correlated host audit events and change activity. |
| CM-7 — Least Functionality | Reducing unnecessary autorun surfaces lowers the chance of persistence abuse. | |
| Recommendation — Correlate registry, file, and process events to surface suspicious persistence changes. Limit unnecessary autorun locations and approved startup entries to reduce persistence exposure. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Startup abuse detection relies on centralized logging of endpoint change and execution events. |
| Recommendation — Collect endpoint logs that record registry edits, file drops, and logon-triggered process starts. | ||
Practitioner Guidance
What to verify: Validate every new or changed autorun entry against an approved software baseline, then confirm the target file’s path, signer, and creation time. If the launch point references a user-writable or temporary location, treat it as higher priority even when the surrounding entry looks ordinary.
Decision rule: If the persistence entry is new and the launched binary, script, or shortcut is not tied to a known install or update process, escalate to containment and hunt for first execution, not just the registry or folder change. If it is tied to legitimate software, document the owner and keep monitoring for target-path drift.
Practitioner takeaway: The strongest signal is the combination of startup-location change plus suspicious target path plus post-logon execution, because that sequence shows persistence being used as an active launch mechanism, not just an inert configuration artifact.
Related resources from NHI Mgmt Group
- Guide: Persistence Techniques Guide
- How can security teams detect Windows Registry Run Keys?
- Why is the abuse of NHIs a priority for security teams?
- How should security teams detect cloud account abuse when attackers use valid AWS access keys to create persistence?
- How should security teams detect SNS abuse when long-lived AWS access keys are exposed?