Microsoft introduced Component Object Model (COM) in Windows 3.11 as a method to implement objects that could be used by different frameworks (ActiveX, COM+, DCOM etc.) and in different Windows environments allowing interoperability, inter-process communication and code reuse. Abuse of COM objects enables red teams to execute arbitrary code on behalf of a trusted process. Administrator privileges are not required to perform COM Hijacking since classes in the HKCU registry hive are executed prior to the classes in HKLM. The only exception affects high integrity processes (elevated) which objects are loaded only from HKLM location to prevent elevation of privileges.
There are multiple methods that execution of code can be achieved but there are several cases which COM has been used in red teaming scenarios for persistence, lateral movement and defense evasion. Depending on how the malicious code will executed various registry sub-keys are used during COM Hijacking. These are:
The above sub-keys are under the following registry hives:
Table of Contents
Discover COM Keys – Hijack
Identification of COM keys that could be used to conduct COM hijacking is trivial and requires the use of Process Monitor in order to discover COM servers which are missing CLSID’s and doesn’t require elevated privileges (HKCU). Process Monitor can be configured with the following filters:
Opening files and executing tasks like a standard user will produce a list with COM keys that could be hijacked in order to load an arbitrary library to a trusted process.
The results could be used directly or exported in various formats like CSV and XML.
A PowerShell script called acCOMplice developed by David Tulis contains a function which can take process monitor results in CSV format in order to extract keys that could be hijacked.
The tool has also a function which can retrieve directly the missing libraries that exist on the system and their CLSID’s.
An alternative method is by executing the following PowerShell snippet as it has has been demonstrated by bohops in his article about Abusing the COM Registry Structure. This can be used to enumerate “LocalServer32” classes that could be hijacked:
Similarly the following PowerShell code can enumerate InprocServer32 classes:
Executing the snippet will produce a list of COM libraries that could be investigated for COM hijacking opportunity.
Matt Nelson and Matthew Graeber developed a PowerShell script (Get-ScheduledTaskComHandler) which can check all scheduled tasks on the host that execute on user logon and are vulnerable to COM hijacking.
The parameter “PersistenceLocations” will retrieve schedule tasks vulnerable to COM hijacking that could be used for persistence and they don’t require elevated privileges. The CLSID and the associated DLL will also displayed in the output.
The task “CacheTask” when invoked uses the “wininet.dll” and has the following CLSID: {0358B920-0AC7-461F-98F4-58E32CD89148}
The CLSID and the associated DLL can be also obtained from the configuration file of the task. This file is stored in the following location:
Alternatively, invoking the “schtasks” utility from the PowerShell console with the parameters below can retrieve also the contents of the file.
Reviewing the task scheduler will verify that the task trigger is to start during the logon of any user. Hijacking the CLSID will establish a persistence condition on the system.
The “InprocServer32” (In-Process Server) registry key indicates where a COM library is located on the disk and defines the threading model. The image below demonstrate the registry keys that exist typically in “InprocServer32“.
Recreating the registry key structure in the HKCU for the “Cache Task” that was discovered above and pointing to an arbitrary DLL instead of the “wininet.dll” will execute the code since the DLL located in the HKCU will be loaded prior to the HKLM.
The following DLL file will create a message box that will demonstrate a message to indicate that code has been executed when the process “CacheTask” is started.
The DLL needs to be dropped into disk and the sub-key “InprocServer32” needs to point to the location of the DLL.
Since “CacheTask” is scheduled to start by default during the log on of any user code will executed permanently across logons (persistence).
A malicious DLL can be generated also with Metasploit utility “msfvenom” by executing the following command:
Replacing the previous DLL with the DLL generated by Metasploit on the same registry path that the hijacked occurred.
Code will executed and a Meterpreter session will established every-time that a user is logon on the target system.
It is also possible to execute fileless payloads like scriptlets instead of DLL files.
The “ScriptletURL” registry key defines the remote location of the arbitrary .sct file that will be fetched and executed when the COM class is invoked.
Executing the following command will invoke the COM class and will execute directly the payload.
LocalServer32 registry entry specifies the location on the system of an external COM object. These are usually applications that have the form of an executable. The following COM class ID has been retrieved earlier during the enumeration of hijackable keys can be used to execute an arbitrary executable.
Replacing the default value of the application with the location on the disk of the arbitrary executable will implement the hijack.
It is also necessary to activate the ClassID by executing the following PowerShell command as otherwise the COM object will be disabled.
When the COM object will be called the arbitrary executable will run and a session will established with the command and control system.
TreatAs/ProgID
The “TreatAs” is a registry key which allows a CLSID to be emulated by another CLSID. This can be used to redirect a COM object to another COM object. This was presented initially by Casey Smith and Matt Nelson in their talk Windows Operating System Archaeology in 2017. Abuse of the “TreatAs” involves the following two steps:
The “ProgID” is the friendly name of a COM object and it is not unique. The following registry keys resolve ProgID’s to CLSID’s.
This means that when an application (client) activates a COM object (class) the operating system will resolve the associated “ProgID” by reading initially the following registry location:
Casey Smith and Matt Nelson released a proof of concept as part of their presentation to demonstrate that a class could be called as well by its “ProgID” or by the “TreatAs” subkey to perform evasion. The following file can be used as an example.
The file will create the required registry keys that would be used for the hijack of a valid CLSID. Executing the command below will import the file into the registry.
The “rundll32” utility with the “-sta” (single threaded apartment) switch can be used to call the malicious “TreatAs” CLSID or the “ProID“.
In both scenarios the arbitrary code is executed successfully and sessions are opened.
InprocServer32 – Internet Explorer
Internet Explorer is used actively in corporate environments as it provides compatibility with internal applications that have a web interface. An analysis of the COMpfun RAT by G Data SecurityLabs revealed that threat actors hijacked a legitimate COM object in order to establish persistence on the system when Internet Explorer process is invoked.
This is because Internet Explorer like many other Windows applications uses the following file “api-ms-win-downlevel-1×64-l1-1-0._dl” or “api-ms-win-downlevel-1×86-l1-1-0._dl” when the process is starting. This file can be found in the following Windows location:
The COM Object hijacking persistence PowerShell script can be used as a proof of concept of this technique. Executing the script will create the required folder structure and will perform a check on the architecture of the host in order to make the necessary registry modifications.
When the process “iexplore.exe” is launched, the calculator will start which will prove that the hijack was successful.
It is also trivial to generate an arbitrary DLL with Metasploit utility “msfvenom” and replace the .dl file in order to establish a Meterpreter session.
Creating the following CLSID manually in the registry and modify the key to point to the location of the DLL on the system.
When Internet Explorer is launched again the DLL file will loaded under a trusted process.
A Meterpreter session will open which will demonstrate that persistence has been achieved. It should be noted that using directly a DLL generated by Metasploit it might cause system instability and Internet Explorer might run as a process but not open. This is because the CAccPropServiceClass () will be called multiple times, therefore some further optimization on the DLL file is needed.
This content was originally published here.