Haxoris Wiki

Overly Permissive File Shares

How Overly Permissive File Shares works

Overly permissive file shares grant Everyone, Authenticated Users or Domain Users read or change on data only a few people need. The pattern is the same on Windows file servers and NAS appliances: a share was created for one team, the fastest way to make it work was to add a broad principal at the top of the tree, and inheritance then pushed that grant down over every subfolder - payroll runs, HR case files, client deliverables, and the configuration exports and scripts that admins parked there. The share ACL and the NTFS ACL disagree, and the effective permission is whichever is looser.

The attacker with any domain account reads the data directly, with no exploit and no privilege escalation, and change rights let them plant a payload where a privileged user will open it. It is easy to miss because the share works and the broad grant is invisible in daily use: nobody browses to the payroll folder to check who else can, access-based enumeration hides folders a user cannot open so the tree looks tidy, and the inherited grant was set once on a parent that no one re-reads. Whether the underlying volume is also unencrypted belongs to the Unencrypted Data At Rest And Backups page.

Overly Permissive File Shares in practice

Enumerate shares across the estate

Start with a low-privilege test account so the result reflects what any employee can reach. Enumerate shares host by host and record where a broad principal already has read.

# host list from the authorised scope, then per-host share read access
nxc smb hosts.lab.internal -u testuser -p '<PASSWORD>' --shares \
  | tee /tmp/isr09-shares.txt

# spider one share read-only to see how deep the broad grant reaches,
# capping size so this stays enumeration and not exfiltration
nxc smb fs01.lab.internal -u testuser -p '<PASSWORD>' \
  -M spider_plus -o MAX_FILE_SIZE=0 EXCLUDE_DIRS=Windows

A share that shows READ or WRITE for a plain user account, not a scoped group, is the surface to measure next.

Read effective permissions on the shares that matter

A share flag is not the whole story; the finding is the effective NTFS permission for a broad principal. Read both ACLs read-only from the file server.

# share-level grants
Get-SmbShareAccess -Name 'Payroll','HR','ClientData' |
  Where-Object AccountName -match 'Everyone|Authenticated Users|Domain Users'

# NTFS grants at the share root, resolved for the broad principals
$paths = 'E:\Shares\Payroll','E:\Shares\HR','E:\Shares\ClientData'
foreach ($p in $paths) {
  (Get-Acl $p).Access |
    Where-Object { $_.IdentityReference -match 'Everyone|Authenticated Users|Domain Users' } |
    Select-Object @{n='Path';e={$p}}, IdentityReference, FileSystemRights, AccessControlType, IsInherited
}

An inherited Modify or FullControl for Domain Users on E:\Shares\Payroll is the exact line to remediate.

Sample content to establish sensitivity

Reachability is only a finding once the content is shown to be sensitive. Read filenames and a single sample file, not the whole tree, and redact what you quote.

# list only - establish sensitivity from names before opening anything
smbclient //fs01.lab.internal/Payroll -U 'testuser%<PASSWORD>' \
  -c 'recurse ON; ls' | head -40

# one sample to prove the class of data, then stop
smbclient //fs01.lab.internal/Payroll -U 'testuser%<PASSWORD>' \
  -c 'get "2026-Q2/salary-run.xlsx" /tmp/sample-redact.xlsx'

One sensitive file readable by a broad principal is sufficient proof; pulling the whole share only widens the blast radius of the evidence you now hold.

Record the finding as a table

Collapse the audit into one row per share so a defender sees principal, right and sensitivity together.

share                    principal            right       inherited  content class     verdict
-----------------------  -------------------  ----------  ---------  ----------------  ---------------
\\fs01\Payroll           Domain Users         Modify      yes        salary runs       FINDING
\\fs01\HR                Authenticated Users  Read        yes        case files, IDs   FINDING
\\nas02\ClientData       Everyone             Change      no         client contracts  FINDING
\\fs01\Finance           Everyone             Read        yes        config, scripts   FINDING
\\fs01\TeamProject       GRP-Project-RW       Modify      no         project files     expected

Any row whose principal is Everyone, Authenticated Users or Domain Users is a need-to-know failure regardless of the data class.

How to fix and prevent Overly Permissive File Shares

  1. Map each sensitive share to an owner and a need-to-know group
    • Name the business owner and the scoped security group for every share before changing an ACL, so removal is a decision and not a guess.
  2. Remove the broad principals and grant scoped groups only
    • Strip Everyone, Authenticated Users and Domain Users from both the share and NTFS ACLs; grant a single purpose-built group instead.
    • Migrate people into the new group first, then remove the broad grant, to avoid a lock-out that gets reverted.
  3. Clean inherited permissions at the sensitive-folder root
    • Break inheritance at the top of the sensitive tree and re-apply explicit scoped ACLs, because a loose parent silently re-grants every child.
  4. Turn on access-based enumeration and object-access auditing
    • Hide folders a user cannot open, and log reads of sensitive shares so an out-of-group access is visible.
    • Partial control: enumeration hiding is cosmetic, not an access control, so it never substitutes for the ACL fix.
  5. Re-scan permissions on a schedule
    • Keep the enumeration as a regression test and diff it, since a new share or a helpdesk fix re-introduces broad grants between annual reviews.

Last updated

References