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: incidents[at]govcert{dot}chGeneral inquiries: outreach[at]govcert{dot}ch
The following email address can be considered as point of contact for FIRST members and other CERTs/CSIRTs:incidents[at]govcert{dot}ch
GovCERT.ch PGP-Key (preferred) Alternative GovCERT.ch PGP Key (for older versions of PGP without Curve25519 support) GovCERT.ch SMIME
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: 184ec697c4151e8d90734e3d9a639b4c8d134825 This binary is also clearly marked as Retefe on VirusTotal: VirusTotal Link
184ec697c4151e8d90734e3d9a639b4c8d134825
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.
sub_7FF7313713A0
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.
F2
F9
RBX
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).
script
ESC
loc_7FF731371413
F4
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
a
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: break else: thestring += chr(b) ea += 1 with open(file_, 'wb') as w: w.write(thestring)
To use the above script, we press ALT + F7 and select the before created script export.py.
ALT + F7
export.py
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.
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.
eval
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.
print
$ 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:
output.js
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