Recently, the Zscaler ThreatLabz team saw the start of a campaign featuring a new multistage payload distribution technique for the well-known banking Trojan named Ursnif (aka Gozi aka Dreambot). The malware has been around for a long time and remains active leveraging new distribution techniques. In this blog, we will analyze one of the recent campaigns.

This new campaign began on March 24, 2020. The malware is being distributed with the name info_03_24.doc, which is quite similar to one of its 2019 malware distribution campaigns (info_07_.{date}.doc). Moreover, the final payload delivery URLs available during the time of analysis were all registered on the same date and around the same time frame (2020-03-24 T12:00:00Z), which is a strong indicator of the beginning of a new campaign.

Multistage

For a long time malware authors have been trying to distribute malware in multiple stages. This helps the main malware evade detection in the early stages so that it can be delivered in the last stage. This is the case with Ursnif. It is being delivered in three stages:

VBA macro [doc] --------------> HTML [mshta]---------------> DLL [regsvr32]

(Stage 1) (Stage 2) (Stage 3)

Why mshta?

One of the reasons malware authors try to switch to new delivery methods is to bypass security defenses, leave fewer footprints, and blend with existing system noise on the victim's machine. This seems to be the reason for using mshta in this new campaign despite using PowerShell as the second-stage payload in the past.

A brief description of mshta

Mshta.exe is a utility that executes Microsoft HTML Applications (HTAs). HTAs are stand-alone applications that execute using the same models and technologies of Internet Explorer, but outside of the browser. Adversaries can use mshta.exe to proxy execution of malicious .hta files and JavaScript or VBScript through a trusted Windows utility. Mshta.exe can be used to bypass application allowlist solutions, which do not account for its potential use, and digital certificate validation. Since mshta.exe executes outside of Internet Explorer's security context, it also bypasses browser security settings.

Doc file analysis [First stage]

As mentioned earlier, the malware's initial payload was being delivered via document files with the name info_03_24.doc during the time of our analysis. The document didn’t contain any exploits but used macro code to drop the second-stage payload. The macro code is obfuscated but doesn’t seem to contain any anti-checks.

VBA macro code analysis

The VBA macro code contains one form and three modules.

Form [frm]: This contains a textbox whose value property contains the second stage payload to be dropped.

Module1 [a7kcX]: This contains an AutoOpen and final macro code execution routine.

Module2 [aDbCyK]: This is the file creation and string decoder routine.

Module3 [axmNj]: This contains string generation and the main routine.

Figure 1: Form and modules in the VBA macro code.

Execution of macro code begins from the AutoOpen routine, which is executed every time you open the document. The AutoOpen routine, in turn, calls the main routine, which performs the following operations:

Obtain the required strings from three string-generator routines.
Copy the mshta.exe code to microsoft.com (possibly to reduce footprints).
Write the second stage payload to index.html.
Execute the index.html with microsoft.com.

Figure 2: String generators and the main routine.

Index.html analysis [Second stage]

The index.html file is obfuscated with garbage code and random variable names. After removal of the obfuscation, the file comes out containing the following code components:

HTML code: This defines a paragraph element, which contains some ASCII data to be used later.

JavaScript: This contains static string variables and the custom decoder

ActiveX: This is used for file system access, downloading final payload and executing it.

Upon execution of index.html with microsoft.com [mshta.exe], the JavaScript and ActiveX code gets executed to perform the following operations:

Create a shell object with ActiveX
Read the paragraph element containing ASCII data using the innerHTML property
Write the read content to the registry key: "HKEY_CURRENT_USER\\Software\\test1\\mykey”
Read the newly created registry key value
Delete the registry key
Pass the read content to the decoder routine
Create a new function object where the function body is decoded ASCII data and it takes two arguments as the inputs, namely ‘u’ and ‘c’
Call the newly created function with u=“261636e223b616f6a7d3c6f3078607e2e65676271647f2572746e657b6f2d6f636e28647 27f627a7c6f687f2f2a307474786” and c=0

Figure 3: The deobfuscated index.html

Decoded ASCII data analysis

The decoded ASCII data is another JavaScript and ActiveX code snippet, which is also obfuscated using garbage code and random variable names. Upon removal of the obfuscation, it turns out to be performing the following operations:

Create an XMLHTTP object, stream object, and shell object using ActiveX.
Get the path %temp% and append index.dll (the final payload filename) to it.
Decode the ‘u’ variable earlier passed as an argument, which turns out to be the final payload URL.
Send a GET request to the decoded URL.
If the response status is 200 and the operation is complete, it saves the downloaded data to the index.dll file created earlier.
Execute the downloaded DLL using regsvr32.

Figure 4: Decoded and deobfuscated ASCII data

Index.dll (third and final stage)

The index.dll turns out to be the final and main payload, which is Ursnif. The DLL is executed using regsvr32 as it doesn’t contain any export functions and the malicious code is present within the DllMain routine itself.

Note: rundll32 is generally used to execute DLLs, and regsvr32 is mainly meant for COM DLLs. Since no exports are present in this case, we can use regsvr32 to execute the DllMain routine, which again might be a good way to reduce footprints or even avoid them due to the unpopularity of regsvr32 among malware. If this is not the case, then only the malware author knows.

Conclusion

The banking Trojan Ursnif (aka Gozi aka Dreambot) is not new, and it continually resurfaces with new distribution techniques. It appears to be back in a form designed to leave fewer footprints and avoid detection while trying to steal victim's data. The Zscaler ThreatLabz team will continue to observe this new version of Ursnif to help keep our customers safe and to monitor whether it returns in another form.

Newly registered campaign domains

hxxp://xolzrorth[.]com

hxxp://grumnoud[.]com

hxxp://gandael6[.]com

hxxp://chersoicryss[.]com

Payload URLs

hxxp://xolzrorth[.]com/kundru/targen.php?l=zoak2.cab

hxxp://grumnoud[.]com/kundru/targen.php?l=zoak4.cab

hxxp://gandael6[.]com/kundru/targen.php?l=zoak6.cab

hxxp://chersoicryss[.]com/kundru/targen.php?l=zoak2.cab

Download URL:

doc-00-2o-docs.googleusercontent[.]com/docs/securesc/97lq9pt3pod9mpumel15kp2j33hcurr8/c560lkciidvhh4viucof3ludaoief0m5/1585069725000/11599430631386789056/11599430631386789056/1yns_1ujuoinor2ytltx8-39p5i0k7i0r?e=download&authuser=0&nonce=ua6b0u4p5r3mq&user=11599430631386789056&hash=irhbu94ms0nq978q6ipge2kgosjdll3a