Attackers use Run Software at Logon to make a programme or script start automatically when a user signs in, giving persistence and repeated execution. Defenders should inspect logon startup locations, review autorun settings and scheduled sign-in mechanisms, and look for unusual binaries, scripts, or commands tied to specific accounts.
How run-at-logon persistence works
Attackers abuse logon-start mechanisms because they execute automatically when a user signs in, without needing a separate launch step. That gives them repeatable execution, a foothold that survives reboots, and a way to blend malicious activity into normal user login behaviour. In practice, the value is not just persistence, it is reliable re-entry.
Run-at-logon can be implemented through multiple startup locations, so defenders should think in terms of execution points rather than a single registry key or folder. The technique may point to a binary, script, or command line, and it may be scoped to one account or broadly available across a system. The key question is whether the logon event is being used to trigger attacker-controlled code.
Where attackers place the autostart trigger
Common placement choices include autorun entries, startup folders, sign-in scripts, scheduled tasks that fire at logon, and related user profile or shell mechanisms. Attackers often prefer a location that is easy to overlook, difficult to distinguish from legitimate software, or tied to a specific user so the malicious change survives routine admin review.
Some placements are more conspicuous than others, but the threat is similar: a benign-looking setting becomes an execution dependency. When the payload is launched through a familiar logon pathway, defenders may see only an ordinary startup command unless they inspect the full target path, command-line arguments, and the account context that owns the entry. Persistence Techniques Guide covers these autostart patterns, including run keys, scheduled tasks, startup folders, and logon scripts.
What defenders should verify during review
Security teams should validate which logon mechanisms are enabled, which account they run under, and whether the referenced file, script, or command is expected for that user or host. Suspicious cases often involve odd parent paths, unexpected binaries in user-writable locations, encoded or obfuscated commands, or entries that point to tooling unrelated to the user’s role.
It is also important to compare the autostart entry against normal software deployment and administrative workflows. A legitimate startup action usually has a clear owner, change record, and business purpose. An attacker-created entry often lacks provenance, appears after an unrelated event, or is coupled with other persistence clues such as unusual services, scheduled tasks, or modified shell settings. MITRE ATT&CK Enterprise Matrix is useful for mapping those persistence patterns to broader adversary behaviour.
Risk and Threat Considerations
Run-at-logon persistence matters because it turns a routine user sign-in into a guaranteed execution opportunity. If the attacker can alter a logon trigger, they can regain execution after reboot, wait for the next sign-in, and continue operating without re-exploiting the target. That makes the technique attractive for maintaining foothold and extending dwell time.
Failure mechanism: A malicious or tampered startup reference executes at sign-in because the logon mechanism is trusted by default and may not be continuously monitored for change.
Impact: The attacker gains repeated code execution, can restore access after interruption, and may use the persisted entry to launch follow-on activity such as discovery, credential theft, or lateral movement.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.001 — Registry Run Keys / Startup Folder | Run-at-logon persistence is an ATT&CK persistence pattern. |
| T1053.005 — Scheduled Task/Job: Scheduled Task | Logon-triggered tasks are a common autostart mechanism. | |
| T1037 — Boot or Logon Autostart Execution | Directly covers attacker use of autostart at user logon. | |
| Recommendation — Monitor and hunt for logon autostart entries that launch unapproved code. Review logon-triggered scheduled tasks for unexpected commands and ownership. Inspect boot and logon autostart points for persistence and hidden execution. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Startup locations are configuration points that need hardening and review. |
| CIS-8 — Audit Log Management | Detection depends on reviewing changes to logon persistence mechanisms. | |
| Recommendation — Harden and audit startup locations to reduce unauthorized logon execution. Log and review changes to autostart locations and scheduled logon actions. | ||
Practitioner Guidance
What to verify: Confirm the exact startup location, the owning account, and the referenced file path before deciding whether the entry is benign. If the command launches from a user-writable path, references an unusual script type, or is not tied to approved software, treat it as suspicious until validated.
Decision rule: If the logon trigger is unnecessary for the application’s function, remove it and replace it with a controlled deployment or service model. If the startup action is required, constrain it to the minimum account context and document why that logon-based execution is needed.
Practitioner takeaway: The practical test is not whether something starts at logon, it is whether that autostart path is expected, attributable, and difficult for an attacker to abuse without being noticed.