Logon Script (Windows) is a script that runs when a user signs in and can map drives, set environment variables or launch applications. Attackers abuse it for persistence and credential theft, while defenders may overlook it during reviews. Check script locations, permissions, execution paths and changes to sign-in behaviour.
How Windows logon scripts work
A windows logon script is part of the sign-in workflow, so it runs with the user’s session context at a point when trust is often high and review is infrequent. That makes it useful for automation, but also attractive to anyone who wants code to execute predictably during login.
Administratively, these scripts are usually used to standardise the user experience, such as drive mapping, environment setup, printer connections, or launching approved tools. Because they are tied to sign-in behaviour rather than interactive execution, they can be overlooked if organisations focus only on obvious startup folders or scheduled tasks.
Why attackers abuse logon scripts
Logon scripts are a persistence mechanism because they offer repeatable execution every time the target user signs in. They are also a convenient place to stage credential theft, path manipulation, or follow-on payload launch, especially when defenders do not review the script source, the hosting location, or the execution path.
The technique is especially effective when an attacker can modify an existing script, replace a referenced file, or point sign-in behaviour at a malicious location. NHIMG’s Persistence Techniques Guide is useful here because it situates logon scripts among other Windows autostart methods that adversaries commonly chain together.
What to verify in exposure reviews
Exposure checks should start with inventory: which logon scripts exist, where they are stored, how they are referenced, and which accounts or groups are assigned to them. Review who can edit the script, who can change the referenced path, and whether the script is loaded from a share, local policy, profile location, or another mechanism that may be easier to tamper with.
It is equally important to check for drift in sign-in behaviour. Unexpected drive mappings, new environment variables, altered startup applications, or a script that suddenly calls out to unusual binaries can be an early indicator that the login path has been abused.
For broader detection coverage, compare observed login-time execution with established attacker tradecraft in MITRE ATT&CK Enterprise Matrix, which helps map sign-in execution to persistence and credential-access patterns.
Defensive controls and response actions
Protect logon scripts with tight permissions, version control, and change approval so that edits are visible and attributable. Script content should be reviewed for hardcoded secrets, unsafe network calls, suspicious child processes, and paths that can be redirected through writable locations or search-order tricks.
If compromise is suspected, remove malicious references, validate the current script content against a known-good baseline, and review whether the login path was used to collect credentials or launch additional payloads. On Windows-heavy environments, the control intent aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, auditing, configuration management, and system integrity.
Risk and Threat Considerations
Logon scripts matter because they run inside a trusted user workflow, where malicious changes can persist quietly and execute before the user notices anything unusual. The main security problem is not the script itself, but the combination of predictable execution, weak change visibility, and the opportunity to abuse sign-in trust.
Failure mechanism: An attacker who gains write access to the script, its referenced path, or the surrounding configuration can turn routine sign-in execution into a persistence and credential-theft channel.
Impact: The result can be repeated code execution at login, theft of credentials or session material, and faster lateral movement if the script is used as an initial foothold or follow-on launcher.
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 SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1037 — Boot or Logon Autostart Execution | Logon scripts are a logon-time persistence mechanism. |
| Recommendation — Map sign-in execution to T1037 and hunt for unauthorized autostart changes. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Script modification and execution depend on enforceable access boundaries. |
| AU-2 — Event Logging | Login-time script changes and execution require traceable audit records. | |
| CM-3 — Configuration Change Control | Script paths and contents are configuration items that need controlled change. | |
| Recommendation — Restrict who can edit or reference logon scripts with enforced access rules. Log script changes and sign-in execution to support review and investigations. Require approved change control for logon script content and references. | ||
Practitioner Guidance
What to watch for: Treat logon script ownership as a governance issue, not a one-time configuration task. The practical question is whether the script still matches intended business use and whether any account with write access could silently convert it into an execution path.
Practitioner takeaway: If a logon script is hard to inventory, hard to attribute, or easy to modify, it is already a control weakness.
Related resources from NHI Mgmt Group
- Who is accountable when a GPO logon script is modified without approval?
- How should security teams improve Windows logon auditing when native Event Viewer is too manual for compliance and forensics?
- Why does Windows logon auditing create so much operational risk in on-prem and hybrid Active Directory environments?
- What are the signs that Windows logon auditing is failing to support auditors and investigators?