Analyzing Ursnif’s Behavior Using a Malware Sandbox

Jun 25th 2019

Ursnif is a group of malware families based on the same leaked source code. When fully executed Urnsif has the capability to steal banking and online account credentials. In this blog post, we will analyze the payload of a Ursnif sample and demonstrate how a malware sandbox can expedite the investigation process.

Access the VMRay Analyzer Report for Ursnif

This blog post will cover a behavioral analysis of a single Ursnif variant. It does not provide comprehensive insights into web injects, infrastructure or attribution. For additional Ursnif analysis see Appendix D.




Ursnif Sample Overview

When Ursnif is downloaded and run (say via a malicious attachment in an email), it first spawns its own explorer.exe process and injects itself into the rogue process. As few legitimate applications ever start their own explorer.exe processes, and we cannot think of a valid reason that the application should inject itself into the process, this technique surfaces as a good indicator for detection. The newly created explorer.exe then injects into the legitimate explorer.exe process, as shown below:


Process Graph Injections - Ursnif Analysis

Figure 1: VMRay process graph showing injections


The initial explorer.exe process installs its configuration under the registry key HKCU\Software\AppDataLow\Software\Microsoft\{Machine-specific ID}, as shown below:


Configuration Written into Registry

Figure 2 – Configuration being written into registry


The malicious behavior happens inside the injected, and legitimate, explorer.exe process based on what was written to the config. Examples include various types of credential stealing, browser injection, and system information collection functions.


C2 Check-Ins

Ursnif communicates over standard HTTP using encrypted HTTP request parameters. During the execution it performs a number of C2 check-ins, as shown below:


Network Activity - Ursnif Analysis

Figure 3: Urnsif’s Network Activity


In the function log we can see the request as cleartext before it is encrypted:


Unencrypted HTTP Request

Figure 4: Function log showing the unencrypted HTTP request


Ursnif then prepends a runtime-generated junk parameter to this request, also visible in the function log:


Junk Parameter

Figure 5: Ursnif adding a junk parameter to the HTTP request


After this function completes, the parameters are encrypted and sent over HTTP to one of the C2 servers.

The request contains various identifiers:

  • Soft
  • Version
  • User
  • Server
  • ID
  • CRC
  • GUID

During our sandbox execution, the parameters, with the exception of the CRC, remained constant. The CRC parameters for this sample include:

  • 114f9e9
  • 114f95d
  • 1198d90
  • 11e2176

This sample leveraged POST requests to upload files for data exfiltration, and added an additional name=X parameter used to indicate the filename.


Stealing Functionality

Besides the Man-in-the-Browser (MitB) attack, various stealer modules were also found to be active.

Cryptocurrency + Disk Encryption

In each injected process, the stealer checks if the process name belongs to a supported cryptocurrency wallet, VeraCrypt, or TrueCrypt. The stealer also looks for a process containing the string “JEdudus.”, which we couldn’t match to a real application but it is among the cryptocurrency wallet names.


Strings Known by Module
Figure 6: Checking if the current process name contains one of the strings known by the module 

The stealer module looks for cryptocurrency wallets that contain the following strings:

  • electrum-
  • bitcoin
  • multibit-hd
  • bither
  • msigna
  • Jaxx
  • armory-


Besides cryptocurrency stealing, the modules named OLSTEALER and IESTEALER were also visible.


VTI Match (Info Stealing)

Figure 7: VMRay Threat Identifier (VTI) match for Ursnif’s data stealing


OLSTEALER steals data from Outlook, including login information, and stores it in a local file. The internal name of the module is visible in Function log:



Figure 8: OLSTEALER module name visible in the function log


The contents of the created file appear as follows:


File Created OLSTEALER

Figure 9: File created by the OLSTEALER module to store data


The IESTEALER module reads Internet Explorer history and passwords.


IESTEALER (Function Log)
Figure 10 – IESTEALER module name visible in the function log
Password Stealing - Ursnif Analysis

Figure 11 – Detection and details for the different password stealing attempts


After stealing from Internet Explorer, the malware also looks for Thunderbird, though the name of the Thunderbird stealer module (TBSTEALER) did not explicitly appear.


Looking for Thunderbird Data

Figure 12: Ursnif looking for Thunderbird data


System Info Gathering

Using built-in Windows system tools Ursnif gathers information about the system. The tools used are:

  • systeminfo.exe – various info about the system including OS version, installed patches, domain, and basic hardware information
  • net view – show network shares
  • nslookup – local IP
  • tasklist.exe /SVC – Services
  • driverquery.exe – Installed drivers
  • (Installed software)reg.exe query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
    reg.exe query "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall


Data Exfiltration

Ursnif caches stolen data to the hard drive into temp files, compresses them into CAB files, and uploads them.

Steps followed to create the CAB:

1. The various stealer modules create files on the hard drive. Some use the %TEMP% directory, others use the random directory created earlier.


Temporary File Creation

Figure 13: VMRay’s Behavior Tab showing temporary file creation


Ursnif Module Creating File

Figure 14: Ursnif module creating file in it own randomly named folder


2. Before sending home the data, Ursnif uses the makecab tool to compress it. Makecab is able to accept a directive file when being called with the /F parameter, which defines the source and target. For each CAB file it needs to create, Ursnif drops a directive file.

  • 01D51ED4E3ECF92009 is the output of the OLSTEALER module.


File Containing Output OLSTEALER

Figure 15: File containing output of the OLSTEALER module


  • 1FB1.bin contains the directives to compress 01D51ED4E3ECF92009 to 2855.bin



Figure 16: File containing directives for makecab


  • 2855.bin is the CAB file created by makecab by calling it with the directive file


makecab (Behavior Tab) - Ursnif Analysis

Figure 17: VMRay’s Behavior tab showing the command line for calling makecab


3. To send the data home, Ursnif uses the same C2 channel with the same encryption, but our analyzed variant also adds an additional “name” parameter to indicate the filename.


C2 Channel

Figure 18: Function log showing Ursnif adding an additional “name” parameter


4. Just like with normal check-ins, Ursnif adds a junk parameter (e.g. uhrg=gbeicj&), then encrypts the parameters.

5. Then it includes the uploaded file in the POST contents to send the file.



Overview of Man-in-the-Browser Attacks

  • A lot of valuable user data (banking, shopping, etc.) is not stored on the hard drive or registry, but accessed through web applications.
  • HTTPS is now the norm. User data is transmitted over a secure connection so Man-in-the-Middle (MitM) from outside the browser is more difficult.
  • To get access to this valuable data, malware goes inside the browser.
  • On Windows, browsers are not well-protected from applications that are already running on the same host – for a website it is very challenging to exploit a modern web browser and escape the browser sandbox. That being said, it’s not difficult to get in when the attacker already has code execution on the system.
  • The usual goal is a web inject:
    1. A trojan is running on the same host as the browser,
    2. Inject into the browser,
    3. Install API hooks, and then
    4. Modify API calls to include the attacker’s JavaScript, which is specific per website.


Ursnif Injecting Code

Figure 19: VMRay process graph showing Ursnif injecting code into Internet Explorer, Firefox and Chrome



SPDY (pronounced “speedy”) is a network protocol that enables compression of HTTP-transmitted data, and HTTP/2 is a version of HTTP derived from SPDY with the same goal. Though neither are security features, they just implement compression, they still cause a bit of extra work for attackers looking to implement MitB attacks. Attackers must decompress the HTTP traffic, or they can just turn off SPDY and HTTP/2 altogether – most attackers prefer to turn them off instead of implementing an extra feature. The fact that a process turns this feature off is a good indicator for a defender – legitimate processes have no reason to turn off compression but browser injectors often do it.


  • For Internet Explorer: Sets the EnableSPDY3_0 value in the HKCU\ \SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings to 0.
  • For Chrome: Starts a chrome process with the --use-spdy=offcommand line argument.
  • For Firefox: this sample didn’t turn off SPDY for Firefox, though we have observed other variants edit the prefs.js file in the Firefox Profile folder, adding the following line:
    user_pref("network.http.spdy.enabled", false);

A similar approach is possible for HTTP/2. The attacker can edit the registry to disable in Internet Explorer, use a command line parameter for Chrome, and edit the prefs.js file for Firefox.


Different Browsers, Different Hooks

The sandbox can report on installed hooks in the “Hook Information” section of each process. For each installed hook it shows the original API, and the (already overwritten) address it points to now. The overwritten address is shown as [closest symbol + offset] to make matching to the overwritten code easier.

Internet Explorer

The observed hooks added to some exported functions of wininet.dll were:

  • InternetReadFile
  • InternetWriteFile
  • InternetReadFileExW
  • HttpSendRequestW
  • InternetQueryDataAvailable
  • HttpOpenRequestW
  • InternetCloseHandle


Hooks Added-IE

Figure 20: VMRay Analyzer showing information about the hooks added to Internet Explorer



This specific sample was not interested in attacking Firefox with web injects. Some other Ursnif variants add hooks to the nss3.dll loaded by Firefox:

  • PR_Read
  • PR_Write
  • PR_Close


Hooks Added to Firefox

Figure 21: VMRay Analyzer showing the hooks added to Firefox


The hooked functions are exports of nss3.dll



Adding hooks is easy with Internet Explorer and Firefox. Since Chrome’s DLL doesn’t export the necessary functions, however, the attacker needs to manually find them in the binary and add the changes.


Ursnif's Hooking Chrome - Ursnif Analysis

Figure 22: Ursnif’s hooking of Chrome as visible on the sandbox level


Extracting the Modules for Static Analysis

It is common for Ursnif samples to implement the malware functionality in a DLL, compress the DLL, attach it to the loader, and pack the whole binary together (loader+DLL). To extract the uncompressed binary, we need to:

1. Unpack the sample: To achieve this, we execute the packed sample in VMRay Analyzer. The sandbox dumps the memory of the unpacked sample, which contains the compressed module.


Memory Dump

Figure 23: Memory dump of the original executable with a tick in the YARA column indicating a match



2. Extract the compressed module: We need 2 elements: the memory dump itself which contains the compressed module and the offset where the module begins. We get this info with the help of a built-in YARA rule that matches on the memory dump which contains the apLib-compressed PE header. The analysis archive contains the memory dump and the offset of the match, we do the extraction based on this.


APLib-Compressed PE Files

Figure 24: Detection showing that VMRay’s built-in YARA for APLib-compressed PE files has matched



3. Decompress the module: For this we use an open-source apLib decompressor by @sandornemes.

The result is the decompressed DLL. According to the headers, the module was compiled on May 26, 2019, and as usual for Ursnif, it is referred to as client.dll.



Figure 25: PEBear showing information about the decompressed DLL


The DLL doesn’t have any exported functions, everything is only reachable from DLLMain, the flow of execution depends on the installed registry entry (described in the very beginning of the post).



We hope you find value in our analysis of Ursnif. The analysis and understanding of the various facets of the malware could have been conducted and collected manually but our investigation was greatly accelerated by using VMRay Analyzer. The publicly-available VMRay Analyzer report for the Ursnif variant discussed throughout this post can be found here:

We look forward to bringing you future detailed reports to help expedite your analysis, understanding, and defensive capabilities. Please view the appendices for the associated IOCs, MITRE ATT&CK mappings, and
related work.

We encourage you to sign up for a trial of VMRay Analyzer, upload your own Ursnif samples, and contact us if you notice evolutions or changes in our findings. Until next time!


Appendix A: Indicators for Host-Based Detection & Identification

  • User process spawning its own explorer.exe process
  • Injection into explorer.exe
  • The configuration is written under registry key HKEY_CURRENT_USER\Software\AppDataLow\Software\Microsoft\
  • Usage of makecab for compression of staged data
  • Injection into browser processes
  • Turning off SPDY or HTTP/2
  • Usage of the following tools for data collection: systeminfo, net, nslookup, tasklist, driverquery, and reg.
  • Additional VMRay Sandbox IOCs can be found here:



Appendix B: Observed MITRE ATT&CK Techniques in this Analysis

The following does not cover all Ursnif techniques, just the
ones that came up in the analysis of this sample.

  • T1045 – Software Packing
  • T1059 – Command-Line Interface
  • T1106 – Execution through API
  • T1179 – Hooking
  • T1055 – Process Injection
  • T1140 – Deobfuscate/Decode Files or Information
  • T1112 – Modify Registry
  • T1003 – Credential Dumping
  • T1081 – Credentials in Files
  • T1214 – Credentials in Registry
  • T1082 – System Information Discovery
  • T1016 – System Network Configuration Discovery
  • T1135 – Network Share Discovery
  • T1007 – System Service Discovery
  • T1119 – Automated Collection
  • T1074 – Data Staged
  • T1185 – Man in the Browser
  • T1043 – Commonly Used Port
  • T1071 – Standard Application Layer Protocol
  • T1132 – Data Encoding
  • T1002 – Data Compressed
  • T1041 – Exfiltration Over Command and Control Channel


Appendix C: Hashes

SHA256: 53f7d917ad9ebf5b7d2ccc1a835083bc0c0b92cc69ee584703ea6e4345f5c457

Extracted client.dll:


Appendix D: Related Work