COM Hijacking: System Hacking Using Windows Internal Processes

To comprehend COM Hijacking, one must first understand what COM is and how the Windows operating system relies on it.

Introduced by Microsoft in 1993, the Component Object Model is an architecture that allows different software components, applications, and languages to communicate and interact with one another. It was designed to promote code reusability. For example, if a developer is writing a new application and needs to implement a "File Save" dialog box, they do not need to write that complex UI code from scratch. Instead, they can simply call upon the pre-existing Windows COM object responsible for rendering that dialog.

The Anatomy of a COM Object

COM objects are essentially standardized binary interfaces, usually implemented as Dynamic Link Libraries (DLLs) or executable files (EXEs). Every COM class is uniquely identified by a globally unique identifier (GUID) known as a Class Identifier (CLSID). A CLSID is a 128-bit integer formatted like this: {00000000-0000-0000-0000-000000000000}. Because humans are bad at remembering 128-bit alphanumeric strings, COM objects are also often associated with a human-readable Programmatic Identifier (ProgID), such as Excel.Application.

The Role of the Windows Registry

When an application requests a specific COM object (by asking for its CLSID), the Windows operating system must figure out where the actual binary file (the DLL or EXE) for that object is located on the hard drive. To do this, Windows heavily relies on the Registry.

The operating system searches for the requested CLSID within the HKEY_CLASSES_ROOT (HKCR) registry hive. Specifically, it looks under HKCR\CLSID\{Target-CLSID}\InprocServer32 (for DLLs) or LocalServer32 (for EXEs). The (Default) value of that registry key contains the exact file path to the legitimate binary that Windows needs to load.

The vulnerability that enables COM Hijacking stems directly from a specific architectural quirk in how Windows searches the registry to resolve a CLSID.

The Registry Search Order Vulnerability

The HKEY_CLASSES_ROOT (HKCR) hive is not actually a real, standalone registry hive on the disk. Instead, it is a virtual, merged view of two different registry locations:

1. HKEY_LOCAL_MACHINE\Software\Classes (HKLM): This hive contains system-wide COM registrations. Modifying this hive requires elevated, administrative privileges.
2. HKEY_CURRENT_USER\Software\Classes (HKCU): This hive contains user-specific COM registrations. Modifying this hive only requires standard user privileges.

When a process requests a COM object, the Windows COM subsystem merges these two locations to create HKCR. Crucially, if a CLSID exists in both locations, the entry in HKCU always takes precedence over the entry in HKLM.

This search order preference is the fundamental flaw that enables the hijack.

Executing the Hijack

An attacker operating with standard, non-administrative user privileges can exploit this search order.

1. Identify a Target: The attacker identifies a legitimate, frequently executed Windows process (like explorer.exe, taskeng.exe, or a widely used application) that regularly calls a specific COM object registered in HKLM.
2. Create the Malicious Payload: The attacker creates a malicious DLL that exports the necessary COM functions (like DllGetClassObject) but also contains their malicious payload (e.g., a Cobalt Strike beacon, a reverse shell, or a ransomware dropper). They drop this DLL in a hidden directory (e.g., %APPDATA%).
3. Plant the Registry Key: The attacker creates the corresponding CLSID structure within the user's registry hive: HKCU\Software\Classes\CLSID\{Target-CLSID}\InprocServer32.
4. Redirect Execution: The attacker sets the (Default) value of their newly created InprocServer32 key to point to the file path of their malicious DLL.

The next time the legitimate application runs and requests that specific CLSID, Windows will search the registry. It will check HKCU first, find the attacker's fake entry, and blindly load the attacker's malicious DLL directly into the memory space of the legitimate, trusted process. The legitimate application acts as an unwitting host, completely masking the malicious activity from casual observation.

Threat actors employ several variations of this technique to achieve different objectives, ranging from simple persistence to complex privilege escalation.

1. Standard COM Hijacking (Persistence)

This is the most common form, used primarily to ensure that malicious code survives a system reboot. Attackers target CLSIDs that are guaranteed to be loaded by the operating system shortly after a user logs in. A prime example is targeting CLSIDs associated with explorer.exe (the Windows shell). Because explorer.exe is essential to the desktop environment, modifying one of its frequently called COM objects ensures the attacker's payload is executed automatically every single time the compromised user authenticates.

2. Phantom COM Hijacking (Missing CLSIDs)

Over the decades, Windows has accumulated massive amounts of legacy code. Many legitimate applications, and sometimes the OS itself, attempt to load COM objects that no longer exist or were abandoned by developers. When Windows searches for these "phantom" CLSIDs, it finds nothing, and the application simply handles the error and moves on. Sophisticated attackers monitor the system (using tools like Sysinternals Process Monitor) to identify these failed CLSID lookups. They then create the missing registry keys in HKCU and point them to their malicious DLL. This technique is incredibly stealthy because the attacker is not overwriting or hijacking an active, functioning component; they are simply fulfilling a request that was previously failing, minimizing the risk of crashing the host application.

3. Bypassing User Account Control (UAC)

COM Hijacking is frequently weaponized to escalate privileges from a standard user to an Administrator, specifically by bypassing UAC. Windows contains numerous "auto-elevating" executables—system binaries located in trusted directories (like C:\Windows\System32) that are cryptographically signed by Microsoft. Because they are highly trusted, Windows allows these specific binaries to execute with elevated privileges without ever displaying the UAC prompt to the user. If an attacker can identify an auto-elevating binary that attempts to load a COM object, they can perform a COM hijack. When the attacker launches the auto-elevating binary, the binary silently elevates to administrative privileges and then loads the attacker's malicious DLL. The malicious DLL inherits the elevated context, granting the attacker silent, administrative control over the machine.

4. Scheduled Task COM Hijacking

Many Windows Scheduled Tasks do not execute standard .exe files; instead, they are configured with a "Custom Handler" that executes a specific COM object (CLSID) when the task triggers. Attackers can hijack the CLSID associated with a high-frequency or highly privileged scheduled task. When the task runs (often operating as the powerful NT AUTHORITY\SYSTEM account), it triggers the COM object, thereby executing the attacker's payload with maximum privileges.

The impact of a successful COM Hijacking attack is severe. It provides attackers with a robust, highly evasive foothold. Because the malicious code is loaded as a DLL directly into the memory space of a digitally signed, legitimate Microsoft process (like explorer.exe or svchost.exe), it frequently bypasses application whitelisting solutions (like AppLocker). Furthermore, because the attacker only modifies the HKCU registry hive, the technique requires zero administrative privileges to execute, making it highly accessible during the initial phases of a breach.

Advanced threat groups, including state-sponsored APTs (such as APT29 / Cozy Bear and APT32 / OceanLotus), and prominent ransomware syndicates have heavily integrated COM Hijacking into their post-exploitation toolkits.

Defending against COM Hijacking is notoriously difficult. Because COM is a fundamental, heavily utilized component of the Windows architecture, security teams cannot simply "turn it off." Furthermore, creating generalized block rules is dangerous, as legitimate software installers and updaters frequently modify COM registry keys. Defense requires high-fidelity monitoring and behavioral analysis.

Proactive Registry Monitoring (Sysmon)

The most effective detection strategy involves aggressively monitoring the Windows Registry for suspicious modifications. Organizations should deploy Microsoft Sysinternals Sysmon and configure it to monitor for specific Event IDs:

• Event ID 12, 13, 14 (Registry Events): Security teams must create rules to alert whenever a process running with standard user privileges creates or modifies a registry key path containing \Software\Classes\CLSID\ and \InprocServer32 or \LocalServer32. Any modification to these paths by an untrusted binary (like a script downloaded from the internet, or macros in a Word document) is a highly suspicious indicator of a potential hijack attempt.

Analyzing Process Execution Anomalies

Security analysts must look for behavioral anomalies regarding how processes load DLLs.

• Unsigned DLLs in Trusted Processes: Alerting logic should trigger if a highly trusted, digitally signed Microsoft process (e.g., explorer.exe) suddenly loads an unsigned DLL, especially if that DLL is located in an unusual, user-writable directory (like %APPDATA%, C:\Users\Public, or C:\ProgramData).
• Process Monitor (ProcMon) Hunts: During incident response, analysts can use ProcMon to hunt for failed RegQueryValue operations on HKLM\Software\Classes\CLSID immediately followed by successful RegQueryValue operations on the corresponding HKCU path, which is the classic signature of the search order vulnerability in action.

Mitigation Challenges

True mitigation of the search order vulnerability is complex. While Microsoft has patched specific UAC bypasses related to COM, the underlying architecture prioritizing HKCU over HKLM remains intact for compatibility reasons. Security teams can attempt to lock down permissions on the HKCU\Software\Classes hive, preventing standard users from writing to it, but this aggressive approach often breaks legitimate legacy applications and requires extensive, careful testing before deployment.