A lot has already been written about TrickBot, a banking trojan which is believed to be the successor of the Dyre banking malware. However, only few articles discuss the trojans core component used to defraud its victims: web injects, so in this blog I will discuss these in depth.
Web injects are pieces of web page markup language (HTML/javascript/…) injected into web pages open on the browser (mostly banking websites), allowing a trojan to alter or replace content and/or display additional fields. Web injects allows attackers (operators) to steal credentials when they are inputted on the web page or to create requests for additional credentials not requested by the bank, such as pin codes. Web injects (also called man-in-the-browser attacks) are thus a beloved technical means for fraudsters to set up their social engineering schemes or to automatically alter money transactions inserted by their victims.
TrickBot uses two types of web injects: ‘web fakes’ and ‘server side injections’, interestingly enough these are the same types of web injects which Dyre used. TrickBot defines and stores its web injects in an XML-like tree structure. Each entry in the configuration list defines a targeted (banking) website, the web inject type and an IP address of a server hosting the web inject. On image one a piece of the configuration list can be seen. This configuration list was found in the memory of the TrickBot process, (which was hiding under ‘svchost’ by making use of the process hollowing technique). In the remainder of this blog I will discuss the two web inject types used by TrickBot. For each web inject type, I will also discuss some possible server-side defensive measures that banks may implement in order to detect customers infected with TrickBot.
Image one: TrickBot’s web inject configuration as seen in memory.
Web Fakes
TrickBot’s web fake is a web injection technique which redirects a victim to a malicious server when he browses to an online banking platform. The malicious server hosts a replica of a bank’s login and post login web pages, effectively moving infected victims away from the bank’s genuine website. Web fakes are defined with sinjtags in TrickBot’s web injection configuration list (image one). When a victim logs in on the replicated banking website, he usually sees a ‘please wait’ message appearing. Simultaneously with the ‘please wait’ message, the credentials inserted on the replica website are sent to the attackers (image two).
Image two: replica banking website showing a ‘please wait’ message while a login notification is sent to the attacker’s server.
Sending the login credentials triggers an alert at the fraudster’s (operator’s) side, allowing the fraudsters to take the opportunity to use these credentials to start a banking session on the real bank’s login page. While the victim is patiently waiting, the operators explore the victims’ accounts and transaction limits in their newly started banking session. At this point, the unusual long waiting time may be the only suspicious indicator for the victim that something is off. The redirection to the banks replica website does not leave any other visual traces: the browser’s URL bar still contains the domain name of the legitimate banking website. Even if the victim would inspect the SSL certificate in the URL bar, he would see the certificate of the real banking website.
When the fraudsters want to exfiltrate money from the victim’s bank account to a money muleaccount, they usually are faced with additional security questions in the banking session. Via a control panel with predefined templates, the fraudsters can interact with their victims who are at that point still seeing a ‘please wait’ message. On the command of the fraudsters, the waiting message is replaced with additional fake pages asking for information needed by the fraudsters to perform the wire fraud. These information requests are ingeniously crafted, which unfortunately leads to some victims answering them. These answers often contain signature tokens, providing the operators with the last piece of information required to loot their victims account.
Detecting Web Fakes
Web fakes, also known as redirection attacks, are hard to detect from a bank’s server side perspective. The only connection that is made to the legitimate bank server, is a connection made in the background by the trojan itself (remember, the connection initiated by the victim is redirected to the malicious server). The connection to the legitimate bank server gets created the moment the victim browses to the online banking platform. This legitimate (SSL) connection is used to display a ‘secure connection’ (lock) icon in the browser’s URL bar as well as to show the legitimate banking website’s SSL certificate. The initial SSL connection generated by TrickBot in its redirection attacks may be detected in the bank’s server loggings. When a customer normally browses to the the online banking platform, a welcome/login portal page is loaded, including all the resources (such as images, external scripts, …) on that webpage. Every request to those resources generates an entry in the server’s logging. However, TrickBot’s SSL connection does not seem to load all these resources (image two, video one). This lack of resource loading anomaly may be a good use case to detect customers infected by TrickBot.
Video one: comparison of the source code of a bank’s login portal on a PC with and without a TrickBot infection.
Server Side Injections
TrickBot’s server side injection is a web injection technique which inserts (injects) additional client-side code (e.g. HTML, JavaScript) in the rendered targeted web page. Server side injections are defined with dinj tags in TrickBot’s web injection configuration list (image one). When a victim browses to a targeted website (i.e. a banking website), the bank’s server response is intercepted by TrickBot before it is rendered in the browser (image three). The bank’s response is then sent to the attacker’s server (image four). The attacker’s server will inject additional code in the webpage (hence the name server side injection) and will send the result back to the victim.
Image three: TrickBot’s server side web injects scheme (source: IBM).
Image four: Network traffic of TrickBot’s browsing module fetching its web inject on the attack server.
At first sight, it may seem that the tactic of sending the entire page to the attacker’s server (just so that the server can inject its malicious code into it), causes a lot of unnecessary overhead. This is contrary to other, older, banking trojans such as Zeus and SpyEye which performed a client side web injection, effectively reducing the amount of bandwidth and processing power needed by the attacker’s server. The older banking trojans received the to be injected code as part of their configuration, famously defined by the data_before/data_endstags (instructing the trojan to fingerprint the constructs in the HTML data present in these tags and to inject malicious code after it) and data_inject tags (defining the to be injected code).The downside of client side injection is that it makes it very easy for security researchers to enumerate the maliciously injected code for each targeted website by just parsing the received configuration, as shown in this presentation. TrickBot thus makes a smart move by using server side injections to keep its configuration schemes as concealed as possible from the prying eyes of security professionals.
The (server side) injected code often has the goal of setting up a social engineer scheme, such as the one in the example of the web fakes. However, another popular injected code category is ‘form grabbing’ code. Form grabbing code is used to grab information in HTML forms. Contrary to key logging, form grabbing allows the trojan to capture and steal only sensitive information present in the forms whereas key logging captures all the data input by the users. Furthermore, form grabbed data is labeled, e.g. password, which simplifies the extraction of specific desired items. Key logging generates a lot of garbage data in its logs which can be time consuming (expensive) for the operator to sift through to find useful tidbits. Additionally, form grabbing has the advantage of not necessarily needing a live operator to respond (such as in the case of the social engineering scheme). A perfect example is for instance a form grabber which grabs credit card numbers submitted on online web shops such as Amazon. These credit card numbers can be captured and stored in a database to be used at a later time. Image five shows a (server side) web injection attack in action, where a combination of social engineering and form grabbing is used. In this situation the victim is again tricked into patiently waiting while the operator is doing its work.
Image five: even though invalid login credentials were entered, a two-minute long waiting message is shown by TrickBot’s browsing module.
Detecting Server Side Injections
Server side web injections are easier to detect (from a bank’s perspective) than web fakes, because the majority of the code rendered by the browser still originates from the bank’s legitimate server. Because of the fact that the bank’s server is still able to dictate part of the rendered code, it can also dictate the browser to do a integrity check on the rendered code. This integrity check can be a piece of javascript integrated on the bank’s portal webpages, checking for the presence of injected code (e.g. ‘form grabbing’ code). The code responsible for the integrity check can of course also be nullified by the attackers by injecting ‘anti-integrity check’ code, so the key thing with this detection method is to either hide the checks well or to change their implementation often. This technique is explained really well in a PhD thesis called ‘defending against browser based data exfiltration attacks’. Similar code modification detection techniquesare nowadays used by websites to check if you run an adblocker.
While I was investigating TrickBot, I also noticed that sometimes TrickBot creates a cookie that isn’t set by the server (image six). This cookie, named ‘tknz_referrer’, seems to store the progress (state) of the additionally injected pages. Browsers by default include all cookies tied to a domain in the request to the server. Detecting such a cookie on the bank’s server side thus a possible way to identify customers infected by TrickBot.
Image six: TrickBot’s browsing module generating an extra ‘tknz_referer’ cookie. This cookie is sent along with each request to the bank’s server.
Source:https://www.uperesia.com/how-trickbot-tricks-its-victims
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
