Contact Us

Persistence – COM Hijacking | Penetration Testing Lab

Cyber Security | July 3, 2020

Microsoft introduced Component Object Model (COM) in Windows 3.11 as a method to implement objects that could be used by different frameworks (ActiveX, COM+, DCOM etc.) and in different Windows environments allowing interoperability, inter-process communication and code reuse. Abuse of COM objects enables red teams to execute arbitrary code on behalf of a trusted process. Administrator privileges are not required to perform COM Hijacking since classes in the HKCU registry hive are executed prior to the classes in HKLM. The only exception affects high integrity processes (elevated) which objects are loaded only from HKLM location to prevent elevation of privileges.

There are multiple methods that execution of code can be achieved but there are several cases which COM has been used in red teaming scenarios for persistence, lateral movement and defense evasion. Depending on how the malicious code will executed various registry sub-keys are used during COM Hijacking. These are:

The above sub-keys are under the following registry hives:

Discover COM Keys – Hijack

Identification of COM keys that could be used to conduct COM hijacking is trivial and requires the use of Process Monitor in order to discover COM servers which are missing CLSID’s and doesn’t require elevated privileges (HKCU). Process Monitor can be configured with the following filters:

COM Hijacking – Process Monitor Filters

Opening files and executing tasks like a standard user will produce a list with COM keys that could be hijacked in order to load an arbitrary library to a trusted process.

COM Hijacking – Process Monitor Results

The results could be used directly or exported in various formats like CSV and XML.

Process Monitor – CSV Export

A PowerShell script called acCOMplice developed by David Tulis contains a function which can take process monitor results in CSV format in order to extract keys that could be hijacked.

AcCOMplice – Extract Hijackable Keys

The tool has also a function which can retrieve directly the missing libraries that exist on the system and their CLSID’s.

Finding Missing Libraries

An alternative method is by executing the following PowerShell snippet as it has has been demonstrated by bohops in his article about Abusing the COM Registry Structure. This can be used to enumerate “LocalServer32” classes that could be hijacked:

Enumerate LocalServer32 Values

Similarly the following PowerShell code can enumerate InprocServer32 classes:

Enumerate InprocServer32 Values

Executing the snippet will produce a list of COM libraries that could be investigated for COM hijacking opportunity.

Enumerate InprocServer32 Results

Matt Nelson and Matthew Graeber developed a PowerShell script (Get-ScheduledTaskComHandler) which can check all scheduled tasks on the host that execute on user logon and are vulnerable to COM hijacking.

COM Hijacking – Retrieve Scheduled Tasks

The parameter “PersistenceLocations” will retrieve schedule tasks vulnerable to COM hijacking that could be used for persistence and they don’t require elevated privileges. The CLSID and the associated DLL will also displayed in the output.

COM Hijacking – Persistence Locations

The task “CacheTask” when invoked uses the “wininet.dll” and has the following CLSID: {0358B920-0AC7-461F-98F4-58E32CD89148}

COM Hijacking – CacheTask

The CLSID and the associated DLL can be also obtained from the configuration file of the task. This file is stored in the following location:

CacheTask – Configuration File

Alternatively, invoking the “schtasks” utility from the PowerShell console with the parameters below can retrieve also the contents of the file.

CacheTask – XML Configuration

Reviewing the task scheduler will verify that the task trigger is to start during the logon of any user. Hijacking the CLSID will establish a persistence condition on the system.

Task Scheduler – CacheTask

The “InprocServer32” (In-Process Server) registry key indicates where a COM library is located on the disk and defines the threading model. The image below demonstrate the registry keys that exist typically in “InprocServer32“.

InprocServer32 – Registry Keys

Recreating the registry key structure in the HKCU for the “Cache Task” that was discovered above and pointing to an arbitrary DLL instead of the “wininet.dll” will execute the code since the DLL located in the HKCU will be loaded prior to the HKLM.

CacheTask – CLSID Hijacked

The following DLL file will create a message box that will demonstrate a message to indicate that code has been executed when the process “CacheTask” is started.

DLL Message Box

The DLL needs to be dropped into disk and the sub-key “InprocServer32” needs to point to the location of the DLL.

InprocServer32 – Hijack Registry Key DLL

Since “CacheTask” is scheduled to start by default during the log on of any user code will executed permanently across logons (persistence).

COM Hijacking – MessageBox DLL

A malicious DLL can be generated also with Metasploit utility “msfvenom” by executing the following command:

COM Hijacking – Metasploit DLL

Replacing the previous DLL with the DLL generated by Metasploit on the same registry path that the hijacked occurred.

COM Hijacking – Metasploit DLL Registry Key

Code will executed and a Meterpreter session will established every-time that a user is logon on the target system.

COM Hijacking – Meterpreter

It is also possible to execute fileless payloads like scriptlets instead of DLL files.

The “ScriptletURL” registry key defines the remote location of the arbitrary .sct file that will be fetched and executed when the COM class is invoked.

ScriptletURL – Registry Key

Executing the following command will invoke the COM class and will execute directly the payload.

InprocServer32 – Execute Scriptlet via ProgID

LocalServer32 registry entry specifies the location on the system of an external COM object. These are usually applications that have the form of an executable. The following COM class ID has been retrieved earlier during the enumeration of hijackable keys can be used to execute an arbitrary executable.

LocalServer32 – Registry Key

Replacing the default value of the application with the location on the disk of the arbitrary executable will implement the hijack.

LocalServer32 – Registry Key Hijacked

It is also necessary to activate the ClassID by executing the following PowerShell command as otherwise the COM object will be disabled.

LocalServer32 – Activate CLSID

When the COM object will be called the arbitrary executable will run and a session will established with the command and control system.


The “TreatAs” is a registry key which allows a CLSID to be emulated by another CLSID. This can be used to redirect a COM object to another COM object. This was presented initially by Casey Smith and Matt Nelson in their talk Windows Operating System Archaeology in 2017. Abuse of the “TreatAs” involves the following two steps:

The “ProgID” is the friendly name of a COM object and it is not unique. The following registry keys resolve ProgID’s to CLSID’s.

This means that when an application (client) activates a COM object (class) the operating system will resolve the associated “ProgID” by reading initially the following registry location:

Casey Smith and Matt Nelson released a proof of concept as part of their presentation to demonstrate that a class could be called as well by its “ProgID” or by the “TreatAs” subkey to perform evasion. The following file can be used as an example.

COM Hijacking – TreatAs & ProgID Registry Keys

The file will create the required registry keys that would be used for the hijack of a valid CLSID. Executing the command below will import the file into the registry.

COM Hijacking – Import Registry Keys TreatAs & ProgID

The “rundll32” utility with the “-sta” (single threaded apartment) switch can be used to call the malicious “TreatAs” CLSID or the “ProID“.

COM Hijacking – TreatAs & ProgID

In both scenarios the arbitrary code is executed successfully and sessions are opened.

COM Hijacking – TreatAs & ProgID Meterpreter

InprocServer32 – Internet Explorer

Internet Explorer is used actively in corporate environments as it provides compatibility with internal applications that have a web interface. An analysis of the COMpfun RAT by G Data SecurityLabs revealed that threat actors hijacked a legitimate COM object in order to establish persistence on the system when Internet Explorer process is invoked.

This is because Internet Explorer like many other Windows applications uses the following file “api-ms-win-downlevel-1×64-l1-1-0._dl” or “api-ms-win-downlevel-1×86-l1-1-0._dl” when the process is starting. This file can be found in the following Windows location:

The COM Object hijacking persistence PowerShell script can be used as a proof of concept of this technique. Executing the script will create the required folder structure and will perform a check on the architecture of the host in order to make the necessary registry modifications.

Persistence COM Hijacking – Internet Explorer

When the process “iexplore.exe” is launched, the calculator will start which will prove that the hijack was successful.

Persistence COM Hijacking – iexplore.exe & calc

It is also trivial to generate an arbitrary DLL with Metasploit utility “msfvenom” and replace the .dl file in order to establish a Meterpreter session.

COM Hijacking – Internet Explorer Metasploit DLL

Creating the following CLSID manually in the registry and modify the key to point to the location of the DLL on the system.

COM Hijacking – Internet Explorer Registry Location

When Internet Explorer is launched again the DLL file will loaded under a trusted process.

Persistence COM Hijacking – Internet Explorer Process Explorer

A Meterpreter session will open which will demonstrate that persistence has been achieved. It should be noted that using directly a DLL generated by Metasploit it might cause system instability and Internet Explorer might run as a process but not open. This is because the CAccPropServiceClass () will be called multiple times, therefore some further optimization on the DLL file is needed.

COM Hijacking – Internet Explorer Meterpreter

This content was originally published here.