Skip to content
HackIndex.io

Writable SMB Shares Detection

3 min read Created Mar 6, 2026 Last updated Aug 17, 2026

Writable SMB shares matter because they turn access into placement. That can be low-value file staging, or it can become script replacement, software tampering, or a path to later code execution if users or services trust content from that share. SMBMap is built for permission review, recursive listing, and upload or download workflows, which makes it the fastest way to validate this cleanly.

SMBMap shows each share with a permission label: READ, WRITE, or NO ACCESS. READ alone is worth noting. It lets you hunt for credentials, configuration files, or sensitive documents. WRITE is the primary finding here. A WRITE label without credentials means the share is open to anyone on the network.

Start with a permission review.

Detecting Writable SMB Shares

┌──(kali㉿kali)-[~]
└─$ smbmap -H $TARGET_IP
┌──(kali㉿kali)-[~]
└─$ smbmap -H $TARGET_IP -u "$USER" -p "$PASSWORD"
┌──(kali㉿kali)-[~]
└─$ smbclient -L //$TARGET_IP -U "$USER%$PASSWORD"

SMBMap reports permissions based on share-level ACLs. NTFS permissions on subdirectories can override that and block the actual write. Always confirm by attempting a real file upload. A report that says WRITE without a successful upload does not hold up as a finding.

If a share shows write access, confirm it directly.

┌──(kali㉿kali)-[~]
└─$ echo test > /tmp/smb_write_test.txt
┌──(kali㉿kali)-[~]
└─$ smbclient //$TARGET_IP/Shared -U "$USER%$PASSWORD" -c "put /tmp/smb_write_test.txt smb_write_test.txt; dir"

Null sessions and guest access are common on aging file servers and misconfigured NAS devices. The -N flag in smbclient skips authentication entirely. If this succeeds, the share accepts connections without any domain account. That is typically a higher-severity finding than write access limited to authenticated users.

For guest-backed testing:

┌──(kali㉿kali)-[~]
└─$ smbclient //$TARGET_IP/Public -N -c "put /tmp/smb_write_test.txt smb_write_test.txt; dir"

The write is confirmed when the file appears in the remote listing. That matters more than a tool saying WRITE, because you now know the share really accepts uploaded content. Remove your test file after confirming access. Use the del command inside smbclient to clean up before moving on.

Check the surrounding directories before you decide impact.

┌──(kali㉿kali)-[~]
└─$ smbmap -H $TARGET_IP -u "$USER" -p "$PASSWORD" -r
┌──(kali㉿kali)-[~]
└─$ smbmap -H $TARGET_IP -r

Exploitation paths from writable shares:

  • Drop SCF/URL/LNK files to capture NTLMv2 hashes
  • Replace existing scripts in startup or logon paths
  • Plant payloads in software deployment shares
  • Stage tools for lateral movement from compromised hosts

If the writable path is just a public drop folder, document it but keep the impact realistic. If it sits in login scripts, software deployment, profile storage, or another trusted path, raise it immediately because writable content in those locations often supports lateral movement or execution chains later.

Watch for false negatives. Some shares reject uploads silently due to disk quotas or antivirus quarantine on write. The file will not appear in the listing even though the upload returned no error. Try a different filename or path. If smbmap hangs without output, firewall rules may block SMB while allowing ICMP. Switch to smbclient for direct connection testing. On modern Windows systems SMBv1 is disabled by default, so ensure your client negotiates SMBv2 or higher.

References