Category Archives: Anti-*

Beyond good ol’ Run key, Part 75

Posted on by

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 🙂

Running programs via Proxy & jumping on a EDR-bypass trampoline, Part 6

Posted on by

In my recent post I documented how you can drop your own wmplayer.exe and force it to be loaded via dvdplay.exe. Here, I will show one of many DLLs that we can force to execute a specifically-named executable – mstran40.exe.

The msrepl40.dll’s internal name is ‘Microsoft Replication Library’ – as far as I can guess it is used by the Microsoft database engine – well, at least it exports a number of database-related functions so it must be somehow related. It doesn’t matter too much.

We are going to use one of the exported functions (#2091) that is kind enough to run any executable that is named mstran40.exe – provided a specific registry key is set. The internal name of the aforementioned function #2091 is JetTrClientInit. The mstran40.exe doesn’t exist on Windows 7 and XP, so while attempting to execute it system will search the PATH directories and since it won’t find it it will run it from a current directory. The trick doesn’t work on Win 10 :(.

The Registry key in question is this:

  • HKLM\SOFTWARE\Microsoft\Jet\4.0\Transporter\TransporterId=GUID

where GUID can be simply this:

  • {00000000-0000-0000-0000-000000000000}

It is required so that the function IIDFromString can succeed in converting it into a proper GUID. We are just providing the conditions for the JetTrClientInit function not to exit prematurely.

See attached animation to see how it works in practice:

Here’s a list of commands:

reg add HKLM\SOFTWARE\Microsoft\Jet\4.0\Transporter /v TransporterId /t REG_SZ /d {00000000-0000-0000-0000-000000000000}

md en-US
copy c:\WINDOWS\system32\en-US\calc.exe.mui c:\test\en-US\mstran40.exe.mui
copy c:\windows\system32\calc.exe c:\test\mstran40.exe

rundll32.exe msrepl40.dll,#2091

And if you are wondering why am I copying the En-us directory and the MUI file; this is to ensure calc.exe (renamed to mstran40.exe) finds its resources which are stored in a separate file (if I chose a different .exe e.g. any console-based program this wouldn’t be necessary, but we all want to see that Calculator, don’t we…).