Loading story…
Researchers reported that Windows' Less Privileged AppContainer (LPAC) sandbox can be made to use some in-process COM and WinRT components without the lpacCom capability by creating or ensuring a process-wide multi-threaded apartment through CoIncrementMTAUsage rather than CoInitializeEx. The finding builds on Windows COM apartment behavior, including the distinction between multi-threaded apartments (MTA) and single-threaded apartments (STA), and shows that MTA-compatible in-process components may be reachable despite the intended capability gate.
The bypass does not extend cleanly to apartment-threaded or out-of-process COM objects. The research found that once COM falls back to worker STAs, RPC remoting, or CoInitializeSecurity, enforcement shifts to RPCSS/DCOM on the server side, where security descriptors and callbacks still validate lpacCom. As a result, the reported weakness affects in-process LPAC checks for certain MTA scenarios, while cross-apartment and out-of-process COM activation remain blocked by existing RPCSS and DCOM protections.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
A Hunt & Hackett blog post analyzed COM and WinRT behavior in the Less Privileged AppContainer sandbox and showed that CoIncrementMTAUsage can bypass the in-process lpacCom check for MTA-compatible components. The post also concluded that RPCSS and DCOM server-side checks still enforce lpacCom for cross-apartment and out-of-process COM activation.
Microsoft published documentation describing the Single-Threaded Apartment COM model for Win32 applications, including how STA threads and objects behave.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers detailed how Microsoft Windows restricts COM and WinRT initialization inside **Less Privileged AppContainer (LPAC)** sandboxes through the `lpacCom` capability, and how those checks can be bypassed for in-process components. In LPAC environments without `lpacCom`, `CoInitializeEx` and `RoInitialize` return access denied, which causes later COM and WinRT activation attempts to fail as not initialized. The report ties those restrictions to Windows' COM architecture, where initialization is a prerequisite for object activation and use. The write-up says in-process activation can still be achieved by manually reproducing normal COM and WinRT loading behavior: reading component registration from the registry, loading the target DLL, and directly calling `DllGetClassObject` or `DllGetActivationFactory`. It further claims the `lpacCom` control is effectively enforced on the client side because `combase` relies on `RtlCheckTokenCapability`, making local patching or hooking of that capability check sufficient to bypass the restriction for in-process components. The researchers noted that `registryRead` access is still required for standard registry-based activation, while out-of-process activation remains blocked and was left for further investigation.
Aug 13, 2026
Security researchers have identified new and stealthy techniques leveraging Microsoft’s Component Object Model (COM) and Distributed COM (DCOM) technologies for lateral movement and persistence within Windows environments. One report details the discovery of a previously undocumented DCOM object that can be abused for remote command execution and persistence by exploiting Control Panel items, highlighting both the technical mechanisms and detection strategies for defenders. The research also reviews the current state of tools like Impacket’s `dcomexec` script and discusses how adversaries enumerate and leverage COM objects for malicious purposes. In a separate breach assessment, investigators uncovered a threat actor using a ComHandler within Windows Scheduled Tasks to maintain long-term command-and-control access. The attacker deployed custom surrogate DLLs and targeted tasks named `User_Feed_Synchronization-{GUID}` to execute code, remaining undetected for at least seven months. This technique, tracked as UKC-1230, demonstrates the real-world application of COM-based persistence and the challenges defenders face in detecting such abuse, especially when attackers mimic legitimate system activity.
Jun 29, 2026
Multiple public write-ups detailed how Windows service and RPC design flaws enabled **local privilege escalation**, **sandbox escape**, and in some cases reliable code execution. Research on the Windows SSDP service linked `FC_BINDING_CONTEXT` misuse to **CVE-2025-48815**, showing that a context handle from one RPC interface could be passed into another interface expecting a different type and ultimately abused to call `CloseHandle` on an unintended handle. Separate analysis of the Windows telephony service described **CVE-2024-26230** as a use-after-free in `tapisrv` caused by improper ownership validation of RPC-managed objects, allowing a dangling pointer to be reclaimed with attacker-controlled data and steered toward `LoadLibraryW` despite **XFG** protections. Earlier Windows RPC research also covered Storage Service bugs **CVE-2019-0983** and **CVE-2019-0998**, where file-copy, directory, and ACL logic exposed through RPC could be abused to overwrite privileged files or alter their security descriptors. Other disclosures showed the same pattern across Windows subsystems. Analysis of **CVE-2022-22715** in `npfs.sys` demonstrated that malformed `LOCAL\` named pipe paths could trigger integer overflow and out-of-bounds kernel writes, enabling escape from the Adobe Reader **AppContainer** sandbox and escalation to kernel read/write. Research into **CVE-2021-1648** in `splwow64` described bypasses in printer-handle validation and an arbitrary address read, while older work on **CVE-2018-8550** examined COM `DfMarshal` abuse for elevation of privilege through privileged unmarshaling paths. Related reporting also highlighted Microsoft hard-link mitigations and a Citrix restricted-desktop breakout that relied on allowed scripting components rather than a zero-day, underscoring how weak validation, unsafe object handling, and incomplete execution controls repeatedly exposed high-impact privilege boundaries on Windows.
Aug 3, 2026