SYSVOL is a share on every domain controller that every domain user can read, and it holds the files behind your group policies. That combination makes it the first place a tester looks after getting any account at all. What comes out is usually a mix of scripts with credentials in them, policies that reveal how the estate is built, and occasionally a password that still works.
Why the share is readable by everyone
Domain members need to read policy to apply it, so read access is by design and cannot be removed without breaking the domain. The problem is what administrators put there. Logon scripts that map drives with a service account password, deployment scripts that call an installer with credentials on the command line, and configuration files copied in for convenience all sit in a location that any user, on any workstation, can list and download. The oldest example is Group Policy Preferences, where passwords were stored with a published encryption key until Microsoft removed the ability to set them in May 2014. The setting is gone. The old files often remain.
Delegation that hands over the domain
Rights over a group policy object are rights over every machine it applies to. If the helpdesk group can edit a policy linked to the servers organisational unit, then compromising a helpdesk account is equivalent to compromising those servers, because a policy can deploy a scheduled task that runs as SYSTEM. Delegation like this accumulates quietly: somebody grants edit rights to solve a problem on a Friday and nobody reviews it. The NCSC’s guidance on preventing lateral movement makes the same argument about administrative tiers, and group policy is one of the clearest places where tiering either holds or collapses.
“Reading SYSVOL is the least glamorous part of an internal test and it produces results more reliably than anything else we do. Last year we pulled a working service account password out of a batch file dated 2016 at a client with an otherwise excellent security programme. Nobody had opened the folder in years, which is exactly why it was still there.”
William Fieldhouse, Director, Aardwolf Security Ltd
Cleaning it up without breaking logons
Work through the share file by file rather than trusting a search for one pattern. Grep for password, net use, and the names of your service accounts, then open anything that runs at logon. Replace credential-carrying scripts with group policy preferences that do not need them, or with a scheduled task running under a managed service account. Rotate any password you find, even where the account appears unused, since unused accounts are exactly the ones nobody monitors. Then audit who holds edit rights on each policy, and reduce that list to a group you can name.
Keeping it clean
Turn this into a recurring check rather than a one-off clear-out. Enable auditing on group policy changes so a new link or an edited policy generates an event somebody sees. Review delegation quarterly against your administrative tier model. Include the share in the scope of your internal network penetration tests, and when comparing experienced penetration testing companies, ask whether their internal methodology includes reading policy files by hand, because an automated scan of a domain controller will report the share as functioning correctly and stop there.
Frequently asked questions about group policy security
These questions follow most internal assessments that touch Active Directory.
Can you restrict who reads SYSVOL?
Not meaningfully, because clients need policy to apply it. The answer is to keep secrets out of the share rather than to control who can read it.
Do these findings apply to Entra-joined devices?
Cloud-managed devices avoid the SYSVOL problem entirely, and they introduce their own equivalent in configuration profiles and scripts. Wherever configuration is delivered centrally, ask what it carries and who can change it.
