Security teams can detect Windows logon scripts by reviewing where they are configured, then correlating those settings with user logon events and endpoint telemetry. Look for unexpected script changes, new network locations, and execution from unusual accounts or devices. Because logon scripts can be abused for persistence or payload delivery, change control and audit trails matter.
Where Windows logon scripts are easiest to spot
Start with the places Windows stores logon script configuration, then confirm which accounts, groups, or policies point to those paths. In practice, the most useful question is not just “is there a script,” but “who can change it, where does it live, and is it consistent with the approved logon path?” That distinction helps separate routine administration from hidden persistence.
Logon scripts are often discovered through policy objects, profile settings, and other startup-related configuration that executes when a user signs in. Because those settings can be inherited, redirected, or overwritten, security teams should compare the configured script location against the baseline for the workstation, user, and domain segment rather than trusting a single host view. The Persistence Techniques Guide is useful here because it groups logon scripts with other boot and logon autostart paths that attackers abuse for persistence.
When reviewing scope, look for scripts that resolve to remote shares, unusual folders, or paths that do not match the normal administrative pattern. A script in a standard location is not automatically safe, and a script in an unexpected location is not automatically malicious, but the mismatch is what creates an investigation lead. The main value is to establish whether the configured path, owner, and change history make sense together.
How to correlate configuration with real logon activity
Configuration alone rarely proves execution, so the next step is to correlate the script settings with user logon events and endpoint telemetry. That means tying a specific logon time, user, device, and session type to the script execution trail, then checking whether the endpoint ever launched the expected interpreter or child process. The Windows Event Log Guide is a practical reference for pairing logon events, process creation, task changes, and other audit records into a timeline.
Good correlation work also looks for secondary indicators: network access to a script share, file modification near the logon window, and repeated execution across multiple hosts. If the same script appears only on one machine, or if it runs from an account that normally does not log on interactively, that is often more interesting than the script content itself. Endpoint telemetry helps answer whether the script is present, launched, modified, or merely referenced.
Analysts should also separate expected enterprise behavior from abuse. Many environments use logon scripts for drive mapping, printer setup, and environment initialization. Detection gets stronger when the script is new, recently changed, delivered from an unusual source, or tied to a user or device outside the normal administration pattern.
What makes logon scripts a useful persistence signal
Logon scripts matter because they run at a predictable point in the user lifecycle, which makes them attractive for persistence and payload delivery. If an attacker can change a script or point policy to a malicious location, they can trigger code on every affected logon without needing a new exploit each time. That is why change control, audit trails, and ownership evidence are part of detection, not just governance overhead.
A useful detection program treats unexpected logon script use as a change in execution authority. The same script mechanism that helps standardise desktop setup can also move commands, staged payloads, or follow-on access into the user session. On Windows systems, pairing that behaviour with hardening baselines and tighter endpoint controls improves confidence that the script is legitimate rather than quietly introduced through misconfiguration or compromise. The Windows Endpoint Hardening Guide helps anchor those checks in the broader Windows control set.
Detection is strongest when teams combine content review with change review. A script that suddenly references a new network location, downloads additional content, or executes under a different account deserves more scrutiny than a longstanding script that only maps resources. The operational lesson is simple: logon scripts are not just configuration objects, they are execution paths.
Risk and Threat Considerations
Logon scripts can be abused because they sit on a trusted execution path that runs automatically during sign-in. If an attacker can modify the script, the backing share, or the policy that points to it, they gain a low-friction way to persist, stage payloads, or execute commands across multiple user sessions.
Failure mechanism: Weak change control, excessive write access, or poor visibility into script locations lets a malicious change blend into routine administration, so the script executes as part of normal logon behaviour.
Impact: The result can be repeated code execution at every user sign-in, broader lateral movement opportunities, and a longer window before defenders notice that a trusted startup path has been repurposed.
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 | T1037.001 — Logon Autostart Execution: Logon Script (Windows) | Logon scripts are a Windows persistence path directly mapped to ATT&CK. |
| Recommendation — Map logon-script activity to T1037.001 and hunt for persistence plus execution from sign-in events. | ||
| CIS Controls v8 | CIS-5 — Account Management | User and admin account control affects who can alter or abuse logon scripts. |
| Recommendation — Review script-write access and remove unnecessary administrative rights to the script path. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Detection depends on audit events that capture logons, script changes, and process execution. |
| AC-6 — Least Privilege | Excessive write access to script locations enables persistence and abuse. | |
| Recommendation — Enable log and audit coverage for logon events, script changes, and related process creation. Restrict write access to logon-script locations to the smallest administrative set. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Logon scripts are configuration assets whose changes need controlled review. |
| Recommendation — Control changes to logon-script locations and contents through approved configuration management. | ||
Practitioner Guidance
What to verify: Confirm the configured script path, the owning account, and the last change source before you trust a logon script as benign. If any one of those three does not line up with the environment baseline, treat it as a validation problem first, not as an accepted exception.
What to measure: Track how often logon script changes occur, how many are tied to approved change records, and how many resolve to remote or user-writable locations. The best signal is not volume alone, but the proportion of script changes that are explainable from change management.
Decision rule: If the script is unexpected or newly modified, prioritise provenance and execution correlation before content review. If the script is expected but running from an unusual device or account, investigate the execution context first, because that is often where compromise shows up.
Practitioner takeaway: Logon script detection works best when teams treat script configuration, execution, and change history as one evidence chain, not as separate checks.