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.
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.
The trojan modus operandi is the following:
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.
After executing the .msi file, the 2nd stage is 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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
In detail, by building the Delphi source-code, obtaining all the overlay windows is possible.
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.
Next, the browser-overlay windows created during malware execution are presented.
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.
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.
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.
During the memory analysis, also the key used to decode the string obtained from Google Docs was collected.
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.
By using Shodan – The search engine for IoT – some details about C2 were collected.
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.
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).
Additional details, including Indicators of Compromise and Yara rules are available in the report published by the Pedro Tavares.
About the author Pedro Tavares
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.
Please vote Security Affairs for European Cybersecurity Blogger Awards – VOTE FOR YOUR WINNERS
(SecurityAffairs – Trojan banker, hacking)
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.