"Something magical happens when reverse engineers write Volatility plugins" - The Volatility Plugin Contest committee on Browserhooks

ESET malware researchers Peter Kálnai and Michal Poslušný were awarded 3rd place in this year's Volatility Plugin Contest for their Browserhooks tool. The duo made use of the knowledge they have gained tracking banking Trojans and Man-in-the-Browser (MitB) malware, and documenting their methods in order to create a specialized detection tool.

The tool, Browserhooks, is a module for the Volatility Framework, which is the most widely-used open-source memory forensic platform with the broadest community of users.

The Volatility Foundation, the non-profit organization behind the Volatility Framework, sponsors the yearly Volatility Plugin Contest to acknowledge the best forensic tools built on the Volatility platform. Peter and Michal submitted their Browserhooks plugin and the contest committee awarded them 3rd place.

To share more details with our audience, we asked Peter and Michal a few questions.

First, guys, congratulations on your success! It seems that you have made it outside your key domain of expertise – is it true?

Peter Kálnai:

Well – yes and no.

On one hand, it’s true that our tool, Browserhooks, is intended for use outside malware research. On the other hand, it would be impossible to create Browserhooks without having attained extensive expertise in the field of malware research and reverse engineering – in particular, the investigation of banking malware. We did a really deep dive into exactly how banking malware attacks work, how this malware changes the system and what traces it leaves behind in consequence. By the way, we presented our findings at the recent Virus Bulletin 2017 conference and received a quite warm reception.

Michal Poslušný:

To facilitate our research, we built a handy tool for following very specific changes in affected systems. Knowing that the issue of banking malware is of utmost interest for security analysts in the financial industry, we decided to improve our tool so that experts in digital forensics and incident response can easily make use of it.

To what extent will they find your tool useful?

Michal:

Well, at least the folks in Volatility who awarded us with the prize consider it useful… Imagine the problems strangers face in a city: without help from locals, they get lost – unless they use some kind of a navigation solution (like a GPS or a street map).

Without a tool like Browserhooks, security analysts need the help of reverse engineers to uncover a banking malware attack. With it, they can classify an incident and close the investigation with a few clicks.

Peter:

In another words, those without reverse engineering skills can now identify indicators of banking malware attacks. Or, more precisely, incidents where banking Trojans applying Man-in-the-Browser attacks were involved.

Please, explain in straightforward terms how your Browserhooks tool works.

Michal:

Browserhooks is an extension of the original apihooks plugin. That plugin is a default solution within the Volatility Framework platform for detecting changes to calls inside exported functions; so-called “hooks”. The problem with the apihooks plugin is that it is not specific to malware, which has several negative consequences. Most importantly, it is not able to find some very specific hooks implemented by banking malware. Also, it is not optimized for speed and leads to a higher number of false positives.

Peter:

With apihooks, some of the system hooks detected may be legitimate. This is as it should be, since apihooks is a general tool. In contrast, Browserhooks is a specialized tool focusing on particular hooks. For example, thanks to our research into banking malware, we have a set of known attack points used by specific banking malware families. As a result, all the hooks detected by Browserhooks are forensically relevant.

Michal:

Or at least they are worth further analysis. Simply put, Browserhooks doesn’t seem to generate any false positives. And there shouldn’t be any false negatives either: I mean, we tried not to miss any currently existing attack method. We'll update the tool when we learn of new attacks, so be sure that you use the most current build of Browserhooks.

Peter:

Back to your question about how Browserhooks works: for technical details, please refer to Browserhooks’ source code.

In non-technical terms, let us demonstrate one use case where the plugin is helpful. Imagine that a malicious email attachment was executed on an endpoint in a corporate network. The system is now compromised and the malware is running and communicating with its command and control server.

There are just a few, unspecific indicators of compromise at the moment – the running processes, the network traffic, and perhaps some registry changes like a persistence mechanism...

After the initial phase, the Trojan may download additional components – for example a banking module.

Afterwards, anytime victims opens their web browsers, the Trojan injects the banking module into the browser’s process space and hijacks – or hooks – particular functions that allow for stealing sensitive information from web forms or modifying the content of internet banking pages...

And these hijacked functions serve as indicators of compromise, right?

Peter:

Exactly. And Browserhooks is designed to recognize them.

Michal:

It maybe of interest that apart from building an extension for apihooks, we have implemented support for hook detection in 32-bit modules running on 64-bit systems. These were not supported by the original apihooks plugin, so we wanted to help because 32-bit web browsers are still quite prevalent.

Yes, the Volatility committee acknowledged your additional efforts in this direction. Maybe this serves as an example of how an open-source community should might work…

Peter:

First, we must say that we are truly happy to have our work acknowledged. Having received a prize when there were so many high-quality submissions displaying invention and effort… we are proud of our work!

Michal:

As for open source: we feel that being a part of an open-source community makes sense. By the way, ESET maintains its official Github page with various tools related to publicized malware investigations.

Peter:

Yes, new ideas spread quickly within open-source communities, which helps to keep bad guys at bay.

And let me add one comment as regards Browserhooks. This effort has not been driven by any vision of a prize. Our main motivation was contributing to the community; receiving a prize is a welcome bonus. In this context, Browserhooks is naturally an ongoing project and we will continue developing it, mostly by adding detection of new attack techniques whenever we discover them.

The complete results and the plugin description are published in the recent blogpost by the organizers.