CVE-2026-32202: APT28's Zero-Click NTLM Theft Through an Incomplete Patch

The CVSS score is 4.3. The actual blast radius is whatever a Russian military intelligence agency wants to do with your domain credentials. CVE-2026-32202 is the latest reminder that severity ratings reflect a vulnerability's mechanics, not its operational value to a real attacker. Microsoft shipped this fix on April 14 with the wrong exploitability index, the wrong exploited flag, and the wrong CVSS vector. Two weeks later, on April 27, they corrected the advisory to confirm active exploitation. The next day, CISA added it to the Known Exploited Vulnerabilities catalog with a hard May 12 federal deadline. You have eight days.

The honest version of what this bug does: opening a folder in Windows Explorer, browsing a network share, plugging in a USB stick, or extracting a ZIP archive that contains a single crafted shortcut file is enough to silently transmit your NTLMv2 password hash to an attacker-controlled server. No clicks. No warning dialog. No SmartScreen prompt. Akamai's Maor Dahan, who discovered the flaw, calls it a "zero-click authentication coercion" issue. APT28 has been chaining a related vulnerability against Ukraine and EU targets since December 2025. The patched version of that exploit chain quietly stopped working in February, but the credential theft path stayed open. That open path is CVE-2026-32202.

How the incomplete patch broke down

The original APT28 zero-day was tracked as CVE-2026-21510 (RCE) and CVE-2026-21513 (LNK file handling). Both rated CVSS 8.8. The campaign delivered weaponized Windows Shortcut files to victims through a phishing email pretending to be from Ukraine's hydro-meteorological center. When the LNK file resolved, Windows Shell parsed an embedded UNC path that pointed at the attacker's SMB server, downloaded a Control Panel object as a DLL, and executed it without SmartScreen validation.

Microsoft's February Patch Tuesday closed the SmartScreen bypass and the RCE. They added a new COM object, ControlPanelLinkSite, that gates SmartScreen verification through ShellExecuteExW. What Akamai found by testing the patch is that the verification fires too late in the execution chain. Earlier in the same call path, CControlPanelFolder::GetUIObjectOf calls PathFileExistsW inside GetModuleMapped to resolve the UNC path for icon extraction. That call triggers the SMB connection to the attacker's server the moment Explorer renders the folder. By the time SmartScreen wakes up to check the file's signature, the NTLMv2 handshake has already happened and the credential is on a server in Moscow.

This is not a memory corruption bug or a logic flaw in some niche component. It is a simple ordering problem in shell32.dll — a trust check that fires after the network call it was supposed to gate. The kind of bug that should never have shipped in 2026, in a code path APT28 had already demonstrated they could weaponize.

Why the CVSS 4.3 is misleading

CVSS 4.3 is the metric for "an attacker can view some sensitive information." On paper that sounds like a low-priority spoofing issue, the kind your patch board defers to next month's change window. The metric is technically accurate and operationally meaningless. Here is what an attacker actually does with the "sensitive information" disclosed:

• Crack it offline. Net-NTLMv2 hashes from a domain user account fall to a modest GPU rig in hours to days for typical enterprise password lengths. If the victim is a privileged service account or a domain admin who happens to browse a folder, the offline crack times collapse to minutes against any password under 12 characters.
• Relay it live. NTLM relay attacks have been the bread and butter of internal pentests since 2008. The captured hash gets forwarded in real time against another service that accepts NTLM authentication — a SharePoint server, an internal LDAP endpoint, an MSSQL instance, an Exchange OWA portal — and authenticates as the victim with no cracking required. ntlmrelayx.py from the impacket toolkit does this in two commands.
• Pivot to Active Directory. If the relayed authentication lands on an LDAP service with the right ACL — and many environments still have over-privileged service accounts — the attacker writes a new computer object to AD, sets a Resource-Based Constrained Delegation entry, and is one S4U2Self call away from impersonating any domain user, including Domain Admin.

The CVSS metric does not model "credential, then chain into AD takeover." That is an operational concern, not a vulnerability mechanic. Read past the score.

What every Windows-network operator should do this week

Patching is necessary but not sufficient. The April 2026 Patch Tuesday fixes the immediate Explorer call ordering issue. It does not fix the architectural problem that NTLM is still spoken outbound from end-user workstations to arbitrary destinations. Variations of this attack will keep landing on whatever the next "we will get to it" CVE turns out to be. The work to do this week breaks into three layers.

Layer 1: Patch verification

If your endpoints applied the April 14 update, you have the binary fix. Do not assume that means deployment. Verify the patch is actually installed across your fleet:

# From a single endpoint
Get-HotFix -Id KB5057xxx | Select-Object HSId,InstalledOn

# Across the fleet via PowerShell remoting
$endpoints = Get-ADComputer -Filter 'OperatingSystem -like "*Windows 10*" -or OperatingSystem -like "*Windows 11*"' -Properties OperatingSystem
$results = Invoke-Command -ComputerName $endpoints.Name -ScriptBlock {
    Get-HotFix | Where-Object {$_.InstalledOn -gt (Get-Date).AddDays(-30)} |
        Select-Object PSComputerName,HotFixID,InstalledOn
} -ErrorAction SilentlyContinue
$results | Export-Csv -Path C:\Temp\april-2026-patch-status.csv -NoTypeInformation

The output is your patch verification record. Anything missing the relevant April KB is exposed and stays exposed until you push the update.

Layer 2: Block outbound SMB at the perimeter

End-user workstations should not be initiating SMB connections to the public internet. Period. There is no business justification for it that survives a five-minute conversation. Block TCP/445 and TCP/139 outbound at the perimeter firewall and at the host firewall:

# Windows Defender Firewall - host-level outbound block
New-NetFirewallRule -DisplayName "Block Outbound SMB Internet" `
    -Direction Outbound `
    -Protocol TCP `
    -RemotePort 445,139 `
    -RemoteAddress "Internet" `
    -Action Block `
    -Profile Any

# Verify the rule is active
Get-NetFirewallRule -DisplayName "Block Outbound SMB Internet" |
    Get-NetFirewallPortFilter | Format-Table

Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Outbound Rules. Match the same configuration. Test on a pilot OU first, then roll out fleet-wide. The only systems that should retain outbound SMB access are domain controllers, file servers, and any specifically allowlisted business application — never user workstations.

Layer 3: Reduce NTLM exposure

The harder conversation. NTLM is the gift that keeps on giving for attackers, and the only durable fix is to stop using it. Microsoft has been telegraphing the deprecation for years. Most environments have ignored it because legacy applications and laptops join the domain over NTLM and nobody wants to be the one who breaks the printer driver from 2014.

The pragmatic path forward, in order of operational difficulty:

1. Audit NTLM usage. Enable NTLM auditing on domain controllers via Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Restrict NTLM: Audit Incoming NTLM Traffic. Set to "Enable auditing for all accounts." Review the resulting Event 8004 logs in Microsoft-Windows-NTLM/Operational to inventory which applications and accounts still depend on NTLM.
2. Enforce SMB signing and Extended Protection for Authentication (EPA). SMB signing prevents inline relay against SMB endpoints. EPA prevents inline relay against HTTP-based services like LDAPS and Exchange OWA. Both have been default-recommended for years and both are still off in the majority of mid-market environments we audit.
3. Enable LDAP signing and channel binding on every domain controller. The single most common NTLM relay path goes through LDAP. Microsoft has the relevant settings in advisory ADV190023, and the Group Policy entries are Domain controller: LDAP server signing requirements and Domain controller: LDAP server channel binding token requirements. Set both to "Required." Pilot first, then enforce.
4. Migrate to Kerberos-only where possible. Modern Windows environments support Kerberos for nearly every authentication path. Use the Restrict NTLM: Outgoing NTLM traffic to remote servers GPO setting to "Deny all" on the systems you have proven do not need NTLM, then expand the scope as you migrate legacy applications.

Detection: what to hunt for now

If you have any reason to suspect exposure to APT28 infrastructure or to LNK files in the wild, hunt for outbound NTLM authentication originating from end-user workstations. The signal is clean and the false positive rate is low because legitimate workstations almost never speak NTLM to external SMB endpoints.

# Sysmon Event ID 3 - network connection from explorer.exe outbound on 445
# Splunk SPL example
index=sysmon EventCode=3 Image="*\\explorer.exe" DestinationPort=445
| where NOT cidrmatch("10.0.0.0/8", DestinationIp)
   AND NOT cidrmatch("172.16.0.0/12", DestinationIp)
   AND NOT cidrmatch("192.168.0.0/16", DestinationIp)
| stats count by ComputerName, DestinationIp, DestinationHostname

# Microsoft Sentinel KQL equivalent
DeviceNetworkEvents
| where InitiatingProcessFileName == "explorer.exe"
| where RemotePort in (445, 139)
| where not(ipv4_is_private(RemoteIP))
| summarize count() by DeviceName, RemoteIP, RemoteUrl

Any hits in the result set are worth a closer look. Pull the LNK files from the user's Recent items and shared drives. Get-Item -Path $shortcut | Select-Object -ExpandProperty Target reveals the embedded path. UNC targets pointing at unfamiliar external hosts are the smoking gun.

What this means if you do not run on-prem AD

An increasing number of SMBs have moved to Entra ID-only or hybrid configurations and assume NTLM is no longer their problem. It still is, in two specific ways. First, Hybrid Azure AD-joined Windows endpoints continue to authenticate via NTLM to on-prem services and across SMB shares — every laptop with an Entra ID identity that occasionally touches an internal file server is in scope. Second, "Entra ID-only" environments still have local accounts on Windows endpoints, and those accounts use NTLM for any local-network resource. The attack surface is smaller, but it is not zero.

The right baseline for a modern SMB environment is "no NTLM, anywhere, ever." If you cannot make that statement, you have NTLM exposure. The April 2026 patch closes one Explorer-shaped hole. The next zero-click coercion bug, on a different shell component or URI handler, will land in some month between now and a Patch Tuesday a year from now. Hardening the underlying authentication protocol is the only path that scales.

The bigger lesson on patch metadata

CVE-2026-32202 sat at "low-priority spoofing bug" in Microsoft's advisory for two weeks while APT28 was actively exploiting it. The disconnect between the published metadata and the operational reality is not unusual. Microsoft Threat Intelligence and Akamai both had the data to update the severity sooner. The advisory caught up only after BleepingComputer pressed Microsoft on the inconsistency.

Run your patch program on the assumption that vendor severity ratings are a starting point, not a verdict. The signals worth weighting more heavily than CVSS: KEV inclusion, attribution to a named threat actor, exploitation reporting from independent researchers like Akamai or Mandiant, and any CVE that touches authentication, credential handling, or shell parsing. Any of those flags should pull a vulnerability into the "drop everything" bucket regardless of what Microsoft's advisory thinks of it on the day it ships.