• Dana Epp

Using Image File Execution options as an Attack Vector on Windows

Updated: Mar 16, 2018

I recently was debating with someone while looking at a threat model about the value of trusting the calling of executable processes in Windows. More to the point, we were discussing some of the weird ways in which you cannot trust WHERE a process is starting from. He was sure CreateProcess() over ShellExecute() would give the isolation control he needed.

Then I showed him Image File Execution Options in Windows.

Anyways, the trick for redirecting a process loading is to attach it to the Image File Execution options within the Windows registry. By simply mapping the executable name to a different debugger source, you can actually load something else entirely.

Let me give you a proof of concept to try:

  1. Start the Registry Editor: Click Start, click Run, and then type regedit.

  2. Locate the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\

  3. To this hive, add the SOURCE exe as a key. Lets use notepad.exe: (Right click and select New, and then Key (Add the key and name it notepad.exe)

  4. To the notepad.exe key, add a new REG_SZ (string) value called Debugger, and point it to c:\windows\system32\cmd.exe.

  5. Start up notepad (Click Start, click Run, and then type notepad)

  6. Notice that a new cmd window opened instead

Now to be fair, this isn't going to elevate your privileges or expose you to any more risk relating to malicious code that couldn't already be executed on your account. But with that said, this has the potential of SERIOUS effects for social engineering hacks and hostile code start points. As an example, spyware doesn't have to worry about trying to hide and start execution in the Run/RunOnce keys when they could simply tag to a common exe that starts up, and on startup spawn the real executable after doing its bidding. I will leave that to the reader to think about.

So what have we learned here? Well first off, its difficult to trust security by path. Secondly, you should be running as a normal user so this sort of attack vector cannot be started. (The DACL on this registry hive would prevent a normal user from touching it). Thirdly, the complexity in behind Windows exposes us to risk when we least expect it. When I first learned about this over a decade ago, I never even knew about this execution path. Even though my threat models show why its better to use CreateProcessAsUser over ShellExecute, it never even CONSIDERED this.