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.
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)
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 whitelisting 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.
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:
Figure 2: String generators and the main routine.
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:
Figure 3: The deobfuscated index.html
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:
Figure 4: Decoded and deobfuscated ASCII data
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.
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.
hxxp://xolzrorth[.]com
hxxp://grumnoud[.]com
hxxp://gandael6[.]com
hxxp://chersoicryss[.]com
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
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
8212E2522300EF99B03DFA18437FCA40