Security teams detect Network Logon Script abuse by reviewing logon-related script execution and changes to policy or profile-based script settings. Alert on newly added scripts, modified script paths, and scripts launched from network locations or user-writable directories. Compare the script contents and execution pattern with approved logon behaviour, especially where persistence or credential theft is suspected.
What network logon script detection should look for
Security teams should treat network logon script as a persistence and execution signal, not just a convenience feature. Detection works best when you baseline approved script locations, expected users, and normal script contents, then alert on new or changed scripts, unusual script paths, and execution from user-writable or network locations. Compare the script with the normal logon workflow before deciding whether it is legitimate.
Because logon scripts often run early in the session, they can be used to quietly stage access, launch payloads, or redirect authentication activity. That makes change visibility important: a path update, a renamed script, or a policy modification can be more important than the script itself. The strongest detections correlate script changes with the account, host, and time of logon so you can separate routine administration from abuse.
For a broader map of persistence techniques that includes logon script abuse, Persistence Techniques Guide is the most relevant internal reference because it places logon scripts alongside the other autostart paths attackers commonly use.
How analysts separate routine logon automation from malicious use
Legitimate logon scripts usually change slowly, live in known management paths, and follow a repeatable execution pattern. Malicious use is more likely when the script appears in an unexpected profile, pulls content from a network share that should not be involved, or introduces commands that do not match the user role or endpoint function. A good review asks whether the script is required for user productivity or whether it is simply a vehicle for persistence.
Content inspection matters because the same mechanism can be used for very different ends. A benign script may map drives, configure printers, or set environment variables. A suspicious one may download payloads, invoke interpreters, stage credentials, or chain into another persistence method. That is why detection should include the script body, not just the presence of a script path.
Execution context also matters. A script launched from a location that ordinary users can modify, or one that suddenly appears after a policy change, deserves immediate triage. Review whether the change coincides with new administrator activity, an endpoint alert, or evidence of lateral movement.
For defenders who want the attack-path view rather than just the endpoint symptom, MITRE ATT&CK Enterprise Matrix helps place logon script abuse in the wider persistence and credential-access pattern. The same alert can then be tested against other techniques that often appear in the same intrusion.
For teams that need a control-oriented lens on script exposure, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful anchor for monitoring, configuration control, and least-privilege enforcement around script execution paths.
What to verify before you call it abuse
Before escalating, verify where the script came from, who changed it, and whether the change was authorised through normal administration. Confirm whether the same script is present across multiple hosts or only on the affected system, because a single-host deviation is more suspicious. If the script points to a network path, validate that the share is controlled and that no one outside the expected admin group can alter it.
Also verify whether the script executed during prior logons, not just the latest one. A script that has been abused for persistence may have been in place long enough to create follow-on activity, so review adjacent indicators such as new autoruns, unexpected child processes, and authentication anomalies.
For logon-script abuse that extends across Windows and other startup mechanisms, the Persistence Techniques Guide is useful again because it helps you distinguish a true logon-script issue from a broader autostart compromise.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.001 — Registry Run Keys / Startup Folder | Logon scripts are a persistence mechanism that should be mapped to autostart abuse patterns. |
| Recommendation — Map suspicious logon-script activity to persistence detections and hunt for accompanying follow-on execution. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Detection depends on knowing the approved script baseline and spotting unauthorised changes. |
| AU-12 — Audit Record Generation | Script execution and path changes must be logged to support detection and investigation. | |
| AC-6 — Least Privilege | Writable script paths and overbroad admin access are core enablers of script abuse. | |
| Recommendation — Establish and monitor approved logon-script baselines so unauthorised changes stand out. Generate audit records for script changes and executions to support alerting and review. Restrict who can modify logon-script locations and shares to reduce abuse risk. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Logon-script detection relies on centralised logs and reviewable execution evidence. |
| Recommendation — Centralise and review logs for script execution, modification, and policy changes. | ||
Practitioner Guidance
What to prioritise: Focus first on newly introduced scripts, unexpected path changes, and any script that executes from a writable or externally controlled location. Those are the changes most likely to represent persistence rather than routine endpoint configuration.
What to verify: Confirm the script owner, the approval path, and the actual content diff, not just the file timestamp. If the script can reach credentials, tokens, or other sensitive material, treat it as a likely compromise path and review related access immediately.
Practitioner takeaway: The practical test is whether the logon script behaves like a controlled administrative helper or like an unauthorised execution foothold, and that distinction comes from path, change history, and content, not from the filename alone.