Subscribe to get the latest updates and resources
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.
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:
– The obfuscation command.
– After de-obfuscated VBA.
The dropper uses a COM object technique to conceal the parent process trail.
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:
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.
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”:
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.
‘hxxps://images2.imgbox.com/d8/0e/eyGVup7s_o[.]png’
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:
“hxxtps://i.postimg.cc/mbBH51RX/cry[.]png?d1=1”
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 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.
Search results for:
