Pierluigi Paganini December 04, 2018

Security experts at Yoroi – Cybaze Z-Lab discovered a new variant of the infamous Ursnif malware targeted Italian users through a malspam campaign.

Introduction

In the last weeks, a new variant of the infamous Ursnif malware was discovered hitting Italian users through a malspam campaign. In fact, Yoroi-Cybaze ZLAB isolated several malicious emails having the following content:

• Subject: “VS Spedizione DHL AWB 94856978972 proveniente dalla GRAN BRETAGNA AVVISO DI GIACENZA”
• Attachment: “GR930495-30495.zip”

The content of the attachment is a .js file and when it is launched, starts the infection by downloading other components from the Internet.

The Dropper

The initial dropper is an obfuscated javascript. Once run, it generates a lot of noisy internet traffic with the purpose to harden the detection of the real malicious infrastructures; as we can see from the following figures, the script contains a series of random-looking URLs it unsuccessfully tries to connect to, generating a huge volume of noise into the analysis environment.

Figure 1: Hard coded urls where the malware tries to connect to generate noise

Figure 2: Generated internet traffic noise

However, the real malicious action performed by the javascript is to create a batch file in the “%APPDATA%\Roaming\325623802.bat” path. The file is a simple script file containing the following code:

Figure 3: Extracted batch file

The script execution pops up to the screen a harmless “FedEx” brochure in pdf format used to decoy the victim, in the meanwhile it downloads and extract a PE32 executable file from a CAB archive hosted on a compromised Chinese website.

Figure 4: PDF downloaded to the internet and shown to the user

The second stage

The second stage of the infection chain is the “ppc.cab” file downloaded by the dropper to the “%APPDATA%\Roaming” location: it actually is a Microsoft Cabinet archive embedding an executable file named “puk.exe”.
The “puk.exe” file promptly spawns a new copy of its own process to make the debugging harder, then it starts several instances of the Internet Explorer process to hide its network activity inside legitimate processes.

Figure 5: spawned processes by the original “puk.exe”

The network traffic generated by the iexplore.exe processes points to the remote destination 149.129.129.1 (ALICLOUD-IN) and 47.74.131.146 (AL-3), part of the malicious infrastructure of the attacker.

Figure 6: C2 network traffic

The beaconing pattern recognized in the C2 communication is consistent with Gozi/Ursnif/IFSB/Dreambot malware variants. In addition, the particular “/wpapi/” base url adopted by the sample matches several malspam campaign tracked during the current year (rif EW. N070618, N030618, N010318).

Figure 7: Malware’s beaconing requests

Persistency

The third stage of the malware is designed to ensure its persistence into the infected system in the long run. It sets up a particular registry key containing chunks of binary data: “HKEY_CURRENT_USER\Software\AppDataLow\Software\Microsoft\6C174C70-DB2B-7E6F-C560-3F92C994E3E6”

Figure 9: Registry key written by the malware

Among the registry key shown above, there is an entry named “ddraxpps”: this particular name has been also used into the persistency mechanism of other Ursnif samples analyzed back in January.  Also, the malware configures a key named “comuroxy” containing a wmic “process call create” command designed to invoke powershell code from the “ddraxpps” entry: C:\Windows\system32\wbem\wmic.exe /output:clipboard process call create "powershell -w hidden iex([System.Text.Encoding]::ASCII.GetString((get-itemproperty 'HKCU:\Software\AppDataLow\Software\Microsoft\6C174C70-DB2B-7E6F-C560-3F92C994E3E6').ddraxpps))".

The “ddraxpps” registry key stores a hex string could be decoded applying a simple hex-to-ascii conversion, its content actually is the following obfuscated powershell code:

Figure 10: body of “ddraxpps” key

The first line of code shows a set of commands allowing the execution of some kind of payload encoded in decimal format. The array of numbers in at line two represents the actual executable payload in decimal notation.

The third line, instead, contains a base64 encoded powershell snippet revealing the usage of a known payload injection technique: the “APC injection” or “AtomBombing”, used to infect the “iexplore.exe” process.

Figure 11: Commands of the third row of “ddraxpps” key

All the commands shown in Figure 11 are necessary to perform the operation of APC Injection: in the first variable “$jtwhasq” there is the import of the necessary library “kernel32.dll”, in particular the functions “GetCurrentProcess()” and “VirtualAllocEx()”. The second row provides the importing of of the functions “GetCurrentThreadId()”, “QueueUserAPC()”, “OpenThread()”. The third contains the real injection: while the first two lines contains the preparation of all imports, functions and relative parameters, the third one is the responsible of the execution of the actual APC Injection technique. The first step is to properly create a Virtual Section using the “VirtualAllocEx()” function of the current process, identified thanks to “GetCurrentProcess()”. The malware is then copied to the virtual section and, finally, this section is injected in a local thread within the “iexplore.exe” process thanks to the “QueueUserAPC()” function.

Conclusion

In the end, the whole infection chain could be summarized in four stages: the generation of network noise to hide the attacker’s infrastructure, the download of the executable payload, the achievement of persistence through the registry key installed and the checking and the download of the Ursnif modules.

Figure 12. Representation of the infection chain

Further details, including IoCs and Yara rules, are reported in the original blog post published by Yoroi.

https://blog.yoroi.company/research/dissecting-the-latest-ursnif-dhl-themed-campaign/

Pierluigi Paganini

(Security Affairs – Ursnif, malware)

[adrotate banner=”5″]

[adrotate banner=”13″]