Mispadu (Ursa) C2C communication behind the scenes

Mispadu, also known as Ursa, is a remote overlay financial malware that targets banks in Spanish and Portuguese-speaking countries such as Mexico, Colombia, Argentina, Chile, Portugal, Spain and more. In simple terms, remote overlay malware is a malicious program designed to control the victim’s system by controlling their mouse and keyboard devices while the fraudster sees the live screen of the victim.

Mispadu first appeared in 2019 and had a reappearance in 2022. Like its counterparts, Mekotio and Grandoreiro, Mispadu is written in the Delphi programming language. Unlike them, it was less common in the wild until recently, when new campaigns were seen in several Central American, Latin American and European countries. For more information about Mekotio, see our previous blog post - Mekotio Banking Trojan Targeting Latin America.

With Mispadu back in business, there were several changes in its operation, including command and control (C2C) communication encoding, which we will explore in this article.

As a remote overlay, the malware’s communication with its operator is crucial for a successful attack. This communication is usually a series of operational commands transmitted from the fraudster to the malicious program that is running on the victim’s system.

Many overlay attacks, such as stealing the victim’s money via their bank account, are executed while the fraudster observes and controls the victim's live sessions.

While it may seem intuitive that communication with the fraudster would occur immediately upon the execution of the malicious program by the user, this is not the case. Such communication poses a significant risk for the fraudster as it might trigger alerts from antivirus programs.

In our scenario and most cases involving other remote overlays, the communication is initiated only after the user accesses one of the malware's targets, specifically Spanish or Portuguese-speaking countries’ bank internet sites.

When the user accesses one of the malware’s target lists, communication with the C2C server is established. This is achieved using the WIN32 Socket APIs, which provide the most convenient method for such communication.

Prior to setting up the socket, the malware populates the socket's information, including the destination port and address.

Once the socket is connected, the message ‘GFHHVG..’ is sent to the C2C server.

After the socket is connected and the beacon is sent to the C2C server, the malware waits for input from the C2C server. Once received, the message is handled by one of the following “read” functions, depending on the sequence of the received message:

These functions are similar to each other and their purpose is to parse the messages that are received from the C2C.

Let’s dive into the first function “TwYHJk1_wC51Read”:

Once the malware receives a message from the C2C, it parses it by decoding the message and then comparing it to a string that represents a command. In the first “read” function as seen in the snippet, the first compared command is “<|SocketMain|>”. In the other “read” functions, the compared commands are different.

Note the function in the address 0x7364A8.

This function is responsible for decoding the whole message. It receives a string, and after several mathematical manipulations, it returns a decoded string.

Let’s look inside that function and discover its algorithm.

Communication encoding serves to conceal the fraudster's intentions and operational methods. This can be accomplished using pre-existing communication algorithms or custom-made ones. As we showed previously, the message ‘GFHHV..’ appears to be an encoded message, which, due to its seemingly random and meaningless nature, raises the suspicion of encoding.

When we investigate the C2C communication decoding function, we can see that the implementation of the decoding mechanism is straightforward and serves the purpose of decoding messages received from the C2C server. This same mechanism is also used to encode messages sent to the C2C server.

Let’s take the above example we want to decode. “GFHHVGCGEFUGAFOFUGCFMFXHVFJ@”

Let’s divide the decoding process into the following steps:

Step 1: Take the first character (“G” GFHHVGCGEFUGAFOFUGCFMFXHVFJ@) and convert it to ASCII. It has a value of 71. From this value, subtract 65 (the ASCII value of ‘A’). The result is 6.
6 is our repetitive value during the decoding process, which we’ll return to later.

Step 2: Take the next character (“F” GFHHVGCGEFUGAFOFUGCFMFXHVFJ@) and convert it to ASCII. It has a value of 70. Subtract 65 (ASCII value of ‘A’).
The result is 5.
Let’s assume it as a variable X.
The two lines of assembly code can be represented with the following equation:
(X + 4X) + (X + 4X)*4 => 25X = 25*5 = 125

Step 3: Take the next character (“H” GFHHVGCGEFUGAFOFUGCFMFXHVFJ), ASCII value: 72. Subtract ‘A’ ASCII value: result 7.
Add to that value the previous step’s result. 125 + 7 = 132.
From that value, subtract two values- a constant value of 66 (‘B’) and the value of step 1. 132 – 66 – 6 = 60. In ASCII, “<”. This is our decoded string’s first character.

Step 4: Iterate again Step 2 + Step 3 with the next pair of characters (“H” & “V”  GFHHVG..), building the decoded string by appending the next decoded character each time.

Step 5: “@” Represents end of string GFHHVGCGEFUGAFOFUGCFMFXHVFJ@
Now we can print out the result of decoding the encoded text: <|PRINCIPAL|>
This string represents the initial communication beacon sent from the malware to the C2C server.

One consequence of this encoding and decoding methodology is that distinct encoded characters can yield the same decoded character.

For example, the characters GGC and AFV both map to the same character P.

Another example, for a more complicated scenario. Talking about strings- both “GFHHVGCGEFUGAFOFUGCFMFXHVFJ” and “AFBHPFVFXFOFTFIFOFVFGFRHPFD” would be decoded to the same plaintext.

One of the benefits of such encoding and decoding algorithms is that if the network is monitored, it is nearly impossible to comprehend the malware's mode of operation without obtaining the decoding algorithm. This is due to the huge variety of encoding options available for each command, causing the same mode of operation performed by the malware to appear different each time to the network monitor.

Once the command is decoded, the path forward for the sample is quite straightforward. Each command possesses its own operational function, enabling the fraudster to perform various tasks on the victim's system, including screen monitoring, mouse and keyboard control and many more.

Let's delve into the implemented commands in the malware that enable the fraudster to execute various tasks on the victim's system.

Upon establishing communication, the malware sends a beacon, denoted as "<|PRINCIPAL|>," to the C2C server to signal the network's establishment.

Once this initial step is completed, the fraudster gains extensive control over the victim's system, capable of performing a wide array of tasks. One crucial command is the extraction of valuable system information. This is facilitated by the "<|Info|>" command, which is used to export fundamental details about the victim's system. These details encompass the Windows version, geographical location, currently active browser, and the current webpage being viewed. Here's an illustrative response from the malware to this command, sent back to the C2C server:

"<|Info|>Win 10<|>Bank x<|>Chrome<|>4:04:12 PM<<"

• The real bank’s name can’t be written in this blog

This response indicates that the victim's system is running Windows 10, is using Chrome and is currently viewing a webpage from Bank x at 4:04:12 PM.

This information is stolen for several reasons. Knowing the operating system of the victim’s device can ease the process of compromising their system with extra malicious tools, as each tool might support different system versions, and knowing the victim’s target bank site can help the fraudster to accomplish a successful attack.

Remote overlay attacks are among the most prevalent threats to users' banking accounts today, posing significant risks to both banks and their clients. A critical aspect of these attacks involves the malware's communication with its operators, which is integral to their operational methodology. Establishing direct and live communication is essential for executing such attacks. By encoding such communication, the malware intends to make it harder to reverse the process and to put another brick in its defensive wall. As cybersecurity experts, our primary objective is to monitor, analyze and block these communications to prevent the successful implementation of fraudulent activities.

To protect themselves, users should regularly review their installed applications, promptly removing any unfamiliar or suspicious ones.

Additionally, it's essential to monitor email accounts for unusual activity, such as unexpected login attempts, and to keep a close eye on cryptocurrency wallets for unauthorized transactions or unknown actions. Staying proactive and cautious can help mitigate the risks posed by this evolving attack paradigm.

IBM Trusteer helps you detect fraud and malware, authenticate users and establish identity trust across the omnichannel customer journey. More than 500 leading organizations rely on IBM Trusteer to help secure their customers’ digital journeys and support business growth.