Skip to content
Reverse Engineering
Persistenceintermediate

COM Hijacking

Malware redirects a Component Object Model (COM) class to its own DLL by populating a per-user CLSID registry entry, so the payload loads whenever a legitimate program instantiates that COM object.

The Component Object Model lets programs instantiate reusable objects by referring to a GUID called a CLSID. Windows resolves the CLSID to a server DLL or EXE through the registry. Crucially, the per-user hive HKCU\Software\Classes\CLSID is searched before the machine-wide HKLM location. An attacker who can write to HKCU (no admin needed) can therefore point an existing CLSID at a malicious DLL, and any process running as that user that instantiates the object will load the attacker's code.

The trigger is whatever legitimate code path creates that COM object — Explorer enumerating shell extensions, a scheduled task, an Office add-in, or a system component polling on a timer. This makes COM hijacking both stealthy (no new autorun entry, no new process) and durable.

How it works

A hijack adds an InprocServer32 default value under a CLSID in the user hive:

text
Key:   HKCU\Software\Classes\CLSID\{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}\InprocServer32
Name:  (Default)
Data:  C:\Users\Public\thumbcache.dll
Name:  ThreadingModel
Data:  Apartment

The example CLSID above belongs to a real shell component that Explorer loads regularly. Attackers prefer to "hijack" CLSIDs that are:

  • Referenced frequently (shell extensions, the Task Scheduler MruPidlList),
  • Abandoned/orphaned — a CLSID with no HKLM entry at all, so the per-user entry is the only resolution and nothing breaks. Tools enumerate these "phantom" COM objects.

Because the per-user key shadows the legitimate machine-wide DLL, the malicious DLL is loaded instead of (or before) the real one with no error to the user.

Detection & analysis

Static analysis:

  • Triage with Autoruns, which has a dedicated COM/CLSID view; enable "Hide Microsoft Entries" and look for HKCU\Software\Classes\CLSID\...\InprocServer32 values pointing at unsigned DLLs in user-writable paths.
  • Offline, parse NTUSER.DAT for Software\Classes\CLSID\*\InprocServer32 and \LocalServer32 entries. Any per-user CLSID that also has an HKLM counterpart is a strong hijack indicator — compare the two DLL paths.
  • In a sample, look for RegSetValue against Classes\CLSID and InprocServer32, and for a hard-coded GUID string that maps to a known shell or scheduler component.

Dynamic analysis:

  • Run the sample under Procmon filtered on Path contains InprocServer32 to capture which CLSID is redirected. Then, with Procmon's Load Image events, observe explorer.exe or another host loading the malicious DLL from the hijacked path.
  • Sysmon Event ID 13 records the InprocServer32 value write; Event ID 7 (Image Loaded) shows the unsigned DLL being mapped into a legitimate host process.

Detection rule hint:

Alert on any write to HKCU\Software\Classes\CLSID\{...}\InprocServer32 (or LocalServer32/TreatAs) whose data is an unsigned binary in a user-writable directory, especially when an identical CLSID is registered in HKLM. The per-user-shadows-machine-wide overlap is the canonical detection signal.

Votes

Comments(0)