The Brazilian malware landscape is notorious for its plethora of Delphi-based code and overall lack of sophistication. But much like the Russian-speaking malware scene, Brazilian cybergangs have been using better malware, such as the recently discovered Client Maximus, in their attacks.

In the summer of 2016, malware like Zeus Panda and Sphinx were spotted in Brazil. Those were followed by intensifying infection campaigns, all targeting Brazilian banks and payment platforms, according to data from IBM X-Force Security Research. Later in the year year, our researchers spotted a new, real-time phishing attack in Brazil, which introduced automation and agility to classic phishing attacks.

It quickly became clear that cybercriminals in Brazil are collaborating with counterparts from other, more sophisticated threat landscapes and importing code and expertise to launch attacks in their own country.

Enter Client Maximus

We recently encountered a case in Brazil that reflects this ongoing trend. Client Maximus is a new malware code that appears to have been written specifically for attacks on Brazilian banks. The malware was recently analyzed alongside other components related to it, leading to further findings and a greater overall understanding of the growing sophistication of cybercrime tools in Brazil.

The purpose of the Client Maximus malware is financial fraud. As such, its code aspires to create the capabilities that most banking Trojans have, which allow attackers to monitor victims’ web navigation and interrupt online banking session at will. After taking over a victim’s banking session, an attacker operating this malware can initiate a fraudulent transaction from the account and use social engineering screens to manipulate the unwitting victim into authorizing it.

Read the white paper: How to outsmart Fraudsters with Cognitive Fraud Detection

Initial Infection Routine

The initial infection begins with a malicious, obfuscated WScript. Upon deobfuscating the script, we discovered that its goal is to download and execute JavaScript on the target endpoint.

Figure 1: Initial script run by new remote overlay malware

The JavaScript fetched by the malicious code here is a larger snippet that runs several antivirus checks and eventually downloads and executes the actual malware. The malware aims to:

  1. Monitor which bank is accessed in the user’s open browser windows;
  2. Remotely control the user’s endpoint at will; and
  3. Overlay fake persistent windows on top of the user’s web browser application.

The attacker sets up the malware to commit financial fraud.

Malware Deployment

Client Maximus is deployed on the endpoint in two different ways. The first method calls for it to be deployed as a custom NSIS Installer. The malware binary is a custom-compiled version of Nullsoft Scriptable Install System (NSIS), which extracts three files into %TEMP% folder. The first file is system.dll, the second file is a malicious dynamic link library (DLL) and the third is the encrypted payload.

System.dll is part of a plug-in for the NSIS installer. It’s actually a legitimate DLL the malware leverages to call its own malicious DLL. After the malware loads the malicious DLL into its own process memory space and calls it using the aforementioned plug-in, the malicious DLL is used to decrypt the payload and load it into the process memory. The activity is subsequently performed by the now-decrypted file.

The Client Maximus malware binary is usually deployed to the current user’s AppData folder with a unique name that depends on the dropper. Unlike most financial malware, the malware itself creates its persistence from the location it runs from. It neither generates a new name nor copies itself to a new location.

In most cases the malware’s persistence is set under the endpoint’s run key (HKCU hive), pointing to the malware’s NSIS binary. In some cases, persistence is achieved by setting a link file to the malware binary’s path under the user’s startup folder.

Client Maximus can also be deployed via DLL hijacking and new technology file system (NTFS) alternate data streams (ADS). In this second deployment style, the malware uses a legitimate binary file, signed by a leading technology vendor, with a malicious DLL in the same folder.

DLL Hijacking Dresses Malware Up in Sheep’s Clothing

While there are many forms of DLL hijacking, the author of Client Maximus used the search path method to achieve it. This method relies on the binary to load DLLs from the application’s current working directory before searching in other directories. It then replaces the original DLL the application tries to load with another DLL, which causes the application to load a different DLL from the original, legitimate program intended to load.

In our case, when Client Maximus is deployed on the infected system, it also creates a malicious DLL, the name of which is determined by the internal name of the aforementioned legitimate library. That causes the legitimate executable to load the malicious DLL and execute it while creating the illusion that the original, harmless file is performing normal activity.

Below are some examples of legitimate binaries and the malicious DLL they hijack:

  • agestore.exe (signed by Microsoft) with malicious DLL name dbghelp.dll
    • Malicious DLL MD5: 31e2cd4728be52c50b8501e91d062cfc
  • AcroTextExtractorexe (signed by Adobe) with malicious DLL name query.dll
    • Malicious DLL MD5: 94a72a13eec55a8a7db64e468b17875e
  • cermgr.exe (signed by Microsoft) with malicious DLL name cryptui.dll
    • Malicious DLL MD5: 3dbe5192c62fad86033d596296865221
  • vprintproxy.exe (signed by VMware) with malicious DLL name vmwarebase.dll
    • Malicious DLL MD5: 35e1218a4a2c45005e73ccc0e511691c

The malicious DLL inside the legitimate process tries to load the encrypted payload from an NTFS ADS. We assume the malware author used NTFS ADS to remain hidden from the user or antivirus tools, although this method is not new.

We can use the Sysinternals Process Monitor to see when it actually loads the NTFS ADS while Windows continues to show this file as empty. In the image below, e2iU0L appears to be of size 0 KB, although it does have contents in reality. We can also see that a file named dbghelp.dll is being used to perform the DLL-hijacking.

Figure 2: Filename dbghelp.dll being used to perform the DLL-hijacking

In the next image, we can see that the malware (s9TLNV.exe) reads the encrypted payload using an NTFS-stream:

Figure 3: Malware file (s9TLNV.exe) reading the encrypted payload using an NTFS-stream

Client Maximus: The Fraud M.O.

After the malware is fully installed on the target endpoint, it is designed to allow a remote attacker to take control of the endpoint based on a triggered action from the victim. Much like other financial malware, the trigger is navigation to a targeted bank’s website.

Monitoring Window Titles to Zero In on Relevant Banks

To determine which sites the victim is accessing, the malware constantly monitors the titles of windows opened in the browser, hashes the titles and compares the hashes against a predefined list of hashes. Once a target match is detected, the malware connects to the attacker’s remote server to notify the fraudster, who can then initiate a remote access session using the malware’s remote-access Trojan (RAT) component.

Figure 4: The malware prints the victim’s windows and sends the data to the fraudster

As a first step in the process described above, the malware monitors the victim’s activity, waiting for a targeted banking session to take place in the browser. To enable the monitoring, the malware takes the following actions:

First, it registers to windows events that indicate the creation of new windows or window title change.

Figure 5: Hooking windows events to monitor window title changes

Upon each of these events, the malware checks the new window title, using the SendMessage application program interface (API), with the “WM_GETTEXT” window message, which allows the malware to obtain each window’s title.

Figure 6: Monitoring window titles using the SendMessage API

Finally, the malware hashes the obtained window title and compares it to a list of prehashed targets. If the current hash matches one of the entries on the list, the malware initiates a network communication with the fraudster’s control server. The author chose to work with hashes in this case to hide the real target list from researchers.

The Logical Flow of the Fraudulent Transaction

The logical flow of the fraudulent transaction is facilitated by overlay screens the fraudster uses to trick the victim into providing authentication elements.

The flow of events for this new malware is no different than previous malicious code categorized under the remote overlay family:

  1. The malware monitors browser windows and waits for a target match.
  2. The victim accesses a targeted bank, at which point the malware notifies the attacker.
  3. The attacker initiates a remote access session to the infected machine.
  4. The victim performs the initial login to the bank account.
  5. The attacker takes the session over by blocking the victim’s access to the browser’s screen, then presents the victim with social engineering screens that cannot be minimized and request more information.
  6. The victim unwittingly provides the attacker with authentication elements.
  7. The attacker finalizes a fraudulent transaction.

Fraud Continues to Evolve

In the past year, we have borne witness to an escalating threat landscape in Brazil, introducing new coding styles to malware projects and revamping popular tools such as the remote overlay Trojan. As we move into 2017, Brazilian banks and payment providers should prepare for continued threat evolution in the country and plan ahead to detect and counter financial threats in new and improved forms.

Banks wishing to protect their customers from evolving threats are invited to learn more about the IBM Security Trusteer Fraud Protection Suite and to read our white paper, “How to Outsmart Fraudsters with Cognitive Fraud Detection.”

Individuals looking for tips on protecting themselves from remote overlay malware and other banking Trojans are invited to read our malware mitigation article.

More from Banking & Finance

Cost of a Data Breach: Banking and Finance

The importance of cybersecurity has touched almost every industry. Beyond that, robust cybersecurity is table stakes for several sectors, particularly health care and the banking and finance industry. Not only is financial data at risk, but so is customer trust. In banking and finance, trust means everything. Yet, consumers are hesitant to share their confidential data. A recent McKinsey survey revealed that no industry achieved a trust rating of 50% for data protection. Here’s the most sobering stat: 87% of…

What Do Financial Institutions Need to Know About the SEC’s Proposed Cybersecurity Rules?

On March 9, the U.S. Securities and Exchange Commission (SEC) announced a new set of proposed rules for cybersecurity risk management, strategy and incident disclosure for public companies. One intent of the rule changes is to provide “consistent, comparable and decision-useful” information to investors. Not yet adopted, these new rules – published in the Federal Register on March 23 – could change reporting requirements. Take a look at some of the big-ticket items and what your organization needs to know.…

SEC Proposes New Cybersecurity Rules for Financial Services

Proposed new policies from the Securities and Exchange Commission (SEC) could spell changes for how financial services firms handle cybersecurity. On Feb. 9, the SEC voted to propose cybersecurity risk management policies for registered investment advisers, registered investment companies and business development companies (funds). Next, the proposal will go through a public comment period until May 9.  The Importance of Cybersecurity in Finance The 2021 X-Force Threat Index found that financial services were the most targeted industry. Manufacturing beat out…

Top Security Concerns When Accepting Crypto Payment

From Microsoft to AT&T to Home Depot, more companies are accepting cryptocurrency as a way to pay for products and services. This makes perfect sense as crypto coins are a viable revenue source. Perhaps the time is ripe for businesses to learn how to receive, process and convert crypto payments into fiat currency. Still, many questions remain. How can you safely enable customers to pay with Bitcoin or other digital currency? What are the security risks that come with cryptocurrency? Let’s…