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:


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


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


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:



About hasherezade

Programmer and researcher, interested in InfoSec.
This entry was posted in Malware, Techniques, Tutorial. Bookmark the permalink.

4 Responses to Hijacking extensions handlers as a malware persistence method

  1. Melina says:

    Very interesting attack vector

  2. Pingback: IT Security Weekend Catch Up – May 27, 2017 – BadCyber

  3. Pingback: Weekendowa Lektura 2017-05-28 – bierzcie i czytajcie | Zaufana Trzecia Strona

  4. Pingback: Persistence – Change Default File Association | Penetration Testing Lab

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s