Beyond good ol’ Run key, Part 108

This is my favorite persistence trick of 2019 so far.

64-bit WOW layer got changed a lot in Windows 10, and this article covers it in-crazy-depth.

An interesting feature that comes as a result of these changes is a functionality provided by OS when the following value exists:

HKLM\SOFTWARE\Microsoft\Wow64\x86\

processname = <your DLL>

One can create e.g. :

HKLM\SOFTWARE\Microsoft\Wow64\x86\

notepad.exe = c:\test\malware.dll

And this DLL will be loaded anytime a 32-bit Notepad is executed.

Since this is a WOW key, only 32-bit programs are affected.

Now for the reason why this is my favorite persistence trick of 2019 so far? There are at least two:

  • The DLL is actually 64-bit (it replaces wow64cpu.dll) so you are basically injecting a 64-bit DLL into a 32-bit process (while this comes with limitations – no access to many APIs as the process is only about to get started – it’s a pretty cool anti-trick)
  • The DLL can be loaded from a UNC path, so it can be both a persistence and lateral movement trick

DefineDosDevice symbolic link trick

I don’t know who is the original author of this trick – I saw it being used by some malware a few years ago and it was also discussed on KernelMode forum, and StackOverflow. Reading McAfee’s paper about Process Reimaging I suddenly remembered it.

How does it work?

With a DefineDosDevice API (the same API that is used by the subst command) we can create a new MSDOS device name. We can map it to a new, non-existing file path. The main executable can be then moved to that new space (i.e. new path the space is mapped to).

This little trick makes the original file ‘disappear’ from the system. Most of the process listing tools continue to map the running process to its original path, yet any attempts to access properties of the file itself end up with nothing. This is because the process is running, but the file it was launched from is ‘not there’ anymore:

Let’s examine it step by step:

  • Create a foobar namespace using DefineDosDevice and point it to \??\c:\test\test_hidden.exe.
  • Move the current process’ file e.g. c:\test\test.exe to \.\foobar.

That’s it.

In my test case I just renamed test.exe to test_hidden.exe, still inside the c:\test. It could be any location really, including very deeply nested directories that may be harder to inspect w/o forensic tools.

To find such mapping, one has to use tools like WinObj – it shows the DosDevice called foobar that points to the .exe:

One can also launch it via \\.\foobar (need a dedicated tool tho).

And if you are wondering what Sysmon will see when we launch such hidden file – luckily, it will link to a proper image on the drive:

Last, but not least – we can create a space that maps to Alternate Data Stream too 🙂 e.g. \??\c:\test\test.exe:hidden. In such case, a copy command can be used to copy files to such newly-created space/location e.g.:

  • copy test.exe \\.\foobar