COM Hijacking (User CLSID)
A per user CLSID that shadows a machine one, so the user DLL loads instead.
Use it to find a per user COM entry that swaps a system component for another DLL or program when it is used.
- UsrClass.dat
- Persistence
What It Is
A CLSID is the unique identifier of a COM component, and its InprocServer32 subkey gives the path to the DLL that implements the component plus its threading model. Windows merges per-user class registrations, kept in the user's UsrClass.dat hive, with the machine-wide ones to form HKEY_CLASSES_ROOT, and the per-user settings take precedence for the interactive user. This key is the per-user InprocServer32 entry for a given CLSID, which an application can use to provide a COM object for one user without changing the machine.
What It Proves
Windows checks the user Classes before the machine Classes. An InprocServer32 or LocalServer32 under HKCU for a known CLSID therefore makes that user load the attacker DLL, or start the attacker program, whenever the component is used.
What It Does Not Prove
It runs when something invokes that CLSID, not on a fixed schedule, so impact depends on which component is hijacked. Thousands of legitimate CLSIDs exist, so hunt for user entries that duplicate machine ones.
Where It Lives
COM Hijacking (User CLSID) lives in the UsrClass.dat hive, and every user profile has its own copy, so what it shows belongs to one user. Offline Hive shows the path inside the hive file, as Registry Explorer opens it, and Live System shows the same key as regedit shows it on a running machine. The line under the path is where the hive file sits on disk.
UsrClass.dat\C:\What It Looks Like
These are two values from this key on ws-042, the fictional machine the wiki follows, decoded into plain English. Each row shows the value as Windows stores it, its name, type and data, then what it tells you.
| Registry Value | What It Tells You |
|---|---|
| alice's hive points one of OneDrive's shell classes at FileSyncShell64 |
| The machine has no class under that GUID, so alice's entry shadows nothing and is OneDrive's own. One in both hives with a different user DLL is the hijack. |
How to Read It
List CLSID subkeys under the user Software Classes that also exist under HKLM. Read InprocServer32 or LocalServer32, whose default value is the DLL or executable loaded. A user DLL in AppData shadowing a system component is the classic hijack.
- When Windows Writes It
- When the user CLSID key and its server value are written.
- Which Windows Versions
- Windows 7 to 11
- Tools That Parse It
- Autoruns, Registry Explorer, RECmd
Hunt It
Defender records these writes within retention. A hit is a user COM registration, and a hijack only if the same GUID also exists under HKLM.
// User CLSID server values being written under HKCU ClassesDeviceRegistryEvents| where Timestamp > ago(Confirm It With
One artefact can mislead on its own. These other records show the same activity, or pin down when it happened, so use them to back up what COM Hijacking (User CLSID) shows.
- Shell ExtensionsShows whether the hijacked CLSID is one Explorer loads at every start.
- AmcacheGives the SHA-1 of the program a LocalServer32 entry starts.
- DLL Load, Sysmon Event 7Not in the RegistryShows the user DLL actually loading, and into which process.
Sources
The facts on this page come from these public pages, which say more on each point.