Detect it by reviewing logon persistence points for new or changed autorun entries, scheduled tasks, startup shortcuts, and registry-based launch locations. Correlate these changes with recent process creation, file writes, and user context. Legitimate software updates usually change known paths or signed binaries; unknown executables, unusual locations, or commands that launch from user-writable directories need investigation.
What security teams should look for first
Start with the places software most commonly persists across user sessions: autorun entries, scheduled tasks, startup shortcuts, and registry-based launch locations. Those are the highest-signal logon persistence points because they show what will execute automatically after authentication, even if the original installer or dropper is gone.
Detection works best when you treat logon persistence as a change problem, not just an endpoint problem. A new entry may be benign if it matches a known deployment path, a signed updater, or an approved management tool, but it becomes much more interesting when it appears in an unusual location or points to a user-writable directory.
For a broader map of these mechanisms, the Persistence Techniques Guide covers the common boot and logon autostart methods that defenders usually need to enumerate together rather than in isolation.
How to correlate persistence with surrounding activity
Persistence entries are most useful when paired with nearby telemetry that explains how they arrived there. Correlate the change with recent process creation, file writes, and the user context that made the modification, because many legitimate software installs and maintenance tools create logon items only as part of a documented change window.
That correlation helps separate installer activity from suspicious staging. A process that writes a new shortcut, task, or registry value and then exits may be a normal updater, but the same pattern from an unfamiliar parent process, an interactive user session that should not manage software, or a script launched from a temporary location deserves investigation.
If the environment includes managed runtime platforms or remote execution services, the Serverless Security Guide is a useful reminder that execution roles and other delegated permissions often explain why a change was possible in the first place, even when the logon mechanism itself is local.
What usually separates benign startup behavior from suspicious logon execution
Benign changes tend to preserve operational continuity: they reuse known install paths, signed binaries, and normal vendor update locations. Suspicious changes often do the opposite, by introducing unknown executables, odd command lines, or launch targets in user-writable directories such as profile folders, temp paths, download locations, or other places users can modify without administrative control.
Registry and shortcut modifications are especially worth reviewing when they point to renamed binaries, encoded commands, or scripts that chain into other interpreters. Those patterns matter because logon persistence is often less about the entry itself than about what it launches next, and that is where defenders usually find the real payload.
The surrounding control environment also matters. The Security Policy Framework Guide helps teams align who is allowed to create or approve persistence-affecting changes, so detection can be judged against an actual baseline instead of ad hoc judgement.
Risk and Threat Considerations
Logon persistence is valuable to attackers because it turns a one-time foothold into repeatable execution. If malicious software can survive reboots or user logons, defenders may lose the chance to contain it with a simple process kill, and every login becomes an opportunity to re-launch payloads, re-establish access, or load follow-on tooling.
Failure mechanism: An attacker or unauthorized installer places a launch point in a startup location, then uses that location to re-execute code each time the user signs in. The failure is usually weak monitoring of autorun surfaces combined with insufficient review of who changed them and why.
Impact: The result can be durable persistence, repeated credential theft, continued lateral movement, and slower containment because the malicious software appears to “come back” after cleanup unless the underlying autorun entry is removed.
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 SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547 — Boot or Logon Autostart Execution | Covers logon persistence mechanisms directly. |
| Recommendation — Map autorun findings to T1547 and hunt for launch-point creation in endpoint telemetry. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Supports detection of suspicious startup changes through logged process and file activity. |
| Recommendation — Centralize and review process, file, and configuration logs for new autostart entries. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Restricts unnecessary software and launch paths that can become logon persistence. |
| CM-5 — Access Restrictions for Change | Controls who can modify registry, shortcut, and task-based launch locations. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Requires reviewing event data that correlates persistence changes with parent process and user context. | |
| Recommendation — Limit approved startup mechanisms to the minimum needed for business operations. Restrict who can change persistence locations and review exceptions promptly. Correlate autorun changes with process, file, and user activity in audit review. | ||
Practitioner Guidance
What to verify: Confirm whether each new or changed logon entry matches a known deployment, an approved updater, or a documented administrative action. If the entry cannot be tied to a change record, treat the binary path, command line, and parent process as part of the incident, not as incidental details.
Decision rule: If the autorun target is unknown, unsigned, or launched from a user-writable path, prioritize containment and removal of the persistence mechanism before spending time proving payload intent. A clean host with an active logon trigger is still a live risk.
What practitioners underestimate: Startup shortcuts and registry launch points often look low severity compared with services or drivers, but they are frequently enough to restore execution after every logon. The practical question is not whether the software is visible, it is whether it can keep coming back.
Practitioner takeaway: The best detection strategy is to pair persistence-point review with file and process context, so you can distinguish normal software lifecycle changes from code that is trying to survive the next logon.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org