How do you detect logon script persistence on Windows?

What logon script persistence looks like on Windows

Logon script persistence is a sign-in autostart path, so the right mental model is not “malware hiding somewhere,” but “a trusted user logon mechanism has been repurposed.” Look for the assignment point first, then the script source, then the execution trail. If a script runs from a share, profile path, startup folder, or other writable location, treat the location itself as part of the persistence mechanism.

Windows environments can surface this through Active Directory user or group policy settings, local profile references, or direct script paths in logon-related configuration. The important clue is change over time: a script that suddenly appears, a path that changes to a less-governed location, or contents that add only a few lines of code to invoke a secondary payload. For broader persistence patterns around persistence techniques, windows logon scripts are one of the easier places for an attacker to blend in.

It also helps to distinguish persistence from ordinary administration. Legitimate logon scripts usually have a clear owner, change history, and a narrow business purpose. Suspicion rises when the script owner is unclear, the contents are obfuscated or unusually terse, or the script executes from a path that non-administrators can modify. In practice, persistence often depends on this trust gap more than on any exotic technique.

How to verify assignment, ownership, and execution

Start with the assignment point. Review the GPO, user object, profile configuration, or other directory attribute that points to the script, and compare it with your approved baseline. Then identify who last changed that setting and whether the change aligns with a sanctioned administrative action. A benign script in an unexpected place is still suspicious if the assignment changed outside the normal process.

Next, validate the script itself. Check file timestamps, hash or content drift, and whether the script references network locations, downloaders, or child processes that do more than routine sign-in work. Correlate these changes with logon events so you can see whether the script executes at sign-in, at interactive logon, or only for a specific user or host. The execution pattern is often more revealing than the file alone.

For identity-adjacent detection, pair script-change evidence with authentication and session context. A new or modified script that first appears after a suspicious logon, a help desk reset, or a privileged directory change is more credible than a script change seen in isolation. The same logic applies when execution begins from a writable share or an endpoint path that should not host privileged startup logic. That is where detection starts to overlap with Identity Threat Detection and Response (ITDR) Guide style monitoring.

Why attackers like logon script persistence

Logon scripts are attractive because they execute during a normal, repetitive business action. That gives an attacker a durable foothold with very low operational noise, especially if the script is small and the payload is delayed until the next logon. The script may never look malicious if defenders only review it as a text file and not as part of the wider execution chain.

The main threat pattern is abuse of trust in a routine control path. If an attacker can modify the script, change the referenced path, or place a script where a user session will execute it, they can achieve recurring code execution without needing a separate scheduled task or service. Once that happens, the same mechanism can support credential theft, lateral movement, or re-entry after cleanup. For a detection and response lens, that is the same class of problem described in ITDR because the persistence is tied to identity activity and user session trust.

Risk and Threat Considerations

Logon script persistence is risky because it sits inside a normal authentication-to-session transition, which means defenders may see it as routine user activity unless they compare assignment, ownership, and script content over time. The risk increases when scripts live in writable paths or network shares, because the persistence mechanism is then only as strong as that file or share governance.

Failure mechanism: An attacker or insider modifies the assigned logon script, replaces the referenced file, or points the logon setting to a new script in a path that still executes at sign-in. Because the action occurs during expected user logon, the change can persist quietly until someone reviews the assignment source and execution trail together.

Impact: The attacker gets repeatable code execution at every logon for the affected user or host, which can enable credential capture, payload staging, or follow-on lateral movement. If the script is shared across users or managed through a higher-level directory setting, the blast radius can extend beyond a single endpoint.

Practitioner Guidance

What to verify: Confirm the authoritative assignment source, the script file path, the last modifier, and whether the path is writable by non-administrators or by a broader group than intended. If any one of those does not match your baseline, treat the script as a persistence candidate even before you prove malicious behavior.

Decision rule: If the script is stored on a share or directory that ordinary users can change, prioritise containment and ownership review over content inspection alone. If the script is centrally managed and signed off, focus on unexpected deltas in assignment or content rather than the presence of a script itself.

What practitioners underestimate: The persistence is often not in the script body but in the control relationship around it. A tiny file can be enough if it executes in a trusted logon path, so the strongest detection is a three-way comparison of assignment, file integrity, and correlated logon activity.

Practitioner takeaway: Treat logon script persistence as a change-control problem first and a malware problem second, because the attacker only needs one trusted execution path to keep coming back.

Related resources from NHI Mgmt Group

• How can you detect AppInit DLL persistence on Windows?
• How can you detect AppInit_DLLs and AppCertDlls persistence on Windows?
• How can you detect application shim database persistence on Windows?
• How can you detect BITS job persistence and malicious downloads on Windows?