SYSVOL Scripts Folder: Authenticated Users Write Trap
A single Modify ACE for Authenticated Users on the SYSVOL scripts subfolder means any domain-joined computer or low-privilege account can overwrite logon.bat or startup scripts. DFSR replicates the tampered file to every domain controller before Group Policy processing runs, and the payload executes under each logging-on user's own security context, including administrators.
Operational summary
At a glance
- Symptom
- Any authenticated domain principal, including a compromised low-privilege account, overwrites a logon or startup script referenced by GPO.
- Likely cause
- Authenticated Users hold Modify or Write NTFS permissions on the SYSVOL scripts subfolder instead of Read & Execute.
- Impact
- The tampered script replicates to every domain controller via DFSR and executes under the security context of each user who logs on, including administrators.
- Verification signal
- Re-run the detection test and a controlled negative-path test.
- Safe correction
- Remove the Authenticated Users ACE from the scripts subfolder, scope write access to a dedicated delegated group, disable inheritance, and audit ACLs after every FRS-to-DFSR migration.
- Rollback or recovery
- Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
The Trap
Authenticated Users granted Modify or Write permissions on the SYSVOL scripts subfolder (\SYSVOL\scripts, exposed externally via the NETLOGON share), overriding the intended Read & Execute default and permitting logon script hijacking.
The Default State
Fresh domain controller promotion sets NTFS permissions on SYSVOL and NETLOGON to Authenticated Users: Read & Execute, which is correct. The trap is introduced afterwards: an administrator adding a helpdesk group or deployment service account picks “Authenticated Users” from the object picker because it autocompletes fastest, then grants Modify instead of scoping to a dedicated security group. It also reappears silently during FRS-to-DFSR migration cutovers (dfsrmig /setglobalstate 3), where ACL reset templates applied to the migrated SYSVOL_DFSR share sometimes reinstate broader write inheritance on script subfolders than the source FRS replica held.
The Blast Radius
Every authenticated principal in the domain, including computer accounts and any low-privilege user with a single compromised workstation, is itself an Authenticated Users member. That account can overwrite logon.bat, a .vbs, or a .ps1 referenced by the scriptPath attribute on any GPO or user object. DFSR replicates the tampered file to every domain controller within the configured replication schedule, so remediation on one DC does not stop execution elsewhere. On next interactive logon, the script runs under the logging-on user’s own token, meaning a Domain Admin logging into a standard workstation executes the attacker’s payload with domain admin rights. Because the parent process chain is userinit.exe or explorer.exe spawning cmd.exe or powershell.exe, this matches normal logon behaviour and rarely triggers EDR heuristics tuned for anomalous parentage.
The Lead Mechanic Fix
Audit current permissions with icacls \domain.localSYSVOLdomain.localscripts and remove the Authenticated Users ACE: icacls \domain.localSYSVOLdomain.localscripts /remove:g "Authenticated Users", then grant write explicitly to a dedicated delegated group only: icacls \domain.localSYSVOLdomain.localscripts /grant "DOMAINGPO-Script-Deployers:(OI)(CI)M". Disable inheritance below the scripts container so future parent-level changes cannot reintroduce the ACE. After any FRS-to-DFSR migration, run dfsrmig /getmigrationstate and diff the resulting ACLs against a stored baseline using Get-Acl before declaring the cutover complete. Add a recurring scheduled check comparing SYSVOL and NETLOGON ACLs against that baseline and alerting on any ACE containing Authenticated Users or Everyone with write, modify, or full control.
Apply the safer control
Before you change production
Confirm the affected scope, export the current configuration, and test the replacement control in a non-production environment first.
Fix commands and configuration
icacls \domain.localSYSVOLdomain.localscriptsicacls \domain.localSYSVOLdomain.localscripts /remove:g "Authenticated Users"icacls \domain.localSYSVOLdomain.localscripts /grant "DOMAINGPO-Script-Deployers:(OI)(CI)M"Verify, roll back or escalate
Verify
Re-run the detection test and a controlled negative-path test. Confirm the unsafe behaviour is blocked while approved traffic still succeeds.
Rollback
Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
Escalate
Escalate when the blast radius is uncertain, the control cannot be tested safely, or remediation requires an outage or security exception.