Attackers use boot or logon autostart execution to make malware run automatically when a system starts or a user signs in. That gives persistence without repeated manual launch. Defenders should review startup entries, scheduled launch points and login scripts, and alert on new or modified autostart mechanisms tied to untrusted code.
How boot or logon autostart execution works as a persistence method
Attackers abuse boot or logon autostart execution because it is a built-in trust boundary: the operating system and user session are supposed to launch approved components automatically. When malware is placed into one of those launch paths, it runs every time the machine starts or the user signs in, which makes persistence reliable and low-effort for the attacker.
The tactic is broader than one registry value or one startup folder. It covers multiple launch points, including logon scripts, scheduled startup actions, services, shell extensions, autorun locations and other mechanisms that the platform processes early in boot or during interactive sign-in. A defender has to think in terms of execution flow, not just a single file path.
That is why a good investigation starts with the normal startup and logon chain for the operating system in use. On Windows, for example, the most important question is not simply whether a file exists, but whether a trusted launch point now points to untrusted code, an unexpected script, or a modified binary. On Unix-like systems, the same logic applies to shell profiles, login hooks, systemd units, launch agents or other session initialization points.
For a broader view of how persistence techniques are used and how they are detected, Persistence Techniques Guide covers the launch points defenders most often need to inspect.
Why attackers prefer autostart over one-time execution
Boot and logon autostart execution is attractive because it survives reboots, user logoff, and many routine cleanup actions. It also blends in with legitimate administration behavior: startup entries, logon scripts and services are normal in many environments, so a malicious addition can look like routine configuration unless teams track change carefully.
Attackers also like these mechanisms because they can be tailored to the context they already control. A local user session may be enough for a logon script or profile modification, while system-level access can support service changes, boot-time launches or other privileged persistence points. The exact technique depends on what the attacker has already compromised and what they need to preserve.
That persistence value is why defenders should treat any new autostart mechanism as a meaningful security event, especially when it references unsigned code, uncommon parent processes, or paths outside managed software locations. The key issue is not just that something starts automatically, but that it does so with trust inherited from the platform.
What defenders should verify first when they suspect abuse
First verify whether the autostart entry is expected, managed and change-controlled. Then confirm the executable, script or command line it launches, because attackers often hide in a wrapper script, a renamed binary or a legitimate launch point that now points elsewhere. Review both the launch object and the target it invokes.
Next compare the current configuration to a known-good baseline. If the change is recent, determine whether it was created through a normal deployment path or by an account that should not be able to modify that autostart mechanism. Review adjacent artifacts such as scheduled tasks, service definitions, registry run keys, startup folders and login scripts, because attackers often plant persistence in more than one place.
Finally, look for evidence that the mechanism has already been used. A boot or logon persistence point is often only one stage in a larger intrusion, so defenders should correlate it with parent process history, newly created files, unusual outbound connections and other signs of prior execution.
Risk and Threat Considerations
Autostart abuse is risky because it turns a single foothold into repeatable execution. If the launch point is privileged or broadly trusted, the attacker gains a durable way to re-enter the environment and may use it to maintain access even after the original payload is removed.
Failure mechanism: The attacker modifies a trusted startup or logon path so the system repeatedly launches malicious code before normal users notice the change, which can hide persistence behind routine boot or sign-in activity.
Impact: This can lead to recurring compromise, continued credential theft, lateral movement and slower incident recovery because the environment keeps re-invoking the malicious code until the underlying launch point is found and 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 surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547 — Boot or Logon Autostart Execution | Directly maps to boot/logon persistence techniques in this question. |
| Recommendation — Hunt for new or modified autostart entries and correlate them with suspicious execution at boot or logon. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Autostart abuse is a configuration integrity issue on endpoints and servers. |
| Recommendation — Baseline and monitor startup, logon and service configurations for unauthorized changes. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | The issue centers on enforcing and monitoring approved startup and logon configuration. |
| AU-6 — Audit Review, Analysis, and Reporting | Detection depends on reviewing logs and correlated changes to autostart mechanisms. | |
| Recommendation — Define and enforce approved autostart settings, then alert on deviations. Correlate audit data with autostart changes to identify suspicious persistence activity. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Startup and logon persistence relies on controlled configuration changes. |
| Recommendation — Control and review autostart-related configuration changes through formal change management. | ||
Practitioner Guidance
What to verify: Treat every autostart finding as a configuration and execution-flow problem, not just a file-check problem. Verify who changed the entry, what process created it, and whether the target binary or script matches the intended software version and path.
What practitioners underestimate: The persistence mechanism is often more important than the payload itself. If the attacker controls the launch point, replacing the malware file alone may not stop re-execution, because the system will simply relaunch the next payload or restored copy.
Practitioner takeaway: The fastest way to miss boot or logon persistence is to search only for obvious malware files; the safer approach is to validate every automatic launch path against a baseline and remove the attacker’s control of the launch mechanism, not just the code it starts.