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…