IBM Security QRadar

Instantiating COM Components using RunDll32

Everything until this point is fine, but how an adversary can hijack the execution of a component to execute his own arbitrary code.

COM Hijacking

One of the most important registry keys that will be needed to execute our component is the ScriptletURL which points to the scriptlet file location.

ScriptletURL registry key

But when the Windows tries to find it, first it will search under the current user hive. Iif it is not there, then it will check the local system hive.

Process Monitor showing the order of checking for the ScriptletURL key

Checking something that doesn't exist during the execution time gives an adversary the opportunity to create it!

To hijack the execution of our simple component, an adversary can create a ScriptletURL key under the current user hive with a value pointing to a malicious scriptlet file, after that when any application will try to use our component, the operating system will execute the malicious scriptlet file rather than the original one.

What's more interesting is that the adversary doesn't need to store his own scriptlet file in the local machine, as the file path can also be in a shared folder, or a remote URL.

As the remote file will be under the attacker control, then he can change the file content to execute any other command, achieving a remote Command & Control!

Blue teams should keep an eye over any new COM component in the user or the system level, also to keep a close eye over any addition or modification related to ScriptletURL registry key.

Sysmon event showing the modification of ScriptletURL key

Using COM Hijacking to Bypass User Account Control (UAC)

User Account Control is a Windows feature that asks the user for a consent or approval to run an application with the administrative privileges. It can be considered as an additional layer of defense.

As an example, a privileged user may double click a malicious executable by mistake, which will lead to running a malicious executable with the privileged user permissions, but with this additional feature, a consent will be required from the user to allow the application to run with the administrative privileges, as follows:

UAC consent

But how can a malicious actor run malicious software without asking for the user's consent?

Microsoft allows some of its executables to auto-elevate and runs with administrative privileges without asking for user consent. The following examples show the Event viewer running as a High integrity level process.

One of the ways to bypass it is by finding a high integrity process "elevated process" that uses or queries something that can be modified by a lower integrity process.

For example, If a high integrity process will use a registry entry in the current user hive, then this entry can be modified from a medium integrity process "unelevated process".

Using the Process Monitor we can see if an elevated process is accessing a registry entry in the current user hive.

The following screen shows how the Event viewer was accessing some registry entries from the current user hive (HKCU) during its execution.

As we can see there are a few registry entries that the event viewer was trying to access during its execution, the event viewer was trying to load the following registry entry from the current user hive:

HKCU\Software\CLSID\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\InprocServer32

And it failed, then it succeeded to find it under the local system hive, An adversary can hijack that by adding a registry entry under the current user hive with the same component class ID, but with a value pointing to a malicious DLL file.

Hijacking an elevated process to load any DLL, is nasty, which could allow an attacker to elevate his privileges, even maintain his access, as whenever the user will open the event viewer the malicious DLL will be loaded!

One of the ways to detect it is by baselining the standard windows COM entries, as the component class ids are unique across the windows operating systems.

QRadar can store such a complex data structure and detect any unexpected modifications to COM components.

Registry modification indicating that a COM component entry has been updated, and the updated value is different from the baseline one.

Detecting Stealthy Persistence Techniques

Imagine whenever you will open "My Documents" folder the malicious code will be executed!, what a stealthy persistence technique!, to achieve that, adversaries are using Junction Folders and Library Files.

What is a Junction Folder, how it can be created, and used for persistence?

Junction Folder is just a kind of a shortcut to another folder. As an example, you can create a junction folder for "My Computer" by creating a new folder with the following name:

TestMyComputer.{20d04fe0-3aea-1069-a2d8-08002b30309d}

The folder will be created, and the random numbers at the end of the file name will not appear if it's a valid component class id.

The creation of the TestMyComputer Junction folder

There are other ways to open the "My Computer" folder using the class id and without creating a new folder, as following:

An adversary can add his own malicious COM component to the registry, with any random class id, even he/she does not need to register the component in the target system. Then the adversary needs to find a way to call his malicious component, one of the ways to do that is by creating a junction folder in the auto startup folders, like: Start Menu folder, which will lead to persistence as whenever the target machine will boot up, the Windows Explorer will navigate to the directories under the Start Menu folder which will be sufficient to trigger the load of the malicious component.

Blue teams need to monitor the creation of junction folders, which can be done using Sysmon, standard windows logs, or by using any File activity monitoring solution.

Sysmon event showing the creation of the junction folder

Adding the Component or the Junction Folder to the Windows Library Files for Stealthier Persistence

The windows Library Files are used to list the files from multiple directories, by default we have the following four libraries in windows:

Each one of them is a file with the following extension: ".library-ms", and can be opened and modified with any text editor.

Cmd.exe showing the library files with their extensions

The "Documents" library will list the files from the following two locations:

%USERPROFILE%\Documents

%PUBLIC%\Documents

We can check it from the top of the Documents library it shows "it includes the files from two locations" as following:

 

An adversary can add or include any additional folder, or can add a malicious component using the class id, as following:

After adding it, whenever the Documents will be opened, the malicious COM component will be loaded (the calculator in our case), this technique is stealthier as the adversary doesn't need to add any file to the startup folders.

Blue teams can detect that by monitoring the creation or modification of a file with the extension of ". library-ms"

Windows event indicating file with ". library-ms" extension has been updated

All Symptoms in One Offense

QRadar can detect the COM malicious activities. Blue teams need to keep an eye over the following artifacts:

- to check for the creation of new COM components in the system and current user hives

- to check if a well-known COM component will be modified with an unusual or unexpected value, which can be done in QRadar by baselining the global windows component ids with their expected values.

- to check for any modification or addition of ScriptletURL or TreatAs registry keys

- the creation or modification of junction folders and library files

 

QRadar has an out of the box use cases to detect the threats at the endpoint level: IBM QRadar Content Extension for Sysmon

To learn more you can also follow Jose Bravo's ongoing video series,  Think Like A Hacker.