Over the course of the last few months, we at Cynet labs have encountered multiple occurrences of the Ursnif banking trojan. Our encounters were mostly in the context of attacks on Italian companies, but they bear high similarity to other Ursnif instances worldwide.
Ursnif is one of the most active trojans worldwide and is mostly focused on stealing banking, cloud storage and email account credentials. While its initial source code was leaked as early as 2013, it gains increasing popularity as well as sophistication of delivery method.
Ursnif is typically delivered by phishing emails, weaponized with Office documents containing malicious macros that invoke a complicated, fileless delivery chain to drop and execute the Ursnif payload, while evading detection of endpoint security measures.
In this blog, we’ll provide a short overview on the common Ursnif components, as well as a new variant we’ve recently discovered which features an interesting bypass of Windows native protections.
Ursnif Main Components
The Ursnif trojan utilizes various techniques to compromise the environment and steal sensitive information and credentials. These are the components we’ve identified in all the instances we examined:
- Obfuscation techniques – advanced ways to break into the system in order to evade AV vendors.
- “Onion replace”
- The following images hide another PowerShell stage.
– The obfuscation command.
- Dropper- its purpose is to download the payload to the compromised environment.
- Macro files
- VBA files
– After de-obfuscated VBA.
The dropper uses a COM object technique to conceal the parent process trail.
- Injection techniques – allows inject code into the address space of the running process.
- APC injection
Recently, we have discovered a new Ursnif variant using a new technique to bypass AMSI:
“The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and services to integrate with any antimalware product present on a machine. AMSI provides enhanced malware protection for your end-users and their data, applications, and workloads.”
The malicious activity process tree:
As we can see, the attack flow starts with “Outlook.exe” process, as we know the Ursnif distributes itself through attachment-weaponized emails that social-engineer the recipients to download and open the file. Logically, the following process is “EXCEL.exe,” and after that, “powershell.exe,” which is triggered by a malicious VBA code in the Excel document and executes an obfuscated command that drops the payload to the endpoint:
Obfuscation First layer
The malicious PowerShell command is highly obfuscated by several techniques escaping character (`), base64 encoder and string formatting operator (-f). After de-obfuscation of the first stage of the attack, we discovered another obfuscation command.
Obfuscation Second Layer
The attacker uses the “iex” (Invoke-Expression) command to execute the malicious command and then hides it by taking the “I “ Character in index 4 and “e” from index 34 and adding the “x”:
Obfuscation Third Layer
The third stage of the obfuscation PowerShell command is very long, so we will divide it into two parts:
In the first part of the code, we can see the following command: “([Environment]::OSVersion.Version.Major -ne ’10’).” This command checks the operation system version, if the result is not equal to Windows 10, it will execute the first part of the code, if it is equal to Windows 10, it will execute the second part of the code.
The first part:
Here we can see the obfuscation techniques that we mentioned above, for example the string formatting operator (-f).
After de-obfuscation and beautification, it appears as follows:
The image hides another PowerShell stage leveraging steganography techniques.
The second part of the malicious code will execute only if the operation system version is equal to Windows 10. This is where the AMSI bypass takes place.
Again, we see a highly obfuscated code. The $y variable contains an array that will load by “[Reflection.Assembly]::Load([byte]$y)|Out-Null”. After further investigation, we can conclude that this variable loads an MZ (executable) file to the memory:
From our initial investigation into the ‘fp()’ function, we discovered the following content:
The ‘pf()’ function downloads another image from the following URL:
In the image, we further detected an encoded malicious command containing a few more stages of obfuscation. After an additional de-obfuscation, we saw there is an additional check for Italian localization and if it is indeed a device based in Italy, there is an attempt to download the Ursnif payload.
Cynet vs. Ursnif Trojan
Cynet can block the execution of Ursnif with three different modules, with no need to rely on signatures:
The Ursnif trojan campaign still distributes itself through phishing email worldwide. While the samples we tested at Cynet Labs feature intense modifications, none succeeded in bypassing Cynet’s protection.