Ursnif variant found using mouse movement for decryption and evasion
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.
Forcepoint customers are protected against this threat via Forcepoint Cloud and Network Security, which includes the Advanced Classification Engine (ACE) as part of e-mail, web and NGFW security products. ACE (also known as Triton ACE) provides signature-less analytics to identify malicious intent, including evasion techniques to mask the malware. Forcepoint NGFW is capable of detecting and blocking TOR.
Protection is in place at the following stages of attack:
Stage 2 (Lure) - Malicious e-mails associated with this attack are identified and blocked.
Stage 5 (Dropper File) - Variants are prevented from being downloaded.
Stage 6 (Call Home) - Attempts to contact its C&C server are blocked.
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.
The rationale behind the Thunderbird-related functionality in this sample is unclear: this may be a first attempt at such activity, potentially meaning that more email clients or applications will be included in future releases.
Forcepoint Security Labs will continue to monitor developments to this threat.
Indicators of Compromise
hxxp://46.17.40[.]22/hyey.pnj hxxp:// 46.17.40[.]142/45.txt hxxp://inshaengineeringindustries[.]com/head.pkl hxxp://ardshinbank[.]at/key/x32.bin hxxp://ardshinbank[.]at/key/x64.bin
82615b4bb03ba00f141bb4d4b57bf8a73e76ebe9 bdcb4b96a281da3e09e29071dc9661ce39d442f1 73fdde182759e644a3d7296537a048a6980e8526 60e221bd9e234ab6786def88a1f0e11460678fb4 ce7e48d8ee6e113429dba75a8528568fda4b0067
Set Autorun Registry
Key: HKEY_USERS\S-1-5-21-746137067-1417001333-1606980848-500\Software\Microsoft\Windows\CurrentVersion\Run Name: Random String Value: rundll32 [malwarepath]