DefineDosDevice symbolic link trick

June 21, 2019 in Anti-Forensics, Archaeology, Malware Analysis

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

Comments are closed.