By: Shaul Vilkomir-Preisman
Ursnif (AKA Gozi), is one of the most enduring pieces of malware in the cybercrime threat landscape, being active for well over a decade now. Its code has been leaked repeatedly and has been used, modified and upgraded extensively; giving rise to many different yet similar variants of this banking malware which are delivered primarily through spam Emails with malicious attachments.
Deep Instinct recently prevented Ursnif being delivered to a customer environment by means of a sophisticated dropper which is disguised as a DHL invoice.
As mentioned above, the dropper, an Excel Spreadsheet, is designed to appear like a DHL invoice, which when opened prompts the user to enable the VBA macro contained.
Once the macro is enabled, it is executed and presents the victim with a decoy progress bar, likely intended to make the malicious document appear more legitimate and stall the victim while the malicious code is being executed.
General infection and de-obfuscation flow is as follows:
The VBA macro is obfuscated and contains many random-generated “comments” intended to make the code appear more legitimate and lower the chances of it being caught by security vendors.
After the decoy progress bar is presented to the victim, the VBA macro reads a portion of the Excel file, which contains a compressed and base64 encoded PowerShell command, which is in turn executed by WMIC.exe (Windows Management Instrumentation Command-Line Utility) after being called for by the VBA using a Shell() function.
Analysis of this PowerShell code reveals complex, heavily obfuscated dropper code, with multiple layers of compression, encoding, and obfuscation.
Decoding and decompressing the initial command blob (shown above) reveals two similar compressed and encoded blobs, which are piped to a function named “ms”.
Replacing this function with a print function enables us to see the content of these blobs and some initial functionalities are revealed, as well as an additional obfuscated blob and an initial de-obfuscation loop, after which the code is again piped to function “ms”.
Repeating the function replacement trick enables to us to see below this 2nd layer of obfuscation and reveals another de-obfuscation function and yet another compressed and encoded blob, with the end result again being piped to function “ms”, again.
Decoding and decompressing the above blob, finally reveals function “ms”, which itself is obfuscated, however, some light manual de-obfuscation will readily reveal the code’s final functionality:
The end result of the above is as follows:
This deletes temporary internet files (top image above)
This executes the payload, after which Ursnif will launch its own instance of iexplore.exe and will attempt to reach its C2 server. (bottom image in above)
The Ursnif payloads are delivered to the victim by a mutation “factory” very similar to what we reported approximately 8 months ago.
While each file is individually unique (has a unique file hash in order to circumvent file-reputation based mechanisms), much like what we previously reported 8 months ago – the mutation is limited to a single file section (.text), with the other file sections being exactly identical.
Additionally, all of the mutated samples feature the function same exports and share the same fake file metadata
All the effort that Ursnif’s operators have put into their mechanism for delivery, appears to have paid off and been well worth it. When this dropper was first uploaded to VT (slightly after we had prevented it in a customer environment) it was only detected by six out of 57 scanning vendors. This case highlights how threat actors are using increasingly sophisticated techniques to ensure that their malware is not detected and that analysis post-detection is much more complicated.
Dropper, prevented and investigated sample
Similar droppers from threat intel data