Network Logon Script

What a network logon script does

A network logon script is part of the sign-in path, so it can quietly execute every time a user authenticates to a domain or networked environment. That makes it useful for legitimate setup tasks, but also attractive for abuse because execution is automatic and trusted.

Administrators often use these scripts to map drives, set environment variables, launch approved tools, or apply user-specific configuration. The same reliability is why attackers target them: if they can alter the script, they can piggyback on normal logon activity.

Why it is a security-sensitive execution point

Because the script runs at logon, it sits on a privileged execution seam between identity, endpoint state, and network access. A malicious change can turn an ordinary sign-in into a persistence mechanism, a command-launch point, or a staging step for broader compromise. The MITRE ATT&CK Enterprise Matrix is useful here because logon-time execution maps naturally to persistence and privilege-oriented tradecraft.

The main control question is not whether the script exists, but who can edit it and where it is stored. If write access is too broad, a low-privilege user, compromised admin session, or malicious insider can inject logic that runs repeatedly without needing a separate scheduled task or service.

Common abuse patterns and what defenders should inspect

Abuse often looks like a small change with outsized impact, such as added command execution, hidden downloads, credential theft helpers, or drive mappings that point users toward attacker-controlled resources. The technique overlaps with broader persistence tradecraft, and NHIMG’s Persistence Techniques Guide covers logon script abuse in the wider persistence landscape.

Defenders should examine the script source, its storage location, change history, and the accounts or groups that can modify it. Review matters because logon scripts are often treated as routine administration, which creates blind spots when unauthorized logic is added and later mistaken for legitimate desktop configuration.

How to reduce exposure and verify trust

Control the script as a managed administrative asset: restrict edit rights, track approval for changes, and monitor for unexpected additions to the commands it launches. If the environment uses central file shares or domain resources to host the script, protect those paths with the same discipline used for other operationally sensitive code and configuration.

Detection should focus on both change and effect. Watch for new outbound connections, unusual command interpreters launched at logon, unexpected drive mappings, and user complaints about sign-in delays or strange session behavior. After any suspected tampering, review the script for secondary payloads and check whether compromised sessions or credentials were used to make the change.

Risk and Threat Considerations

Network logon scripts are high-value because they combine trusted execution with repetition, which makes them a strong persistence and initial action mechanism once an attacker can modify them. The risk is greatest when script storage, file permissions, or administrative workflows are weak enough to let a compromised account alter code that runs for many users.

Failure mechanism: An attacker gains write access to the script or its backing share, inserts malicious commands, and relies on normal logon events to execute them across affected endpoints.

Impact: This can lead to repeated code execution, persistence, lateral movement assistance, user session manipulation, and broader endpoint compromise that is harder to spot than a one-time malicious file drop.

Practitioner Guidance

Why practitioners should care: Treat network logon scripts as privileged automation, not convenience text files. If they are editable by too many people, they become a durable foothold for anyone who can influence the domain file path or the account that manages it.

What to watch for: Prioritise review of changes that add hidden execution, downloaders, encoded commands, or new references to external hosts. A small script delta can be more dangerous than a large one because it blends into expected logon activity.

Practitioner takeaway: If you do not continuously know who can edit the script and what it now contains, you do not really control its behaviour.

Related resources from NHI Mgmt Group

• Who is accountable when a GPO logon script is modified without approval?
• Who should be able to respond when suspicious logon activity is detected on a Windows network?
• How should security teams use logon activity to detect an attacker who has already breached the network?
• GPO Logon Script