Auditing Outlook NTLM Hash Exposure: From Zero-Day Path to Patch Tuesday Triage

On this page

Introduction — Why an Outlook NTLM Hash Leak Outranks Generic Credential Theft

What the Public Record Actually Says About This Outlook Zero-Day

Microsoft confirmed in-the-wild exploitation; the fix shipped in the November Patch Tuesday release

What is still not public — CVE identifier, exact trigger, and affected build range

The 1,093 vs 1,094 count discrepancy between reports and why the exact number should not drive your response

How Outlook Ends Up Sending Your Net-NTLM Hash to an Attacker

The NTLM challenge-response handshake in one paragraph, focused on what actually crosses the wire

Coercion surfaces Outlook has historically exposed — UNC paths in messages, remote images, WebDAV/DAVSearch, OLE and RTF content, calendar invites

What a captured Net-NTLMv2 response is worth — offline cracking versus live relay

From Leaked Hash to Authenticated Session — Relay Mechanics

Why a hash is not a password but still authenticates

Relay targets that change the severity of the finding — SMB, LDAP, HTTP, ADCS certificate endpoints

The three things that break a relay: SMB signing, LDAP channel binding, and Extended Protection for Authentication

Audit Step 1 — Inventory Outlook and Patch Posture

Enumerating Office and Outlook builds with PowerShell (click-to-run versus MSI paths)

Pulling update history from WSUS, MDE, or the local hotfix list

Building a per-host exposure list instead of a single fleet-wide number

Audit Step 2 — Find Outbound NTLM Leaks That Are Already Happening

Windows event IDs that matter: 4624 Logon Type 3, 4776, and the NTLM operational log 8001–8005

Egress signals on TCP 445 and 139 from workstation subnets

Detection queries for workstation-to-workstation SMB authentication anomalies

Audit Step 3 — Measure Your Actual Relay Surface

Checking SMB signing enforcement with a scoped PowerShell or GPO report

Verifying LDAP signing and channel binding requirements

Identifying ADCS and other high-value relay endpoints that lack EPA

Compensating Controls You Can Ship Before the Patch Reaches Every Host

Blocking outbound SMB from workstation VLANs, with a firewall rule example

Outlook hardening — remote content, picture blocking, and the relevant Trust Center registry keys

NTLM restriction policy and auditing via the RestrictNTLM settings

Credential Guard and Protected Users as depth, not as a substitute for patching

Triaging a Four-Digit Patch Tuesday Without Losing the One That Matters

Rank on known exploitation first, then exposure, then CVSS — not the reverse

The order I would apply patches this cycle and the reasoning behind it

A short table mapping finding type to owner and acceptable remediation window

What I Confirmed, What I Inferred, and What I Did Not Test

Further Reading

Conclusion — Patching Is the Easy Part; Proving You Are Not Relaying Is the Work

Introduction — Why an Outlook NTLM Hash Leak Outranks Generic Credential Theft

Patch Tuesday always brings credential-theft headlines. Most are noise. This one is not: an exploited Outlook zero-day that leaks Windows NTLM authentication hashes gives an attacker something that authenticates without ever learning a password, and what it authenticates to is decided by your network, not by Microsoft. This post is the audit path for that exposure — inventory Outlook build coverage, hunt outbound NTLM leaks that are already happening, measure the relay surface that turns a captured hash into a session, and rank the fix inside a roughly 1,094-CVE November release.

That distinction changes the remediation order. If an attacker steals a password, you rotate it. If an attacker captures a Net-NTLMv2 response, rotation does nothing for the captured blob — you either crack it (slow, password-quality dependent) or relay it live to another service that accepts NTLM without signing or channel binding (fast, and entirely dependent on how your environment is configured).

The patch is the easy half. The half that actually decides your exposure is whether an unprivileged host on your workstation VLAN can authenticate to an arbitrary SMB, LDAP, or ADCS endpoint. Most organizations cannot answer that question today, and the commands below are built to produce evidence rather than opinions.

What the Public Record Actually Says About This Outlook Zero-Day

Microsoft confirmed in-the-wild exploitation; the fix shipped in the November Patch Tuesday release

The update shipped on November 10, 2026, and both reports I worked from agree on the shape of it: Microsoft confirmed that attackers are exploiting an Outlook flaw to steal Windows authentication hashes, and the fix landed inside a monthly release containing roughly a thousand vulnerabilities. SecurityWeek reported the exploited Outlook zero-day among 1,094 flaws published November 10; CyberSecurityNews covered the same exploited flaw with a 1,093 count.

The number is not the important part. What matters is that the Outlook fix is shipping alongside confirmed exploitation, which puts it in the small set of updates you apply first regardless of what else is in the release.

What is still not public — CVE identifier, exact trigger, and affected build range

I want to be precise about what I know and do not know here, because guessing a CVE ID is how bad vendor-risk tickets get written.

The source material I worked from did not give me the CVE identifier, the specific Outlook coercion surface involved, or a build range. So I am not going to invent them. Here is what to pull from primary sources before you brief anyone:

The 1,093 vs 1,094 count discrepancy between reports and why the exact number should not drive your response

Two reports, two months, one number apart. The likely explanations are mundane: Microsoft's own per-release tally vs. a figure that includes a late addition, a vendor-reported third-party CVE, or a difference between counting CVEs and counting KBs that carry them. I do not know which is authoritative, and it genuinely does not matter.

A four-digit count is a distraction metric. It tells you the release is large; it tells you nothing about your risk. The only three numbers that should shape your week are:

1. How many of those CVEs are flagged as exploited.
2. How many affect software you actually run (from your own inventory, not the advisory list).
3. How many of those affected assets are reachable from a threat path you have evidence for.

If you triage by the churn number in the headline, you will spend the week patching .NET DoS bugs and miss the one that hands out NTLM responses.

How Outlook Ends Up Sending Your Net-NTLM Hash to an Attacker

The NTLM challenge-response handshake in one paragraph, focused on what actually crosses the wire

NTLM is a challenge-response protocol. The client opens with a NEGOTIATE message listing its username and domain. The server replies with a CHALLENGE carrying an 8-byte random nonce. The client answers with an AUTHENTICATE message containing a response computed from the server's nonce, a fresh client nonce, a timestamp, target metadata, and a key derived from the password — specifically, an HMAC-MD5 keyed by the MD4 hash of the UTF-16LE password. The server (or, for domain accounts, a domain controller) recomputes and compares.

The critical property: the password never crosses the wire, but the response is a reusable proof that the client knows it. In shape, it looks roughly like this:

const crypto = require("crypto");

// Shape of the Net-NTLMv2 response (MS-NLMP), abridged — not a working implementation.
const ntHash = Buffer.from("8846f7eaee8fb117ad06bdd830b7586c", "hex"); // MD4(UTF-16LE(password))
const serverChallenge = Buffer.from("0123456789abcdef", "hex");
const blob = Buffer.from(authBlobHex, "hex"); // timestamp + client nonce + target info

const v2hash = crypto
  .createHmac("md5", ntHash)
  .update(Buffer.from("ALICE" + "CORP", "utf16le"))
  .digest();

const proof = crypto
  .createHmac("md5", v2hash)
  .update(Buffer.concat([serverChallenge, blob]))
  .digest();

The proof value is what an attacker wants. It is not the password. It is not even the NT hash. But if it reaches a service that will accept it, it is an authenticated session.

Coercion surfaces Outlook has historically exposed — UNC paths in messages, remote images, WebDAV/DAVSearch, OLE and RTF content, calendar invites

Outlook is a rendering engine for content authored by strangers, and some of that content is allowed to reference network resources. Whenever Outlook dereferences a \\host\share path or an HTTP resource that triggers a 401, Windows will attempt authentication, and the credential used is typically the logged-on user's.

I want to be explicit: I do not know which of these is the surface for the November 2026 flaw. The CVE-2023-23397 and CVE-2024-21413 rows are precedents, not attributions. What I do know is that the class keeps recurring, because the underlying design — a mail client that resolves remote authentication references for the logged-on user — has never been fully closed off. The fix is per-vector, and each fix is a whack-a-mole answer to a structural problem.

What a captured Net-NTLMv2 response is worth — offline cracking versus live relay

Two paths, very different economics.

Offline cracking is a guess-and-check loop against a captured blob. Hashcat mode 5600 covers Net-NTLMv2:

hashcat -m 5600 captured.txt rockyou.txt -O

Whether that succeeds depends entirely on password entropy and whether the value was ever in a breach corpus. A 20-character generated password does not fall. A Season+Year corporate standard does, typically in minutes.

Live relay skips cracking entirely. You forward the server's challenge to a real target, relay the response back, and inherit the session. The value of the capture is then bounded not by password strength but by what will accept the relay. That is a configuration question, and it is yours to answer.

From Leaked Hash to Authenticated Session — Relay Mechanics

Why a hash is not a password but still authenticates

In a relay, you are a man-in-the-middle on an authentication conversation you did not start. The victim's Outlook connects to your listener; you connect to the real target; you pass the target's challenge back to the victim; the victim's LSASS computes a valid response; you forward it. The target sees a valid NTLM logon from the victim's account.

You never see the password. You never see the NT hash. You get a session token on someone else's service. This is why "we rotate passwords quarterly" is not a control for this class.

Relay targets that change the severity of the finding — SMB, LDAP, HTTP, ADCS certificate endpoints

Not all relay destinations are equal. Ranked by how bad the outcome is in a typical Active Directory environment:

The ADCS row is the one people underweight. A relayed Net-NTLMv2 response is a moment in time; a certificate issued from a relayed session is valid for months.

The three things that break a relay: SMB signing, LDAP channel binding, and Extended Protection for Authentication

These are the three controls that convert relay from "trivially available" to "requires a misconfiguration":

1. SMB signing required. If the server requires signing, the relayed session fails because the attacker cannot produce a valid signature over the session key. This must be required, not merely enabled — "enabled" means the client can opt out.
2. LDAP signing plus channel binding. LDAPServerIntegrity = 2 requires signing; LdapEnforceChannelBinding = 2 binds the authentication to the TLS channel, so a relayed auth over a different channel is rejected.
3. Extended Protection for Authentication (EPA). Channel binding and service binding for HTTP-based NTLM, which is what closes ESC8 on /certsrv.

Newer Windows builds have started enabling SMB signing by default, and Microsoft has published SMB security hardening guidance for Windows 11 and Windows Server 2025. That is progress, not coverage. Plenty of fleets still have servers where signing is enabled-but-not-required, and old MSI-era file servers that were never touched. Check; do not assume.

Audit Step 1 — Inventory Outlook and Patch Posture

Enumerating Office and Outlook builds with PowerShell (click-to-run versus MSI paths)

Click-to-run and MSI installs report versions in different places, and a fleet query that only checks one will silently miss half the estate.

## Click-to-run: authoritative version + channel
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration' |
  Select-Object ProductReleaseIds, VersionToReport, Platform, UpdateChannel, CDNBaseUrl

## Either install type: the binary itself
$paths = @(
  "$env:ProgramFiles\Microsoft Office\root\Office16\OUTLOOK.EXE",
  "${env:ProgramFiles(x86)}\Microsoft Office\root\Office16\OUTLOOK.EXE",
  "$env:ProgramFiles\Microsoft Office\Office16\OUTLOOK.EXE"
)
$paths | Where-Object { Test-Path $_ } | ForEach-Object {
  [pscustomobject]@{
    Path    = $_
    Version = (Get-Item $_).VersionInfo.ProductVersion
  }
}

Sample output from a lab host:

ProductReleaseIds VersionToReport Platform UpdateChannel
----------------- --------------- -------- -------------
O365ProPlusRetail  16.0.17928.20156 x64     CurrentChannel

Path                                                       Version
----                                                       -------
C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE 16.0.17928.20156

The version string is what you compare against the KB. Do not compare ProductReleaseIds — that tells you the SKU, not the patch level.

Pulling update history from WSUS, MDE, or the local hotfix list

Three sources, three different failure modes. Use all three as cross-checks if you can.

## Local: the QFE list. Fast, but C2R updates often do not appear here.
Get-HotFix | Where-Object { $_.HotFixID -match 'KB\d+' } |
  Sort-Object InstalledOn -Descending | Select-Object -First 10

## WSUS server: what is approved and still needed
Get-WsusUpdate -Classification Security -Status Needed |
  Where-Object { $_.Update.Title -match 'Outlook' } |
  Select-Object -First 5 UpdateTitle, InstallationState

From Defender XDR, DeviceTvmSoftwareInventory gives a per-device view that survives C2R/MSI differences:

DeviceTvmSoftwareInventory
| where SoftwareName has "Office" or SoftwareName has "Outlook"
| project DeviceName, SoftwareVendor, SoftwareName, SoftwareVersion, EndOfSupportDate, OSPlatform
| summarize arg_max(SoftwareVersion, *) by DeviceName, SoftwareName

Building a per-host exposure list instead of a single fleet-wide number

"94% patched" is an executive metric, not an engineering one. What you need is a join. A host is genuinely exposed when it is unpatched Outlook and SMB signing not required and outbound 445/139 reachable and the user is not in Protected Users.

The last column is what turns an audit into an incident response. Sort by it descending.

Audit Step 2 — Find Outbound NTLM Leaks That Are Already Happening

Windows event IDs that matter: 4624 Logon Type 3, 4776, and the NTLM operational log 8001–8005

On the 8001–8005 range: these events only appear once you have enabled the Network security: Restrict NTLM audit policies, and I recommend verifying the exact ID-to-outcome mapping against the documentation for your build rather than hardcoding my recollection into a detection rule. What is reliable is the source log and the fact that the events fire per-sending-process, which is exactly the attribution you want.

A PowerShell query for the DC-side signal:

Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4776
  StartTime = (Get-Date).AddHours(-24)
} -ErrorAction SilentlyContinue |
  Select-Object -First 5 TimeCreated, @{n='Account';e={$_.Properties[1].Value}},
    @{n='Workstation';e={$_.Properties[2].Value}}

Sample shape:

TimeCreated          Account  Workstation
-----------          -------  -----------
11/11/2026 09:14:02  ALICE    WKS-0142
11/11/2026 09:14:02  ALICE    WKS-0142
11/11/2026 09:31:47  BOB      WKS-0871

The signal to hunt: a workstation name authenticating to something that is not a file server, and repeating on a schedule.

Egress signals on TCP 445 and 139 from workstation subnets

If you have firewall or NetFlow data, this is the cheapest detection you will write all week. Workstations talking SMB to other workstations is almost never legitimate in a modern environment.

From Defender XDR, DeviceNetworkEvents gives you process attribution directly — which is the key detail, because "OUTLOOK.EXE opened a TCP connection to port 445 on a private address" is not ambiguous:

DeviceNetworkEvents
| where ActionType == "ConnectionSuccess"
| where RemotePort in (445, 139)
| where RemoteIPType == "Private"
| where InitiatingProcessFileName =~ "OUTLOOK.EXE"
| project Timestamp, DeviceName, InitiatingProcessAccountUpn,
          RemoteIP, RemotePort, InitiatingProcessCommandLine
| sort by Timestamp desc

Even if the November 2026 flaw turns out not to use SMB, this query is worth keeping permanently. It catches every coercion class that lands on 445.

Detection queries for workstation-to-workstation SMB authentication anomalies

Combine the identity side and the network side. On the SecurityEvent table:

SecurityEvent
| where EventID == 4624 and LogonType == 3
| where AuthenticationPackageName =~ "NTLM"
| where AccountType == "User"
| project TimeGenerated, Computer, Account, WorkstationName, IpAddress
| summarize Connections = count(), Targets = make_set(Computer, 5)
    by Account, WorkstationName, bin(TimeGenerated, 1h)
| where Connections > 5

Two things to sanity-check on your own tenant before trusting this: the AuthenticationPackageName field name in your SecurityEvent schema, and whether your logon auditing policy actually captures Type 3 successes. I have seen both wrong more than once.

Audit Step 3 — Measure Your Actual Relay Surface

Checking SMB signing enforcement with a scoped PowerShell or GPO report

Locally:

Get-SmbServerConfiguration |
  Select-Object EnableSecuritySignature, RequireSecuritySignature, EnableSMB1Protocol

EnableSecuritySignature RequireSecuritySignature EnableSMB1Protocol
----------------------- ------------------------ -------------------
True                    False                    False

That RequireSecuritySignature = False is the finding. Enabled-but-not-required means the client chooses, and an attacker relaying controls the client.

Across a scoped set of hosts:

$targets = Get-Content .\fileservers.txt
Invoke-Command -ComputerName $targets -ScriptBlock {
  $c = Get-SmbServerConfiguration
  [pscustomobject]@{
    Host     = $env:COMPUTERNAME
    Require  = $c.RequireSecuritySignature
    SMB1     = $c.EnableSMB1Protocol
  }
} -ErrorAction SilentlyContinue | Select-Object Host, Require, SMB1 | Sort-Object Require

Do not run this against 4,000 hosts and expect clean results. Run it against the subset that would be a relay target: file servers, jump hosts, and anything with admin shares enabled.

Verifying LDAP signing and channel binding requirements

On every domain controller, read two registry values:

$vals = 'LDAPServerIntegrity','LdapEnforceChannelBinding'
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' |
  Select-Object $vals

LDAPServerIntegrity       LdapEnforceChannelBinding
-------------------       --------------------------
2                         2

Interpretation: LDAPServerIntegrity 1 = none, 2 = require signing. LdapEnforceChannelBinding 0 = never, 1 = when supported, 2 = always. A DC sitting at 1 and 0 is a relay destination. Microsoft's KB4520412 / LDAP channel binding and signing guidance covers the staged rollout — it has been available since 2020, so there is no argument for being at 0 in 2026.

Identifying ADCS and other high-value relay endpoints that lack EPA

First, does Web Enrollment even exist in your environment?

Get-WindowsFeature -Name ADCS-Web-Enrollment | Select-Object Name, InstallState

If it does, check the IIS authentication configuration on the CertSrv application:

& "$env:windir\system32\inetsrv\appcmd.exe" list config "Default Web Site/CertSrv" `
  -section:system.webServer/security/authentication/windowsAuthentication

<windowsAuthentication enabled="true" useKernelMode="true">
  <extendedProtection tokenChecking="Allow" flags="None" />
</windowsAuthentication>

tokenChecking="Allow" fails open. Require is the setting that breaks the ESC8 relay: the authentication token must be bound to the channel, so a relayed auth over a fresh TCP connection is rejected. The Certified Pre-Owned research documents the whole ESC family and is still the best reference for what to check beyond /certsrv.

If you have Web Enrollment installed on an enterprise CA and tokenChecking is not Require, fix that before you finish triaging the November release. It is a one-line configuration change with a larger risk reduction than most of the CVEs in the release.

Compensating Controls You Can Ship Before the Patch Reaches Every Host

Blocking outbound SMB from workstation VLANs, with a firewall rule example

This is the highest-value, lowest-effort control in the entire list, because it breaks the coercion path regardless of which Outlook vector is used.

New-NetFirewallRule `
  -DisplayName "Block-Outbound-SMB-Workstation" `
  -Direction Outbound `
  -Protocol TCP `
  -RemotePort 445,139 `
  -Action Block `
  -Profile Domain,Private

A safer deployment shape is block-by-default with explicit permits:

New-NetFirewallRule -DisplayName "Allow-SMB-FileServers" -Direction Outbound `
  -Protocol TCP -RemotePort 445 -RemoteAddress 10.20.4.0/24,10.20.5.0/24 `
  -Action Allow -Profile Domain

Verify from a client afterwards — Test-NetConnection -ComputerName 10.20.9.50 -Port 445 should return TcpTestSucceeded : False against a peer workstation and True against a permitted file server.

Outlook hardening — remote content, picture blocking, and the relevant Trust Center registry keys

I'll be straight with you about this one, because it is where bad blog posts invent registry values.

What I am confident about: blocking automatic picture download is the single most effective client-side mitigation for the image-based coercion path, it is configurable in Outlook's Trust Center, and it is enforceable at scale through the Office ADMX templates or the Office Cloud Policy Service. What I am not confident about is the exact per-user HKCU value name that stores the toggle on a given build, so I do not hand-edit it — I check the policy layer instead:

## Did the policy actually land, or is the UI just showing a default?
Get-ChildItem 'HKLM:\SOFTWARE\Policies\Microsoft\Office\16.0\Outlook' -ErrorAction SilentlyContinue |
  Select-Object PSChildName
Get-GPOReport -All -ReportType Xml |
  Select-String -Pattern 'Outlook' -SimpleMatch | Select-Object -First 5

The limitation that matters: remote content blocking does not cover UNC paths in HTML bodies, OLE object resolution, or calendar reminder file paths. CVE-2023-23397 was a reminder property, and no picture setting would have stopped it. That is precisely why the network control above has to exist — the client-side settings are per-vector, and the vector changes.

Two more settings worth verifying on the endpoint rather than trusting the GUI:

## NTLMv2 only, refuse LM and NTLM
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel

## Is Credential Guard actually running?
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object SecurityServicesRunning, VirtualizationBasedSecurityStatus

NTLM restriction policy and auditing via the RestrictNTLM settings

RestrictSendingNTLMTraffic under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 is the control that stops the leak at the source. Values: 0 = allow all, 1 = audit/block only to a deny list, 2 = block all outbound NTLM except explicitly allowed servers listed in ClientAllowedNTLMServers (a REG_MULTI_SZ).

The rollout order that does not cause an outage:

1. Enable the audit policies (Network security: Restrict NTLM: Audit Incoming/Outgoing NTLM traffic) and let them run for a week. The 8001–8005 events will show you exactly which applications depend on NTLM, with process attribution.
2. Enable RestrictSendingNTLMTraffic = 1 with a deny list containing your known-bad destinations.
3. Move to 2 with ClientAllowedNTLMServers populated from step 1's evidence.

Step 1 is the one people skip, and step 1 is the one that prevents you from breaking a line-of-business app on a Friday. Microsoft's Restrict NTLM policy documentation lists the full value semantics and the exception list behavior.

Credential Guard and Protected Users as depth, not as a substitute for patching

Here is where I will take a clear position: Credential Guard does not help with this class of attack, and treating it as a mitigation is a category error.

Credential Guard isolates LSASS so that reusable credential material cannot be extracted from memory. In a coercion attack, nothing is extracted. LSASS is asked, legitimately, to compute a response to a challenge — it does that happily, and the response leaves the machine over the network. The protection is at the wrong layer.

What does help, at the account layer:

• Protected Users membership blocks NTLM authentication entirely for those accounts, along with cached credentials and unconstrained delegation. Put every Tier 0 and Tier 1 admin account in it. That converts a relayed admin session from critical to impossible.
• Tier separation so that a workstation-captured response belongs to an account that cannot write to anything interesting.

Neither is a substitute for the patch. Both are worth doing this week if you have not.

Triaging a Four-Digit Patch Tuesday Without Losing the One That Matters

Rank on known exploitation first, then exposure, then CVSS — not the reverse

CVSS measures the severity of a hypothetical exploitation, not the likelihood that someone is exploiting it against you right now. A 9.8 in a product you do not run outranks nothing. A 7.1 with an Exploitation Detected flag and a public proof-of-concept outranks almost everything.

My ordering:

1. Exploited in the wild (Microsoft's exploitation flag, CISA KEV).
2. Reachable from your exposure list — internet-facing, or reachable from a workstation VLAN.
3. Pre-auth over post-auth.
4. Identity infrastructure over application servers, because a domain compromise resets the whole exercise.
5. CVSS score, last.

The order I would apply patches this cycle and the reasoning behind it

And the part that matters more than the table: if you cannot get the Outlook fix onto a host today, ship the network block today. The patch closes the specific vector. The egress rule closes the class.

A short table mapping finding type to owner and acceptable remediation window

What I Confirmed, What I Inferred, and What I Did Not Test

Confirmed from the source material: Microsoft confirmed in-the-wild exploitation of an Outlook flaw that steals Windows authentication hashes; the fix shipped in the November 10, 2026 Patch Tuesday release; the release contained roughly 1,093–1,094 vulnerabilities depending on which report you read; two independent outlets covered it on November 10–11, 2026.

Confirmed from documented Windows and Microsoft behavior: the Net-NTLMv2 response derivation, the relay-breaking role of SMB signing / LDAP channel binding / EPA, the registry value names and their semantics, the correct appcmd section for IIS extended protection, and the CVE-2023-23397 / CVE-2024-21413 precedents.

Inferred, not confirmed: that the November 2026 flaw follows one of the historical Outlook coercion patterns. I listed the patterns because they are the ones that have recurred, not because I know which one applies. That would need confirmation from MSRC's advisory.

Not tested: the exact CVE identifier, the affected build range, and the trigger surface — none of these appeared in my source material, so I did not invent them. The command outputs shown above are representative samples from a lab host, not captures from a production fleet; the commands themselves are standard documented cmdlets, but you should expect your values to differ. I also did not test whether the specific November 2026 fix can be bypassed, and I would not assume it cannot.

Further Reading

• MSRC Security Update Guide — filter the November 2026 release on Exploitation Detected to get the actual CVE ID and affected builds for the Outlook flaw.
• CVE-2023-23397 (Outlook elevation of privilege, exploited) — the calendar reminder coercion precedent.
• CVE-2024-21413 (Outlook file:// moniker / Protected View bypass) — the hyperlink coercion precedent.
• Microsoft NTLM overview (Win32) — protocol background for the challenge-response mechanics.
• Network security: Restrict NTLM — outgoing NTLM traffic to remote servers — value semantics and the ClientAllowedNTLMServers exception list.
• KB4520412 — LDAP channel binding and LDAP signing requirements — the staged rollout for LDAPServerIntegrity and LdapEnforceChannelBinding.
• Certified Pre-Owned (SpecterOps) — ADCS attack paths including ESC8 and what EPA actually blocks.
• CISA Known Exploited Vulnerabilities catalog — cross-check the exploitation flag against a second primary source.
• Hashcat example hashes — mode 5600 reference for Net-NTLMv2.

Conclusion — Patching Is the Easy Part; Proving You Are Not Relaying Is the Work

Applying the Outlook fix is a deployment task. It will get done, eventually, with a ring-based rollout and a compliance dashboard that says 97%.

The harder question, and the one I would want answered before I signed off on this cycle, is: on the hosts that are still unpatched tonight, can an attacker turn a coerced NTLM response into a session somewhere? If the answer is "probably not, but I have not checked," then you have not remediated the exploited vulnerability — you have scheduled its remediation and accepted the risk in the interim without measuring it.

Three things you can do this week that do not depend on the patch reaching every host: block outbound SMB from workstations except to explicit file servers, require SMB signing on relay targets, and set tokenChecking="Require" on any ADCS web enrollment endpoint. Then go pull the CVE ID from MSRC and finish the patch rollout, because the network controls are a backstop, not a resolution.