Audit which SMB shares on your LAN are writable, and by whom

The question usually arrives from an insurer’s questionnaire or after a ransomware story in the news: “Can a normal domain user write to any file share on your network?” The honest answer at most small companies is “probably, somewhere” — a Scans folder on a multifunction printer’s host, an old Public share on a retired app server, a Software$ share someone set to Everyone/Full Control in 2017. This guide finds them.

The approach has two halves. First, sweep the LAN with LizardSystems Network Scanner, which lists shared resources (including hidden $ shares) and checks read/write access for the current account or for a user you specify. Second, confirm anything suspicious with built-in PowerShell, because a remediation plan should rest on what the server says, not on a single tool’s column.

Ground rules

• Your own network, with authorization. Enumerating shares and testing write access on machines you don’t administer is off-limits. Get the scope (subnets, and whether servers in a DMZ are in or out) signed off in the ticket first.
• Use a test account, not your admin account. Scanning as a Domain Admin tells you nothing — you can write everywhere. Create a disposable account that is a member of Domain Users only, and nothing else. Disable it when the audit is done.
• Know the tool’s limits. Network Scanner’s current version is 21.07, released in July 2021, and the vendor’s supported-OS list stops at Windows 10 / Server 2016. It generally runs on newer Windows, but that’s not a vendor promise. Personal use is free; auditing a company network is business use, which the vendor licenses per machine (US$79.95 at the time of writing — check the vendor’s current pricing page). See the Network Scanner review for the full picture.

Step 1 — Define the ranges

1. Get the scanner from the vendor’s product page at lizardsystems.com and check the published SHA-256 before running it (our where to get it page explains how).

2. On the Scan tab, add each server and user VLAN as a range. The address field accepts compact expressions, which saves typing when your VLANs are numbered sensibly:

   10.20.10-12.1-254
   10.20.40.1-254

3. Leave the NetBIOS service ticked, and add FTP and HTTP only if you also want to see those resources in the same report.

Step 2 — Include hidden shares

The vendor states the scanner can list system and hidden NetBIOS shares; look through the NetBIOS tab in Preferences and make sure nothing there limits the results to ordinary shares. You want to see ADMIN$ and C$ (they tell you which machines expose admin shares at all) and, more importantly, the hand-made ones like Backup$ or Install$ that someone hid rather than locked down.

Step 3 — Scan as the test user

1. Start the scanner from a session belonging to the test account. The simplest way on a domain-joined admin workstation:

   runas /user:CORP\smb-audit "<full path to the Network Scanner executable>"

   Copy the real path from the program’s Start menu shortcut (Open file location → Properties). Alternatively, use the scanner’s option to check access rights for a specified user instead of the current one.

2. Run the scan. The tool is multithreaded, so a few /24s finish quickly; the slow part is hosts that answer on 445 but take a while to enumerate.

3. When it completes, use the filter to show only resources with write access. That filtered list is your audit finding.

Step 4 — Export the evidence

Export the filtered view. Network Scanner writes HTML, TXT or XML — HTML is the easiest to attach to a ticket for a non-technical reader, XML if you want to parse it later. There is no CSV option, so if your tracker wants CSV, convert the XML in PowerShell or paste from the HTML table.

Step 5 — Confirm on the server

Each “writable” line needs confirming, because effective access is the combination of share permissions and NTFS permissions — the more restrictive of the two wins. From an elevated PowerShell on your admin workstation:

# All non-special shares on a server
Get-SmbShare -CimSession FS01 | Where-Object { -not $_.Special } |
  Select-Object Name, Path, Description

# Share-level permissions for one share
Get-SmbShareAccess -CimSession FS01 -Name Scans

# NTFS permissions on the folder behind it
icacls \\FS01\Scans

Look for Everyone, Authenticated Users, Domain Users or BUILTIN\Users with Change/Full at share level and (M), (F) or (W) in the icacls output. Both conditions together mean an ordinary user can write.

Then prove it the boring way, as the test account:

New-Item -Path \\FS01\Scans\_audit-delete-me.txt -ItemType File
Remove-Item \\FS01\Scans\_audit-delete-me.txt

Step 6 — Fix and re-scan

1. Replace broad groups with a dedicated security group (FS01-Scans-RW) and grant Modify only there; keep share permissions at Authenticated Users: Change or tighter and let NTFS do the fine-grained work — or tighten both, per your own standard.
2. Remove shares nobody can explain after a short notice period. Rename to OLD-… first if you’re nervous.
3. Re-run the same scan as the same test account and export again. The before/after pair is what an auditor wants to see.

Common mistakes

• Scanning with an admin token. Everything looks writable, the report is useless.
• Reading share permissions alone. Everyone: Full Control at share level is Windows’ old default and is often harmless because NTFS restricts it. Check both layers.
• Ignoring non-Windows hosts. NAS boxes, printers with scan-to-folder and Linux Samba servers are frequent offenders and won’t appear in AD-based reports.
• Deleting shares during business hours. A “nobody uses this” share is used by exactly one scheduled task at 2 a.m.
• Leaving the test account enabled. Disable it and note the date in the ticket.

Related reading

For a quick host inventory before an audit like this, see sweeping a VLAN to CSV. The Angry IP Scanner vs LizardSystems Network Scanner comparison explains when share-aware scanning is worth paying for, and the rest of the field is in LAN & Port Scanners. If you want to watch the actual SMB negotiation on the wire while testing, Wireshark is the tool.