🔍COM Hijacking - T1546.015

0x01: Introduction

Adversaries may establish persistence by executing malicious content triggered by hijacked references to Component Object Model (COM) objects.

This technique is tagged as T1546.015 on MITRE ATT&CK and is a technique used by many threat actors for persistence and privilege escalation purposes, In this article I will in-depth on how the hijacking technique works and how to implement it and its many variants.

This technique can be performed by an ordinary, non-admin user and can achieve both persistence and privilege escalation, we'll discuss what makes it possible in the next section.

COM Object Execution

Before we understand how to hijack a COM Object's execution, we need to know how it is executed.

Without diving into detail (for that you have Demystifying Windows Component Object Model (COM)), a COM object is implemented as either a DLL or an EXE. When a client program want to execute a COM object, it executes certain functions that initialize the steps for executing that COM Object.

One of those crucial steps is resolving the location of the COM Object's implementation in order to execute it, after it locates the implementation, if everything else went smoothly it executes it.

For the rest of the article I'll refer to an activated COM object as "COM Server".

COM Registry database

To locate a COM object, the registry is used. Windows Registry contains the mapping information for every COM object implementation on disk.

These are the locations of the registry keys from which you can extract the location of a COM Object:

• HKEY_CLASSES_ROOT\CLSID

• HKEY_CLASSES_ROOT\WOW6432Node\CLSID

To retrieve the mapping (location) of the COM Object, we are required to use one of the following identifiers:

CLSID -

Class ID, Is a globally unique identifier (GUID) that Identifies a COM Class. CLSID -> {72C24DD5-D70A-438B-8A42-98424B88AFB8}

• In GREEN, the full registry key path,

• In BLUE, the CLSID of the COM Object,

• In RED the location on disk of the COM Object's implementation which is a DLL implementation (.ocx is a DLL).

When executing a COM Object, the windows service manager (SCM) attempts to locate the CLSID it received as an argument in the registry, once it locates the key with the CLSID it queries its keys in attempt to find the COM server.

The keys that potentially contain the path to the COM Server are:

• InprocServer32 - Path to a DLL Server

• LocalServer32 - Path to an EXE Server

ProgID -

Program ID is A friendly name for a COM Class which can be used in a similar manner as CLSID.

When We instantiate a COM Object we can use ProgID instead of CLSID provided that the ProgID key in the registry contains the appropriate mapping to the relevant CLSID. As you can see ProgID acts like an alias to the actual CLSID of the COM Object.

• In GREEN we see the full registry key path of the CLSID that this ProgID is mapped to

• In BLUE, the name of the ProgID

• In RED, the mapping CLSID that's mapped to this ProgID

0x02: The Windows Registry

Registry Overview

COM Object execution hijacking can be achieved in a variety of methods; However, All of them* rely on a single registry principle which prioritize configuration inside certain hives over another.

In case you don't know what the Registry is, In its simplest form, it's a database where you can store and retrieve configuration data.

A hive is a logical group of keys, subkeys, and values in the registry that has a set of supporting files loaded into memory when the operating system is started or a user logs in.

The Windows Registry has multiple hives, these hives are nested inside various KEYS, we'll only discuss the relevant keys that are required to understand the hijacking concept.

• HKEY_CURRENT_USER (HKCU) - Contains settings that apply only to the interactive user.

• HKEY_LOCAL_MACHINE (HKLM) - Contains default settings that can apply to all users on the local computer.

• HKEY_CLASSES_ROOT (HKCR) - Provides a view of the registry that merges the information from HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE

32-bit application data and 64-bit application data in the Registry

On 64-bit windows systems, the configuration data of 32-bit application will be saved under different keys than the 64-bit application.

The structure of the keys will stay similar aside from being nested under the key Wow6432Node.

For example:

• Key for 64-bit application will look like this:

  • HKEY_CURRENT_USER\SOFTWARE\Classes

• Key for 32-bit application will look like this:

  • HKEY_CURRENT_USER\SOFTWARE\WOW6432Node\Classes

COM Identifiers & Registry

As we previously discussed, COM has two main types of identifiers it leverages to locate COM objects, CLSID and ProgID.

Below is an exhaustive list of location in which you can find these identifiers and query them, it is also where the SCM goes to look for the location of the COM Servers, note that under the keys with "CLSID" you'll find (surprise surprise) CLSIDs, and under the other ones you'll find ProgID.

Exhaustive list of COM Identifiers registry locations:

• HKEY_CLASSES_ROOT

• HKEY_CLASSES_ROOT\CLSID

• HKEY_CLASSES_ROOT\WOW6432Node

• HKEY_CLASSES_ROOT\WOW6432Node\CLSID

• HKEY_CURRENT_USER\SOFTWARE\Classes

• HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID

• HKEY_CURRENT_USER\SOFTWARE\WOW6432Node\Classes

• HKEY_CURRENT_USER\SOFTWARE\WOW6432Node\Classes\CLSID

• HKEY_LOCAL_MACHINE\SOFTWARE\Classes

• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID

• HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes

• HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\CLSID

0x03: Hijacking COM Objects - Examples

Many Threat Actors leverage COM Hijacking in their tooling for persistence purposes (APT28, Turla) and it is also available out-of-the-box in many offensive frameworks.

In this section i'll present and demonstrate multiple COM Hijacking techniques and their variants, some are well-known and some are less.

All of them has to do with hijacking the execution process of a COM object in one way or another. Further more, you can get creative by combining some of the techniques and features into some less known hijacking flows.

CLSID Hijacking

This is the most common form of hijacking. In which we modify the registry value InprocServer32 which contains the location of the target COM Server, and eventually map it to our own malicious COM Object.

For the hijack to succeed we need

1. A COM Object we compiled

2. Create/Edit the relevant registry Keys/Values of the to-be-hijacked COM Obejct

Explaining The Process

1. We Choose the target COM Object we wish to hijack. For example: Wscript.Shell COM Object, Its CLSID is - {72C24DD5-D70A-438B-8A42-98424B88AFB8}

2. These are the configuration of the selected target COM object as they appear in HKLM

3. If we check the same path for the HKCU hive, we see that nothing exists there (and it shouldn't usually), once we hijack this CLSID, this key will be created in this hive (HKCU)

4.To create and edit the relevant registry keys i'll use the COMHijackToolKit which is a PowerShell script that's a part of acCOMplice.

In addition, I've compiled a COM Server (TestCOMServer.dll) using this source (COM Proxy will be explained later in this article) that we would use to replace the wshom.ocx server.

5. The script loads the COMHijackToolkit utility, Creates the registry value to point to our DLL in HKCU, then Executes the COM object (using a ProgID), then cleans up the registry by deleting the new registry values that hijack the object.

Let's execute the script init-com-hijack.ps1, We can see the script created the registry entry in HKCU that points to our DLL:

The result of executing our COM Server is a message box, we can also see that our dll was successfully loaded to the process that executed the COM object (powershell.exe).

In our example I performed a cleanup of the registry key we created that hijacks the object, if we will not delete our key, every program that executes the WScript COM will execute our DLL instead.

TreatAs Hijacking

This is another form of CLSID Hijacking, without modifying the actual server value(InprocServer32) in the registry. Instead, we specify the CLSID of a class that can emulate the current class.

Which means that we can use this key to redirect the execution of a certain COM object to a different one. This time only providing a different CLSID without modifying the InprocServer32 value of the original COM Object.

For the hijack to succeed we need

1. A COM Object we compiled

2. Register our COM object in the registry

3. Create/Edit the relevant registry Keys/Values of the to-be-hijacked COM Obejct

Explaining The Process

I'll use an example from Matt Nelson's and Casey Smith's lecture. As you can see we register a COM object of our own and then we add a TreatAs key to the COM Object we wish to hijack.

In this case we hijack the {3734FF83-6764-44B7-A1B9-55F56183CDB0} object and map it to points to our CLSID which is - {0000001-0000-0000-0000-0000FEEDACDC}

If we proceed to execute the original COM object by CLSID, we'll see that our .sct file is executed instead, opening calc.exe

The cool thing about this technique is that it evades simple detections that are based on detecting the modification of the InProcServer32 value in specific common COM Objects, and results only in editing the TreatAs value which is less common.

ProgID Hijacking

When a program instantiate a COM object with ProgID, it will go through a resolution process to determine the CLSID that's mapped to the ProgID.

For the hijack to succeed we need

1. A COM Object we compiled

2. Register our COM object in the registry

3. Create/Edit the relevant registry Keys/Values of the to-be-hijacked COM Obejct

Explaining The Process

1. We'll choose Wscript's COM whos CLSID is {72C24DD5-D70A-438B-8A42-98424B88AFB8} and identify its ProgID by navigating the to the CLSID key in the registry and observing the value of ProgID

2. Now that we know the ProgID we navigate to its location - \Classes\Wscript.Shell We can see that the ProgID is mapped to the {72C24DD5-D70A-438B-8A42-98424B88AFB8} CLSID which is indeed, the WScript COM Object's CLSID.

3. To Hijack the ProgID we are required to:

• Create a new ProgID key in HKCU that is mapped to our desired COM Object CLSID

• Register our own COM object (or use an existing one)

This screenshot below shows a .reg file that I'll use to import all registry changes with ease by using the command:

reg.exe import .\ProgIdHijackDLL_Wscript.reg

Let's Understand what's happening

1. Create a new ProgID I am creating a new registry key with the same name of the ProgID I want to hijack in HKCU and add a mapping to a Class ID (CLSID) I generated. This step causes the hijack to work and redirects every call made via this ProgID to the CLSID I mapped.

2. Registering our COM Object

   Because I use a CLSID that I generated which didn't exist before, I am required to register it, otherwise the mapping will point nowhere and nothing will happen. So I am creating the CLSID key, along with the mapping to our DLL on disk and with the appropriate ProgID.

Registry state after the modification

Execution

As you can see, when executing WScript via ProgID we successfully hijack the execution

However, If we try to execute it via the CLSID which we DIDN'T hijack, the hijack will not work (as expected) and we will not see our message box. This technique variant can thwart detection mechanisms relying on modification of the InProcServer32 value in specific COM objects.

ScriptletURL - "Fileless" COM Execution

Instead of dropping to disk your custom COM object(DLL), you can utilize Windows Scripting Components (Scriptlets), the ScriptletURL configuration allows us to register a remote location containing an .sct file, that will be downloaded and executed. Windows Script Components provide you with an easy way to create Component Object Model (COM) components using scripting languages such as VBScript, JScript and JavaScript.

Script component technology is made up of the following:

• The script component run-time (Scrobj.dll).

• Interface handlers

• Your script component file (a.sct file). In your script component, you specify which interface handler you want to use.

There are three main requirements to utilize the ScripletURL configuration

• The script component run-time (Scrobj.dll) needs to be the "COM Server"

• Create an appropriately structured .sct file

• Provide a reachable address when specifying the location of the .sct file

I've taken this example from Matt Nelson (@enigma0x3) and Casey Smith (@subtee) lecture Windows Operating System Archaeology which I highly recommend watching, and used it to register a COM Object with the ScriptletURL option.

As you can see, we performed a ProgID hijack of the "Scripting.Dictionary" ProgID, in-addition to creating our CLSID with the relevant configuration to utilize the ScripletURL feature. The result is a registered COM Object, with the Windows Scripting Component Run-time (scrobj.dll) as it's server (InprocServer32) and a URL path that remotely retrieves the scriptlet from github.

When a program creates a new instance of the COM object we hijack using the ProgID Scripting.Dictionary it will fetch the .sct file from the URL, scrobj.dll will handle the registration details that exist within the file and will then invoke the relevant interfaces to execute the code inside (VBScript, Jscript, etc)

0x04 Enhancing the Hijack

Choosing The Right COM Object

Identifying Common COM Objects

When you use COM Hijacking for persistence, you probably want the object you hijack to be executed relatively frequently and so you'd want COM objects that are actually getting called by the system or other programs.

One strategy you may take is opening your favorite monitoring tool such as Procmon, and monitor registry query event for any of the interesting keys we discussed(InprocServer32, TreatAs, ScriptletURL, CLSID, and any key under \Classes\), quantify the results and decide on an object to hijack.

Here's for example a Procmon session I monitored for 30 seconds, with the InProcServer32 filter inside the "Path" column yields 17K+ registry events (!). Of course you still need to filter and remove duplicates but this is enough to get you going :)

Missing Libraries

Another Interesting thing you can do is enumerate registered COM Object that points to non-existent DLLs by checking the InProcServer32 path and attempting to late the DLL on disk, and thus hijacking the execution without modifying the registry.

If you just want to quickly test that on your machine, acCOMplice has implemented a PowerShell function to do just that "Find-MissingLibraries"

Better Stability

Hijacking COM Objects can be risky business, modern Windows systems still use COM everywhere all the time, and you might brake the system if you hijack the wrong COM object with proper handling.

So you either have to "Choose The Right COM Object", or you can create your COM server as a Proxy DLL that will execute your code but also provide the program that called the original COM object with the actual implementation of the original COM object.

A PoC of this idea can be found here

This approach still doesn't guaranty 100% stability, however it does reduce the frequency of crashes and system breakage.

0x05 Conclusion

COM Hijacking is a common method for persistence and can appear in many forms and variations. Although COM is a complicated technology, detection of COM Hijacking is relatively easy when you know what to look for, which is mostly the modification of registry keys and values we discussed in this article. Consider also adding context and additional events to avoid false positives.

Although an old technology COM is still widely used by windows and worth getting to know.

If you're interested to learn COM in a more granular fashion I suggest to read Microsoft's Documentation or you can start with this page:Demystifying Windows Component Object Model (COM)