Skip to content

Instantly share code, notes, and snippets.

@sucremad

sucremad/ComHijacking.md Secret

Last active July 31, 2021 21:46
Show Gist options
  • Save sucremad/a62050bda4181911178493302fa082c8 to your computer and use it in GitHub Desktop.
Save sucremad/a62050bda4181911178493302fa082c8 to your computer and use it in GitHub Desktop.
Download ZIP
Persistence via COM Hijacking
Raw
ComHijacking.md

So, 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 uses COM objects, and the COM servers are the COM objects themselves. The COM server can be hosted either in a DLL (called in-process server) or in an EXE (called out-of-process server).

image

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 for 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

image


image


image


Some Use Cases

Malware authors can use malicious VBA macros to run arbitrary command. Here is an example of 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, 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, 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 privilages 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 gets 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 used through normal system operation, 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 has missing CLSIDs under the HKCU.

For that lets filter the ProcMon.

image

Do standart user things and ProcMon will capture events and they are orphaned CLSIDs.

image

This lists consists of possibly hijackable trusted processes. Lets save it and then we will extract keys to hijack. David Tulis developed a script for that called acCOMplice.

image

Finding missing libraries on the system

image

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 take precedent. So attackers can entry their own malicious dll here. With this techinique, malicious dll will run instead of real COM component. This impacts only the current user and does not require special privileges. However, this will have a suspicious look because of 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.

image

HKEY_CURRENT_USER\Software\Classes\CLSID > New > Key

image

Then add the same CLSID as commonly used component and point it to malicious dll.

image

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.

image

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 created the malicious CLSID, we need a new CLSID (as the same with target component) and add the TreatAs key with the CLSID of the malicious class.

If the victim tries to load target component, again, the malicious payload will run.

image

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 uninstalled. In this situation an attacker can place a malicious payload at abandoned paths, but this is not feasable 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 crashes 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 break.

Scheduled Tasks

Since Scheduled tasks take actions 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 their XML schema file, we will see a COMHandler under the Actions Context with CLSID.

By modifiying 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 due to 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 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.exe usage can be monitored

References and More

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment