dllhost.exe

dllhost.exe exists so a COM object can run in its own process instead of inside the application that uses it. When a COM server is configured to run in a surrogate, for stability or isolation, Windows starts a dllhost.exe and loads the component's DLL into it. The classic example is thumbnail generation: Explorer hands the risky job of parsing an unknown file to a COM Surrogate, so a malformed file crashes dllhost.exe instead of the desktop. The genuine binary lives at C:\Windows\System32\dllhost.exe, with a 32-bit copy under SysWOW64.

A legitimate dllhost.exe almost always carries a /Processid:{GUID} argument naming the COM class it is hosting, and it is started by the COM infrastructure, so its parent is normally an svchost.exe running the DCOM Launch service. Many short-lived instances are normal as thumbnails render and shell actions run.

Instances come and go with the COM work that spawns them. What a given dllhost.exe is hosting is identified by the CLSID on its command line, which maps to a registered COM server under the registry's CLSID key.

Because dllhost.exe is always present and unremarkable, it is a common cover for malware. Some samples simply run under the name from the wrong directory (T1036.005), so a dllhost outside System32 is an immediate flag. More often, attackers inject into a genuine dllhost to blend in as a COM surrogate (T1055). A dllhost.exe with no /Processid argument, one reaching the network, or one spawning a shell is behaving unlike the real host, which only ever loads and runs a registered COM class.

Its defining abuse is COM hijacking (T1546.015). An attacker repoints a CLSID's registry entry, typically under HKCU, at their own DLL, so the next time that COM object is invoked, dllhost loads the malicious DLL under a trusted, signed process. This gives both execution and persistence, and it survives without any obvious autostart entry. A /Processid CLSID whose registered server is a DLL outside System32, especially one defined per-user, points to a hijack.