All posts

CVE-2025-50154 — Zero-Click NTLM Hash Disclosure via LNK Patch Bypass

Published on
August 2025
CVE-2025-50154 — Zero-Click NTLM Hash Disclosure via LNK Patch Bypass
Table Of Contents
Introduction
Vulnerability Bypass
How It Works (Step-by-Step)
Detection Opportunities
Threat Hunting Playbook
Defensive Measures
Conclusion
References

Introduction

Microsoft patched a vulnerability that allowed attackers to harvest NTLMv2-SSP hashes without user interaction. The flaw was originally triggered when Process.exe rendered the icon of a .LNK shortcut file referencing a remote SMB path. While the patch blocked icon loading from SMB shares, further research uncovered a bypass: by modifying how .LNK files are structured, attackers can still force Explorer to reach out to remote servers — leaking NTLM hashes silently.

This bypass (CVE-2025-50154) highlights how incomplete mitigations can be abused by determined attackers and why SOC teams must treat every patch as a checkpoint, not a finish line.

Vulnerability Bypass

  • Original flaw (CVE-2025-24054):
    Explorer automatically rendered icons from .LNK files, even if hosted on remote SMB shares, causing the system to leak NTLM hashes to the attacker-controlled server.
  • Microsoft’s patch:
    Blocked remote SMB paths when resolving .LNK icons.
  • New bypass (CVE-2025-50154):
    Instead of using a remote icon directly, attackers craft a .LNK file with:
    • Default icon from shell32.dll (so no SMB lookup for the icon).
    • Target path pointing to a binary on a remote SMB share.
    When Explorer parses the .LNK, it attempts to inspect the target binary for embedded icon resources (RT_ICON / RT_GROUP_ICON in .rsrc). This re-introduces the SMB connection, leaking NTLMv2-SSP hashes to the attacker — all without a single click.

How It Works (Step-by-Step)

  1. Crafting the Malicious LNK
    • The attacker generates a .LNK file with PowerShell:
    • IconLocation → local shell32.dll (avoids patch check).
    • TargetPath → \\attacker-server\share\payload.exe.
    Crafting LNK
  2. Delivery to Victim
    • The .LNK file is delivered via email attachment, malicious download, or dropped on a shared folder.
  3. Automatic Processing by Explorer
    • As soon as the victim’s Explorer renders the shortcut on Desktop, Downloads, or Start menu, it tries to resolve the target binary’s icon metadata.
    • This forces Explorer to connect to the attacker’s SMB server.
  4. NTLM Hash Disclosure
    • The SMB server challenges the client.
    • Explorer responds with NTLMv2-SSP hashes of the logged-in user.
    • These can be cracked offline or relayed to pivot inside the domain.

Key takeaway: even with Microsoft’s patch, the resource parsing logic in .LNK files still enables zero-click NTLM leakage.

Detection Opportunities

  • Windows Event Logs
    • Event ID 4624 (NTLM logons, Type 3) from unexpected remote servers.
    • Event ID 4625 (failed NTLM attempts) in clusters — sign of brute-force/offline cracking.
  • Network Monitoring
    • Outbound SMB traffic to untrusted IPs/domains.
    • NTLM negotiation sequences (ntlmssp) in PCAPs.
  • Endpoint Telemetry (EDR/XDR)
    • Process.exe making SMB connections — highly suspicious.
    • LNK files created from external sources (e.g., Downloads folder).

Threat Hunting Playbook

  • Search for .LNK file creations from untrusted sources.
  • Correlate SMB connections initiated by process.exe.
  • Hunt for repeated NTLMv2 challenge-response attempts across multiple servers.

Defensive Measures

  1. Patch Management
    • Apply Microsoft’s latest updates, but recognize patch bypass risk.
  2. NTLM Hardening
    • Disable NTLM where possible.
    • Enforce SMB/LDAP signing.
    • Enable Extended Protection for Authentication (EPA).
  3. Blocking Vectors
    • Use AppLocker or Smart App Control to block untrusted .LNK execution.
    • Strip .LNK attachments at mail gateways.
    • Segment high-value servers from accepting SMB auth.
  4. SOC Visibility
    • Create detection rules:
      • Sigma: detect process.exe initiating SMB sessions.
      • Splunk/ELK: alert on NTLM logons from unexpected external IPs.

Conclusion

CVE-2025-50154 demonstrates that attackers evolve faster than patches. Even when vendors close one door, subtle logic flaws (like resource parsing in .LNK) can re-open the attack surface.

For defenders, the lesson is:

  • Patch rapidly, but don’t rely solely on patches.
  • Hunt for abuse patterns (NTLM in places it shouldn’t be).
  • Move toward NTLM deprecation — the only true long-term fix.

Zero-click NTLM attacks aren’t going away — but with layered defenses, strong visibility, and proactive hunting, SOC teams can stay one step ahead.

References