This is a little, naughty trick that enables us to achieve persistence in a quite an unexpected way.

When we talk about PATH environment variable, we know that we can set it to a specific variable using the Registry keys:

• HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
• HKCU\Environment

The problem with these is that they affect either the whole system, or the specific user. The are also widely known and any attempts of modification will be easily visible.

There is one more.

I actually described it in this series and referred to it twice; the key in question is located here:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

(Note that there is no WOW64 equivalent.)

In the first instance, I was talking about changing the (Default) value for applications to point to a malware, and mentioned the Path value will contain the string that will prepend the PATH for the application.

In the second instance I pretty much described an example of what this post discusses in more detail.

Whatever is included inside the Path variable will be added to the PATH of the program; whether it is prepended or appended is dictated by a presence of an undocumented value AppendPath. If AppendPath exists the content of Path will be appended to the PATH; if it is missing, the value of PATH will be prepended (and this is a default behavior).

As I mentioned one can change the path for pretty much any application (and create new entries for e.g. randomized file entries). While dvdplay.exe discussed earlier is a bad example, because it’s not really used that frequently, one could toy around with more popular apps.

For instances, adding:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
  App Paths\cmd.exe\Path=c:\test

will ensure that whatever program is executed from the terminal will be searched for within the current directory, then c:\test, and then directories listed inside the PATH. Have a look at what happens when you run Notepad from terminal in such scenario:

It’s a perfect condition for a more elaborate PATH companion malware.

The same goes for powershell.exe, cscript.exe, etc.

And there is more.

Any application that uses LoadLibrary will follow the DLL Search Order and as such, may end up loading the DLL from the c:\test directory.  Let’s think of the last scenario for a moment – we could place an EXE in one place, and then drop the DLL in another. The only link for finding the DLL would be in that Registry Key.

The below example illustrates it perfectly.

We add:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
  test.exe\Path=c:\test

We then place c:\test\foobar.dll and then run the c:\somefolder\test.exe – the test.exe uses LoadLibrary to load ‘foobar’ DLL and exits (the DLL is loaded w/o providing a path forcing the program to walk through the DLL Search order).

Without looking into the App Paths registry branch, or preserving the environment variables at the time the test.exe program ran, it is going to be impossible to link these two binaries in any way. Collection of samples or ‘combos of samples that work together’ will be also harder.

And yes, you could modify rundll32.exe to point its extra path item to some hidden folder too 🙂