Recently published blog posts:
Go to the blog archive and browse all previous blog posts
we have published so far.
Subscribe to the GovCERT.ch blog RSS feed to stay up to
date and get notified about new blog posts.
Recently published whitepapers:
Subscribe to the whitepapers RSS feed to stay up to date
and get notified about new whitepapers.
Report an incident:
The following email address can be considered as point of
contact for FIRST members and other
Alternative GovCERT.ch PGP Key (for older versions of PGP without Curve25519 support)
Published on November 8, 2018 09:20 UTC by GovCERT.ch (permalink)
Last updated on November 8, 2018 09:20 UTC
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.
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.
Let’s explain briefly the modus operandi and the infrastructure elements of Retefe after the client infection:
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:
Let's start directly in IDA Pro, which initially shows the entry point of the malware sample:
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.
ALT + m
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).
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):
CTRL + m
ea = ScreenEA()
file_ = AskFile(1, "*.*", 'output file')
thestring = ""
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 export.py.
ALT + F7
$ 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:
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.
Back to top