Microsoft - NTLM Hash Disclosure Spoofing (library-ms)

Microsoft — NTLM Hash Disclosure & Spoofing via .library-ms (CVE-2025-24054)

This article explains the background, impact, detection, and remediation for the vulnerability commonly referenced as the ".library‑ms NTLM information disclosure / spoofing" issue (tracked as CVE‑2025‑24054). It is written from an enterprise security perspective and focuses on defensive guidance, risk reduction, and detection recommendations rather than exploitation details.

What is a .library‑ms file?

A .library‑ms file is a Windows Library definition file: a small XML-based file that defines a logical collection of folders and resources presented together in File Explorer. Because Windows Explorer parses these files automatically (for example during thumbnailing, preview, or when a library is opened), malformed or specially crafted library definitions can cause Explorer to resolve network resources referenced inside the file.

Vulnerability overview (high level)

At a high level, the vulnerability arises when Windows Explorer (or related shell components) processes a .library‑ms file that references external network resources. During resolution of those references, the OS may attempt to authenticate to a remote resource using the machine or user credentials (NTLM authentication). An attacker who controls the remote endpoint can therefore capture an NTLM challenge/response or otherwise cause disclosure of authentication material that can be abused for credential replay, relay, or lateral movement if other network protections are not in place.

Key points (non‑actionable):

• The issue is an information disclosure problem — it can cause clients to attempt network authentication to attacker-controlled hosts when a .library‑ms file is opened or previewed.
• Because NTLM responses can be relayed or cracked in some environments, the outcome can materially increase risk of account compromise or lateral movement.
• Microsoft reviewed and later acknowledged the issue; it was assigned CVE‑2025‑24054 and fixed by Microsoft security updates. The original reporter (John Page, aka hyp3rlinx) publicly described the issue in 2018 and was later credited when the CVE was assigned in 2025.

Impact and business risk

• Credential exposure: Client machines may inadvertently disclose NTLM authentication material to an external server.
• NTLM relay/pass‑the‑hash risk: In environments where legacy protocols or misconfigurations allow relaying, disclosed NTLM material can be abused to access other resources.
• Social engineering vector: Attackers can craft files that look legitimate (UI spoofing) and induce users to open them, increasing chances of credential exposure.
• Supply‑chain and email vectors: The file type can be distributed via email, downloads, or removable media; previews in Explorer or attachment viewers may trigger the behavior.

Timeline and attribution (concise)

• 2018 — Initial report and public advisory by John Page (hyp3rlinx).
• 2018–2024 — Limited initial vendor response; other researchers later re‑reported related behaviors.
• 2025 — Microsoft assigned CVE‑2025‑24054 and published mitigations/patches; the original reporter received retroactive credit.

Detection: what to log and look for

Monitoring for this class of issue centers on detecting unexpected SMB/NTLM authentication activity and anomalous network connections originating from user workstations (especially explorer.exe or other shell processes).

• Enable and collect:
  • Windows Security logs (enable auditing for logon events; 4624/4625 are useful for successful and failed logons).
  • SMBClient and SMBServer operational logs (Microsoft‑Windows‑SMBClient/Operational and Microsoft‑Windows‑SMBServer/Operational).
  • Audit NTLM authentication (via Group Policy) to get more granular NTLM events and context.
  • Network telemetry: firewall, proxy, and IDS/IPS logs for outbound connections to TCP/445 and TCP/139.
• SIEM/UEBA indicators to hunt for:
  • Explorer.exe making outbound TCP connections to SMB ports (445/139) to unusual IPs shortly after a user opens an attachment or downloads a file.
  • Unexpected network logon (4624) with Logon Type 3 (network) or other patterns tied to SMB from endpoints that normally do not mount remote shares.
  • NTLM auth activity to internet‑facing addresses or to IPs that are not known/approved internal file servers.

Example SIEM query (conceptual)

// Pseudocode / conceptual Splunk-style query
index=wineventlog (EventCode=4624 OR EventCode=5156)
| eval proc=ProcessName, dst_port=DstPort, dst_ip=DstIP
| where proc="explorer.exe" AND (dst_port=445 OR dst_port=139)
| stats count by host, proc, dst_ip, dst_port, user

Explanation: This example searches Windows event and firewall logs for explorer.exe initiating connections to SMB ports. Tailor fields and indexes to your environment's telemetry. Do not rely on a single signal — correlate process, network, and authentication logs.

Mitigation and hardening (practical, defensive)

Mitigations should be prioritized by patching, network controls, and least‑privilege/NTLM hardening.

• Apply vendor patches: Deploy Microsoft updates that address CVE‑2025‑24054 as the first and highest‑priority step.
• Block unnecessary outbound SMB: At network edge/firewall, block outbound SMB traffic (TCP 445, 139) from client subnets to the Internet and to untrusted networks.
• Restrict NTLM:
  • Enable Group Policy settings to restrict NTLM usage (e.g., restrict outgoing NTLM authentication to specific servers).
  • Move to Kerberos where possible and reduce reliance on NTLM. Consider the "Audit" stage before enforcement to discover dependencies.
• Enable SMB signing and other SMB hardening features to reduce relay/abuse risk.
• Application restrictions: Use AppLocker or Windows Defender Application Control (WDAC) to limit which processes can handle/parse user‑supplied files and to prevent untrusted code from running.
• User controls: Disable file previews for risky file types in email clients/previewers, and block or warn on downloaded .library‑ms files if not expected by policy.
• Endpoint protection: Ensure EDR/AV signatures and heuristics are up to date; many EDRs detect suspicious processes making SMB network calls after opening attachments.

Remediation checklist (operational)

Action	Priority	Notes
Install Microsoft security updates that address CVE‑2025‑24054	High	Apply to all client and server OS builds in scope
Block outbound SMB from client networks	High	Firewall rule: deny TCP 445/139 to Internet/untrusted networks
Enable NTLM auditing and review logs	Medium	Audit first to identify dependent systems before blocking
Harden NTLM and enforce Kerberos where possible	Medium	Use Group Policy and domain hardening controls
Educate users on opening files from untrusted sources	Low	Train to avoid unknown attachments and to report suspicious files

Example defensive PowerShell snippets (safe)

These snippets are defensive: the first checks installed updates for a placeholder KB; the second creates a local firewall rule to block outbound SMB on the host.

# Check installed HotFixes - replace  with vendor KB(s)
Get-WmiObject -Class Win32_QuickFixEngineering |
  Where-Object { $_.HotFixID -like "*KB*" -and $_.Description -like "*Security*" } |
  Select-Object HotFixID, Description, InstalledOn

Explanation: This lists installed QuickFix/HotFix entries (historical Windows update records). Replace or filter by a known KB number if Microsoft lists specific update KBs for your OS build. Use centralized patch management reports for enterprise‑wide completeness.

# Create a local firewall rule to block outbound SMB (TCP 445 and 139)
New-NetFirewallRule -DisplayName "Block Outbound SMB (client protection)" `
  -Direction Outbound -Action Block -Protocol TCP -RemotePort 445,139 `
  -Profile Domain,Private,Public -Description "Block outbound SMB to untrusted hosts"

Explanation: This command adds an outbound firewall rule on Windows to block TCP ports 445 and 139 across all profiles. In enterprise environments, implement equivalent rules at perimeter devices or via Group Policy rather than on individual hosts.

Operational best practices

• Test changes in a staging environment before enforcing NTLM restrictions or firewall blocks; many legacy apps depend on NTLM and may require exceptions.
• Combine perimeter and endpoint controls — a defense‑in‑depth approach reduces exposure if one layer fails.
• Use centralized patch management (WSUS, SCCM, Intune, or other MDM) to ensure all endpoints receive updates quickly.
• Prioritize visibility: enable logging, collect telemetry centrally, and periodically hunt for unexpected NTLM/SMB activity originating from client hosts.

Responsible disclosure and research context

Vulnerabilities in widely used file parsers are often subtle because automatic parsing in explorer/previewers increases attack surface. Responsible disclosure and patching are essential. The history of this issue underscores the value of ongoing research, vendor engagement, and layered mitigations until a vendor patch is broadly deployed.

References

• Microsoft Security Response Center (MSRC) advisory for CVE‑2025‑24054 — search Microsoft's update guide for full remediation details.
• Original public writeup by John Page (hyp3rlinx) — public advisories and archive pages from 2018 provide historical context.
• Community writeups and collections (Packet Storm, CXSecurity archives) — for researcher context; use responsibly.

For operational teams: prioritize patching and network egress restrictions, enable NTLM auditing to understand exposure, and deploy monitoring rules that correlate Explorer behavior with outbound SMB connections. These steps materially reduce the risk posed by this vulnerability class while you deploy vendor updates and perform remediation validation.