HIGH: APT28 Exploits Incomplete Windows Shell Patch for Zero-Click NTLM Theft (CVE-2026-32202)

If you ever wanted proof that "patched" is not a synonym for "fixed," Microsoft just handed it to you on a silver platter. CVE-2026-32202 is a Windows Shell spoofing flaw that Microsoft initially shipped without much fanfare during the April 14 Patch Tuesday cycle, only to come back two weeks later and quietly admit two uncomfortable truths. The vulnerability is being actively exploited in the wild, and it exists because the patch they pushed back in February for an APT28 zero-day did not actually close the door it was supposed to slam.

The drop-everything calculus on this one is interesting. The CVSS sits at a relatively modest 4.3, which would normally land it somewhere between "schedule it for next month" and "don't lose sleep." That number is misleading. The bug is being weaponized by Russia's GRU-affiliated APT28, also tracked as Fancy Bear, Forest Blizzard, GruesomeLarch, and Pawn Storm depending on which vendor's threat reports you read on a given Tuesday. The campaign began in December 2025 and has been hitting Ukrainian government targets and European Union nations ever since. CVSS scores measure technical impact in isolation. They do not measure the fact that a foreign intelligence service is sitting in your environment harvesting credentials.

Akamai's research team, with security researcher Maor Dahan leading the analysis, dug into the original APT28 zero-day chain and found that Microsoft's February fix did not finish the job. The original zero-day was tracked as CVE-2026-21510 and CVE-2026-21513, both rated CVSS 8.8, both involving malicious Windows Shortcut files that could be used to load attacker-controlled DLLs from remote servers via UNC paths. Microsoft addressed the remote code execution path by enforcing SmartScreen verification on file signatures and origin zones. What they did not address was the order of operations. The trust check was happening too late. By the time SmartScreen got around to deciding whether the file should run, Windows Explorer had already reached out across the network to grab an icon, established an SMB session with the attacker's server, and politely handed over the user's NTLM credentials in the process.

That gap between path resolution and trust verification is the entire ballgame. When a victim opens a folder containing a malicious LNK file, Windows Explorer asks shell32 to fetch an icon from whatever path the shortcut specifies. If that path is a UNC pointing to an attacker server, the operating system initiates an SMB connection without asking permission, without a click, and without any warning to the user. The SMB handshake includes automatic NTLM authentication, which means the victim's Net-NTLMv2 hash is now sitting on a server in Moscow or wherever else the campaign infrastructure happens to live. From there the attacker can either crack the hash offline or relay it in real time against another service that accepts NTLM, like a SharePoint server or an internal LDAP endpoint. Either way the victim never touched a thing.

This is the kind of attack that frustrates defenders because the user did exactly what every security awareness training has told them to do. They did not click a suspicious link. They did not open an attachment. They opened a folder. That is it. Browsing a network share, connecting a USB stick, or extracting a ZIP archive that contains a crafted LNK is enough to fire the chain. Windows Explorer does the rest, helpfully and silently, exactly as designed.

Microsoft's handling of the disclosure has been, to put it generously, awkward. The original April 14 advisory listed CVE-2026-32202 with incorrect metadata, including the wrong exploitability index, the wrong exploited flag, and an inaccurate CVSS vector. On April 27, Microsoft updated the advisory to confirm active exploitation and corrected the technical fields. The two-week gap between "low-priority spoofing bug" and "actively exploited by a Russian intelligence service" is exactly the window where defenders were almost certainly relying on Microsoft's initial assessment to make patching decisions. That window is precisely the kind of thing APT28 plans for.

For administrators, the immediate move is to apply the April 2026 Patch Tuesday updates if you have not already. If you patched on the 14th, you are technically covered for the binary fix, but you should revisit your vulnerability management workflow and ask why a CVSS 4.3 spoofing bug was sitting in the "we will get to it" pile when it should have been in the "drop everything" pile. The right answer is that you trusted Microsoft's initial scoring, which is a reasonable thing to do, and Microsoft's initial scoring was wrong. That is worth a conversation with your team about how you weight vendor severity ratings against actual threat intelligence going forward.

Patching is necessary but not sufficient. NTLM is the gift that keeps on giving for attackers, and any environment that still permits NTLM authentication outbound to arbitrary destinations is going to keep getting bitten by variations of this same attack. Microsoft has been telling people to disable NTLM for years, and most environments have ignored that advice because legacy applications make it painful. If you needed an excuse to revisit that decision, here it is. Block outbound SMB at your perimeter firewall. Enforce SMB signing and Extended Protection for Authentication on internal services. Audit which accounts can be relayed and tighten the privileges of any account whose hash might end up in a foreign capital. Group Policy can disable NTLM authentication selectively, and Windows 11 has been slowly turning the screws on legacy NTLM by default. Modern environments should be pushing toward Kerberos-only wherever possible.

Detection-wise, this attack leaves fingerprints. Outbound SMB connections from end-user workstations to external IP addresses are highly anomalous in most environments, and any decent EDR or network monitoring stack should be flagging them. Unusual LNK files arriving via email, shared drives, or removable media are worth a look, particularly any that contain UNC paths in their target fields. PowerShell hunts using Get-Item against suspect shortcut files will reveal the embedded paths quickly. If you have Sysmon deployed, event ID 3 for network connections originating from explorer.exe or shell32-related processes connecting outbound on port 445 is a high-value detection. Splunk and Sentinel queries for outbound NTLM authentication attempts crossing trust boundaries should already be table stakes for any organization handling sensitive data.

The threat actor profile here matters for response planning. APT28 is not opportunistic crimeware. They pick targets, they plan campaigns, and they tend to chain initial access with longer-term collection objectives. If you find evidence of CVE-2026-32202 exploitation in your environment, do not assume the attackers got the credential and left. Assume they used the credential to pivot, and start hunting for follow-on activity. Look for unusual authentication patterns, lateral movement attempts, credential dumping on member servers, and any outbound traffic to known APT28 infrastructure. The Akamai research and corroborating reports from Microsoft Threat Intelligence have published indicators worth ingesting into your SIEM.

For managed service providers, this story writes its own pitch deck. You have a Russian intelligence service actively exploiting a vulnerability that Microsoft itself initially misclassified, in an environment where most clients are running NTLM because that is just how Windows networks work. The conversation with your customers practically conducts itself. NTLM hardening assessments, SMB egress filtering reviews, and Active Directory tier-zero protection projects are all legitimate engagements that this incident justifies on its own. The smart move is to package a focused offering around credential theft prevention specifically and lead with the question of whether the customer has any visibility into outbound SMB traffic at all. Most do not, and the discovery phase alone often surfaces enough other issues to justify a longer engagement.

The bigger lesson is one that security teams keep relearning. Vendor patches close the specific bug they were written for, not necessarily the underlying class of weakness. When a researcher tells you a fix was incomplete, it usually was, and the second wave of exploitation tends to be smarter than the first. Treat patch notes as the start of an investigation, not the end of one.