COM object hijacking sits in an awkward middle ground: it’s well documented in MITRE ATT&CK, actively used by threat actors ranging from APT29 to opportunistic infostealers, and yet it frequently slips through detections tuned primarily for more visible persistence mechanisms like scheduled tasks and services. The reason is straightforward — COM hijacking requires only a registry write accessible by any user, generates no new process, and produces no easily visible artifact after the redirected DLL has loaded.

The technique is mapped to T1546.015 (Event Triggered Execution: Component Object Model Hijacking) and crosses both Persistence and Privilege Escalation tactics. Understanding how Windows resolves COM objects is the starting point for detection.

How COM Resolution Works

When an application requests a COM object by CLSID (Class ID), Windows searches for the server implementation in the following registry order:

  1. HKCU\Software\Classes\CLSID\{<CLSID>}\InprocServer32 — user-space, writable without elevation
  2. HKLM\Software\Classes\CLSID\{<CLSID>}\InprocServer32 — system-wide, requires admin
  3. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellCompatibility\... (some edge cases)

The user-hive lookup happens first. An attacker who writes a CLSID entry under HKCU pointing to a malicious DLL will have that DLL loaded whenever any application on the system instantiates that COM object — before Windows ever checks the machine-level legitimate entry. No elevation required. No process spawned. The malicious code runs in the context of the application that loaded the COM object.

Several hundred COM objects registered under HKLM are instantiated by common Windows components — Explorer, Task Scheduler, Windows Update, various MMC snap-ins. Attackers target those that are frequently triggered, giving their implant reliable execution on common user actions.

The HKCU Hijack Pattern

The most commonly abused variant writes a new subkey under:

HKCU\Software\Classes\CLSID\{<CLSID>}\InprocServer32

With a (Default) value pointing to the attacker-controlled DLL path, and a ThreadingModel value of Apartment or Both to avoid COM threading errors.

Common COM objects targeted in the wild include {BCDE0395-E52F-467C-8E3D-C4579291692E} (MruPidlList), {42aedc87-2188-41fd-b9a3-0c966feabec1} (CLSID for shell32 DLL browser), and numerous shell extension CLSIDs triggered by Windows Explorer operations.

TypeLib Hijacking

A less-discussed variant targets TypeLib registration. Applications that late-bind COM objects via IDispatch query the TypeLib registry to locate interface definitions. These are stored under:

HKCU\Software\Classes\TypeLib\{<LibID>}\<version>\<locale>\win32

Writing a path to a malicious DLL here achieves the same outcome for applications using TypeLib lookup paths. It’s rarer in the wild but evades some detections that look only at InprocServer32.

Detection Data Sources

Effective COM hijack detection requires two independent signal types: registry write telemetry and DLL load tracking.

Registry writes: Sysmon Event ID 13 (Registry value set) and Event ID 12/14 (Registry create/delete) cover COM-relevant paths. Windows Security audit policy with Object Access: Registry enabled provides similar data natively. For cloud SIEM consumers, Microsoft Defender for Endpoint surfaces these as registry events in the DeviceRegistryEvents table.

Image loads: Sysmon Event ID 7 (Image Loaded) captures DLL loads with full path and hash. The critical attribute here is the combination of a legitimate hosting process (e.g., explorer.exe, mmc.exe) loading a DLL from an anomalous path — %APPDATA%, %TEMP%, %USERPROFILE%\Downloads, or any non-standard location.

Sigma Rules

The following Sigma rules cover the primary detection surfaces.

Rule 1: HKCU COM InprocServer32 Registration

title: COM Object Hijacking via HKCU InprocServer32 Registration
id: a7f3b2c1-4d8e-4f1a-9c2b-3e5d6f7a8b9c
status: experimental
description: Detects registration of COM objects under HKCU\Software\Classes\CLSID that may indicate COM hijacking for persistence.
references:
  - https://attack.mitre.org/techniques/T1546/015/
author: SOC Analyst Hub
date: 2026-08-07
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1546.015
logsource:
  category: registry_set
  product: windows
detection:
  selection:
    TargetObject|contains:
      - '\SOFTWARE\Classes\CLSID\'
    TargetObject|endswith:
      - '\InprocServer32\(Default)'
      - '\InprocServer32\'
    RegistryKeyPath|startswith:
      - 'HKEY_USERS\'
      - 'HKCU\'
  filter_legitimate:
    Details|startswith:
      - 'C:\Windows\'
      - 'C:\Program Files\'
      - 'C:\Program Files (x86)\'
  condition: selection and not filter_legitimate
falsepositives:
  - Software installations that register COM objects to AppData locations (e.g., Chrome, Office add-ins)
  - Developer environments registering COM objects during build
level: medium

Rule 2: DLL Loaded from User-Writable Path by COM Host Process

title: Suspicious DLL Load from User-Writable Path via COM Host
id: b8c4d3e2-5f9a-4b2c-ad3e-4f6e7a8b9c0d
status: experimental
description: Detects DLL loads from user-writable paths by processes known to host COM objects, which may indicate COM hijacking.
references:
  - https://attack.mitre.org/techniques/T1546/015/
author: SOC Analyst Hub
date: 2026-08-07
tags:
  - attack.persistence
  - attack.t1546.015
logsource:
  category: image_load
  product: windows
detection:
  selection_process:
    Image|endswith:
      - '\explorer.exe'
      - '\mmc.exe'
      - '\taskhost.exe'
      - '\taskhostw.exe'
      - '\dllhost.exe'
      - '\svchost.exe'
      - '\searchindexer.exe'
  selection_path:
    ImageLoaded|contains:
      - '\AppData\Local\'
      - '\AppData\Roaming\'
      - '\Users\Public\'
      - '\Temp\'
      - '\Downloads\'
  filter_known_good:
    ImageLoaded|contains:
      - '\AppData\Local\Microsoft\Teams\'
      - '\AppData\Local\Google\Chrome\'
      - '\AppData\Local\Programs\Microsoft VS Code\'
  condition: selection_process and selection_path and not filter_known_good
falsepositives:
  - Electron applications (Teams, Slack, VS Code) load DLLs from AppData
  - User-installed legitimate software
level: high

KQL (Microsoft Sentinel / MDE)

HKCU COM registration via Defender for Endpoint:

DeviceRegistryEvents
| where RegistryKey has_all ("HKEY_CURRENT_USER", "Classes", "CLSID")
    and RegistryKey contains "InprocServer32"
    and ActionType == "RegistryValueSet"
    and RegistryValueName == "(Default)"
    and not (RegistryValueData startswith "C:\\Windows\\"
          or RegistryValueData startswith "C:\\Program Files")
| project Timestamp, DeviceName, InitiatingProcessFileName, 
          InitiatingProcessCommandLine, RegistryKey, RegistryValueData
| sort by Timestamp desc

DLL loaded from user-writable paths by COM host processes:

DeviceImageLoadEvents
| where InitiatingProcessFileName in~ ("explorer.exe", "dllhost.exe", "mmc.exe", 
    "taskhost.exe", "taskhostw.exe", "searchindexer.exe")
    and FolderPath has_any ("AppData\\Local", "AppData\\Roaming", "\\Temp\\", "\\Downloads\\")
    and not FolderPath has_any ("Google\\Chrome", "Microsoft\\Teams", "Programs\\Microsoft")
| project Timestamp, DeviceName, InitiatingProcessFileName, FolderPath, FileName, SHA256
| sort by Timestamp desc

Threat Hunting Approach

Rather than waiting for alert triage, hunt proactively by establishing baselines:

  1. Enumerate HKCU COM entries: Query your endpoint management for the list of COM objects registered under HKCU\Software\Classes\CLSID\ across your fleet. Any CLSID that appears only on a subset of machines with a DLL path in user-writable directories warrants investigation.

  2. Cross-reference with HKLM: For each HKCU CLSID entry, check whether the same CLSID is registered under HKLM. If it is, you have a classic hijack condition — the user-space entry will shadow the system entry for that CLSID.

  3. Check DLL signing: Legitimate COM objects registered to system paths are typically signed by Microsoft or the application vendor. Unsigned DLLs in user-writable paths loaded by system processes are high-confidence indicators.

Known Threat Actor Usage

APT29 (Cozy Bear) has used COM hijacking targeting MRU (Most Recently Used) CLSIDs that fire on Explorer actions. The technique appears in several publicly documented intrusions attributed to the group as a low-noise persistence mechanism following initial compromise. Scattered Spider has also been documented abusing COM hijacking as a secondary persistence path alongside more visible mechanisms.

Reduce false positive rates by maintaining an allowlist of COM objects legitimately registered per application in your environment. Deploying Sysmon Event ID 7 with include filters for DLL loads is essential — without it, COM hijacking via DLL redirect is nearly invisible.