What is the “DLLHOST.EXE” Process Actually Running

Malware Analysis
1

dllhost.exe

If you’ve been reading my recent blog posts, you’ll notice that I’ve taken an interest in windows processes. If you haven’t yet check my two recent posts on “svchost.exe” and “rundll32.exe”. Please do.

A Deep Dive Into RUNDLL32.EXE

Continuing with the same theme, today we’ll be taking a look at “dllhost.exe” and answering the simple question.

“What is the DLLHOST.EXE process actually running”

Before we can answer this question, let’s first take a little detour and understand a little bit about COM.

Component Object Model (COM)

Let’s start with a definition from MSDN about COM.

The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundation technology for Microsoft’s OLE (compound documents), ActiveX (Internet-enabled components), as well as others. — MSDN

In other words, COM provides a mechanism for developers to create and control objects (components) that can be used by and from applications, frameworks and the OS itself (I.e Code Reusability). It also allows inter-process communication even across machines and networks with (DCOM) and all of this while being language agnostic.

https://networkencyclopedia.com/wp-content/uploads/2019/09/component-object-model-com.gif

At the basic level, COM defines a COM Component that can contain multiple COM objects which they contain one or multiple interfaces.

COM objects and interfaces are registered in the windows registry under the following registry key.

HKEY_CLASSES_ROOT/CLSID/{GUID}

“All users” and “Users” specific settings are stored in the following keys respectively

“HKEY_LOCAL_MACHINE\Software\Classes” 
“HKEY_CURRENT_USER\Software\Classes”

Inside these CLSID keys you’ll see sub keys containing the word “Server” that’s because COM communication is modeled after a Client/Server architecture.

The client is any application requesting a COM Object (CLSID) from the system, the server requests are handled by the Service Control Manager (SCM). (See figure below)

COM Object Example Request
  1. Client request a COM Object
  2. The SCM locates the COM object on the registry via its CLSID
  3. The SCM then makes a request to the server (be it local or remote) and grab a reference to the COM class.
  4. The SCM passes the reference back to the client, which he can use to create the object.

For more information about COM and its technical details, please refer to MSDN.

COM Technical Overview - Win32 apps

COM Registry Keys (CLSID / ProgID / AppID)

Now with that little introduction into COM is out of the way, let’s talk about some important registry keys that are related to COM.

CLSID

As mentioned before the CLSID is a globally unique identifier that identifies a COM object. It contains a reference to the “server” (file on disk) that’ll implement the requested class.

Its “InProcServer32” in the case of a DLL object, and “LocalServer32” in the case of an executable object.

ProgID

Is another way to identify a COM object but with less precision as it’s not guaranteed to be unique. (Note that this is an optional key)

AppId

The AppID is a key that groups the configuration of one or more (D)COM objects.

Let’s illustrate all of this with an example and let’s take the “Thumbnail Cache Class Factory”

The COM factory is registered and can be found in the registry via its CLSID {AB8902B4–09CA-4BB6-B78D-A8F59079A8D5} and since this object is designed to run as a DLL you’ll notice the “InprocServer32” key that contain a reference to the DLL that will get loaded when this object is requested.

You’ll also notice that this object contains an AppID key which contain the configuration and permissions in which this object will get run.

And that’s how a typical object is laid out in the registry in the general case.

DLL Surrogate

Now that we understand a little bit more about how things work in COM. Let’s ask the following question.

What if we used a COM Object that’s running inside our process as a DLL and it crashes? Well the short answer is, the whole process will crash. That’s exactly what was happening to our poor friend explorer back in the day.

“explorer.exe” was using a COM object to compute folder thumbnails, but as the COM object crashed for whatever reason, it took the parent process down with it.

To solve this issue, Microsoft created the COM SURROGATE process.

COM Surrogate (DLLHOST.EXE)

Here is a description of the COM Surrogate process from the official Microsoft blog “The Old New Thing”

The COM Surrogate is the I don’t feel good about this code, so I’m going to ask COM to host it in another process — Old New Thing

In short we can host COM Objects in a standalone process called “dllhost.exe” that runs, as the name suggest DLL’s.

All you need is a value of type “REG_SZ” in the AppId key called “DllSurrogate” set to an empty string or NULL.

And when the system requests the DLL it’ll launch the default surrogate process (which is “dllhost.exe”) and you’ll see something like the following in your process tree or logs.

Where the “Processid” flag represents the CLSID / AppId of a COM object.

DLLHOST & Malware

As one may suspect, the “dllhost.exe” process has been used by malware in the past (especially trickbot).

One of the use cases is the usage of the CMSTP COM Interfaces such as CMSTPLUA {3E5FC7F9–9A51–4367–9063-A120244FBEC7} and CMLUAUTIL {3E000D72-A845–4CD9-BD83–80C07C3B881F} to bypass UAC (User Account Control).

So always monitor what’s being passed to a “DLLHOST.EXE” process and make sure that the COM interface is not hijacked or being used maliciously.

Conclusion

This conclude our discussion on “dllhost.exe”. I hope you enjoyed reading and that you learned something along the way.

Please if you have any feedback or suggestions regarding this topic or any other send them my way on twitter @nas_bench

Happy Hunting

Resources

Article Link: What is the “DLLHOST.EXE” Process Actually Running | by Nasreddine Bencherchali | Medium