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
- Man-in-the-Browser
- Different Browsers, Different Hooks
- 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:
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:
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:
Figure 3: Urnsif’s Network Activity
In the function log we can see the request as cleartext before it is encrypted:
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:
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.
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.
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:
Figure 9: File created by the OLSTEALER module to store data
The IESTEALER module reads Internet Explorer history and passwords.
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.
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 informationnet view– show network sharesnslookup 127.0.0.1– local IPtasklist.exe /SVC– Servicesdriverquery.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.
Figure 13: VMRay’s Behavior Tab showing temporary file creation
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.
01D51ED4E3ECF92009is the output of the OLSTEALER module.
Figure 15: File containing output of the OLSTEALER module
1FB1.bincontains the directives to compress01D51ED4E3ECF92009to2855.bin
Figure 16: File containing directives for makecab
- 2855.bin is the CAB file created by makecab by calling it with the directive file
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.
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.
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:
- A trojan is running on the same host as the browser,
- Inject into the browser,
- Install API hooks, and then
- Modify API calls to include the attacker’s JavaScript, which is specific per website.
Figure 19: VMRay process graph showing Ursnif injecting code into Internet Explorer, Firefox and Chrome
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 Settingsto 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.jsfile 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:
InternetReadFileInternetWriteFileInternetReadFileExWHttpSendRequestWInternetQueryDataAvailableHttpOpenRequestWInternetCloseHandle
Figure 20: VMRay Analyzer showing information about the hooks added to Internet Explorer
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_ReadPR_WritePR_Close
Figure 21: VMRay Analyzer showing the hooks added to Firefox
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.
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.
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.
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).
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
makecabfor 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,andreg. - 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)