Hijacking extensions handlers as a malware persistence method

Recently I gave a presentation titled “Wicked malware persistence methods” (read more here). After releasing the slides I got questions about some of the demonstrated methods – especially about the details of extension handler hijacking – so, I decided to explain it in a blog post.

As an introduction, you can see a video demonstrating how it looks in action:

The demo app is open source and you can find it on my github:

https://github.com/hasherezade/persistence_demos/tree/master/extension_hijack

Basically, the goal to achieve was to deploy a malware each time when the user clicks a file with some defined extension – in a way that no change in the default behavior will be noticed. For the demonstration purpose, instead of a malware I used simply calc.exe 😉

How the extension handling works?

On Windows, extensions that are known by the operating system are defined in the registry. For example, we have an .html extension:

Each of the defined extensions may be connected with some handler, that is also defined in the registry. In my case, .html files are handled by FirefoxHTML:

The handler has various features defined – but the most important is command:

The command defines what action has the be taken when the file with the particular extension is clicked.
Let’s take a closer look at the above command:

C:\Program Files\Mozilla Firefox\firefox.exe -osint -url "%1"

As we can see, it runs firefox.exe with some parameters – one of them (%1) is the name of the file that was clicked. Thanks to this, Firefox opens the clicked file.

How to abuse it for executing a malware?

Knowing the above, we can overwrite the command by our own, that will be deploying a malware. For example:

Now, the .html extension is not handled by the firefox.exe, but by the ProxyApp.exe (see the code here) – that deploys firefox.exe, but also a malicious app (or calc in our demo case 😉 ). From the point of view of the user nothing has changed – firefox opens the document as it was before – but in the background another application starts to run…

If we modify the handlers defined under the keys of the current user, we not need any type of privilege elevation to install this type of hijack.

Global and local handlers – and how to hijack even more extensions

Extension handlers are defined at two levels – global, that are defined in the

HKEY_CLASSES_ROOT

…and local – that are defined for a particular user, i.e.:

HKEY_USERS\S-1-5-21-1929933236-2258453022-3626796957-1000_Classes

Their hierarchy of execution goes like this: if no local extension/extension handler is defined, then the global one  is executed.

This gives us very important advantage…

Obviously, without Administrator privileges we cannot modify the keys under HKEY_CLASSES_ROOT – but still we can read them. Also, we can modify the keys belonging to the current user.

So, the trick is simple – read the extensions handlers defined globally, rewrite them locally and then install the hijack.

Does it work for every version of Windows?

I tested it under: Windows 7 32/64, Windows 8.1 32/64, Windows 10 32 bit – and it worked stealthy, without any problems.

Win8.1 64 bit:

Win10 32 bit:

Appendix

https://attack.mitre.org/wiki/Technique/T1042