Everyone Has Write Access: How to Find the NTFS Permissions That Put Your Data at Risk

Overpermissive NTFS folders are the most common file server security finding, and the hardest to detect without tooling. The permission was set years ago. Nobody documented why. The folder has been wide open ever since, and nobody noticed because nothing went visibly wrong — until a ransomware encryption, a data leak, or an auditor's finding surfaces it.

This guide covers the specific permission patterns that represent real risk on Windows file servers, how to find them systematically, and how to prioritize remediation without breaking the applications and workflows that depend on the current access structure.

---

The five permission patterns that create real risk

1. Everyone or Authenticated Users with Write or FullControl

This is the single most dangerous permission on any shared folder. "Everyone" literally means every security principal that can authenticate to the machine — including guest accounts, service accounts, and accounts from trusted domains. "Authenticated Users" is nearly as broad — every account that successfully authenticates.

When either of these principals has Write or FullControl on a shared folder, every user on the network can create, modify, and delete files in that folder. This is the permission state that allows ransomware to encrypt an entire file share from any compromised workstation on the network.

It's also disturbingly common. The pattern is almost always the same: someone needed to share a folder quickly, set permissions to Everyone:FullControl to "get it working," and never came back to restrict it.

2. Broken inheritance with no documented justification

NTFS inheritance means a subfolder inherits its parent's permissions by default. When someone breaks inheritance on a subfolder — by clicking "Disable inheritance" in the Advanced Security dialog — the folder's permissions diverge from the parent.

Sometimes this is intentional and correct: a restricted HR subfolder within a shared department tree, or a confidential folder that should be visible only to specific users.

Often it's accidental or expedient: someone broke inheritance while troubleshooting an access problem, applied explicit permissions to fix the immediate issue, and left it. The folder now has permissions that don't match any policy. Future admins don't know whether the break was intentional or a mistake.

Broken inheritance creates invisible permission boundaries that accumulate over time. On a file server with hundreds of folders, dozens of broken inheritance points create a permission structure nobody fully understands.

3. Orphaned SIDs from deleted accounts

When a user or group is deleted from Active Directory, any ACL entries referencing that account's SID remain on the filesystem. The SID no longer resolves to a name — it displays as S-1-5-21-3456789012-... instead of DOMAIN\Username.

Orphaned SIDs are usually harmless — they reference a deleted account that can't authenticate. But they're not always harmless:

• If a new account is created with the same SID (possible in certain migration or domain trust scenarios), it inherits the old account's permissions on every folder that still has the orphaned ACE.
• Orphaned SIDs from deleted groups can still apply if the group's SID was reused or if the account was deleted from one domain but still exists in a trusted domain.
• Large numbers of orphaned SIDs slow down access token evaluation, which can cause intermittent "access denied" errors or slow folder access on file servers under load.

4. Service accounts with unnecessary privilege

Backup agents, antivirus scanners, monitoring tools, and other services often run under dedicated service accounts. During installation, these accounts frequently get FullControl on entire directory trees — because the installer documentation says "grant full access" and nobody questions it.

The service only needs Read access to function. But it has FullControl, which means if the service account is compromised — through a vulnerability in the service, credential theft, or lateral movement — the attacker inherits FullControl on every folder the service can access.

Service account permissions are rarely reviewed after the initial installation because the service works and nobody wants to break it by removing permissions. They persist indefinitely, expanding the blast radius of any compromise that targets the service.

5. Deep explicit override chains

When permissions are overridden explicitly at multiple levels in a folder hierarchy — the share has one set, a subfolder overrides it, a sub-subfolder overrides that, and so on through five or six levels — the resulting permission structure is effectively opaque.

Nobody can look at a deeply nested folder and determine its effective permissions without tracing the entire inheritance chain. The Windows "Effective Permissions" tab theoretically shows this, but only for one user at a time on one folder at a time — useless for auditing.

Deep override chains usually indicate years of incremental permission changes without cleanup. Each change solved an immediate access problem without considering the cumulative complexity.

---

Why manual inspection doesn't work at scale

The Windows Security tab shows permissions for one folder at a time. Checking permissions across a file server with 3,000 folders means 3,000 right-click → Properties → Security → Advanced interactions.

Even if you had the patience, the Security tab has limitations:

• It shows ACL entries but doesn't flag which ones are risky
• It shows SIDs it can't resolve but doesn't tell you they're orphaned
• It shows inheritance status but doesn't tell you where in the tree inheritance was broken
• It doesn't export anything — no CSV, no report, no evidence

PowerShell's Get-Acl is better for enumeration but outputs SDDL — a machine-readable format that requires decoding to be human-readable. Building a script that walks a tree, decodes every SDDL string, resolves every SID, and applies risk logic is a multi-day project.

The tool you need reads the filesystem's security descriptors, decodes them into human-readable output, applies risk scoring, and produces a structured report. This is a solved problem — you shouldn't have to build it yourself.

---

Prioritizing remediation without breaking things

The first permissions audit on a neglected file server invariably produces a list of findings. The temptation is to "fix everything" immediately. This is how you break applications.

The safe approach:

Fix Critical findings immediately. Everyone or Authenticated Users with Write/FullControl is never acceptable on a shared folder that contains real data. Remove these permissions and replace them with specific groups. If something breaks, the application was depending on an insecure permission — that needs to be fixed, not preserved.

Investigate High findings before changing. Broken inheritance and service account permissions may be intentional. Before removing them, determine whether an application, script, or workflow depends on the current permission state. Change only after confirming the dependency is understood.

Document Medium findings for the next review cycle. Orphaned SIDs and Domain Users permissions are worth cleaning up but aren't urgent. Flag them, document them, and schedule remediation for the next maintenance window.

Ignore Low and Info findings until everything above is clean. Deep override chains and disabled accounts are cleanup tasks, not security tasks. Fix them when the important stuff is handled.

---

What to do next

If your file servers have been in production for more than a year without a systematic permissions review, you almost certainly have overpermissive folders. The question isn't whether they exist — it's how many there are and how critical the data inside them is.

NTFS Permissions Auditor walks the tree, scores every ACL entry for risk, and produces the two files you need: a complete permissions inventory and a risk-sorted findings list. The trial scans 500 paths — enough to see what's on your file server before committing.

Run it on your most sensitive share first. The risk report will tell you exactly what to fix and in what order.