# Overly Broad SMB Share Access

> Identifies misconfigured SMB shares with excessive permissions, covering enumeration techniques, access testing, and tools like smbclient and CrackMapExec.

- **URL:** https://hackindex.io/services/smb/vulnerability-discovery/overly-broad-smb-share-access
- **Path:** SMB > Vulnerability Discovery
- **Up:** [Vulnerability Discovery](https://hackindex.io/services/smb/vulnerability-discovery.md)
- **Published:** 2026-03-06
- **Updated:** 2026-08-11

This page is for cases where access is technically authenticated but still too broad. Overly broad SMB access often leaks data across teams, exposes infrastructure material, and gives low-privileged users content that supports credential discovery or lateral movement.

An account that reads `C$` or `ADMIN$` is a clear miss. An account that sees shares from another business unit is a finding too. The risk is not only reading sensitive files directly. Broad access gives an attacker directory structure, script names, config file locations, and service account hints. That context drives the next phase without opening a single file.

Start by mapping what the account can actually see.

## Detecting Broad SMB Access

```bash
nxc smb $TARGET_IP -u "$USER" -p "$PASSWORD" --shares
smbmap -H $TARGET_IP -u "$USER" -p "$PASSWORD"
smbclient -L //$TARGET_IP -U "$USER%$PASSWORD"
```

Then inspect the shares that look out of scope. The output shows share names with READ and WRITE permission columns. WRITE access to anything outside the account's own working area is immediately reportable. READ access requires more judgment.

Note every share that belongs to a different team or function. Administrative shares like `C$`, `ADMIN$`, and `IPC$` should not be readable by regular domain accounts. Seeing them listed for a standard user indicates a misconfiguration beyond share permissions alone. Share names that indicate cross-boundary exposure:

- `Backup`, `Deploy`, `Staging` (infrastructure)
- `Scripts`, `Config`, `IT` (admin tooling)
- `Finance`, `HR`, `Legal` (sensitive business data)
- `SYSVOL`, `NETLOGON` (domain controller shares)

Start recursive listing on those first.

```bash
smbmap -H $TARGET_IP -u "$USER" -p "$PASSWORD" -r
smbclient //$TARGET_IP/Shared -U "$USER%$PASSWORD" -c "dir"
```

The finding is stronger when the account reaches infrastructure shares, backup locations, deployment content, user home data from other teams, or sensitive departments such as finance or HR. Even without write access, broad read exposure can still lead to credential recovery, key theft, internal recon, or discovery of trusted script paths.

In recursive output, look for config files, credential stores, `.ps1` and `.bat` scripts, `.kdbx` files, private keys, and deployment packages. A script with a hardcoded service account name is already useful. A share full of deployment scripts can reveal internal hostnames, service credentials, and trust paths. Document the share name, the access level, and a representative file list per share.

When this check returns nothing useful, consider the cause. A firewall may block SMB from non-domain-joined attacker machines. A GPO may restrict share visibility per security group. If `smbmap` errors but `smbclient` connects, try both before concluding access is blocked. Testing from a compromised domain-joined host often bypasses source-IP restrictions that block external attacker machines.

If the account only reaches expected working data, move on. If access crosses business boundaries or reaches infrastructure content, keep the exact share names and review them for sensitive files next.

## References

- [NetExec](https://github.com/Pennyw0rth/NetExec) - Authenticated SMB share enumeration
- [SMBMap](https://github.com/ShawnDEvans/smbmap)
- [smbclient man page](https://www.samba.org/samba/samba/docs/man/manpages/smbclient.1.html) - Authenticated share access and listing