Give a tester an ordinary user account and the first thing they do is enumerate file shares and read what that account can reach. It is not glamorous and it produces results in every environment. Salary spreadsheets, scanned passports, board papers, database backups and documents with passwords in them all turn up on shares that were opened to everyone for a reason nobody now remembers.
How permissions get this loose
Through a thousand small decisions. A project needs quick collaboration so a folder is opened to authenticated users. A migration copies data and applies default permissions. A leaver’s folder is left in place in case somebody needs it. Nested groups compound the effect, because a group granted access years ago has since become a container for half the company. Nobody sets out to publish payroll data internally, and the outcome is the same as if they had. The permissions were reasonable when they were set and nothing in the process ever revisits them.
What a tester actually does
Enumerate every share the account can see, then search rather than browse. Filenames containing password, backup, salary and confidential come first, followed by file types that hold credentials such as configuration files, scripts and database exports. Tooling automates the crawl and flags interesting content, so what would take a person a week takes an afternoon. The output is usually a list the client finds more alarming than any technical vulnerability, because it needs no exploitation and any employee could have found it. Contractors and temporary staff have the same access while they are with you, and nobody reviews what they read.
“The document that causes the most trouble is rarely the one with the most sensitive data. It is the spreadsheet of service account passwords that somebody in infrastructure keeps for convenience, on a share the whole IT department can read. Those credentials usually work, and they usually have more privilege than the person who wrote them down realised.”
See also: How General Dentistry Protects Oral Health Across Every Stage Of Life
William Fieldhouse, Director, Aardwolf Security Ltd
Fixing it without a year-long project
Start with discovery rather than redesign. Scan the shares yourself with the same tooling a tester would use, and sort the results by sensitivity rather than by volume. Deal with credentials first, since those are actively dangerous: rotate anything found and remove the file. Then work through the largest exposures by finding the data owner and agreeing who genuinely needs access. Restructuring an entire file server is a long project, and removing the worst dozen exposures is a fortnight of focused work with a visible result.

Keeping it under control
Set the default the other way. New shares should be closed and opened deliberately rather than open and closed on request. Review permissions annually for shares holding personal or financial data, and use group membership rather than individual entries so leavers are handled by your identity process. Apply retention so old material is archived rather than accumulating year after year in a folder nobody opens, and use internal infrastructure penetration testing to check what a standard account can reach, supported by regular security scanning of the servers hosting it.
Frequently asked questions about share permissions
These questions come up whenever an internal report lists exposed documents.
Is Authenticated Users a safe permission?
It means every account in the domain, including service accounts and any account an attacker compromises. Use it only for material you would be comfortable seeing on a noticeboard in reception.
Do cloud file services have the same problem?
Yes, in a different shape. Sharing links, organisation-wide access and inherited permissions on sites produce the same outcome, and search tools make the exposure more visible rather than less.
