Category Archives: Compromise Detection

Beyond good ol’ Run key, Part 55

Posted on by

The flexibility offered by the Registry comes with a price. Whoever is in a position to change the Registry keys or its values can affect not only the way OS works, but also adjust the functionality of many programs relying on some particular settings. If we talk about persistence, there is yet another location that may be abused for this purpose. The trick I am going to describe is actually very old, but with the intention to document as many persistence mechanisms as possible nothing should be omitted. Plus, it still works on win 10.

Looking at the following location:

  • HKLM\SOFTWARE\Microsoft\Windows\
    CurrentVersion\Explorer\MyComputer

we can quickly guess that the keys listed underneath refer to a couple of utility tools that Windows occasionally runs:

Exploring them we can find out that the settings are mapped to the following locations:

  • BackupPath = %SystemRoot%\system32\sdclt.exe
  • cleanuppath = %SystemRoot%\System32\cleanmgr.exe /D %c
  • DefragPath = %systemroot%\system32\dfrgui.exe

Obviously, replacing these settings with your own (read: malware) will end up with the replacement programs being executed at the time OS will decide to kick off the respective activity (or, the user triggers it – see example below).

The easiest way to test this particular persistence mechanism is by replacing the entry for the CleanupPath; since this is a path pointing to the tool that will be executed when you click the Disk Cleanup on a drive, the replacement tool will be executed immediately after clicking the button (in my case it’s just a calculator):

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!