Category Archives: Autostart (Persistence)

Beyond good ol’ Run key, Part 54

Posted on by

The need to test modules and the will to support legacy stuff have one thing in common – at least on Windows. These functions are heavily integrated with the system and both offer lots of various built-in mechanisms that can be used as an uncommon persistence mechanism. I have already described many of them, but recently I came across yet another legacy settings that we can add to our ‘dodgy autostart’ repertoire.

Let me introduce you to so-called Legacy CPL Mapping.

It is available since at least Windows 7, works under win10, and… it has to do with the way Control Panel Applets are launched; speaking pragmatically – there is a setting in Registry that helps to handle legacy Control Panel Applets.

The setting is stored in the following location:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
    Control Panel\Legacy CPL Map

By opening a number of CPL files and filtering procmon logs to focus on the ‘Legacy CPL Map’ keys only we can quickly confirm that anytime the .cpl file is launched, the system ‘talks’ to the Registry to check the respective ‘Legacy CPL Map’ setting for the applet:

The keys stored underneath include names of the Control Panel applets, and can be CPL names (f.ex. main.cpl), canonical names (f.ex.: Microsoft.PowerOptions, Microsoft.EaseOfAccessCenter), or DLLs (f.ex. ntvdmcpl.dll /this is the one that actually led me to this discovery/).

Each key represent the legacy setting for a given applet and can contain one of two values:

  • AppletCanonicalName
  • ShellExecute

The first is a canonical name of the applet we wish to replace the legacy applet with (f.ex. could use ‘Microsoft.PowerOptions’). The name is then used by the IOpenControlPanel::Open method to launch the mapped applet.

The second is just a command line that will be passed to ShellExecuteEx function.

Obviously, both can be abused.

Let’s have a look at the easy one – the ShellExecute.

The settings:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
    Control Panel\Legacy CPL Map\Microsoft.PowerOptions\ShellExecute

are being accessed when we click the ‘Additional Power Settings’ button under Settings\Power & Sleep:

By setting this value to calc.exe, we will launch the Calculator anytime someone tries to launch these settings:

This is what procmon sees when we click the button:

Of course, relying on Power Options is probably not enough – some users don’t touch it all. But… There is plenty of other .cpl files to look at…

  • c:\WINDOWS\system32\appwiz.cpl
  • c:\WINDOWS\system32\bthprops.cpl
  • c:\WINDOWS\system32\desk.cpl
  • c:\WINDOWS\system32\Firewall.cpl
  • c:\WINDOWS\system32\FlashPlayerCPLApp.cpl
  • c:\WINDOWS\system32\hdwwiz.cpl
  • c:\WINDOWS\system32\inetcpl.cpl
  • c:\WINDOWS\system32\intl.cpl
  • c:\WINDOWS\system32\irprops.cpl
  • c:\WINDOWS\system32\joy.cpl
  • c:\WINDOWS\system32\main.cpl
  • c:\WINDOWS\system32\mmsys.cpl
  • c:\WINDOWS\system32\ncpa.cpl
  • c:\WINDOWS\system32\powercfg.cpl
  • c:\WINDOWS\system32\sysdm.cpl
  • c:\WINDOWS\system32\TabletPC.cpl
  • c:\WINDOWS\system32\telephon.cpl
  • c:\WINDOWS\system32\timedate.cpl
  • c:\WINDOWS\system32\wscui.cpl

Another interesting feature: one could add ‘c:\WINDOWS\system32\powercfg.cpl’, or any other .cpl to one of the standard Startup locations and it will never raise suspicion since it’s a Microsoft-signed binary. Once the Startup entry is launched, the calc.exe (or possible malware) will pop up!

Beyond good ol’ Run key, Part 53

Posted on by

Most of the persistence methods described in this blog series so far focused on the old-school assumption that the system is a typical ‘bare metal’ Windows host. Over last couple of years many hosts are no longer real, and VDIs and Guest OS technologies they rely on introduce new techniques that attackers and malware can potentially use to stay persistent on the system. The features that are designed to support work of VDI may as well serve a malicious purpose. And this is what this post is about.

I will describe the example of VMWare Workstation as it is easy to test with, but it applies to VM server/cluster technologies as well.

VMWare Workstation is one of the most popular VM products on the market. Among many rich features that it offers, it is also including a well-documented mechanism that leverages a number of batch files that are executed when the power state of the guest OS changes – these states are:

  • Power On
  • Power Off
  • Suspend
  • Resume

Anyone who does reverse engineering for living uses these features all the time. VMs are an excellent solution to ‘freeze’ the session, test some code path, and revert to the previous snapshot if the code ‘escapes’ or program exits/crashes. It speeds up the analysis a lot and allows us to work in a comfort zone no other reversing tools can typically provide.

The VMware Workstation stores its batch files inside the c:\Program Files\VMware\VMware Tools\ directory – exploring this location we can quickly find a number of interesting files:

  • c:\Program Files\VMware\VMware Tools\poweroff-vm-default.bat
  • c:\Program Files\VMware\VMware Tools\poweron-vm-default.bat
  • c:\Program Files\VMware\VMware Tools\resume-vm-default.bat
  • c:\Program Files\VMware\VMware Tools\suspend-vm-default.bat

The top of the files typically states that:

@REM ########################################################################
@REM # DO NOT modify this file directly as it will be overwritten the next
@REM # time the VMware Tools are installed. 
@REM ########################################################################

but of course, we are not going to listen.

Modification of these files can provides a decent persistence mechanism. Obviously, re-installing the VMTools and/or reverting to a previous snapshots can mitigate it, but if the VDI host is indeed running for a long time, this could be a possible good place to run something malicious from. In the VDI farm/cluster scenario, anyone who cans modify the source code of a vmware tools baseline could establish such persistent mechanism on (and infect) the whole cluster (deployment to all nodes).

Interestingly, these batch files can serve another purpose: they can cause some DoS annoyance (for a lack of a better name as it’s hardly an anti-vm trick). Adding a simple ‘pause’ command to any of these files will ‘prevent’ the VMWare from executing the state-changing operation as it will wait for the cmd.exe process that handles the ‘pause’ command to exit:

Since ‘pause’ requires pressing the key and the script is running in a different session the vmtoold.exe will just enter a sort of never-ending loop. The side-effect of it is that the user won’t be able to f.ex. ‘suspend’ or ‘power off’ the guest system.