Persistence: “the continued or prolonged existence of something”

Part 2: COM Hijacking

In the first post I talked about my favourite persistence technique using Microsoft Office add-ins and templates. My second favourite technique for persistence is using COM hijacking which will be covered below, including a walkthrough of a hijackable interface in a default Windows 10 install.

The Component Object Model (COM) is a Windows feature for providing interoperability between software components through the Operating System itself. In short, COM hijacking techniques attempt to abuse this interoperability by redirecting or hijacking an invoker application in to calling the attacker payload. COM classes can be associated with a handler DLL, which will execute when the invoker application attempts to perform interoperability.

There are several techniques within the concept of COM hijacking that can be used to perform the hijack; I’ll focus on the simplest and my favourite, the HKCU hijack. In short, there are two registry locations where COM Class IDs live:

• HKLM\SOFTWARE\Classes\CLSID
• HKCU\SOFTWARE\Classes\CLSID

The keys are then merged within the HKEY_CLASSES_ROOT hive. The nuance here is that the HKCU entries will take precedence over the HKLM ones meaning that if you can override the search order, you can potentially force your DLL to be loaded instead as a low privileged user.

Once you’ve identified a COM class that you can hijack, the next thing you need is a trigger to load the class. An example of an ideal trigger is a scheduled task such as one that executes at logon as this does not need user interaction. Let’s look at a hijackable scheduled task that I identified in Windows 10.

The configuration files for all scheduled tasks live in the C:\Windows\System32\Tasks folder; the task we’re going to focus on is the Wininet Cache Task found under C:\Windows\System32\Tasks\Microsoft\Windows\Wininet\CacheTask.

Looking at the configuration file we can see that the task has the {0358B920–0AC7–461F-98F4–58E32CD89148} ClassID and uses the c:\windows\system32\wininet.dll when invoked:

Taking a closer look in the Task Scheduler tool we can see the task is configured to run at logon:

Taking a look at this CLSID in the HKLM registry we can see the DLL is referenced by the InProcServer32 key and can only be modified by the TrustedInstaller group:

However, without modifying the scheduled task or existing registry keys, we can hijack the search order by creating an equivalent key structure in HKCU with an InProcServer32 key pointing to a user controlled DLL:

Placing a simple x64 DLL such as the following in the location referenced by the InProcServer32 key causes it to be executed when the task runs, in this case at logon:

Next in this series on persistence, I will cover my third favourite persistence technique; WMI triggers.