Email
YouTube
Twitter
Reddit
DETAILS
This analysis covers the initial infection vector for URSNIF Banking Trojan and how we can defeat obfuscation and its anti-sandbox technique. This analysis will not cover the URSNIF Trojan itself.
We start by examining the javascript file and discover that it is heavily obfuscated. Using a Notepad++ addon called “JStool” helps to format the Javascript from it’s minified version, but will not remove the obfuscation.
It is important to note that this javascript file is not meant for inclusion in a web page. This .JS file would most likely be sent as an attachment with an inticing name in an email for the end user to double click. In order to debug this file we will use the following command to launch our Just In Time debugger and step through the code:
Once inside the debugger we locate a common instruction near the end of the code execution flow and set a breakpoint. We then run the file to this point and inspect the local variables. We see that the .JS file is about to download an executable named S3BzHNmoZ.exe. Advancing one step will download the file to our %TEMP% directory. We can then copy that file out of the directory before the next instruction in the .JS file launches it.
Inspecting the downloaded EXE we don’t see too many strings for hints. This means the file is packed or obfuscated in some way. Considering there are numerous imports and many decoding routines within the binary we can conclude that the strings are deobfuscated at runtime.
Attempting to run the EXE dynamically inside of a sandbox results in an infinite loop, but running the file outside of the sandbox results in a full infection. This is curious behavior and leads us to investigate what anti-sandbox routine this file is utilizing to perform these actions.
Attaching a debugger to the EXE and returning to user code reveals the loop we are stuck in. Opening the EXE in IDAPro and navigating to the address in question reveals an anti-sandbox routine which checks for the amount of processes running. It does so by calling the FindWindow API and checking for the non-existent window "gggg". The malware will then iterate over all the processes in view searching for the "gggg" window title. If all processes are iterated through and the window is not found, the malware will make sure that the total number of processes it searched through is greater than a desired amount. If the total number is less, then the loop will continue indefinitely.
This is easily patched by calculating the offset of the comparison in the file and NOPing (0x90) the instruction (in our case the address is 0x0040198f). Binary editing the EXE to ignore this comparison allows the file to fully run in a sandbox environment.
Once fully running, the EXE will deobfuscate an additional EXE stub into a new section of memory. Code execution is carried out by this new section of memory and shortly after injects additional code into svchost.exe. The Ursnif Trojan will now run in the context of svchost.exe and beacon to its C&C server using the following network GET requests (note the .AVI video file extension on the GET Request. This is typical C&C Communication for URSNIF):
The main controller contacted after infection was 217.182.73.92:443
We start by examining the javascript file and discover that it is heavily obfuscated. Using a Notepad++ addon called “JStool” helps to format the Javascript from it’s minified version, but will not remove the obfuscation.
It is important to note that this javascript file is not meant for inclusion in a web page. This .JS file would most likely be sent as an attachment with an inticing name in an email for the end user to double click. In order to debug this file we will use the following command to launch our Just In Time debugger and step through the code:
Once inside the debugger we locate a common instruction near the end of the code execution flow and set a breakpoint. We then run the file to this point and inspect the local variables. We see that the .JS file is about to download an executable named S3BzHNmoZ.exe. Advancing one step will download the file to our %TEMP% directory. We can then copy that file out of the directory before the next instruction in the .JS file launches it.
Inspecting the downloaded EXE we don’t see too many strings for hints. This means the file is packed or obfuscated in some way. Considering there are numerous imports and many decoding routines within the binary we can conclude that the strings are deobfuscated at runtime.
Attempting to run the EXE dynamically inside of a sandbox results in an infinite loop, but running the file outside of the sandbox results in a full infection. This is curious behavior and leads us to investigate what anti-sandbox routine this file is utilizing to perform these actions.
Attaching a debugger to the EXE and returning to user code reveals the loop we are stuck in. Opening the EXE in IDAPro and navigating to the address in question reveals an anti-sandbox routine which checks for the amount of processes running. It does so by calling the FindWindow API and checking for the non-existent window "gggg". The malware will then iterate over all the processes in view searching for the "gggg" window title. If all processes are iterated through and the window is not found, the malware will make sure that the total number of processes it searched through is greater than a desired amount. If the total number is less, then the loop will continue indefinitely.
This is easily patched by calculating the offset of the comparison in the file and NOPing (0x90) the instruction (in our case the address is 0x0040198f). Binary editing the EXE to ignore this comparison allows the file to fully run in a sandbox environment.
Once fully running, the EXE will deobfuscate an additional EXE stub into a new section of memory. Code execution is carried out by this new section of memory and shortly after injects additional code into svchost.exe. The Ursnif Trojan will now run in the context of svchost.exe and beacon to its C&C server using the following network GET requests (note the .AVI video file extension on the GET Request. This is typical C&C Communication for URSNIF):
CONCLUSION
This analysis covered the Javascript file which successfully downloads and launches the Ursnif trojan. The script and subsequent executable utilized obfuscation and an anti-sandbox technique to avoid analysis but both can be easily defeated with minimal reverse engineering.
Ursnif is a multi-faceted malware which has the capability to infect the host with spyware, ransomware, and backdoors. Be sure to double check any file that is sent to you via email. You may get more than you bargain for.
Ursnif is a multi-faceted malware which has the capability to infect the host with spyware, ransomware, and backdoors. Be sure to double check any file that is sent to you via email. You may get more than you bargain for.