T1037.003: Network Logon Script
Adversaries may use network logon scripts automatically executed at logon initialization to establish persistence. Network logon scripts can be assigned using Active Directory or Group Policy Objects.[1] These logon scripts run with the privileges of the user they are assigned to. Depending on the systems within the network, initializing one of these scripts could apply to more than one or potentially all systems. Adversaries may use these scripts to maintain persistence on a network. Depending on the access configuration of the logon scripts, either local credentials or an administrator account may be necessary.
Analyst context for executives and security teams
Network logon scripts matter because a single centrally assigned Windows logon script can run automatically for many users or systems. If an adversary can alter or add one, persistence may occur broadly at user logon and under the assigned user’s privileges, turning an identity or directory-control weakness into an enterprise-wide resilience issue.
Executive priority
Treat this as an Active Directory and Group Policy governance risk, not just an endpoint scripting issue. Leaders should ask who can modify network logon scripts, how changes are approved and evidenced, and whether SOC/IR teams can quickly identify affected users and systems if a script is abused. This is especially relevant for persistence, privilege-escalation investigation, audit readiness, and prioritizing least-privilege controls around shared script locations.
Technical view
For Windows environments, validate control and monitoring around logon scripts assigned through Active Directory or Group Policy Objects. Because ATT&CK provides no native detection text for this sub-technique, use the related detection strategy context: DET0367 detects Network Logon Script abuse through multi-event correlation on Windows. SOC teams should correlate directory/GPO assignment changes, script file modifications, permission changes, and logon-time script execution patterns rather than relying on a single event type.
Likely telemetry
- Active Directory changes related to user logon script attributes or policy assignment
- Group Policy Object creation, modification, linking, and delegation changes
- File and directory permission changes on locations used to store network logon scripts
- File write, rename, or content-change events for logon script files
- Windows logon/session events for users receiving the script
Detection direction
- Validate that detections cover both the control-plane change and the execution outcome: AD/GPO assignment changes plus script modification plus logon-time execution.
- Tune for authorized administration by comparing changes against approved change windows, expected administrators, and known script repositories.
- Review blind spots where script storage locations are not monitored, GPO changes are not retained, or endpoint script/process telemetry is unavailable at logon.
- Use relationship context from DET0367 as a cue to prefer multi-event correlation over isolated alerts, since legitimate logon scripts are common in managed Windows environments.
Mitigation priorities
- Prioritize M1022: restrict file and directory permissions on logon script storage locations so only necessary administrators or processes can write or modify scripts.
- Apply least privilege to Active Directory and Group Policy administration paths that can assign or change network logon scripts.
- Maintain reviewable change control for logon script content, GPO links, and delegated permissions.
- During incident response, identify the assigned scope of any suspect script because one assignment may affect multiple or potentially all systems depending on configuration.
Analyst notes and limits
This take is based on ATT&CK T1037.003 Network Logon Script, its Windows platform scope, persistence and privilege-escalation tactics, the stated use of Active Directory or Group Policy Objects, and relationships to DET0367 and M1022. The key defensive decision is whether the organization can prove who can change logon scripts and whether telemetry can connect a directory or file change to logon-time execution.
The ATT&CK object does not provide official detection text, procedure examples, or environment-specific storage paths. Local validation is required to determine where logon scripts are stored, who can modify them, what GPO or AD attributes are used, and what telemetry is actually collected.
Network Logon Script
Adversaries may use network logon scripts automatically executed at logon initialization to establish persistence. Network logon scripts can be assigned using Active Directory or Group Policy Objects.[1] These logon scripts run with the privileges of the user they are assigned to. Depending on the systems within the network, initializing one of these scripts could apply to more than one or potentially all systems. Adversaries may use these scripts to maintain persistence on a network. Depending on the access configuration of the logon scripts, either local credentials or an administrator account may be necessary.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1037 | Boot or Logon Initialization Scripts | This object subtechnique of Boot or Logon Initialization Scripts. |
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 826d2add7d34… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Petri Logon Script AD
Daniel Petri. (2009, January 8). Setting up a Logon Script through Active Directory Users and Computers in Windows Server 2008. Retrieved November 15, 2019.
Open source URL -
[2]
mitre-attack T1037.003Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.