You are browsing the archive for Forensic Analysis.

Beyond good ol’ Run key, Part 56

January 19, 2017 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

Every once in a while I describe a persistence mechanism that is just plain silly. This is one of these cases.

The user interface of Windows applications has not changed much since Windows 3.xx. The same window classes utilized by the same frameworks are being leveraged by a large number of applications. And as these frameworks evolve the capabilities offered to UI designers are visibly improving. Somewhere there, sandwiched between the ugly Delphi buttons from the 90s and the annoying Microsoft’s ribbon of the noughties – a SysLink control appeared. The control became popular pretty quickly as it accepts a very primitive form of a HTML language syntax (so primitive that it’s just an anchor tag <a href=link id=ID>Link</a> ) to define a clickable link (or a number of them).

The idea behind this was to make a life easy for developers who saw the progression of HTML-based controls, but didn’t want to bother with the cumbersome task of embedding the WebBrowser container on their dialogs just to create a simple web link. SysLink delivers, and link-like UI elements all now over the place. Interestingly, there is a lot of variants of this class (or, there are a lot of classes designed by different authors and frameworks that implement such functionality). The Visual C offers ‘ATL:<hexadecimal numbers>’ class f.ex. ‘ATL:00D52128’, or ‘ATL:0107E1C8’. Other applications and frameworks may use different classes – a good example is Sysinternals tools – there, the class is just a regular ‘Static’ (that responds to a click), or in some of its tools (f.ex. procmon) a class is called ‘HyperlinkClass’.

Not all of these classes have a property that I want to talk about (‘HyperlinkClass’ doesn’t).

Two examples of SysLinkish classes follow (all the links on the screenshots are implemented in a similar way):

As I mentioned, the aforementioned SysLink class became at some stage omnipresent and many Windows programs and applets still rely on it when they show a helpful link, or two. When clicked, such link typically leads to a help page, or opens a browser to redirect a user to one of many KB articles on Microsoft web site. The control is used by many applications as well.

Before I explain the trick that can be used to establish a very lame persistence let me add one more important thing here. There are two ways of handling the events from the SysLink controls. There is a first one, in which the window’s procedure handles the incoming notifications and reacts to them (f.ex. it calls WinExec, or ShellExecute function), and the second one – where a SysLink control interprets the quasi-HTML code and opens the link specified by the anchor’s href parameter on its own. The latter is of our interest as it doesn’t require modification of the code.

It’s now time to demonstrate how we can abuse the SysLink control and the following example will show exactly this.

When you run Windows Defender’s executable c:\Program Files\Windows Defender\MSASCui.exe on Windows 10, you may be be shown the following window:

Do you see the ‘Privacy Statement’ or ‘Learn more’ links? They are created by the SysLink’s cousin: ‘ATL:<hexadecimal numbers>’ class (and in my testing instance it is ‘ATL:00D52128’).

When we check the properties of the window ‘hosting’ the link (using f.ex. WinExplorer from Nirsoft) we can observe that the link is indeed provided directly as a window text and includes an anchor:

  • <A HREF=”″>Privacy Statement</A>

This is promising.

We can use WinExplorer again – this time to modify the link to ‘<A HREF=”file://c:\windows\system32\calc.exe”>Privacy Statement</A>’.

You see where it is going? 🙂

What happens now when we click that ‘Privacy Statement’ link?

Yup. The Calculator is launched.

This is ‘how’.

Let’s discuss now ‘where’.

The SysLink (and its cousins) can be defined in many places:

  • Can be created dynamically using a WC_LINK class – this is not interesting as we don’t want to modify the code + binaries are often signed
  • It can be defined directly inside the dialog resources of the executable (f.ex. look for “SysLink” class) – same issues as above
  • MUI files – this could be potentially interesting (it is not signed so it can be modified freely)

In order to establish a ‘real’ persistence, the original non-malicious link has to be found first, and then replaced. As mentioned – the replacement is pretty hard for the actual EXE, or DLL resources as they are typically signed these days. But MUI files are not.

So, provided that:

  • The program using MUI files can be found
  • The control interprets the SysLinkish markup language (the anchor definition)
  • The control does not process notification messages; instead the SysLinkish control processes the markup language on its own launching the links as it is defined by the anchor

and of course

  • The program is quite popular and there are high chances of the user clicking the link after all

the actual persistence can be achieved…

Right. I doubt we will ever see it being used in a real attack as it is just too convoluted. it could be thought of as a ‘last resort’ solution for a potential reintroduction of malware on the system.

And yes, it’s plain silly. I told you so.

Okay… the chances of actually make it work can be improved. Searching for Unicode ‘’ string inside the c:\WINDOWS\System32\en-US\ folders shows at least 60 files. Having such redirection all over the place could eventually lead to re-infection.

Last, but not least – the SysLink control may not be such a good target to be abused as a) it is a bit of a dying breed (old dialogs are replaced by HTML-based forms) b) not that many people click links (f.ex. how many times did you actually click the ‘Privacy Statement’ link?), but as far as I know it’s free from any HTML control restrictions. And yes, since nowadays lots of UI is designed using HTML forms it is a possible avenue for further exploration…

Beyond good ol’ Run key, Part 54

January 16, 2017 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

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!