No items found.
Get in touch
Windows
sLoad
Ramnit
drIBAN

Uncovering drIBAN fraud operations. Chapter 1: Introduction and Malspam

Published:
4/5/23
Download the PDF version

Download your PDF
 guide to TeaBot

Get your free copy to your inbox now

Download PDF Version

Welcome Back!

In 2019, the Cleafy Threat Intelligence and Incident Response Team (TIR) observed and analyzed a persistent fraud operation that started around that time. It was hitting Italy and was leveraging an interesting infection chain, which Threat Actors (TAs) consolidated over the past few years.

We intend to release a series of articles that aims to share the details about our latest operation on a specific TA, or group of affiliates, tracked by the usage of an almost brand-new web-inject kit, dubbed as drIBAN, for conducting banking frauds against Italian Corporate banking clients.

Through these reports, you will see names already mentioned by trusted companies such as Mandiant, Cyberreason, etc. However, it takes a lot of work to find a single spot where you can see a threat's big picture. Commonly, looking for information feels like being lost in an internet jungle with hundreds of open tabs, trying to collect and put together information that somehow will overlap.

To fight this sense of loss, we want to help readers and analysts to pinpoint the big picture of this TA and give a deep dive into this injection kit.

Introduction

The main goal of drIBAN fraud operations is to infect Windows workstations inside corporate environments trying to alter legitimate banking transfers performed by the victims by changing the beneficiary and transferring money to an illegitimate bank account (дропы, “drops” in Russian) controlled by themself or affiliates, which are then responsible for handling and laundering the stolen funds.

Using web injects is a common technique used by various TAs during banking fraud operations since they can change the behavior of a targeted web page (on a client’s side) by adding malicious code and intercepting all the HTTP requests and responses from the server.

The key component of those frauds operations is drIBAN, a web inject kit with a powerful ATS engine (Automatic Transfer System), leveraged by TA for successfully bypass identity verification mechanisms, such as MFA and SCA adopted by banks and financial institutions during login and payment’s authorization phases.

Throughout this series of technical reports, we will approach different aspects of TA fraud operations, including a technical analysis of the infection chain used by TA for conducting frauds against Corporate banking clients in Italy, which combines the usage of multiple advanced malware components.

Figure 1 - Snippet of drIBAN web inject kit
Figure 1 - Snippet of drIBAN web inject kit

Please note that this series of technical reports were extracted and redacted from a “Private Release” report (TLP:AMBER) provided to our clients, applicable CERTS/CSIRTS, and law enforcement agencies.

drIBAN, who?

driBAN is a web-inject kit that emerged around 2019 and was used against multiple corporate Banking websites in Italy. Typically, web injects are part of a MITB attack (Man-in-the-Browser) to modify the content of a legitimate web page in real time by performing API hooking. They are considered an extension of the form-grabbing technique because they can intercept and manage web responses to alter content before it is displayed in the browser (bypassing TLS protocol).

After the first campaign, targeted at multiple Italian Corporate Banking sites in 2019 and 2020, this threat became silent until 2021, when a new wave of incidents was observed. Our telemetries registered a new major campaign hitting thousands of victims in Italy.

2021 has been marked as “a new era for drIBAN”, since, for the first time, many improvements and advanced evasion techniques were introduced, shifting from a more classic “banking trojan” operation to an APT threat. This showed fully fledged capabilities in establishing persistence against targeted corporate banks for an extended period, especially if TA found evidence of weaknesses in anti-fraud countermeasures or in the authorization process. Moreover, in July 2021, we identified multiple bank accounts highly correlated with TA and used them for “debugging purposes” against anti-fraud countermeasures where new payloads were tested before starting with new fraud attempts.

The following image describes the latest infection chain adopted by TA behind drIBAN fraud operations, well consolidated over the last few years:

Figure 2 - 2022 drIBAN infection chain
Figure 2 - 2022 drIBAN infection chain

OSINT information and our metrics suggest that there could be an overlap between drIBAN fraud operations and TA-554. This assumption is based on country targets (Italy, the UK, and Canada) and the code routine observed in sLoad. Those functions have in common specific checks for inspecting bots and conducting banking frauds, especially for Ramnit. As we said, this hypothesis is supported by an authoritative security firm such as ProofPoint.

Now that we have tracked a path toward this TA and their injection kit, it's time to move on to the first step in this new highway: the beginning of the chain.

PEC malspam

Since the final target of those fraud operations is corporate banking clients, the initial malspam is operated through “certified emails”, also known as PEC, widely used in business environments in Italy since the receipt also has legal value. This peculiarity appears to be initially adopted by TA in 2019. Still, it is used as the default for the following reasons:

  • PEC emails are considered “certified email” in Italian territory, giving a false sense of security to receivers.
  • PEC emails are mostly used in corporate environments, which increases the possibility of infecting corporate workstations with direct access to banking portals, reducing uninteresting bots.
Figure 3 – sLoad malspam example. Source: Cert-AGID
Figure 3 – sLoad malspam example. Source: Cert-AGID

The email attachment typically includes a couple of harmless files (e.g., .pdf, .png) and an executable file, typically in the form of .wsf, .vbs, or .ps1, which is the sLoad downloader. Since sLoad can be considered the most exposed piece of malware adopted by TA for their banking fraud operations, they have consolidated over the past years a few techniques to maintain a very low detection rate from AVs solutions, such as obfuscation and encryption, as well as the usage of “one-time” link, from where the sLoad downloader will retrieve and execute the sLoad core Powershell script. Once this link has been used (most commonly by an unaware victim), it gathers the sLoad payload from the server side. However, this action will disable additional interaction through this link, lowering the chance for analysts to get a “fresh connection” to the server hosting the code.

sLoad

sLoad is a Powershell loader, already well-described by technical reports from various security firms, which includes advanced reconnaissance features like: collecting system information (e.g., “computer name”, “network details”, “list of running processes”, etc.), taking screenshots, loading additional stages/payloads, etc.

Figure 4 – sLoad core snippet
Figure 4 – sLoad core snippet

One of the main techniques adopted by sLoad for reducing its detection is Living Off The Land, also known as LOLBins which consists in abusing legitimate built-in Windows tools and products for hiding its malicious execution and network communications, respectively Powershell and BITSAdmin.

Figure 5 – Powershell and BITSAdmin processes launched via sLoad
Figure 5 – Powershell and BITSAdmin processes launched via sLoad

When sLoad is successfully installed into the victim machine, botnet operators begin identifying low-hanging invalid bots, such as VM machines, sandboxes, etc.. often used by malware researchers for conducting analysis, starting discriminating illegitimate bots, blocking them for receiving additional payloads from now on.

This “enrichment phase” could continue for days or weeks, depending on the number of infected machines. Additional data will be exfiltrated to make the resulting botnet more and more solid and consistent.

An interesting technique adopted by TA for concluding their reconnaissance phase is checking the DNS cache against a predefined list of corporate banking institutes and exfiltrating the results. More specifically, sLoad starts to retrieve information contained in the APPDATA folder and initializes a variable that contains all bank institutions that are part of its targets. Then it starts to perform matching between these variables to understand if the infected machine is involved with one of these targets. If so, sLoad continues with its infection. Otherwise, it will continue to run without performing any further action (it's worth mentioning that this approach highlights the importance given to the recognition phase by this TA).  The figure below represents a code snipped of this technique.

Figure 6 –DNS cache checks performed via sLoad
Figure 6 –DNS cache checks performed via sLoad

Now, all the bots that successfully pass those steps will be selected by botnet operators and considered as “new candidates” for banking fraud operations moving forward to the next stage, where Ramnit, one of the most advanced banking trojans, will be installed.

Conclusion

As in all good stories, the time to stop has come.

Even if the screen is demanding to be burned with other contents and we are devoured by the will to share all this, we believe that additional information could become overwhelming.

In this article, we have just scratched the surface of one of the most prominent threats hitting the Italian market nowadays. The main purpose was to start creating awareness, an overview of the infection chain, and also focusing on the very first step, which represents one of the most critical parts due to the nature of its vector.

See you in the next chapter!



Appendix 1: IOCs

IoC Type Description
d5299434aa5119814df6f50d9ddce8e1 Hash Malspam attachment
7e9280027235462727a9a351429725c6 Hash sLoad downloader
2c7a9e3fe582667826510d70b8c79f19 Hash sLoad core
6c3db9101ead9e8461ae3846c43aa8ec Hash sLoad 2nd stage module (DNS cache checks)
jopkerto[.]tech Domain sLoad C2
guituk[.]eu Domain sLoad C2