@April 16, 2022
The deep magics of the Component Object Model continually amaze me.
Our subject for today’s note post is COM hijacking Adobe Creative Cloud for userland persistence. I confirmed that Creative Cloud and the multiple different software components that it uses during runtime allow for an arbitrary DLL to be loaded into the program.
I first learned about COM Hijacking in RastaMouse’s RTO course, where it proceeded to blow my mind wide open. I then cemented it as one of my favorite things to do for userland persistence.
COM Crash Course
Generally speaking, COM is a Windows feature that allows interoperability between software programs. It forms the base for Office’s Object Linking and Embedding (OLE) feature that red teamers know and love. COM allows programs in Windows to communicate via an application-level client/server architecture.
There are many ways to inject malicious code when pulling off a COM hijack. The one I’ll focus on for this note post is leveraging the InProcServer32 registry sub-key load order.
The What?
Let’s break it down:
- Every COM object has a COM class ID (CLSID).
- Every COM object has a location in the registry. Really, it is represented in a few different areas in the registry. We will make use of this fact to inject our malicious code.
- Given any COM object, you can find its configurations in the following registry locations:
HKEY_CURRENT_USER\Software\Classes\[CLSID]HKEY_LOCAL_MACHINE\Software\Classes\[CLSID]HKEY_CLASSES_ROOT\[CLSID]- HKEY_LOCAL_MACHINE represents machine wide registry configs and you need high-integrity access to manipulate it. HKEY_CURRENT_USER represents a local user’s registry configs and, like its name would suggest, you can manipulate it with regular user level access.
- One of these configurations is the
InProcServer32registry sub-key. This sub-key points to the full path of a DLL that is loaded into a process when it invokes a specific COM object. - Now, here’s the kicker: there is a search order for how the DLL is loaded in. The entry in the HKCU takes precedent over the entry in HKLM when the COM object is instantiated.
How do we combine these primitives to inject malicious code?
The Technique and My Methodology
First, we need to find a program that is vulnerable to this technique. But how do we do that?
Adobe Creative Cloud, in this case, is incidental. The following methodology can be applied to any program running on the Windows OS to search for COM hijack vectors. In fact, if you find a COM object that services multiple different programs, the hijack will occur when any of those programs instantiate the object.
Pick a Target
Go find some random program to inspect. The more complicated, the better 😉.
Run Procmon
Using Procmon, set the following filters:
Process name contains [name of the process]Path contains InProcServer32Operation is RegOpenKeyResult contains NOT FOUND
What are we asking for here? Show me every time [program name] tries to open the InProcServer32 registry sub-key and fails to do so.
This will clue us in on how the program tries to instantiate COM objects.
In my example, I set the filters and started Adobe Creative Cloud. After searching through the results in Procmon, I found this:
A RegKeyOpen attempt on a CLSID InProcServer32 sub key failed. This is a strong indicator that this COM instantiation can be hijacked when the process is started.
Remember how each COM object has a CLSID? We can look up the specific CLSID to find out what COM object this program is trying to run:
MSXML2.DOMDocument.3.0! Of course!
What does this COM object do? A better question would be: who cares? I have no idea what this part of the program is trying to accomplish by invoking this COM object. Nor does it matter!
Check The Registry
To check and find out if we can hijack this COM instance for sure, we can use the following PowerShell commands:
Get-Item -Path "HKLM:\Software\Classes\CLSID\{F5078F32-C551-11D3-89B9-0000F81FE221}\InprocServer32"Get-Item -Path "HKCU:\Software\Classes\CLSID\{F5078F32-C551-11D3-89B9-0000F81FE221}\InprocServer32"We are looking for the following results:
Notice how the two commands are almost the same, but look at different registry hives: HKLM vs. HKCU. So how do we interpret the results?
- There is an entry for a DLL in the HKLM sub-key for this COM class, in this case it is
msxml3.dll. - There is no such sub-key in HKCU. So if we create one and point the path at our malicious DLL, we can inject it into the process when the COM object is instantiated.
Drop a Sneaky Link
Sneak a sneaky (dynamic) link (library) into the file system somewhere. It does not matter where because we can now control the value of the InProcServer32 path and simply point it at our sneaky DLL.
Create the Sub-Key
Create the key for the CLSID in HKCU:
New-Item -Path "HKCU:Software\Classes\CLSID" -Name "{F5078F32-C551-11D3-89B9-0000F81FE221}”Add the InProcServer32 sub-key with the path to our sneaky boi:
New-Item -Path "HKCU:Software\Classes\CLSID\{F5078F32-C551-11D3-89B9-0000F81FE221}" -Name "InprocServer32" -Value "C:\Users\Matt\Desktop\beacon.dll”Add an additional sub-key to specify the threading model for the DLL’s execution:
New-ItemProperty -Path "HKCU:Software\Classes\CLSID\{F5078F32-C551-11D3-89B9-0000F81FE221}\InprocServer32" -Name "ThreadingModel"-Value "Both”At this point, the hijack has been prepared. It’s now only a matter of opening the program or waiting for someone else to open the program:
Done and dusted.
Considerations
But wait, notice how the program fails to load! The beacon is functional, but the program won’t launch correctly now.
When you hijack the COM object, you’re replacing the DLL that it intends to load with your own malicious DLL. So naturally, this is going to break things. The next part of this is a bit more work and I’ll leave it as an exercise to the reader: COM hijack by DLL proxying.
Simply put, create a DLL that runs shellcode for a beacon but also redirects the program to the original DLL so it still loads. In this case, I would need to analyze that original DLL (msxml3.dll) and have my malicious DLL redirect execution into it after running the shellcode of the beacon. That way, your malicious code still runs, but the program can still function.
Hunting for COM hijacks is a lot of fun, but you may notice that a successful COM hijack will break things and the beacons that spawn from COM hijacks will be erratic. I won’t say which component specifically, but I COM hijacked something native (and important 😈) to the Windows OS one time and received a few hundred beacons in the span of a few minutes that all died after a single check-in. It was hilarious, but not particularly useful.
That’s all for today! Go find some COM hijacks!
-Husky
— — — — — — > Back to Notes
Further Readings
🌐 Where You Can Find Me
🐦 Twitter | 📡 Main Blog | 👽 GitHub | 📺 YouTube
📒Recent Notes
8/30/22 Content Creators, I Will Teach You Cyber Jiu-Jitsu
8/12/22 The Responsible Red Teamer’s Manifesto
7/30/22 On Patching Binaries
7/16/22 MS-Interloper: On the Subject of Malicious MSIs
4/22/22 Failing All The Way To Token Manipulation, Part 1
4/16/22 COM Hijacking Creative Cloud
