Brief introduction

COM Hijacking technique has a simple theoretical basis, similar to the DLL Hijacking one:An attacker may create it by means of altered information. For instance, a path leading the victim to a DLL created by the attacker instead of to the searched one. We can benefit from the by-default order used by the program to search for this object:

COM (Component Object Model) is a binary-interface standard for software components allowing communication between processes as well as dynamic creation of objects, regardless of the language used to program them. COM provides a stable ABI (Application Binary Interface) that does not change with compilers’ different versions. This is appealing for C++ developers when the code must be shared with clients using different compilers’ versions.

COM objects are commonly compiled as a DLL, but the way they are used is particular. COM objects must be unequivocally identifiable at execution time, so the GUID identification method is used.

{CB4445AC-D88E-4846-A5F3-05DD7F220288}



Each COM object is registered under its corresponding GUID, together with one or more keys that provide information on the object itself, such as the real path of its specific DLL. Usually, COM objects are registered under the following registry paths: HKLMSOFTWAREClassesCLSID or HKLUSOFTWAREClassesCLSID. There, under the corresponding GUID key, InprocServer, InprocServer32, InprocHandler e InprocHandler32 registry keys are commonly used to provide the object DLL with the paths. If the COM object is under the root HKEY_LOCAL_MACHINE (HLKM), this means that it is available for all users on the computer and has been created thanks to system admin permissions; while those under the root HKEY_CURRENT_USER (HCKU) are valid for the user currently authenticated and not necessarily created by an admin.

The system’s search order is quite interesting. A typical scenario is going firstly to user’s branch and then to the computer’s branch where it is executed. Let’s think of an application that when boosting needs to use the functions of the COM object located on the following registry key:

HKEY_LOCAL_MACHINESOFTWAREClassesCLSID{CB4445AC-D88E-4846-A5F3-05DD7F220288}InprocServer32

However, before examining there, the application search for it in the following path:

HKEY_CURRENT_USERSOFTWAREClassesCLSID{CB4445AC-D88E-4846-A5F3-05DD7F220288}InprocServer32

In case this last key did not exist, we would be facing an application vulnerable to COM hijacking. Performing the technique only involves creating the following structure on the registry:

HKEY_CURRENT_USERSOFTWAREClassesCLSID

{CB4445AC-D88E-4846-A5F3-05DD7F220288}

InprocServer32

(Default) = C:DLLsMaliciosasmiDLL.dll

COM Hijacking as a persistence technique

The COM Hijacking technique to achieve persistence brings several advantages against the remaining traditional techniques to boot the system. The best way is to have a native COM object, called every time the system is boosted. The main problem here is that native COM objects are usually located on HKCR (classes root) instead of on the user’s own registry, so a user on its own should not be able to access it.

The truth is that HKCR is a virtual view of that we see both on HKCU and HKLM. This means that if you wish to write a key on

HKCRCLSID{A47979D2-C419-11D9-A5B4-001185AD2B89}

You would be able to do it by creating it on

HKCUSoftwareClassesCLSID{A47979D2-C419-11D9-A5B4-001185AD2B89}

Consequently, to perform the hijack over the native COM object on Windows, the key may be created as shown in the following image, where you can observe how it is immediately spread.