You are browsing the archive for Malware 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=”https://go.microsoft.com/fwlink/?LinkId=521839″>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 ‘http://go.microsoft.com/fwlink’ 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 55

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

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):