Since the end of April 2020, a new trojan has been affecting Portuguese users from several bank organizations.
The modus operandi of this piece of malware is not new in Portugal. At least since the year of 2014 that new variants have been observed, with minor changes, and with the objective of collecting bank details of the victims.
One of the last occurrences was last December 2019, where the Lampion trojan operated in a very similar way, changing only the way the malware was distributed (via AWS S3 buckets and with the first stage encoded in a highly obfuscated VBS file).
This new variant has been distributed via malscam campaigns that impersonate invoices from the Vodafone group, as shown below.
The first stage of this malware is an MSI (Microsoft Installer) file that downloads the malware from a google-sites server and deploys it in the Windows startup folder. After that, the infected computer is restarted to make the trojan persistent.
Afterward, the malware runs on the compromised machine, collecting sensitive data from browsers, including credentials for accessing bank portals. The malware can also obtain data on the clipboard and it contains keylogger features to collect everything the victims are writing and send the information to the C2 server.
As a way of obtaining banking details, when the malware detects that the victim is accessing a target homebanking portal, it triggers a window overlaid on the browser simulating the legitimate system and requesting additional details, such as credentials and SMS tokens.
When malware initiates, it requests Google Drive documents for details on the C2’s IP address. This is a mechanism that makes C2 persistence and dynamics.
The number of victims in Portugal has increased significantly in recent weeks. The success of malicious campaigns always depends on the starting point of infection: social engineering. In this sense, users should be aware of emails of this nature and never click on email links or open attachments in case of suspected malicious activity.
For more details on this finding see the Technical Analysis below.
Since the end of April 2020, a new Trojan variant is affecting users from several bank organizations in Portugal. At first glance, the malware is originated from Brazil – based on artifacts collected during the analysis.
The malware is disseminated via malspam campaigns – phishing emails distributed for a high range of users and using a template that impersonates an invoice email from the Vodafone group.
Figure 1: Phishing templates used to distribute the threat in Portugal.
During Sl-LAB analysis, and also according to @t14g0p – a Portuguese security researcher, this malware is similar to other threats from Brazil observed in Portugal since 2014.
Lampion malware, for instance, was spread on end-December 2019 and took advantage of AWS buckets to host the first stage and to download the files into the victim’s machine. One of the files was a DLL that exported functions to capture home banking credentials.
This new threat takes advantage of google-sites and Google Drive documents to distribute the threat in Portugal. The high-level diagram of this threat is presented below.
Figure 2: Trojan banker high-level diagram.
The trojan modus operandi is the following:
- The user downloads a file after accessing the malicious URL available on the phishing email
- The user extracts the .msi file from the zip file and executes it (1st stage)
- The .msi file (the downloader) downloads the trojan malware from a google-sites domain and saves it into the Windows startup applications folder, thus ensuring that the malware will be executed whenever the user login in the system (2nd stage)
- The malware process starts, which in turn communicates with google docs to read the contents of 3 different documents. These documents contain the configuration of C2 addresses and a bitcoin address
- The malware is running and monitoring the user’s actions and periodically requesting commands from the command and control (C&C) server
- Browser overlay is performed in order to collect banking credentials when the victim accesses specific homebanking portals.
Initial infection – the zip file (1st stage)
Threat name: FATURA34109093137173917200003123.zip
First submission VT: 2020-05-02 01:32:12
After analyzing the compromised server distributed along with malspam email, two zip files with different names – in distinct directories – were observed. The reason why two paths were identified on the server is simple: the threat is the same but used in different phishing campaigns.
Figure 3: Trojan banker .zip file (1st stage) downloaded from the compromised server.
After executing the .msi file, the 2nd stage is downloaded from the google-sites server.
Figure 4: 2nd stage downloaded from the google-sites server.
Next, the trojan is deployed into the Windows startup folder (a .zip file with an arbitrary name – jmccnJJi.zip – with the PE file inside). Finally, the PE file – the trojan – is dropped in the same folder (fZpoAruv.exe).
Figure 5: The 2nd stage (fZpoAruv.exe) is deployed on the Windows startup folder.
When the .msi installation ends, the victim’s computer is rebooted to make the malware persistent. The malware starts whenever the victim login in the system.
Trojan banker (2nd stage)
Threat name: fZpoAruv.exe
First submission VT: 2020-05-03 07:35:06
In detail, the malware was developed in Delphi as usual in threats from Brazil. The Embarcaredo IDE was used to support its development.
Figure 6: Delphi and Embarcadero were used by crooks to develop the trojan.
Delphi and Embarcadero have been used by Brazilian criminals to develop new malwares. Inside the trojan is possible to identify several Portuguese words, allowing to confirm its origin.
PORTUGUESE, ENGLISH, NEUTRAL
Figure 7: Languages detected by analyzing the source-code.
As a way of preventing malware from running on virtual machines (VM-Protect) and analyzing it (anti-debug/reverse), the well-known packer Armadillo was used to make the Trojan protected.
Figure 8: Packer Armadillo 6.X-9.X used to protect the malware.
This type of protection makes it hard to analyze. As noted below, the malware has some calls in the IAT related to VM protection mechanisms.
Figure 9: VM protect calls present in the IAT.
If the malware detects it is running inside a virtual machine, it kills the process itself and removes itself from the Windows startup folder.
Packers and protectors like Armadillo are used to protect code, including malware, as they allow to add an extra layer against reversing and anti-VM.
Continuing with the analysis, during the malware execution mutex were created in the system, a mechanism often used to avoid a new infection.
"RAL1DAED25C" "1DAED25C::WK" “8D8CE7A22019”
Figure 10: Mutex created during malware execution.
The trojan also checks some registry keys to identify whether it is running inside a VM:
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System name: SystemBiosDate HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System name: SystemBiosVersion
SQL queries to detect VMs were also observed when we analyzed the malware.
SELECT * FROM Win32_ComputerSystem WHERE (Manufacturer LIKE'%VMware%') Or (Manufacturer LIKE'%innotek%') Or (Manufacturer LIKE'%Microsoft%') Or (Manufacturer LIKE'%RingCube%')
Digging into the details
As observed below, the initial sections of the trojan are empty, with raw size at zero. These are unusual sections, furthermore, there are two sections of the binary with execution privileges.
Figure 11: Unusual PE file sections.
This PE file has 16 sections, much more than normal ~10 sections.
An interesting detail is that one of the sections: .pdata has an entropy of 8. This indicator corroborates that this section is packed. This detail can be observed on the next Figures.
Figure 12: .pdata section highlighted is packed with entroty = 8.
In the PortEx graphic below, it’s possible to see some details already mentioned. A great part of the PE file is packed (0.0 – light gray), and the other part has code repetition (0.2 dark gray). The dark gray region is related to the PE file empty sections.
Figure 13: Trojan banker PortEx graphic.
IAT – Keystrokes, clipboard and browser overlay
From the IAT analysis, calls used to get key states are observed. This is a feature of this malware: capture keystrokes and send the information onto the C2 server. Also, functions to manage the clipboard were identified.
Figure 14: Calls used to collect data from clipboard and key states.
Another feature of this malware is to create windows overlaid on the browser when the victim navigates to a homebanking portal (browser overlay).
Additional artifacts of a specific Portuguese bank organization were found. Next Figure presents target messages hardcoded and used to create the overlay window during malware execution.
Figure 15: Target message hardcoded inside the malware.
This targeted message, in particular, is displayed in a Delphi overlay window when the victim accesses the target homebanking. Next, another message this line hardcoded, now about another bank.
Figure 16: Hardcoded message inside trojan.
In detail, by building the Delphi source-code, obtaining all the overlay windows is possible.
Figure 17: Browser-overlay windows hardcoded inside the malware.
Looking at the Figure and the “Picture.Data” object in particular, it is base16 encoded, aka hex. The “Picture.Data” property data starts with a UTF-8 encoded ShortString containing the name of the TGraphic-derived class that produced the image data. In this case, that class name is encoded as: 0954506E67496D616765.
The first byte (hex 09) is the number of bytes in the class name (9), the following 9 bytes (hex 54 50 6E 67 49 6D 61 67 65) are the UTF-8 octets of the class name (TPngImage), and the remaining stream bytes are the actual PNG image data.
By ignoring this header, obtaining all the browser-overlay windows from the Delphi code is possible.
Details inside malware (browser-overlay)
Next, the browser-overlay windows created during malware execution are presented.
Figure 18: Browser overlay: Security mode installation and data collector.
Whenever the application detects the victim is accessing a homebanking portal, it launches one of the following windows on the screen, maximized, and requesting the victim’s details.
Figure 19: Delphi form parameters (Width, Height and Maximized).
Figure 20: Browser overlay windows (1).
Figure 21: Browser overlay windows (2).
Figure 22: Browser overlay windows (3).
Figure 23: Browser overlay windows (4).
Communication with C&C server (C2)
The malware communicates with the C2 server in order to receive additional commands and to send the exfiltrated information from the victim’s machine.
To communicate with C2, the malware uses 3 Google Drive documents, where the addresses of the C2 controlled by criminals are available and encoded. With this approach in place, the C2’s IP addresses can be changed at any time.
On the other hand, removing google doc files from the cloud is a potential kill switch for this malware.
Google docs URLs, like other critical strings, are obfuscated and are unobfuscated and stored in a global variable during the initialization process. After obtaining the URL, a function responsible for reading the google docs document and extracting the content between the strings “start =” and “= end” is called. This content is finally passed to a function that decrypts it and is later stored in a global variable that stores the C2 address.
We can confirm the exact time the docs are accessed below.
Figure 24: Traffic network when the trojan gets the C2 IP address from Google docs.
By analyzing the memory of the compromised machine, it is possible to verify that the malware, once unpacked, communicates with 3 Google Docs documents to obtain the IP addresses of C2 and also a bitcoin address of a wallet with recent transactions.
Collected URLs from memory:
https://docs.google.]com/document/d/1hp6jZYnlZAtMZgIpw2YGyciS1qxck-OUPteOw9sFhX0/edit https://docs.google.]com/document/d/10Yx33pplUYa46H45-r7JrdKsUMgeXcxMn2_AABUrsfE/edit https://docs.google.]com/document/d/1-NZxqAKYFK-c1c_80VjLHfhLNlb8cK5u-jy-5VSeOto/edit
Request and response from Google Docs (memory snippet):
Figure 25: Encoded string (C2 IP address) obtained from Google Docs URL.
During the memory analysis, also the key used to decode the string obtained from Google Docs was collected.
Figure 26: Key used in an XOR function to decode the Google Docs strings.
The following code, distributed by @t14g0p, is a python implementation to decrypt the strings from google documents.
Encoded string: work3
Decoded string: inicio= E86AFC51FA58A4E62D1324242C6B =fim
Encoded string: work2
Decoded string: inicio= E86AFC51FA58A4E62D1324242C6B =fim
Encoded string: btc
Decoded string: inicio= C587DE50CC66FB0175C84BDE6491CA20AC2FE256C746CE3DE175B365D424022C638498 =fim
In detail, the bitcoin wallet was used in recent transactions, last: 2020-01-14 00:22h. However, no malicious activities related to bitcoin was identified during the trojan analysis.
Figure 27: Bitcoin wallet and transactions – address also available on Google Docs and hardcoded inside trojan.
By using Shodan – The search engine for IoT – some details about C2 were collected.
Figure 28: Trojan C2 server RDP port.
During the execution of the malware, it was identified that it communicates with another address (the compromised server from where the payloads were initially downloaded).
After a few minutes of collecting information about the infected machine, the trojan sends encrypted commands onto this server.
Figure 29: Communication with control panel.
This is a PHP service, probably a control panel to manage the victims and collect details on infections.
In this specific request, and based on the path, the trojan sends details about which antivirus is installed on the victim’s machine.
Malicious endpoints are still active at the moment of writing this report (05-05-2020).
Mitre Att&ck Matrix
Thank you to all who have contributed:
Indicators of Compromise (IOCs)
--sample-- MD5: dc61d6239c2848bf8994df95740cbb13 https://sites.google.]com/site/xbet362/control.zip https://vodafone-pt.]ciscofreak./com/my/ https://vodafone-pt.]ciscofreak./com/nf/ --C2-- 23.106.124.]20 23.108.57.]243 http://23.106.124.]20/avs/img1/index.]php --google-docs-- https://docs.google.]com/document/d/10Yx33pplUYa46H45-r7JrdKsUMgeXcxMn2_AABUrsfE/edit https://docs.google.]com/document/d/1hp6jZYnlZAtMZgIpw2YGyciS1qxck-OUPteOw9sFhX0/edit https://docs.google.]com/document/d/1-NZxqAKYFK-c1c_80VjLHfhLNlb8cK5u-jy-5VSeOto/edit --BTC_ADDR-- 18KdHi9CJea1AjEtrVQSfqyN6QXZvJZXqS
Sandbox online analysis
GitHub SI-LAB Yara repository here.
Pedro Tavares is a professional in the field of information security, working as an Ethical Hacker, Malware Analyst, Cybersecurity Analyst and also a Security Evangelist. He is also a founding member at CSIRT.UBI and Editor-in-Chief of the security computer blog seguranca-informatica.pt.
In recent years he has invested in the field of information security, exploring and analyzing a wide range of topics, such as pentesting (Kali Linux), malware, hacking, cybersecurity, IoT and security in computer networks. He is also Freelance Writer.
Read more here.