Detecting COM Hijacking: HKCU CLSID InprocServer32 Overrides

When an application instantiates a COM object, Windows resolves its CLSID by checking the current user’s registry hive before the machine hive. An attacker with ordinary user rights can therefore create an HKCU entry that shadows a legitimate HKLM class and points InprocServer32 at a malicious DLL or a scriptlet. The next time a trusted process such as explorer.exe requests that object, the payload loads, giving stealthy, userland persistence.

Signals at a Glance

Registry Writes Under HKCU Classes

Legitimate installers rarely write InprocServer32 values into a user hive, because per-machine registration goes under HKLM. That makes the HKCU path a high-signal location. Sysmon reports these writes under the HKU hive with the user SID, so match on the path suffix rather than the root:

title: COM Class Registered Or Overridden In User Hive
logsource:
  product: windows
  category: registry_set
detection:
  selection:
    TargetObject|contains: '\Software\Classes\CLSID\'
    TargetObject|endswith:
      - '\InprocServer32\(Default)'
      - '\LocalServer32\(Default)'
      - '\TreatAs\(Default)'
  susp_value:
    Details|contains:
      - '\AppData\'
      - '\Temp\'
      - '\ProgramData\'
      - '\Users\Public\'
      - 'scrobj.dll'
      - 'script:'
  condition: selection and susp_value
level: high
# tune/validate: some developer tools register per-user COM servers in AppData.

Treat the target process as a second signal. Explorer, the Office applications and scheduled-task hosts instantiate many COM objects at startup, so those are the processes whose unexpected module loads matter.

Sweeping for Shadow Entries

A shadow entry is an HKCU CLSID that also exists under HKLM. Hijackers rely on exactly this, whereas a CLSID that exists only in HKCU is a per-user registration. The sweep below lists every HKCU server value, flags those that shadow an HKLM class, and reports the file signature:

# PowerShell: HKCU COM servers, flagging shadows of HKLM classes
$base = 'HKCU:\Software\Classes\CLSID'
Get-ChildItem $base -ErrorAction SilentlyContinue | ForEach-Object {
  $clsid = $_.PSChildName
  foreach ($srv in 'InprocServer32', 'LocalServer32') {
    $key = Join-Path $_.PSPath $srv
    if (Test-Path $key) {
      $path = (Get-Item $key).GetValue('')
      $file = $path -replace '^"?([^"]+)"?.*$', '$1'
      $sig  = if ($file -and (Test-Path $file)) { (Get-AuthenticodeSignature $file).Status } else { 'FileMissing' }
      [pscustomobject]@{
        CLSID  = $clsid; Server = $srv; Path = $path
        Shadows = Test-Path "HKLM:\SOFTWARE\Classes\CLSID\$clsid"
        Signature = $sig
      }
    }
  }
} | Where-Object { $_.Shadows -or $_.Signature -ne 'Valid' }
# tune/validate: run on a clean baseline host; per-user app registrations will appear.

• Alert on any HKCU CLSID that shadows a class listed in public COM-hijack research, and rank by whether the server DLL is unsigned or in a user-writable path.
• Enforce it from the other side: monitor HKLM class changes too, since an elevated attacker can modify the machine registration directly.
• Look at how the payload gets used. After a hijack, the loading process is trusted, so correlate with outbound network from explorer.exe or an Office process that never normally connects out.
• Hunt TreatAs redirects, which forward one CLSID to another and are easy to miss in a path-only review.