Analyzing Ursnif’s Behavior Using a Malware Sandbox

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.

Contents

• Ursnif Sample Overview
• C2 Check-Ins
• Stealing Functionality
  • CryptoCurrency & Disk Encryption
  • OLSTEALER & IESTEALER
  • System Info Gathering
  • Data Exfiltration
• Man-in-the-Browser
  • Overview of Man-in-the-Browser Attacks
  • SPDY & HTTP/2
• Different Browsers, Different Hooks
  • Internet Explorer
  • Firefox
  • Chrome
• Extracting the Modules for Static Analysis
• Conclusion
• Appendix A: Indicators for Host-Based Detection & Identification
• Appendix B: Observed MITRE ATT&CK Techniques in this Analysis
• Appendix C: Hashes
• Appendix D: Related Work

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:

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

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:

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

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

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.

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

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

OLSTEALER & IESTEALER

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

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:

The contents of the created file appear as follows:

The IESTEALER module reads Internet Explorer history and passwords.

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

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 127.0.0.1 – 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.

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.

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

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

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.

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.

Man-in-the-Browser

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.

SPDY & HTTP/2

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.

Ursnif:

• 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

Firefox

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

The hooked functions are exports of nss3.dll

Chrome

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.

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.

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.

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.

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).

Conclusion

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: https://www.vmray.com/analyses/53f7d917ad9e/report/overview.html

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: https://www.vmray.com/analyses/53f7d917ad9e/report/ioc.html

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:
f54b56916010c5563634bfcad6b9e3f9855e5fcd48d96c1872510ecd6dadf3a7

Appendix D: Related Work

• Peter Kalnai’s and Michal Poslušný’s VirusBulletin 2017 paper on browser attack points:
• James Wyke’s Botconf 2018 talk about web inject tracking
• Maciej Kotowicz’s 2016 paper about ISFB
• 0verfl0w’s blog posts about reversing ISFB loaders (parts 1 and 2)