Component Object Model Hijacking

Welcome to another blog post with information about the scenarios we write for our platform, this time it’s about the “Component Object Model Hijacking” attack that we can find in the MITRE ATT&CK matrix. Our intention is to provide information about security threats with enough technical data to satisfy those of you that are curious and want to understand the inner workings of the threat techniques we implement.

In this blog post you will also be able to learn more about our “Managed Privileges” feature, which allows you to specify a user account to be used when executing assessments, so any system interaction will be performed with the privileges of the given user. The attack we are demonstrating now only works when it is executed with an integrity level not higher than Medium, therefore, executing this attack within the context of a privileged system account (e.g. SYSTEM) would not work as expected.

Component Object Model Overview

Component Object Model (COM) is an object-oriented system meant to create binary software components that can interact with other objects. It is an interface technology that allows reusing objects with no knowledge of their internal implementation. A COM object is made up of data and functions that manipulate the data, where the access of this data is achieved through one or more sets of related functions. The interfaces of COM objects are these functions sets, being these interfaces strongly typed by their GUID (Global Unique Identifiers). This definition might sound a little bit convoluted, but things are going to be clearer once we get hands-on.

The main benefits of using COM are the following:

Component location transparency: COM objects are referenced by GUID, their location in the file system can be any place.
Network protocol agnostic: using a COM object implementing network communications does not require the user to know about the underlying network mechanisms.
Programming language agnostic: COM objects can be created and used by many different languages, the requirement is to follow the COM standards.

Windows Explorer, the file manager application that is included with releases of the Microsoft Windows operating system, from Windows 95 onwards, is a pretty good example of an application that extensively uses COM objects.

COM Hijacking Attack

In this section we are going through a COM Hijacking Attack, starting with the explanation of the main concepts to learn about COM, and finishing with the attack itself.

The first section explains how a COM object is loaded by a process. The second section covers how the system manages access to the files implementing the COM functionality. The third one, and last section, showcases the attack based on the concepts explained in the first two sections below.

Loading COM Objects from a Process

Whenever a program wants to load a COM object, it creates an uninitialized object instance of a given class by calling the Windows API CoCreateInstance, where one required parameter by this function is the CLSID (class identifier). The following image shows a call to CoCreateInstance function (section framed in red) with CLSID DCB00C01-570F-4A9B-8D69-199FDBA5723B (sections framed in purple) from Internet Explorer:

Internet Explorer calling CoCreateInstance with CLSID DCB00C01-570F-4A9B-8D69-199FDBA5723B

The operating system uses the information in the registry to determine which binary contains requested COM code when a program calls CoCreateInstance with a given CLSID value. In the previous image, the CLSID obtained from x64dbg can be found in the registry (sections framed in orange), which its object description is NetworkListManager (section framed in blue).

The following image shows the contents of the “InProcServer32” subkey under the CLSID key shown in the previous image. The blue area contains the binary file associated with the registry key contained inside the red area, which belongs to the CLSID shown before.

Binary file location at Windows registry for COM id DCB00C01-570F-4A9B-8D69-199FDBA5723B

From the image we can also view some CLSIDs available in the system, there are lots of them in a typical Windows installation. Resuming the execution of CoCreateInstance will load the executable file associated with the specified CLSID value in memory (if it has not already been loaded).

Process Monitor detecting iexplorer.exe trying to load COM id DCB00C01-570F-4A9B-8D69-199FDBA5723B

It is important to note that several Windows system binaries use COM objects and that there are several of them installed by default, as shown with Internet Explorer and as we will show with getmac.exe and Explorer.

System’s Procedure to Load COM Object Implementations from Binary Files

The following process is used by Windows to find the specific location of the COM object binary to be loaded after the CoCreateInstance function has been called. We just went through that process transparently when showing how a process loads a COM object, but we are going to cover it in more detail now.

Before a process can access a COM object it must have been registered first. Windows enables COM object registration in two different registry paths:

“HKEY_CURRENT_USER\Software\Classes” contains settings that apply only to the interactive user.
“HKEY_LOCAL_MACHINE\Software\Classes” contains default settings that can apply to all users on the local computer.

However, using a registered COM object is typically achieved through the “HKEY_CLASSES_ROOT” (HKCR) registry key only, which provides a merged view of both registry paths under the hood.

The relevant aspect here from an attacker perspective resides in the “HKEY_CURRENT_USER” (HKCU) key, which is checked first when trying to load COM objects, thus giving priority to user’s specified COM objects rather than system-wide COM objects (more information about this in HKEY_CLASSES_ROOT Key).

The following image shows this behavior for the Explorer.exe process. In the first line, the process is trying to access CLSID 77F10CF0-3DB5-4966-B520-B7C54FD35ED6 at HKCU registry key. As that CLSID is not present at HKCU registry key, Windows falls back to HCKR (HKLM under the hood) for the same CLSID, being successful in the last attempt.

Process Monitor detecting Explorer.exe trying to load COM id 77F10CF0-3DB5-4966-B520-B7C54FD35ED6

After the above, we now have key information that we can use to carry out a COM Hijacking attack. On the one hand, we have learned that Windows contains system binaries using COM objects, so if we can trick the system to load COM objects created by ourselves instead of the original ones, we will be able to perform a persistence attack. On the other hand, we also know that CLSID registry keys stored under the user’s registry key (HKEY_CURRENT_USER) will be looked at first, so an attacker can easily carry out this attack by modifying the user’s registry key to change the COM object to a malicious one, which will be loaded by a system binary eventually when it is used by that user.

Attack Replication

At the back of the explanations above, let’s see how this technique works.

I had mentioned earlier that we will need to use the Managed Privileged feature. The main reason why is because a program execution with integrity level higher than Medium will look for the CLSID on “HKEY_LOCAL_MACHINE\Software\Classes” instead of the current user registry key (more information about this can be found here), and Managed Privileges allows to execute the scenario as a non-privileged user.

Bearing the above in mind, the first step is to gather system executables that try to load a COM object and note the CLSIDs used. In order to find and load these, we are going to use Process Monitor tool from Sysinternals. Binaries intensively used by the system such as explorer.exe are good candidates for attackers. However, for this PoC we wanted to showcase that there are other Windows applications that can successfully load COM objects.

We have divided this process into four different steps:

1- Setup Process Monitor Filters

To discover the processes we are interested in, we need to start Process Monitor and set up these two filters which ‘Action’ is ‘Include’:

Process Monitor filter to detect access to COM CLSIDs at HKEY_CURRENT_USER registry key

After setting the filters, make sure “Show Registry Activity” is enabled and that Process Monitor is capturing data. Now you can start executing system binaries and detect which ones are looking for COM objects.

2- Find Windows Binaries Loading COM Objects

There are a bunch of Windows binaries inside %WINDIR%\System32 folder. In our search, we have focused on non-GUI binaries that run without required parameters. We found “%WINDIR%\System32\getmac.exe”, which will be used to demonstrate this attack. These are the traces captured by the tool once the binary has been executed:

Process Monitor detecting getmac.exe trying to load COM id 4590F811-1D3A-11D0-891F-00AA004B2E24

These results show the access attempts to registry keys regarding a COM object with CLSID “4590F811-1D3A-11D0-891F-00AA004B2E24”. The application tries to load first the CLSID key from HKCU, but it fails as it does not exist by default. Then it looks at HKCR (remember that it is HKLM under the hood), which is the system’s default, and that value does exist.

The interesting registry key access is the one that ends with “InprocServer32” as this is the one that references the binary object (wbemprox.dll) that will deliver the COM functionality that “getmac.exe” requests. This next screenshot shows the registry value of the loaded registry key by “getmac.exe”:

Default binary object for COM id 4590F811-1D3A-11D0-891F-00AA004B2E24

3- Placing Custom DLL To Be Executed

With the information from the previous step, we have placed a custom-crafted DLL in “%WINDIR%\Temp\com_hijacking.dll” which on process attach creates the file “%TEMP%\attackiq_com_hijack.log”.

The next step is to set the default value of “HKCU\Software\Classes\CLSID\{4590F811-1D3A-11D0-891F-00AA004B2E24}\InprocServer32” registry key. This should have the following value: “%WINDIR%\Temp\com_hijacking.dll” (“C:\Windows\Temp\com_hijacking.dll” in our case). This modification should be made by an application using an integrity level of Medium or lower, as the modification will not be effective for the current user as explained earlier. This will create the registry key that we saw before did not exist, so next time “getmac.exe” is executed it will load our DLL instead of the system’s default.

4- Tweak Process Monitor Filter To Detect Custom DLL execution

Before executing the “getmac.exe” binary again, we will remove the previous Process Monitor filters and add these three new ones:

Process Monitor filters to detect if COM Hijacking attack is successful

This will allow us to quickly see three different things:

Verify the access to the CLSID we just set up is successful now (it was failing before as it did not exist)
How the “getmac.exe” loads the “com_hijacking.dll” (line with Operation “Load Image” on the next screenshot)
How the “getmac.exe” creates the “attackiq_com_hijack_file.log” as a result of loading “com_hijacking.dll” (last three lines of the next screenshot)

Process Monitor detecting a successful COM Hijacking attack

This demonstrates how the COM Hijacking attack worked successfully. This is the same attack procedure that our Component Object Model Hijacking scenario performs to replicate this attack.

After executing this threat, an attacker is able to silently achieve persistence in a system using a not so common yet used in the wild technique.

AttackIQ Scenario

In AttackIQ we have developed a scenario that executes the attack just described. To start with, this section describes the characteristics of using either a default or a custom scenario configuration in our Platform. Then, it covers the results obtained from executing the scenario once it is properly configured and there are no security controls preventing the attack.

1.- Default scenario configuration provided by AttackIQ

The scenario is configured to use the same exact binary (getmac.exe) and the same COM CLSID (4590F811-1D3A-11D0-891F-00AA004B2E24) we have seen above. Then, a custom-crafted DLL is used to avoid breaking any system binary execution using that CLSID.

Straight forward scenario configuration using defaults

The DLL used by default is a proxy DLL for the webmprox.dll. As this DLL contains the same functions as the original webmprox.dll, a call to our DLL will have the same behavior as calling the original webmprox.dll. This ensures that all applications using that binary DLL will not crash while the scenario is being executed.

Besides forwarding function calls to the original webmprox.dll, our DLL creates an innocuous file when it is loaded. This innocuous file, or canary file, is used by the scenario to decide whether the scenario execution was successful or not, so we consider that our DLL was successfully loaded when that specific file exists. Two DLL versions (32 and 64 bit) are bundled with the scenario for higher compatibility with the test environment.

2.- Custom scenario configuration

Our Platform also allows you to configure this scenario with your desired values, so you can hijack the system with your desired COM CLSID, binary and DLL.

Unchecking the “Use AttackIQ’s Defaults” checkbox will reveal several parameters to customize the scenario.

Customizable COM Hijacking scenario options

This option is enabled for advanced users as it requires you to create your own DLL. If it is incorrectly created, it will likely break the functionality of any Windows binary that uses the hijacked COM CLSID during the time the scenario is being executed.

3.- Scenario results

Once the scenario is properly configured, either with default or custom parameters, its execution using Managed Privileges will show an output very similar to this:

Successful COM Hijacking attack with default parameters

These logs show the scenario being able to accomplish the COM hijacking attack in an asset without security controls preventing the attack. Using the Process Monitor tool with the same filters mentioned in the Attack Replication section applied would have shown the same results included in that section.

Our research team is working on writing scenarios that are capable of testing if security controls are preventing this kind of attack, in addition to many other different attacks used by threat actors. This is achieved by using AttackIQ scenarios which can be very specific, such as this one, or they can be as generic as needed to modify user-provided registry keys. With these generic scenarios, everybody can test any kind of attack based on registry modifications. There are also many other generic scenarios such as executing system commands, modifying files, exfiltrating files, discovering network assets, using different persistence techniques, etc.

Mitigations

COM objects are commonly used by the system, so blocking access to COM objects is not recommended as it will likely cause a system malfunctioning.

However, creating new registry entries under HKEY_CURRENT_USER\Software\Classes\CLSID\ is something uncommon. Consequently, detecting changes under that registry key will help to detect COM Hijacking attacks. In case there is an application already using this registry location legitimately, just monitor that the path to the COM object used by that application does not change without being noticed.

References

“Chapter 7 (Analyzing Malicious Windows Programs) – The Component Object Model.” Practical Malware Analysis: the Hands-on Guide to Dissecting Malicious Software, by Michael Sikorski and Andrew Honig, No Starch Press, 2012.

TTPs