COM Object?
The Microsoft Component Object Model (COM) is an interface standard that allows the software components to interact and communicate with each other’s code without knowledge of their internal implementation. Microsoft says
COM is a technology that allows objects to interact across process and computer boundaries as easily as within a single process
It uses client/server architecture. COM clients are the programs that use COM objects, and the COM servers are the COM objects themselves. The COM server can be hosted either in a DLL (called an in-process server) or in an EXE (called an out-of-process server).
COM objects ,can be created and used by in any languages, was designed to support reusable software components that could be utilized by all programs. Some COM clients examples:
- VBA -> CreateObject
- PowerShell -> New-Object -COMObject
- Python -> pywin32
- Ruby -> win32ole
COM objects are identified by their globally unique identifiers (GUIDs) known as class identifiers (CLSIDs) and interface identifiers (IIDs) and they are registered in
* HKEY_CURRENT_USER\Software\Classes\<CLSID> (Per-User)
---merged---> HKEY_CLASSES_ROOT\CLSID
* HKEY_LOCAL_MACHINE\Software\Classes\<CLSID> (System-Wide)
registry hives. The merged registry hive HKCR contains the combined information of HKCU and HKLM.
HKCU vs HKLM
- HKLM contains information related to the computer while HKCU contains information specific to the user.
- If there is a change in HKLM, it affects every user of that computer but if HKCU has a change, it only affects that user.
- HKLM requires administrator privileges while it is enough to have regular user privileges for HKCU
- HKLM is loaded on start-up, HKCU is loaded when the user logged in.
Some important registry sub-keys:
- InprocServer/InprocServer32 – represents a path to a dynamic link library (DLL) implementation, in-process COM objects
- LocalServer/LocalServer32 – represents a path to an executable (exe) implementation, in another process
- TreatAs – Points another CLSID
- ProgID – human-readable text equivalent
Some Use Cases
Malware authors can use malicious VBA macros to run arbitrary commands. Here is an example of the usage of WScript.Shell COM objects in VBA:
Sub WriteRegistry()
Dim WshShell As Object
Set Wshshell = CreateObject("WScript.Shell")
WshShell.Run( "powershell.exe <command>")
End Sub
As another example, an Excel sheet can be embedded in a Word document.
Also, COM can be used in third-party applications. We can show 7-Zip right-click menu items as an example. Here, the Windows explorer shell is the COM client.
Abusing COM Objects – COM Hijacking
Before a process can access a COM object, registration is needed first. Via regsvr32.exe, COM object can self-register.
regsvr32.exe /n <dllname>.dll
When registering an object, HKCU key has precedence over HKLM key. This means that keys are read from HKCU before HKLM, and to add keys HKCU no special privileges are required. Thus, COM hijacking can be performed with regular user privileges.
Any object is registered in HKCU hive will be loaded before an object is registered in the HKLM hive.
Exception:
High integrity processes (elevated) load only from HKLM to prevent elevation of privileges.
When the legitimate programs used COM objects, their associated DLLs get loaded into the process address space of the client program. This is where the idea comes into play. If the attacker replaces the registry entry with the malicious DLL, when the hijacked object is used through normal system operation, the adversary’s code will be executed.
In short, a system-wide COM object is replaced by a malicious user-specific object.
COM hijacking technique can be used for persistence, lateral movement, privilege escalation and defense evasion.
To hijack a COM object:
- First, we need to find hijackable keys and extract them to use.
- Second, we need to create our payload.
- Finally, hijack the key.
Let’s see how we can enumerate the keys with Procmon.
How to Find COM Hijacking Opportunity Using Sysinternal Tools
For enumerating possible keys to hijack, we can use Process Monitor from Sysinternals. We can discover COM servers that have missing CLSIDs under the HKCU.
For that let us filter the ProcMon.
Do standart user things and ProcMon will capture events and they are orphaned CLSIDs.
This lists consists of possibly hijackable trusted processes. Let’s save it and then we will extract keys to hijack. David Tulis developed a script for that called acCOMplice.
Finding missing libraries on the system
As a result, Process Monitor can be used to enumerate CLSIDs. When you find a possible CLSID, you can hijack it with one of the techniques.
How It Can Be Used For Persistence
COM hijacking is a stealthy persistence technique. We can find this technique in Mitre ATT&CK framework.
It has multiple techniques like hijacking existent components by CLSID, ProgID, or scheduled tasks etc. Let’s cover some of them.
Hijacking by CLSID
We know that COM components are identified by CLSIDs and HKCU takes precedent. So attackers can enter their own malicious dll here. With this technique, malicious dll will run instead of the real COM component. This impacts only the current user and does not require special privileges. However, this will have a suspicious look because the real component will not be launched and do their functions. To avoid this situation, the combination of malicious payload and instance of the original COM component will work.
Let’s try to get a reverse shell with this technique.
HKEY_CURRENT_USER\Software\Classes\CLSID > New > Key
Then add the same CLSID as a commonly used component and point it to malicious dll.
Now, if the victim tries to load the component that the attacker chose, it launches a reverse shell back to the attacker.
Hijacking by ProgID
An application can use the ProgID when they do not know the CLSID of a component. Similarly, to hijack by ProgID, a false ProgID entry can be added under the HKCU with the malicious CLSID.
Hijacking by TreatAs
According to Microsoft, TreatAs specifies the CLSID of a class that can emulate the current class. With TreatAs, we can make a reference to a different component.
After creating the malicious CLSID, we need a new CLSID (as the same with the target component) and add the TreatAs key with the CLSID of the malicious class.
If the victim tries to load the target component, again, the malicious payload will run.
Hijacking Orphaned Keys
Sometimes, there may be nonexistent InprocServer32/InprocServer and LocalServer32/LocalServer key-values. For example, this case can occur when 3rd party software components are uninstalled. In this situation, an attacker can place a malicious payload at abandoned paths, but this is not feasible all the time because most COM servers require Administrator privileges for writing.
Search Order Hijacking
This technique based on registry precedence rules. Like Bohops says in the blog post, “By adding the proper registry keys in the HKCU Registry hive, keys located in HKLM are overridden (and ‘added’ to HKCR) when referencing the target COM object.”
When you load a different dll, it may crash the applications. To avoid that leoloobeek wrote COMProxy. It allows us to run the malicious functionality and at the same same time the original DLL’s functionality. So, it protects applications from breaking.
Scheduled Tasks
Since Scheduled tasks take action from HKCR\CLSID, we can find a possibility to hijack because of the precedence rules.
Like enigma0x3 mentioned in his blog post before, some of the scheduled tasks have “Custom Handler” action. When we look at their XML schema file, we will see an COMHandler under the Actions Context CLSID.
By modifying the Default value of the CLSID’s sub-key with our malicious payload, when the scheduled task run, the malicious payload is executed.
How We Can Detect It?
COM hijacking technique is not an easily detectable technique because it uses trusted system processes.
- Because of the COM components registry entries, per-user is not frequent, these changes can be considered suspicious.
- Sysmon can be configured for HKCU\CLSID actions.
- Watch TreatAs keys
- Check abandoned keys
- If there is a registered per-user COM object which has a different dll in machine-wide, it is suspicious.
- Due to CLSIDs can be called by
rundll32.exe -sta {CLSID},rundll32.exeusage can be monitored
References and More
- https://attack.mitre.org/techniques/T1546/015/
- https://docs.microsoft.com/en-us/windows/win32/com/com-objects-and-interfaces
- https://youtu.be/pH14BvUiTLY
- https://youtu.be/svFundrBIiQ
- https://youtu.be/yecohKHoh6g
- https://youtu.be/3gz1QmiMhss
- http://www.differencebetween.net/technology/hardware-technology/difference-between-hkey_current_user-and-hkey_local_machine/
- https://stmxcsr.com/persistence/2020/02/15/com-hijacking.html
- https://0xpat.github.io/Abusing_COM_Objects/
- https://www.elastic.co/blog/how-hunt-detecting-persistence-evasion-com
- https://bohops.com/2018/06/28/abusing-com-registry-structure-clsid-localserver32-inprocserver32/
- https://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/
- https://enigma0x3.net/2016/05/25/userland-persistence-with-scheduled-tasks-and-com-handler-hijacking/
- http://codetastrophe.com/Larimer-VB2011.pdf
- https://attackiq.com/2020/03/26/component-object-model-hijacking/
- https://pentestlab.blog/2020/05/20/persistence-com-hijacking/
- https://www.cyberbit.com/blog/endpoint-security/com-hijacking-windows-overlooked-security-vulnerability/
- https://cyberfishnews.com/persistence-com-hijacking-44899.html
- https://github.com/nccgroup/acCOMplice
