You are browsing the archive for Incident Response.

Beyond good ol’ Run key, Part 74

March 26, 2018 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Riddles, Incident Response

This is a very obscure persistence mechanism that affects VMWare Tools versions that utilize the vm3dum DLL (‘VMware SVGA 3D Usermode’):

  • c:\Program Files\Common Files\VMware\Drivers\video_wddm\vm3dum.dll

When loaded (which happens e.g. when Internet Explorer is launched) the DLL checks the content of the following registry key:

  • HKLM\SOFTWARE\VMware, Inc.\VMware Tools\Usermode\
    AdapterShimPath=<path>

and loads library that the path points to.

There is also one more key:

  • HKLM\SOFTWARE\VMware, Inc.\VMware Tools\Usermode\
    ShimPath=<path>

but the condition for loading this DLL is not entirely clear to me.

Beyond good ol’ Run key, Part 73

March 15, 2018 in Anti-Forensics, Autostart (Persistence), Compromise Detection, EDR, Forensic Analysis, Incident Response, Living off the land

If you have a dvdplay.exe program on your system you can quickly do two things with it:

  • use it to disturb the process tree
  • leveraging the fact it is a signed binary – add it to any common startup place and achieve a nice, invisible persistence mechanism, possibly bypassing some security  solutions (they will just detect entries pointing to a signed binary and nothing else)

How?

The dvdplay.exe program is a simple wrapper that actually calls wmplayer.exe. But not the one you would expect.

In order to find a path to the wmplayer, it reads the following Registry key:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wmplayer.exe
"Path"="c:\\malware\\"

So… changing that path to any path in your control, you can drop your wmplayer.exe there and voila!