Malspam campaigns, short for malicious spam campaigns, represent a prevalent form of cyber threat that involves the distribution of harmful emails on a large scale. We’ve often seen malicious files in the form of .exe, .docx. .pdf and even .ISO armed up with malicious code with an intent to break into systems to gain access to information that is often used for monetary gain.
Today, we will explore a threat that, while initially taking a unique form, has now become a prevailing constant in our present day. We’ll be taking a dive into analyzing ‘Retefe’ a .js based Windows Banking Trojan.
Retefe possesses the ability to utilize Windows PowerShell to not only download and implant additional malware onto the system but also to aid attackers in extracting credentials for online banking portals. Its primary objective revolves around supporting attackers in pilfering credentials from online banking websites, with a particular focus on targeting Swiss banks. The malware’s binary code primarily functions as a dropper component, designed to construct a VBA file. This VBA file subsequently loads multiple tools onto the compromised host, including 7zip and TOR. Through the installation of a new root certificate, the VBA file enables the rerouting of all traffic through TOR to a host controlled by the attacker, thereby effectively facilitating a Man-in-the-Middle (MITM) attack on TLS traffic.
So let’s start…
The sample we are going to analyze today has the MD5 hash value - “49cdc811243fcf399d826aa3c813f7c7”.
We open the .js file in a text editor of choice. As we open the file we see JS code but we can see that there’s an eval present. In .JS, eval() method evaluates or executes an argument. If the argument is an expression, eval() evaluates the expression.
Windows Script Host or WScript provides an environment in which users can execute scripts in various languages that use various object models to perform tasks. So yes .JS, VBS files can be executed in windows using it’s built-in interpreter.
So here instead of eval() we replace it with WScript.echo() which will echo the output instead of running the malicious file in our VM.
we run this .js script using cscript.exe via cmd or powershell in our windows VM (do not run this on your host machine!!!)
Once the file is run we see an another eval() function.
So we pipe this out to another js file and do the same by replacing eval() with WScript.echo(). And, we see another eval.
Doing the same again! But this time the result is different and luckily we now see JS code. So lets pipe it to another file and beautify it using CyberChef or any other tool you want.
So now as we start to take a look at the code we see multiple variables. We see some base64 strings and most importantly 4 .onion domains. As we already know that this Trojan has the capability of routing the traffic over TOR these 4 domains do make sense to us.
We see functions making API calls to services like ipify.org & icanhazip.com in order to get the victim’s IP address and other such info.
Furthermore, we see code snippets where base64 strings are being decoded by a function. We can decode these strings ourselves to get an idea of what the attacker intends to do with this decode.
We can see below that these base64 strings decode to registry paths.
Coming back to the top where we saw 4 domains and more base64 strings. We decode these base64 strings in order to get the obfuscated code.
So after decoding the string for the ‘cert’ variable it was looking like it’s some kind of a TLS certificate that this trojan writes to the disk and installs in order to perform MITM on the TLS traffic in order to steal victim’s credit card or other sensitive info.
Furthermore, as we go on analyzing the code and decoding the base64 strings we see VB script responsible for installing the certificate onto the victim’s host.
Analyzing further we see powershell code responsible for routing the traffic via TOR.
The above code downloads the TOR package and an unofficial build of socat from github for facilitating transfer of data to attacker controller machines over TOR.
And, lastly we see a function that uploads log files to a remote FTP server with HARDCODED CREDENTIALS present in the code.
There are many other interesting functions and code blobs responsible for making changes in the registry for persistence. Further analysis can show other artifacts related to the infection on the victim’s host.
Retefe uses base64 encoding and decoding subroutines in order to obfuscate the code to a certain level. While Retefe’s distribution has a limited global footprint, its attacks are strategically focused on online banking customers within select countries. The latest campaign highlights a concerning trend: Retefe’s potential expansion to impact users in other nations, as it leverages its infections to introduce supplementary malware.
I hope it was fun, until next time!
