A few months ago, we blogged about the banking trojan Retefe (Blog post in German) that was and still is targeting Switzerland. First off, Retefe is different because it only targets Switzerland, Austria and Sweden (and sometimes Japan). Contrast this to many other banking Trojans, which have a much more global and dynamic target list. Not only that, but the Retefe infrastructure also prevents computers from not affected countries to connect to its systems by using geo-location aware access lists and filters. The second unique property of Retefe is the fact, that it only modifies the operating system by adding a fake root certificate and by changing the DNS server for domain name resolution. After infection, the installer removes itself, which makes life hard for anti-virus software trying to detect a malicious Retefe component or activity.
Since a few days, Retefe is back again with a new twist. It still targets the same countries and the same banks. Not too exciting, the spam campaign has changed. However, in this wave Retefe is picky and only installs itself on selected computers. And some icing to the cake, it also installs another malware called DOFOIL. In this blog post, we give a technical analysis of the new Retefe.
Infection Vector
As in previous campaigns, Retefe is still spreading through spam e-Mails. The e-Mail sender is spoofed and the e-Mail body tries to convince the victim to open the attached file. In previous campaigns, Rich-Text-Format (RTF) files with an embedded Control Panel (CPL) file where used. On the one hand, using an embedded CPL file within a RTF file is a clever way of avoiding detection by many sandboxes and anti-virus solutions. On the other hand, users learned at least to some extend, not to click on Windows Executable (EXE) files. But what could possibly go wrong with an RTF file and a strange embedded object (CPL) file. Eventually, many users clicked on the object icon in the RTF document and infected the computer with the malware. The current campaign uses a similar approach but instead relies on an obfuscated Javascript file.
Sample e-Mail with the malicious attachment:
Opening the Javascript file will in most cases open the default web browser on the operating system. Looking at the Javascript file in a text editor leaves you in the dark:
The file, however, is easily de-obfuscated, revealing the following readable code:
The Javascript code not surprisingly downloads the Retefe installer (exrxerxewrxwe.exe), saves it in the %TEMP% directory and then executes the installer.
System Modifications
The Retefe installer does most system modifications by using PowerShell commands:
Collect all web browser cookies from Internet Explorer and store them into a temporary file:
Then check all web browser cookie-stores (in our case Mozilla Firefox, Internet Explorer, Google Chrome) for persistent cookies of a targeted bank:
If, and only if, such a cookie is found will the installer attempt to manipulate the system. Otherwise, it leaves the system alone and jumps right to phase two, described below. This is a crucial difference to previous campaigns where the system modifications happened in all cases. Now, they only happen for users who have visited a targeted bank in the past, i.e. are likely to be a customer of an affected bank.
The system modifications consist still of a fake root certificate that is added to the certificate store. The current fake root certificate has the serial number 00:D8:8C:95:23:2D:17:8B:E0 and the following Issuer and Subject names and validity period:
Note that the there is also a valid VeriSign Class 3 Public Primary Certification Authority – G5 certificate although with a different validity period and serial number.
More interesting, this time Retefe does not change DNS name servers anymore but instead adds an automatic proxy URL to all web browsers. For Internet Explorer and the global operating system settings, the configuration setting looks like:
The proxy.pac file contains rules, which define how a web browser can automatically choose the appropriate proxy server for a given domain or URL pattern. The first proxy.pac file, which we have seen, were plain readable Javascript. Meanwhile the attackers obfuscated this file too, using the same obfuscation algorithm as for the Rechnung.js file above.
Obfuscated proxy.pac file:
The de-obfuscated proxy.pac file contains a list of the targeted bank domain names again. If the victim surfs to one of these domains it will go through the specified SOCKS proxy.
De-Obfuscated proxy.pac file (Proxy IP address and target domain name changed):
Phase two: the DOFOIL Malware
We’re not done yet: Another very important difference to the previous Retefe campaigns happens now. The old Retefe did not install any software component and as a result had no update mechanism. The attackers simply ran another spam campaign if they needed more or refreshed infected clients. The new Retefe installs an additional malware called DOFOIL, which is the latest member of its malware family. The deployed version was recently discovered by Trend Micro. This malware is always installed regardless of any browser cookies. For details on DOFOIL see the Trend Micro blog post for more information on DOFOIL. Here we just summarize some important facts about DOFOIL: The binary is installed in the users %APPDATA% directory, and a registry RUN key (HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run) is created. It points to the installed executable for persistence during shutdown and reboot of the operating system. Furthermore, the malware is able to alter the operating system by downloading additional software and changing operating system settings.
Modus Operandi
All traffic aimed at the bank goes to the infrastructure of the attackers (Rogue Proxy & Webserver). The fake e-Banking website is an well crafted copy of the original website. The differences to the original are very subtle and hard to spot, even for experts. Most users will just login to the fake e-Banking website and thus provide their login credentials to the attacker. For most banks, the fake e-Banking website will also ask for the second authentication token. This token will then be used by the attacker to login on the real e-Banking website, in real-time. In case the attacker also requires a transaction code for the fraud payment, the user is held in a waiting loop and prompted to enter a new token a few seconds later. If the bank happens to use mTAN-SMS as second authentication token, the fake e-Banking website will ask the user to install a mobile malware instead. A download link to the malware is sent to the users mobile phone after they provided their phone number. It’s of course suspicious that the download link points to a file outside the official app stores (e.g. Google Play for Android). However, the social engineering works and most users will trust the fake bank website and proceed with the installation as requested by the installation guide on the fake website.
Modus Operandi of Retefe
Defense and Protection
SWITCH-CERT monitors the Swiss university and education network for infections and informs affected organizations. In collaboration with the big ISPs in Switzerland we try to prevent infections from happening and also block communication to malicious servers. This has worked very well for Switzerland in the past and hopefully again for this variation. If you are concerned that your computer is infected, we encourage users to check their PCs with the free tools provided by the Swiss Internet Security Alliance.
As a DNSSEC advocate, I also want to mention that the current fraud schema used by Retefe could be detected and prevented by the use of DNSSEC. For this to work, the bank would need to sign their e-Banking domain name and also make use of DANE. With DANE you can validate X.509 certificates tied to TLS using DNSSEC lookups (TLSA record). The bank could publish a TLSA record to create TLS certificate pinning for its web server certificates. A client system needs to use a validating DNSSEC resolver. Already 23% of Swiss Internet users do so that according to measurements by APNIC. However, the web browser also needs to validate the TLSA record. Bummer: Today no web browser does this out of the box. Installing a web browser add on such as the DNSSEC/TLSA Validator from nic.cz gets TLSA validation into the web browser. For interested readers we have several articles about DNSSEC, which give more details about the topic:. Have a look at the category DNS & DNSSEC for some posts of the past.
Filed under: E-Banking, Malware Tagged: Bankentrojaner, E-Banking, Malware, Retefe