VB2017 paper and update: Browser attack points still abused by banking trojans

Posted by   Martijn Grooten on   Jul 25, 2018

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/.

Latest posts: