Security teams detect Boot or Logon Autostart Execution by reviewing persistence points that run programs at startup or user logon. Monitor registry run keys, startup folders, scheduled tasks, services, and login scripts for new or modified entries. Treat unsigned binaries, unusual locations, and changes made outside normal administration windows as suspicious until validated.
What security teams should look for first
Detection starts with the places an operating system and common software use to launch code automatically. That means registry run keys, startup folders, services, scheduled tasks, and logon or boot scripts. The key question is not only whether an entry exists, but whether it was newly created, recently modified, unsigned, or placed where normal administration would not usually put it.
Good detection also depends on baselining. Legitimate startup mechanisms are often noisy in enterprise environments, so teams need a known-good view of common entries by host role, software stack, and administrator change window. Without that baseline, persistence blends into routine automation and becomes hard to separate from expected startup behaviour.
For broader persistence tradecraft, the Persistence Techniques Guide is the most direct internal reference point because it covers run keys, scheduled tasks, services, and related autostart mechanisms together.
How to distinguish malicious autostart from normal administration
Most detections succeed or fail on context. A startup entry may be benign if it matches a signed vendor installer, a known management tool, or a documented deployment process. It becomes much more interesting when the binary is unsigned, launched from an unusual path, references a recently created script, or appears outside a patching, provisioning, or change-control window.
Teams should also compare the autostart entry with the parent artefact it launches. A suspicious registry value or scheduled task is often only the visible pointer, while the real signal is the payload location, the command line, the user context, and whether the target binary changed at the same time. Tracking those relationships helps separate ordinary software behaviour from persistence designed to survive reboot or logon.
Good hunting here is often easier when mapped to common adversary persistence patterns in MITRE ATT&CK Enterprise Matrix, which helps analysts group local findings into a known persistence technique rather than treating each artefact as an isolated event.
Where detections usually fail and how to tighten them
The usual failure mode is incomplete coverage. Teams may monitor registry keys but miss scheduled tasks, services, login scripts, or startup folders, leaving a gap that attackers can use after initial access. Another common gap is weak file telemetry, which makes it hard to see whether the launched binary, script, or shortcut was replaced after the autostart entry was created.
Detection is stronger when it combines configuration monitoring with execution telemetry. Changes to autostart locations should be correlated with process creation, service creation, task registration, and script execution so the team can see both the persistence mechanism and the resulting launch event. That combination is more reliable than any single indicator on its own.
For the wider detection and incident-handling workflow around this kind of activity, SANS Security Resources is a useful practitioner reference for detection engineering and SOC operations.
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 CSF 2.0 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 | Directly covers the persistence technique this question asks teams to detect. |
| Recommendation — Map startup changes to T1547 and alert on new or modified autostart entries. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Activities | Detecting unauthorized autostart changes depends on continuous monitoring of host activity. |
| Recommendation — Monitor host persistence points continuously and flag unauthorized modifications. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Log review and alerting are central to spotting persistence changes and their execution. |
| Recommendation — Collect and review logs for service, task, script, and registry changes linked to startup execution. | ||
Practitioner Guidance
What to prioritise: Focus first on autostart locations that are both high-value and commonly abused, especially services, scheduled tasks, and logon scripts. Those areas usually provide the fastest signal when an attacker wants reboot persistence or user-session persistence.
What to verify: Confirm the launcher, the target binary, the signer, the path, and the change time before you decide an entry is benign. If the autostart object points to an unexpected location or an unsigned payload, treat it as suspicious until the source of the change is proven.
What good looks like: Your tooling should show a baseline of expected startup entries, alert on new or modified entries, and preserve enough context to tell whether the launch was tied to an approved change or to unexplained persistence activity.
Practitioner takeaway: The most useful detection is not “something starts at boot,” but “something started at boot that should not have been there, or should not have changed when it did.”