URSNIF VARIANT FOUND USING MOUSE MOVEMENT FOR DECRYPTION AND EVASION
In January 2016 Forcepoint Security Labs reported an email campaign delivering the Ursnif banking Trojan which used the ‘Range’ feature within its initial HTTP requests to avoid detection.
In July 2017 we discovered a malicious email sample delivering a new variant of Ursnif, attached within an encrypted Word document with the plaintext password within the email body. As recorded in several other Ursnif campaigns reported since April 2017, this Word document contains several obfuscated VBS files which load malicious DLLs through WMI.
However, these samples appear to exhibit new features including anti-sandboxing features that use a combination of mouse position and file timestamps to decode their internal data and the ability to steal data from the Thunderbird application.
A sample lure email for this campaign is shown below:
Once decrypted, it shows three OLE document icons with the extension “docx”, which will lure users to double click them directly (see below):
In fact, their file properties show they are three identical VBS scripts, including same highly obfuscated code padded with lots of garbage scripts to cover up normal logic.
Once triggered, it tries to download malware from ‘hxxp://46.17.40[.]22/hyey.pnj’. If this fails, a second attempt will be made to another site: ‘hxxp://inshaengineeringindustries[.]com/head.pkl’. These files are in fact DLL files which have been designed to be loaded through WMI:
rundll32 [malwarepath] DllRegisterServer
This malicious DLL is packed and again padded with lots of garbage code to hamper static analysis attempts. During execution, it will drop a second DLL file, map this new DLL to the current address, fix the Import Address Table and Relocation Table, then finally jump into the entry point to execute.
The dropped DLL first does self-checking on integrity and then:
- Performs anti-sandboxing checks
- Performs anti-VM checks
- Implements persistence through an autorun registry key
- Injects itself into the ‘explorer.exe’ process
The remainder of this analysis will focus on the new mouse-based anti-sandboxing/decryption capabilities.
The algorithm used by this sample uses the difference between the current and previous recorded mouse coordinates to detect mouse movement and avoid sandbox environments where the mouse is not usually moved. It further uses the value generated by this process to ‘brute force’ its own decryption key.
Step One – Key Generation
Firstly, the malware calculates the D-Value (delta) between the x- and y-coordinates of the last and current mouse position. It then selects the sum of the .BSS section’s Relative Virtual Address (RVA) and ‘SizeOfRawData’ value as a base seed.
It XORs the base seed with the file creation time (in this case ‘Apr 11 2017’) to get a value which is added to the lowest 5 bits of the mouse D-Value to get the decryption key.
Step Two – Decode .BSS Section
The malware loops through the .BSS section of the DLL one DWORD at a time, XORing the current DWORD data with the last DWORD data. This value is then XORed with the decryption key generated above and right-rotated by the loop count. The ‘current’ DWORD is then replaced.
Step Three – Verify The Deciphering Key
After .BSS section data is decoded, three values are acquired from offsets 0x61d, 0x619, and 0x625 in the .BSS section, and their sum compared with checksum ‘0EE553B4E’. If this matches, it will execute the rest of the code, otherwise it has to restore the encrypted .BSS section raw data and try to re-calculate new key for another attempt at the decryption and verification operation.
If run in sandbox environment, since the D-value based on the mouse movement always is 0, the ‘BSS’ section is always inaccurately decoded and will loop execution of same code. While in a realistic environment, due to only using the lowest 5 bits of D-value rather than the full 32 bits, it is more likely to get correct value to decode section data.
The decryption key itself is an important global constant which will be used in subsequent code to decode APIs, a hidden PE file (DLL file in this variant), synchronous objects, Registry data, URLs, etc.
In addition, the decoding operations are implemented at run time, preventing memory analysers from dumping the whole plaintext string stream of malware memory, e.g.
Decoding Windows APIs used for further injection operations:
With the aid of the decryption key, an additional embedded PE file (a 3rd DLL file) can be safely extracted from data section of the second DLL file, released to a temporary buffer, and injected into the ‘explore.exe’ process.
Ursnif spreads itself through emails provided with a plaintext password for an attached encrypted document. In general, this method is used by senders when the attached documents contain sensitive content. In recent years, this method is widely leveraged by threat actors, who want to ensure their payload successfully bypasses IDS detection and to deceive recipients to firmly believe that the mail may contain important information.
Overall, Ursnif is well concealed: it communicates with C2 servers via Tor, limiting its traceability, and is equipped with anti-sandbox and anti-VM techniques.
You value our work? Please support us