COM Hijacking - T1546.015
Component object model hijacking method for persistence and privilege escalation.

0x01: Introduction

Adversaries may establish persistence by executing malicious content triggered by hijacked references to Component Object Model (COM) objects.
The references to COM objects are stored in the Registry.
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 detail both use-cases and how to achieve them.
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.
If you wish to read about COM objects with greater detail, read Demystifying Windows Component Object Model (COM)

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 steps is locating 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 Server:
There are additional locations, but for the sake of keeping this section short and clear, I'll discuss them in a later section to avoid confusion.
To retrieve the mapping (location) of the COM server, we are required to use on of the following identifiers:
CLSID - Class ID, Is globally unique identifier (GUID) that Identifies a COM Class. CLSID Example - {72C24DD5-D70A-438B-8A42-98424B88AFB8}
CLSID Key containing the mapping to the Wscript.Shell Server -> wshom.ocx
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 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, A friendly name for a COM Class which can be used in a similar manner as CLSID, ProgID Example - Wscript.Shell
The format of a ProgID is <Program>.<Component>.<Version>, separated by periods and with no spaces, as in Wscript.Shell.1
We can also locate COM Objects with a Program ID, as you can see Program ID 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.
Don't forget: All mapping actually occurs via CLSID eventually.
The ProgID key contains and mapping to a CLSID which then contains the mapping to the actual DLL/EXE.

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.
Configurations on the HKEY_CURRENT_USER hive takes precedence over configurations inside the HKEY_LOCAL_MACHINE hive. The reason for that, is to enable a user-specific configuration (HKCU) whilst having a generic configuration as well (HLKM).
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.
The Interactive user can change keys and values that are nested inside this key, changing keys Does Not require administrative privileges under the current user hive.
  • HKEY_LOCAL_MACHINE (HKLM) - Contains default settings that can apply to all users on the local computer.
Only Administrator can Modify keys on this hive
  • HKEY_CLASSES_ROOT (HKCR) - Provides a view of the registry that merges the information from HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE
Unlike HKCU and HKLM that have an actual hive file on disk, this key does not. This is because HKCR is a combined view of the HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE hives.

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:
  • Key for 32-bit application will look like this:

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:

0x03: Hijacking COM Object

Work In Progress