Loading story…
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.
Get the actors, campaigns, and ATT&CK mapping behind it.
3 events from the most recent confirmed update back to the earliest known activity.
The reference states that Less Privileged AppContainer (LPAC), a more restrictive extension of AppContainer, was introduced in Windows 10.
The reference states that Windows Runtime (WinRT) was introduced with Windows 8 for Windows Store applications, and that AppContainer was introduced in Windows 8 as a sandboxing feature.
A Hunt & Hackett blog post analyzes how COM and WinRT initialization is blocked in LPAC without the lpacCom capability and describes bypass techniques for in-process components, including manual activation and patching or hooking the client-side capability check. The post also notes that registryRead is required for registry-based activation and that out-of-process activation remains blocked.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
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 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.
Aug 21, 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
Windows attackers have used **Component Object Model (COM) hijacking** to gain persistence by altering Registry entries so legitimate applications load attacker-controlled code during normal execution. MITRE documents the technique as `T1546.015`, noting that adversaries can replace COM object references or abuse **TypeLib** keys to redirect execution to malicious DLLs, scripts, or even remotely hosted payloads via the `script:` moniker. The approach is designed to survive reboots while blending into routine system activity, especially when attackers choose COM objects that are invoked often enough to ensure execution but not so critical that failures immediately expose the compromise. Public examples show both proof-of-concept and criminal use. A technical walkthrough demonstrated creating a user-level `HKCU\Software\Classes\CLSID\{...}\InprocServer32` entry so a process such as **Firefox** would load a malicious DLL instead of falling back to system-wide COM registrations, illustrating how COM hijacking can provide persistence and defense evasion. In the wild, the **W32.Silon** banking trojan reportedly replaced a CLSID reference for Microsoft-signed `msimtf.dll` with a malicious `msjet51.dll`, causing **Internet Explorer** to load the payload, steal online banking credentials, hide artifacts, and exfiltrate captured data to command-and-control servers.
Aug 15, 2026