COM Hijacking: The Registry Persistence Technique Hiding in Plain Sight

Component Object Model (COM) hijacking is one of the quietest persistence techniques in the Windows attacker playbook. It leaves no scheduled task, no Run key, no service — just a small edit to a registry value that most defenders never inspect. Because thousands of legitimate COM objects are instantiated during a normal boot and login, a hijacked object blends into the noise and executes with the privileges of whatever process loaded it. This post breaks down how the technique works and, more importantly, how to hunt it before it becomes a foothold you didn't know you had.

How COM resolution actually works

Every COM object is identified by a GUID called a CLSID. When an application wants to instantiate one, Windows looks up that CLSID in the registry to find the DLL or EXE that implements it — the InprocServer32 (for in-process DLLs) or LocalServer32 (for out-of-process EXEs) subkey. The critical detail attackers exploit is search order: Windows checks the per-user hive HKEY_CURRENT_USER\Software\Classes\CLSID before the machine-wide HKEY_LOCAL_MACHINE\Software\Classes\CLSID.

That ordering is the whole game. A standard user can write to their own HKCU hive with no elevation. By registering a CLSID there that already exists in HKLM, an attacker overrides the legitimate object for that user — and any process running in that user's context will happily load the attacker's DLL instead.

The hijack, step by step

A typical hijack of a commonly-loaded CLSID looks like this:

reg add "HKCU\Software\Classes\CLSID\{GUID}\InprocServer32" /ve /d "C:\Users\Public\evil.dll" /f
reg add "HKCU\Software\Classes\CLSID\{GUID}\InprocServer32" /v ThreadingModel /d Apartment /f

The next time a process resolves that CLSID — explorer.exe on shell refresh, a scheduled COM task, or an Office add-in — it loads evil.dll under the user's identity. No reboot, no admin rights, no new autostart entry for a defender to notice.

Two related variants make detection harder:

• TreatAs redirection. Instead of pointing InprocServer32 at a payload, the attacker adds a TreatAs key that transparently maps one CLSID to another. COM follows the redirect, so the original object silently resolves to a substitute class the attacker controls.
• Abandoned / phantom CLSIDs. Software that references a CLSID whose implementing DLL was uninstalled leaves a dangling reference. An attacker who plants a DLL at the expected (now-empty) path gets loaded with zero registry writes flagged as "overrides."

Why it's a favorite for both persistence and escalation

COM hijacking maps to MITRE ATT&CK T1546.015. It earns its place because it delivers three things at once:

1. Persistence. High-frequency CLSIDs re-execute the payload on every login or shell interaction, no separate autostart needed.
2. Privilege context. Hijack a CLSID loaded by an elevated auto-elevating process and the payload inherits that token — a path to UAC bypass and escalation.
3. Stealth. The artifact is a registry value, not a file or a task, and it lives in a hive most EDR tuning under-monitors.

How to hunt COM hijacks

The strongest signal is simple: any CLSID that exists in both HKCU and HKLM is suspicious by default. Legitimate per-user COM registration is rare on a workstation, so the overlap set is small and reviewable.

• Enumerate HKCU\Software\Classes\CLSID\*\InprocServer32 and LocalServer32, then diff against HKLM. Flag every CLSID present in both.
• Inspect the target path of each user-hive entry. A COM server pointing at %TEMP%, %APPDATA%, C:\Users\Public, or an unsigned DLL is a red flag.
• Hunt TreatAs keys under user hives — they are almost never legitimate on endpoints.
• Enable registry auditing (Event ID 4657) on the Classes\CLSID subtrees so new writes generate an event, and verify the code signature of every DLL a COM server resolves to.

The mental model: a registry key that quietly redirects a system component to attacker-controlled code, loaded by trusted processes. Trust the process, and you inherit the trust of the DLL it loads.

Where WinSentinel fits

Manually diffing two enormous registry hives per machine is exactly the kind of tedious, error-prone check that never gets done consistently. WinSentinel's persistence-hunting module enumerates the CLSID subtrees on every machine — free, with no limits, all 33 modules on a single host — surfaces HKCU/HKLM overlaps, flags COM servers resolving to unsigned or user-writable paths, and calls out TreatAs redirects. It ties each finding to the loading process so you can see the blast radius instead of a raw GUID.

For teams running fleets, WinSentinel Pro rolls those per-machine findings into a central view: spot the same suspicious CLSID appearing across ten endpoints (a campaign, not a one-off), track drift when a new COM override shows up, and get alerted rather than discovering it during an incident. The detection runs locally on each machine; Pro is about orchestrating and correlating those results across the org.

COM hijacking thrives on the assumption that nobody looks at the CLSID hive. Make looking automatic, and the technique loses most of its edge.