In this era of Ransomware attacks and Zero Day attacks, it’s easy to forget about pervasive threats like Banking Trojans which have been around for some time. These same threats have evolved significantly over the past years, constantly presenting new challenges to security teams. In this post—condensed from a SANS webcast I hosted – Sr. Research Analyst Tamas Boczan and SANS analyst Jake Williams explore the ways in which banking trojans work their way inside the perimeter, demonstrate why banking trojans are not just a problem for financial institutions and provide detailed analysis of two of the most insidious banking trojans — Trickbot and Ursnif . Read on to understand how these threats evade detection and what security teams can do to better detect them.
Banking Trojans: A Persistent and Evolving Threat
Everything old is new again. That sentiment is especially true in cybersecurity, as threat actors have become masters at dusting off old threats and adapting them to work their way inside the castle walls. Back in 2006 as online banking was becoming broadly adopted, the first banking Trojan ZBOT (aka, Zeus) made headlines with its stealthy ability to steal banking credentials via man-in-the-browser, keystroke logging and form grabbing techniques.
While banking trojans and infostealers use similar methods to gain access to sensitive information, they’re markedly different in terms of the complexity of the code and their behavior once they’ve secured entry onto a user’s machine. SANS analyst Jake Williams explains: “Banking trojans are a special class of proxy server that enable attackers to exfiltrate data hidden within a legitimate data stream. More importantly, modern banking trojans can modify live data in the victim’s web browser without modifying the SSL lock indicator. The attacker doesn’t need to worry about that because they are modifying content directly in the victim’s browser.”
In other words, the fact that this is happening is completely hidden from the user since it’s happening directly in the browser. “There’s been a lot of confusion about this as most people don’t think this scenario is even possible. We saw this happening quite a bit around GDPR with users being tricked into giving up social security numbers and other PII through these types of web-inject man-in-the-browser scenarios,” says Williams.
In fact, these types of dynamic web injects have become a hallmark of modern banking trojans, as they can be injected directly into the Document Object Model and are much more difficult to detect from a user perspective since they have grown accustomed to seeing more frequent user interface updates. Once the attacker is in the browser, they can both modify the content presented and redirect the control flow – and do so without arousing any suspicion from the victim.
Banking Trojans: Not Just a Problem for Banks
While banking trojans were initially designed to capture an individual user’s banking credentials, it doesn’t mean they aren’t a threat to the enterprise. Like infostealers, they are primarily deployed by casting a wide net via phishing and drive-by download campaigns. However, attackers, opportunistic by nature, have demonstrated their ability to quickly pivot their focus when presented with a bigger fish – especially a corporate target attached to a larger network.
“Increasingly we are seeing banking trojans being used as a back door access when a bigger or better target is identified. There’s a perception that banking trojans just target financial institutions but that’s really not true,” says Williams. “In fact, in our own analysis, we’ve found that these trojans are conducting a wide range of information reconnaissance, from querying the network for configuration settings, recording what software and services are installed and running, to HR and payroll systems – all of which the attackers can leverage for future attacks.”
Banking Trojans in the Wild
According to Williams, SANS has seen numerous cases of attackers using the access provided by banking trojans to conduct APT-style reconnaissance. “Banking trojans are a battering ram to get into the network with the attacker looking around saying, ‘Now that I’m inside and knocked the front door down, what do I want to do from here?’ Is this compromised machine joined to a domain and what is that domain? After that, we’ve seen some push for lateral movement. In essence, what we’re looking at here is more advanced intellectual property kinds of attacks.”
Williams wraps up his portion of the webinar by discussing some of the top banking trojans and the methods they are using to infiltrate machines (Office and browser vulnerabilities representing the most common methods) and the means of propagation (phishing and exploit kits). The bottom line according to Williams is that banking trojans remain as difficult to detect as ever and that it’s going to require a lot of monitoring and analysis tools to effectively detect them.
In the second half of the webinar, VMRay’s Sr. Threat Researcher, Tamas Boczan and I look at banking trojans from a forensic perspective and take a deep dive into Trickbot and Ursnif, two of the more popular banking trojans that have evolved in different ways.
Banking Trojans v. Infostealers: A Question of Complexity
It’s easy to conflate banking trojans with commodity infostealers. While they both have in common that they are designed to steal credentials, they are in fact quite different from one another (read more about the Infostealer Kill Chain) For one thing, infostealers are often sold as a package based on the set of applications an attacker wants to steal information from – browsers, mail clients, crypto wallets, etc.
Banking trojans, on the other hand, are designed to be a modular framework. As Tamas explains, “Banking trojans are usually bigger framework-like modular systems which contain multiple modules, some of which are designed for stealing banking information with web injects and other software or various types of recon and deploying secondary payloads.”
Compared to banking trojans, info stealers are relatively simple to create. “For an experienced programmer, it shouldn’t take more than a few hours,” notes Tamas. Banking trojans with web inject kits however are huge projects as the author needs to create a separate implementation for every single website that they support – and they typically support hundreds of websites. This difference is reflected in the price as most infostealers can be purchased on open forums for less than a $100 whereas banking trojans like Trickbot and Ursnif are difficult to acquire and cost tens of thousands of dollars.
Examining the Behavioral Traits of Trickbot & Ursnif
As VMRay’s Sr. Threat Researcher, Tamas Boczan has spent a significant amount of time analyzing the behavioral traits of two prominent banking trojans: Trickbot and Ursnif. Ursnif is particularly interesting because has this distinct and varied evolutionary tree. Active for over a decade, it has undergone several transformations, largely due to the fact that its source code was leaked twice which contributed to its many forked variants.
What we’re calling Ursnif is a group of similar malware which is based on the same leaked source code, so ISFB, Dreamboat, or Gozi all belong under the Ursnif umbrella. From the two leaks – Gozi in 2006 and ISFB in 2015 – many variants emerged, some of which were deployed concurrently. Trickbot’s evolution, however, has been very different. Its source code was never leaked so it doesn’t have as many variations as Ursnif. But what it lacks in variation, it makes up for in a long history of added modules – some 14 Trickbot modules in total. Besides stealing information from browsers, Trickbot also has various modules for reconnaissance – from gathering information about the network and searching through emails to SQL databases and POS terminals.
Evasion Techniques & Detection
No malware discussion is complete without talking about evasion techniques (read our recap from our May webcast: Dissecting Popular Evasion Techniques). Our work at VMRay is focused squarely on sandbox evasion techniques but malware tries to evade pretty much every security product out there, not just sandboxes. This is especially true when it comes to banking trojans such as Trickbot and Ursnif.
Trickbot attempts to evade detection in a few key ways. These include delayed execution, which occurs both on the client side and the server side. On the client side this is implemented with simple time delays while on the server side, module execution can be delayed over a period of time. Trickbot also attempts to kill Windows Defender before any windows are launched so that way it won’t be able to detect the modules that it downloads later.
Ursnif’s many variants feature different evasion techniques. The most common one is geolocation in which the server is only willing to reply to a client that is originating from a specified range of IP addresses. So if the malware isn’t executed in the right geolocation then the server won’t reply. Other variants check for other user interactions such as if the cursor is moving with the right velocity, registry key and module checks, etc.
To learn more about Banking Trojans, view the full webcast: Hitting the Silent Alarm on Banking Trojans
