At VB2017 in Madrid, ESET researcher Peter Kálnai presented a paper he wrote together with his colleague Michal Poslušný, in which they looked at how banking malware interacts with browsers. Today, not only do we publish the paper (in

HTML

and

PDF

format) and the video recording of their presentation, but we also publish a guest blog post from Peter, in which he summarises the recent developments in this space.

Peter and Michal will be back at

VB2018

in Montreal, to

present a paper

on the various cells belonging to the Lazarus Group.

Register now

to ensure you get to see their talk, as well as some of the many other exciting presentations on the programme.

#VB2017 follow-up: mid 2018 update

Peter Kálnai & Michal Poslušný, ESET

MITB attacks in Chrome

In this short note, we look back to research presented at VB2017 [

1

]. Statements in bold are the key remarks from the original paper/presentation that have remained true.

Thanks to its popularity,

Google Chrome

is still heavily targeted by banking malware, but recent updates in the browser have given malware authors a lot of trouble, largely due to internal changes related to SSL functionality.

The SSL_VERSION constants were removed from the

kTLSProtocolMethod

virtual method table (in short, SSL VMT) in the stable release of version 61 that came out on 5 September 2017. This has affected many man-in-the-browser (MITB) implementations since then

. The changes resulted in active banking bots switching their approach to locating the character string “../../third_party/boringssl/src/ssl/tls_method.cc” instead, and counting its relative position toward SSL VMT. However, that worked only until the first stable release of

Chrome

version 64 (64.0.3282.119) on 24 January 2018, when several key changes appeared. First,

ssl3_read_app_data

and

ssl_read_close_notify

were removed from SSL VMT, which denied malware authors the ability to read incoming http(s) data using SSL VMT functions. Next,

ssl3_write_app_data

was moved from 9th to 8th position in the table.

Moreover, another notable change happened because of the switch from

Microsoft

Visual C++ compiler to Clang around March 2018 [

2

]. Among other things,

SSL_read

was no longer inlined in

DoPayloadRead

as it had been previously in Profile guided optimization builds from the MSVC. A slight change had come earlier in version 63, when error tracing strings of the

DoPayloadRead

and

DoPayloadWrite

procedures were added and gave malware authors an easy way to find these important functions by looking up references to the strings.

After these changes, malware authors were forced to leave the SSL VMT lookup and instead shift their attention to the higher level SSL function wrappers

SSL_read

and

SSL_write

. Again, authors use various approaches to look up these functions – some search for binary patterns of the functions directly, while others look up referenced string constants that are used in these functions.

Figure 1: Constants dropped in the Chromium release from 15 June 2017.

Figure 2: Two attack points dropped in the Chromium release from 17 October 2017.

Figure 3: Attack points in Chrome since version 64.

.

Families of banking trojans

Malware authors do not copy from each other

. True. Despite the principles of the approaches being basically the same, their implementation differs across currently active families. Most families perform a binary pattern-based search, mainly of the

SSL_read

and

SSL_write

functions, for example this is done by Win/Dridex, Win/Kasidet and Win/Qbot, where the choice of sets of patterns is unique to particular families. The latter has had trouble finding the attack points even in its latest build. On the other hand, the Win/Trickbot project has been dedicated to MITB, because it tries to hook additional functions (like the wrappers of

SSL_read

and

SSL_write

) for recent

Chrome

versions, and moreover carries the hooking ability even for  version 46 from October 2015.

The most innovative approach has been displayed by a new banking family called Win/Karius, which successfully finds the relevant points of interest even in newer

Chrome

versions months after its release. The method is based on the choice of a single character string that reveals the location of all attack points at once (so it works effectively


¹


in the same way as the SSL_VMT table did previously). The generic approach implemented a long time ago by the Win/Spy.Ursnif family, which was described in our paper [

1

], is still working – the time the authors invested in developing this robust method really paid off, as support was maintained the whole time. The authors only had to make a slight adjustment with the introduction of

Chrome 64

, where instead of the

ssl3_read_app_data

function they implemented a new hook for the

ssl3_open_app_data

function to keep the read functionality.

Win/Tinukebot, meanwhile, has lost its

Chrome

-hooking ability in recent versions, because its implementation of

Chrome

MITB has remained the same. The

Google

project from which the attacks drew inspiration,

WebPageTest

, no longer provides hints for this type of MITB (see

Figure 4

). Despite this, the

gangs behind the attacks

are generally

persistent in their implementations of MITBs

.

Table 1

shows an updated summary of targets, cf. [

1

, Table 2]. Also note the increases in the bot versioning numbers.

Figure 4: MITB against Chrome 64+ not open-sourced anymore.

Table 1: Summary of targets.

Volatility Framework

The

browserhooks

plug-in [

3

] has been updated. Recall that it is a plug-in for Volatility Framework that extends

apihooks

and detects various types of hooks as performed by banking trojans. The algorithmic location of SSL VMT was completely dropped and replaced with an array of offsets of the attack points in

Chrome

64.0.3282.119 to 67.0.3396.99. This is also the future plan for the tool: to leave any algorithmic lookup and just rely only on the offsets of the attack points.

Conclusion

The banking trojans we have mentioned are actively developed and distributed in the wild, which is implied not just by looking at their compilation timestamp but also by the data in

Table 1

.

The

MITB

support for browsers is

indeed

a good indicator of whether a malware family is still active

. Considering the current status quo of the corresponding code in the

Chromium

project, the 2-3 month trialling of

Chrome

development roughly approximates the amount of time that many of the developers of these malware projects need just to wait in stand-by mode. As a security response. Still,

web browsers are not able to defend against the attacks by their own means

and as a reliable security measure,

the use of third-party protections that secure browser processes by encrypting keystrokes, or by providing an isolated environment that prevents code injection from remote processes

is strongly recommended.

Footnotes

¹

For some reason, the switch from GPO to Clang compilation unified the way the assemblies of

DoPayloadRead

and

DoPayloadWrite

look.

References

[1] Kálnai P.; Poslušný, M. Browser attack points still abused by banking Trojans. 27th Virus Bulletin International Conference (VB2017), Madrid.

https://www.virusbulletin.com/virusbulletin/2018/07/vb2017-paper-browser-attack-points-still-abused-banking-trojans/

.

[2] Clang is now used to build Chrome for Windows. March 2018.

http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html

.

[3] volatility-browserhooks.

https://github.com/eset/volatility-browserhooks

.

[4] Checkpoint. Banking Trojans Under Development. June 2018.

https://research.checkpoint.com/banking-trojans-development/

.