# Analyzing Ursnif’s Behavior Using a Malware Sandbox **[vmray.com/cyber-security-blog/analyzing-ursnif-behavior-malware-sandbox/](https://www.vmray.com/cyber-security-blog/analyzing-ursnif-behavior-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](https://www.vmray.com/analyses/53f7d917ad9e/report/overview.html) _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 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.](https://www.vmray.com/analyses/53f7d917ad9e/report/network.html) 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. ----- 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: electrumbitcoin 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 10 – IESTEALER module name visible in the function log _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 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,](https://www.vmray.com/analyses/53f7d917ad9e/report/files.html) 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. ``` 01D51ED4E3ECF92009 is the output of the OLSTEALER module. ``` _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 _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-inthe-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. _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 HTTPtransmitted 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=off command 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:` ``` HttpOpenRequestW ``` ----- ``` InternetCloseHandle ``` _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_Read PR_Write PR_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](https://github.com/snemes/aplib) [@sandornemes.](https://twitter.com/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](https://www.vmray.com/products/malware-sandbox-vmray%20analyzer/) VMRay Analyzer report for the Ursnif variant discussed throughout this post can be found here: [https://www.vmray.com/analyses/53f7d917ad9e/report/overview.html](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,](https://www.vmray.com/analyzer-malware-sandbox-free-trial/) 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](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](https://www.virusbulletin.com/blog/2018/07/vb2017-paper-and-update-browser-attack-points-still-abused-banking-trojans/) points: [James Wyke’s Botconf 2018 talk about web inject tracking](https://www.botconf.eu/wp-content/uploads/2018/12/2018-J-Wyke-Tracking-actors-through-their-webinjects-.pdf) [Maciej Kotowicz’s 2016 paper about ISFB](https://twitter.com/maciekkotowicz) [0verfl0w’s blog posts about reversing ISFB loaders (parts 1 and](https://twitter.com/0verfl0w_) [2)](https://0ffset.net/reverse-engineering/malware-analysis/analyzing-isfb-second-loader/) -----