COM Hijacking – Windows Overlooked Security Vulnerability

Forget all you know about sophisticated code injection technique. Persistence in the system and running code as part of a trusted critical process can be done with ease without implementing complex code injection mechanism. COM hijacking is a well-known technique, however today it remains an overlooked persistence and injection mechanism which is stealthier than most of the known code injection techniques. Today most security products can easily detect code injection by hooking the desired API calls and marking a certain order as malicious. On the other hand, COM hijacking is hiding within benign COM objects instantiation, therefore it is complicated to differentiate malicious behavior from benign.

In this proof-of-concept research, we show how easy it is to find hundreds of COM objects that can be used to inject code into the most common injection candidates such as; Explorer.exe, svchost, chrome, iexplore, etc. In addition, doing so will also serve as a persistence mechanism at the same time, which reduces the need to implement one of the known and conspicuous persistence keys.

The investigation started with the analysis of the latest brand of “Turla Mosquito”.

In the ESET report on the Turla Mosquito the researchers specified the following:

“It will replace the registry entry under HKCR\CLSID\{d9144dcd-e998-4eca-ab
6a-dcd83ccba16d}\InprocServer32 or HKCR\CLSID\{08244ee6-92f0-47f2-9fc9-929ba
a2e7235}\InprocServer32 with the path to the loader. These CLSIDs correspond respectively
to EhStorShell.dll and to ntshrui.dll. These DLLs are launched legitimately by a lot of processes,
including explorer.exe”

This indication made us wonder how many silent keys are out there waiting to be abused by malicious actors. In order to do a preliminary examination, we decided to focus on phantom COM objects and Search Order Hijacking.

COM, Phantom and COM Hijacking

COM allows different software components to interact by advertising objects and their interfaces in a global repository, this repository is handled by the Windows registry system.

When a software component is accessing a COM object this access is handled via query to the registry according to a unique identifier called GUID, under each GUID there is a reference to the file implementing the classes interfaces.

The registry system is constructed of hives, in which HKCU is the current user hive, which holds all user-based COM objects registration and HKLM is the local machine hive, which holds all COM objects that are relevant for the entire machine.

In addition, COM employs a security policy that restricts access of high integrity processes to HKLM entries to avoid UAC bypass, since medium to low integrity processes cannot write to HKLM hive while HKCU hive is available to all processes.

Phantom COM Objects

Phantom COM objects are references in the registry for objects that don’t have an implementation file on disk. For example, under the registry key HKCU\CLSID\{xxxx}\InprocServer32\Default  where {xxxx} is the appropriate GUID for the COM object you should find a reference to a file yyy.dll. If this file is not present on disk or the “(default)” entry is missing, a process requesting access to this object will fail.

COM Search Order Hijacking

Machine-wide COM objects are registered in:

HKEY_LOCAL_MACHINE\Software\Classes

Per-user COM objects are registered in:

HKEY_CURRENT_USER\Software\Classes

User-specific COM objects can be registered by any process at medium integrity level and are only visible to the user that installs them. However, they take precedence over machine-wide objects in the COM subsystem. COM object hijacking is a technique in which malicious software can replace a benign system-wide COM object with a malicious user-specific object that gets loaded in its place.

Our COM Hijacking POC

The intention of our COM hijacking POC was to mimic the operations that a malicious actor would perform when trying to research unmapped vectors that can be abused to perform malicious operations.

We began by trying to map candidates that can be abused to generate COM hijacking. The first step was to select a target application. We chose “Explorer.exe”, which is a common target for malware since it is responsible for all the desktop user operations and therefore whitelisted by many security products.

Step 1:  Enumerating all possible candidates using ProcMon

We were monitoring the application operations using ProcMon, a Sysinternals tool used to monitor certain system operations.

ProcMon was used to enumerate all the failures of “RegKey Open” by Explorer.exe where the path suffix was “InprocServer32″, this will identify potential missing registry values that are either not present at all or are present at the HKLM hive and not in the HKCU.

The output was extracted to a CSV file called TargetCLSIDs.csv

Step 2:  Implant Dummy.dll in each of these keys

We generated our own stub DLL called “Dummy.dll” which basically just unloads itself in the DLL main function. This was done to reduce the timeout and collision issues and enable smooth testing.

Then we generated a PowerShell script which does the following:

1. Parses the CSV file and extracts the keys
2. Generates a batch file that will write to each Path in the “(default)” key the path to a dummy DLL
3. Dummy DLL is renamed with a sequence number to uniquely identify the appropriate key from the original CSV
4. Runs the batch file

PowerShell Snippet:

PowerShell Output:

Step 3: Verifying which DLLs were loaded by each module

To verify which DLLs were successfully loaded by which module, we used ProcMon. This time we were monitoring the “load image” event and searching for entries with a path column containing “Dummy%” and with “Success” in the result column.

As you can see the findings are alarming. Not only were these DLLs loaded by the original “Explorer.exe”, they were also loaded into tons of other processes. Some of them are commonly abused by malware authors since they are trusted, whitelisted processes such as; iexplore.exe, Chrome.exe, and svchost. Chrome and iexplore are usually whitelisted to have network connectivity since these are browsers which require access to most sites.

svchost.exe, a.k.a. the service host process serves as a shell for loading services from DLL files. Therefore, since IPS and endpoint security products aim to avoid false positives and allow critical services to run with any interruptions, they must whitelist svchost.exe and allow it to do many “Suspicious” activity that may be blocked if it were any other process that is not an OS Process.

Another troubling finding is the fact that adding these DLLs doesn’t even require a boot. Since most keys were affected immediately upon running the target process, some keys did not even require execution of the target process for a process which is already running such as “Explorer.exe”

Full Result Set:

Explorer

212-   HKCR\CLSID\{0e119e63-267a-4030-8c80-5b1972e0a456}\InprocServer32
175-   HKCR\CLSID\{69486DD6-C19F-42e8-B508-A53F9F8E67B8}\InprocServer32
90-    HKCU\Software\Classes\CLSID\{b03c2205-f02e-4d77-80df-e1747afdd39c}\InprocServer32
127-   HKCR\CLSID\{9BA05972-F6A8-11CF-A442-00A0C90A8F39}\InprocServer32
21-     HKCR\CLSID\{4661626C-9F41-40A9-B3F5-5580E80CB347}\InprocServer32
219-   HKCU\Software\Classes\CLSID\{35786D3C-B075-49B9-88DD-029876E11C01}\InProcServer32

Chrome

14-    HKCU\Software\Classes\CLSID\{BCDE0395-E52F-467C-8E3D-C4579291692E}\InprocServer32
63-    HKCU\Software\Classes\CLSID\{591209c7-767b-42b2-9fba-44ee4615f2c7}\InprocServer32
19-    HKCU\Software\Classes\CLSID\{9FC8E510-A27C-4B3B-B9A3-BF65F00256A8}\InprocServer32
137-  HKCU\Software\Classes\CLSID\{00021401-0000-0000-C000-000000000046}\InprocServer32

iexplore

0-     HKCU\Software\Classes\CLSID\{660b90c8-73a9-4b58-8cae-355b7f55341b}\InprocServer32
15-   HKCU\Software\Classes\CLSID\{317D06E8-5F24-433D-BDF7-79CE68D8ABC2}\InprocServer32
17-   HKCU\Software\Classes\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7}\InprocServer32
19-   HKCU\Software\Classes\CLSID\{9FC8E510-A27C-4B3B-B9A3-BF65F00256A8}\InprocServer32
63-   HKCU\Software\Classes\CLSID\{591209c7-767b-42b2-9fba-44ee4615f2c7}\InprocServer32
136- HKCU\Software\Classes\CLSID\{00020420-0000-0000-C000-000000000046}\InprocServer32

svchost

0-     HKCU\Software\Classes\CLSID\{660b90c8-73a9-4b58-8cae-355b7f55341b}\InprocServer32
21-   HKCR\CLSID\{4661626C-9F41-40A9-B3F5-5580E80CB347}\InprocServer32
14-   HKCU\Software\Classes\CLSID\{BCDE0395-E52F-467C-8E3D-C4579291692E}\InprocServer32
19-   HKCU\Software\Classes\CLSID\{9FC8E510-A27C-4B3B-B9A3-BF65F00256A8}\InprocServer32
63-   HKCU\Software\Classes\CLSID\{591209c7-767b-42b2-9fba-44ee4615f2c7}\InprocServer32
137-   HKCU\Software\Classes\CLSID\{00021401-0000-0000-C000-000000000046}\InprocServer32
157-   HKCR\CLSID\{A47979D2-C419-11D9-A5B4-001185AD2B89}\InprocServer32

Dllhost

96- HKCU\Software\Classes\CLSID\{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}\InprocServer32

PowerShell

0-      HKCU\Software\Classes\CLSID\{660b90c8-73a9-4b58-8cae-355b7f55341b}\InprocServer32
137-  HKCU\Software\Classes\CLSID\{00021401-0000-0000-C000-000000000046}\InprocServer32

Step 4: Verifying hijack side effects on the OS

Now all that is left is to play with the OS and see which OS functionalities were broken in a way which can be obvious to the user.

A real malware author with time and patience would have done one of the following:

1. Full Proxy DLL implementation to the original DLL
2. Upon initial load, remove the added DLL to reduce visibility and add it again before shutdown
3. Search for keys which don’t break any critical infrastructure or OS capabilities

In our case, we did not notice any crash of the OS. We did notice some functionality which did not work correctly such as using the Windows Key, etc.

COM Hijacking In the Wild

When searching for the keys on the web, we discovered numerous samples using these keys. However, not as many as we would have expected given the simplicity of using these techniques and the lack of security awareness for this risk:

• Trojan-Dropper.Win32.Agent.nxtj 482a70b7f29361665c80089fbf49b41f

{BCDE0395-E52F-467C-8E3D-C4579291692E}

• Trojan-Dropper.Win32.Agent.nxtn 88fc61bcd28a9a0dc167bc78ba969fce

{BCDE0395-E52F-467C-8E3D-C4579291692E}

• UDS:DangerousObject.Multi.Generic 11f814e7fb9616f46c6e4b72e1cf39f6

{BCDE0395-E52F-467C-8E3D-C4579291692E}

• Trojan:WinREG/Startpage.M a864bb896b24175d58aa15bacf646954

{00021401-0000-0000-C000-000000000046}

• Powerlikscc108b012ed2e9ed687d1406ffef92b0

{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}

In addition, we have seen indications of monitoring these keys by the famous VAULT7 leak:

Summary:

Our little experiment was a troubling success. We discovered the following:

• Hundreds of registry keys are vulnerable to COM hijacking and Phantom COM Objects loading
• This COM hijacking process is easy to implement and doesn’t require any sophisticated and noisy code injection technique
• The fact that these objects failed to load in the first place, allowed us to quickly and efficiently map the dependent processes
• COM hijacking can be done effectively using regular user privileges
• By simple manipulation of the registry, you gain persistence and code injection in a single flow
• Running the injected DLL can happen without requiring a reboot
• Running the injected DLL won’t usually have any visible side effects on the user
• These COM values are not monitored today by most security product
• These alarming findings were discovered by evaluating a single process on a single use case of “inproc server”. The full scope of the problem is far wider
• It is used in the wild, but not intensely as regular registry run key and injection techniques

Mitigations:

1. Consider using a security solution that mitigates the risk by monitoring COM search order hijacking and phantom COM objects loading
2. Give high attention to crashes and error messages on user’s PCs. They might be an indication of malicious activity

Authors

Yaniv Assor –  Background Research and POC Implementation

Doron Vazgiel – POC Implementation

Meir Brown – Research Advisor