Analyzing CVE-2026-21513: APT28's MSHTML 0-Day Playbook
Just saw the Akamai report regarding APT28 exploiting CVE-2026-21513 prior to the February 2026 Patch Tuesday. It’s an 8.8 CVSS score, but the 'security feature bypass' classification is what concerns me most. It suggests they aren't necessarily breaking out of the sandbox, but rather confusing the MSHTML Framework's protection mechanisms to allow unauthorized actions.
Given that MSHTML (Trident) is still lurking in various legacy enterprise applications and Office previews, this attack surface is larger than we'd like to admit. We know APT28 has a history of leveraging this platform; this feels like a refinement of their old favorites rather than a brand new vector.
I'm currently updating our detection logic to focus on anomalous process chains originating from binaries that host the WebBrowser control. We can't rely solely on the patch since the exploitation window was open before the fix was available.
Here is a basic KQL query I'm using to hunt for suspicious parent-child processes related to this vector in Sentinel:
DeviceProcessEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName in~ ("excel.exe", "winword.exe", "outlook.exe", "iexplore.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "mshta.exe", "wscript.exe")
| project Timestamp, DeviceName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, SHA256
| where isnotempty(InitiatingProcessCommandLine)
Has anyone else started hunting for this specific CVE in their environment, or are we mostly relying on generic ASR rules to block the behavior?
Good start on the query, but I'd recommend filtering out signed macro activity to reduce noise. In our SOC, we've had success correlating this with network events. If a document spawns a shell and immediately hits a known bad IP or non-standard port, that's your smoking gun. We also enabled ASR rule 'Block all Office applications from creating child processes' temporarily, which broke a few internal workflows but caught the activity instantly.
From a pentester's perspective, this bypass is nasty because it often bypasses Mark of the Web (MOTW) protections. If APT28 is combining this with macro delivery or phishing links, standard user awareness training won't stop the execution if the browser component fails to enforce the security zone. I'd suggest checking your AppLocker policies to ensure mshta.exe is strictly blocked unless absolutely necessary.
Validating Derek's point on MOTW—once that's gone, the file looks trusted locally. Since APT28 loves web shells, I’d suggest tightening egress filtering immediately. If they bypass the endpoint protections, we catch them at the network boundary.
Here’s a Kusto query we use to correlate suspicious MSHTML process spawns with external IP connections:
kusto DeviceProcessEvents
| where FileName in ~ ("mshtml.dll", "iexplore.exe")
| join kind=inner DeviceNetworkEvents on DeviceId
| where RemotePort == 443 and InitiatingProcessFileName != "iexplore.exe"
Solid insights. From a DLP standpoint, if the MOTW fails, we rely on behavioral analysis. I recommend hunting for suspicious parent-child process chains, specifically legacy Office apps spawning shells via MSHTML. You can use this PowerShell snippet to audit local machines for recent activity patterns we've associated with this CVE family:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.Message -match 'ParentProcessName.*\\WINWORD.EXE' -and $_.Message -match 'NewProcessName.*\\cmd.exe'}
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access