Reversing Retefe

Published on 2018-11-08 09:20:00 UTC by (permalink)

Reversing Retefe


Approximately one year ago, we have published our blog post The Retefe Saga. Not much has changed since last year except that we have seen a rise of malspam runs in the last couple of weeks and we want to use the opportunity to show how to reverse engineer the Retefe malware.

Let's start with a graph of the Retefe malspam runs, we have seen the past 3 years. Apart from a few weeks, Retefe has been hitting Switzerland with malspam waves several times a week. On the right hand side of the diagram, you can see the companies from which the attackers have impersonated the brands to lure innocent users into opening the documents attached or clicking on links.

Retefe Timeline
Retefe Timeline

But Retefe is not only targeting eBanking customers in Switzerland but also in Liechtenstein, Austria and Norway, using localized malspam themes to motivate recipients of such malspam emails to open the attachment and infect themselves with Retefe.

Modus Operandi

Let’s explain briefly the modus operandi and the infrastructure elements of Retefe after the client infection:

  1. If the victim wants to connect to a eBanking website, the client is redirected through TOR to the fraudster eBanking portal.
  2. After the victim has entered the eBanking credentials, the website displays a download link to an Android app (if necessary for the login) for the second factor which will be used to complete the login sequence.
  3. The fraudster grabs the entered credentials.
  4. The fraudster uses the entered credentials to set up a session to the victims bank and issues a payment to a specific account

Retefe Modus Operandi
Modus Operandi

Reversing the Binary

Retefe is usually delivered by a malicious Microsoft Word document with Macros, which downloads and executes an x64 binary. In this blog post we focus on the downloaded executable.

We will analyze a Retefe sample with the following SHA-1 hash:
This binary is also clearly marked as Retefe on VirusTotal:
VirusTotal Link


Let's start directly in IDA Pro, which initially shows the entry point of the malware sample:

Entry Point
Entry Point

As we walk through the first part of the assembly code, we see a call to a function named sub_7FF7313713A0 (highlighted in the screenshot above). Double-clicking on this function brings us to the next screenshot which is already the most important part of this binary.


An XOR operation on a memory location inside a loop is often indicative of interesting data being decrypted. This is why we set a breakpoint F2 at this exact position in IDA. So let's give it a try and start the debugger with F9. The debugger will stop as expected at the breakpoint. Next we earmark the memory location which is deciphered in the loop: we jump to RBX (this can be different in your case) using the registers window and we add a marker ALT + m in the IDA disassembly window.


Mark Position
Mark Position

Enter mark description
Enter mark description

We have named the marker script, because we would like to know what will be at this exact position after the XOR decryption routine. Now we can go back to the graph view ESC, remove the breakpoint F2, place the cursor after the decryption routine loc_7FF731371413 and press F4 (Run to cursor).

Remove Breakpoint
Remove XOR Breakpoint

We can now assume that the XOR encrypted code is decrypted and located at the position we have marked before. The easiest way to check this assumption is to jump to the marked position, which we called script. Just press CTRL + m and select script. This will lead us directly to the decrypted code, after we converted it to an ASCII string (press a):

JavaScript Code
JavaScript Code

This looks very promising and seems to be JavaScript code. We could now select the whole script and remove the obsolete characters or we can use a small Python script to extract all characters of the JavaScript:

ea = ScreenEA()
file_ = AskFile(1, "*.*", 'output file')
thestring = ""
while True:
    b = Byte(ea)
    if not b:
        thestring += chr(b)
    ea += 1

with open(file_, 'wb') as w:

To use the above script, we press ALT + F7 and select the before created script

This concludes the work done in IDA Pro. After deciphering the JavaScript, the executable will run the code with a built in JavaScript scripting engine and terminate. In the next section we analyze the JavaScript.

Debugging JavaScript

There are many tools for debugging JavaScript, most notably web browsers. For Retefe we are going to use rhino as a script interpreter.
Before we start the script with rhino we will have a look at the JavaScript. A quick glance shows us a function called eval, which is always suspicious and usually means, that the code is obfuscated. Retefe uses AES encryption to hide its code from signature based detection and simple analysis.

Cracking the obfuscation is trivial though: We can replace the eval function with a simple print and run the code with rhino in a unix environment. We also pipe the result to js-beautify to get a nicely formatted JavaScript.

$ rhino exported.js | js-beautify -d | sed 's/\"\ +\ \"//g' > output.js

If we open the output.js in a text editor, we see a lot of useful information.
Some interesting parts of the script are listed below:

Code snippetDescription
["sanitized1.onion", "sanitized2.onion"]TOR communication domains
this.InstallCert = function()Installing a root certificate
String.format("{0}.js?ip={1}"Setting a proxy pac
if (muilangs == 'en-US')Checking the MUI language of the OS -> This is interesting, because only non en-US systems will be infected!

You could further decode the base64 encoded parts with the unix command

$ echo "BASE64CODE" | base64 -d

and you would see even more! For example a socks (socat) installation, a TOR client installation, some FTP connections, the certificate (COMODO) itself and much more.


We tried to show you an easy way to manually reverse engineer a Retefe binary. Retefe serves as an excellent case study for people who would like to use IDA for the first time.
All the information we have found in the binary by reversing it, can also be easily extracted automatically by simply brute-forcing the XOR key in the executable and scripting the Linux commands.

Share on Twitter Share on Facebook

Back to top