AN0311: Analytic 0311
Monitoring modification and execution of user or system logon scripts such as in registry Run keys or startup folders.
Analyst context for executives and security teams
This analytic focuses on watching for changes to and execution of Windows logon scripts, including locations such as registry Run keys and startup folders. For leaders, the practical value is persistence visibility: if an unauthorized script is added to a logon path, activity can recur every time a user or system signs in, complicating containment and recovery.
Executive priority
Prioritize this as a Windows endpoint and incident response readiness issue. Security leaders should ask whether SOC teams can prove they collect and retain evidence of logon-script modification and execution, whether changes to autorun locations are reviewed, and whether incident responders can quickly distinguish approved administrative logon automation from suspicious persistence. This also supports audit and compliance evidence around endpoint change monitoring and control validation.
Technical view
For Windows environments, validate monitoring around user and system logon script locations, specifically registry Run keys and startup folders as named in the ATT&CK description. Because no official detection logic is provided, detection engineering should define local baselines for expected logon scripts, approved administrative tools, and normal software installer behavior, then alert on unexpected creation, modification, or execution in those paths. IR teams should be prepared to correlate file changes, registry changes, process execution, user context, and sign-in timing.
Likely telemetry
- Windows registry modification events for Run key locations
- File creation and modification events for startup folders and logon script paths
- Process execution telemetry for scripts or binaries launched from logon locations
- User or system logon events to correlate execution timing
- Endpoint security alerts or audit logs showing autorun or startup item changes
Detection direction
- Confirm telemetry exists for both modification and execution, not just one side of the behavior.
- Baseline approved enterprise logon scripts, software updater entries, and administrative automation to reduce false positives.
- Tune for newly created or recently modified startup items that execute at or shortly after logon.
- Correlate registry or startup-folder changes with the responsible user, process, host, and subsequent execution.
- Review blind spots on unmanaged Windows endpoints, endpoints with limited registry auditing, and systems where startup-folder file monitoring is not collected.
Mitigation priorities
- Maintain an inventory of approved Windows logon scripts and autorun entries.
- Limit who can modify system-wide logon script locations and startup paths.
- Use endpoint configuration and change-control processes to review additions to registry Run keys and startup folders.
- Ensure incident response playbooks include validation and cleanup of logon persistence locations.
- Retain sufficient endpoint telemetry to support post-incident scoping across affected Windows systems.
Analyst notes and limits
This object is a MITRE detection analytic, not a technique description. It provides a concise behavior statement but no official detection logic, tactics, relationships, aliases, or labels. The Glexia take therefore emphasizes validation questions and telemetry classes rather than a specific rule.
The supplied ATT&CK fields only support Windows as the platform and only identify monitoring of logon script modification and execution, including registry Run keys and startup folders. No relationship context, adversary usage, impact, prevalence, or guaranteed detection method was supplied; local environment baselines are required.
Analytic 0311
Monitoring modification and execution of user or system logon scripts such as in registry Run keys or startup folders.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | da14f73f4362… |
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]
mitre-attack AN0311Open 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.