Hunting for COM Hijacks
Last updated
Last updated
Instead of hijacking COM objects that are in-use and breaking applications that rely on them, a safer strategy is to find instances of applications trying to load objects that don't actually exist (so-called "abandoned" keys). Process Monitor is part of the excellent Sysinternals Suite. It shows real-time file system, registry and process activity and is very useful in finding different types of privilege escalation primitives.
It's more straight forward to hunt for hijacks on your own machine first, and then implement them on the actual target. Launch procmon64.exe on Attacker Desktop.
Due to the sheer number of events generated, filtering is essential to find the ones of interest. We're looking for:
RegOpenKey operations.
where the Result is NAME NOT FOUND.
and the Path ends with InprocServer32.
\
\
To speed the collection up you click random things, go into the Windows menu, launch applications etc. After a minute or so, I have ~500 events. Most of them are from Explorer, some from 3rd party software and others from OS components.
\
\
One aspect to look out for is the number of times a particular CLSID is loaded. If you hijack one that is loaded every couple of seconds, you're going to have a rough time - so it's well worth the additional effort to find one that's loaded semi-frequently but not so much so or loaded when a commonly used application (Word, Excel, Outlook, etc) is opened.
Scrolling through, I picked out this CLSID being loaded by C:\Windows\System32\DllHost.exe.
\
We can use some quick PowerShell to show that the entry does exist in HKLM, but not in HKCU.
\
To exploit this, we can create the necessary registry entries in HKCU and point them at a Beacon DLL. Because this is still on our attacking machine, we'll point it straight at C:\Payloads\http_x64.dll
.
\
When DllHost.exe loads this COM entry, we get a Beacon.
\
\
To clean-up a COM hijack, simply remove the registry entries from HKCU and delete the DLL.
\
\
Another great place to look for hijackable COM components is in the Task Scheduler. Rather than executing binaries on disk, many of the default Windows Tasks actually use Custom Triggers to call COM objects. And because they're executed via the Task Scheduler, it's easier to predict when they're going to be triggered. We can use the following PowerShell to find compatible tasks.
\
This script is rather self-explanatory and should produce an output similar to the following:
\
If we view the MsCtfMonitor task in the Task Scheduler, we can see that it's triggered when any user logs in. This would act as an effective reboot-persistence.
\
\
Lookup the current implementation of {01575CFE-9A55-4003-A5E1-F38D1EBDCBE1} in HKEY_CLASSES_ROOT\CLSID.
\
We can see it's another InprocServer32 and we can verify that it's currently implemented in HKLM and not HKCU.
\
Now it's simply a case of adding a duplicate entry into HKCU pointing to our DLL (as above), and this will be loaded once every time a user logs in.