SWITCH Security-Blog

SWITCH-CERT IT-Security Blog


Why the most successful Retefe spam campaign never paid off

Switzerland is one of the main targets of the Retefe banking trojan since its first appearance in November 2013. At that time, it changed the local DNS resolver on the computer (See also blog post “Retefe Bankentrojaner” in German only). Almost a year went by until they changed to the still current approach of setting a proxy auto-config (PAC) URL (See also blog post “The Retefe banking Trojan has targeted Switzerland“). To understand the story of this blog post, it helps to understand the modus operandi of the Retefe malware. We recommend you read up on it on our blog links posted above if you are not familiar with it.

While the Retefe actors are constantly changing tactics, for example their newest campaigns also target Mac OS X users, their malware still works the same. One of notable changes was the introduction of Tor in 2016. At first, they started using Tor gateway domain names such as onion.to, onion.link within the proxy auto-config URLs, later on they switched to Tor completely. The advantage of using Tor is of course, anonymity and the difficulty to block or take down the infrastructure.

Onion domain names don’t use DNS or do they?
The Tor network can use .onion domain names but these names are not resolved over DNS but instead work only in the Tor network. RFC 7686 (The “.onion” Special-Use Domain Name) goes into more details on the special case of .onion domain names. However, the fact is that .onion domain names do leak into the DNS system. For potential reasons and more information on this subject we recommend the paper by Versign Labs “Measuring the Leakage of Onion at the Root” (PDF).
Continue reading


A file that wasn’t there

One of our minions (he was introduced in this blog entry a while ago) recently came to us asking for advice: he was about to automate yet another task, by using his Python-fu, and realized that he misses entries in the file system as well as in the registry.

Notably, he only sees this behaviour on 64bit-versions of the Windows operating system:

Windows Explorer (64bit) vs Python application (32bit)

Left: Windows Explorer (64bit) lists several folders and files.   Right: Python application (32bit) only lists the folder Microsoft.

The left image shows the folder C:\Windows\System32\Tasks as seen in the Windows Explorer, the right image as seen in a simple 32bit-python application. Only the subfolder Microsoft is listed there. Something is amiss.

 

Below is the code to produce the right image, when executed in a 32bit-version of Python:

import glob, os
for pathfilename in glob.glob(r"C:\Windows\System32\Tasks\*"):
    print pathfilename

Continue reading


An attachment that wasn’t there

By Slavo Greminger and Oli Schacher

On a daily basis we collect tons of Spam emails, which we analyze for malicious content. Of course, this is not done manually by our thousands of minions, but automated using some Python-fu. Python is a programming language that comes with many libraries, making it easy for us to quickly perform such tasks.

Python’s email library deals with, well, emails. And it does it well. But on October 3rd, we encountered an attachment that wasn’t there – at least according to Python’s email library.

Mal-formatted email

Left: Outlook Web does not show the attachment          Right: Thunderbird does show the attachment

Now how could that happen?

Emails do have a certain structure, which is described nicely in RFC #822, RFC #2822, RFC #5322, RFC #2045, RFC #2046, RFC #2047, RFC #2049, RFC #2231, RFC #4288 and RFC #4289. Even though these RFC’s are clear in their own way, an illustration might help (we focus on multipart emails only) to understand why Python’s email library got fooled.

Continue reading


Protect your network with DNS Firewall

If you run your own mail server, you will quickly find out that 90% of the e-mails you receive are spam. The solution to this problem is e-mail filtering, which rejects or deletes unwanted spam. This solution is generally well accepted, and most users would not want the old days back when your inbox was filled with scams. Those people who want spam can also work around it by disabling spam filtering for their e-mail address or opting to run their own mail server.

Spam, scammers and other malicious abuse are not unique to e-mail. One possible approach is to invent a filtering technology for every protocol or service and allow the service owners to block misuse according to their policy. On the other hand, most services on the Internet make use of the Domain Name System (DNS). If you control DNS name resolution for your organisation, you can filter out the bad stuff the same way you filter out spam on e-mail. The difference and the advantage of DNS is that DNS filtering is independent of the service you use.

Back in 2010, ISC and Paul Vixie invented a technology called Response Policy Zones (RPZ) (See CircleID Post Taking back the DNS). While it has always been possible to block certain domain names from being resolved on your DNS resolver, adding host names manually as an authoritative zone does not scale.

(Illustration Christoph Frei)

(Illustration Christoph Frei)

Continue reading


Drive-by code and Phishing on Swiss websites in 2014

In 2014, about 1,800 Swiss websites were cleaned from drive-by code, compared with 2,700 in 2013, a decline of 33%. At the same time, the number of phishing cases affecting .ch and .li top-level domains rose from only a handful in 2013 to more than 300.

Drive-by code on Swiss websites in 2014

Last year, 35,796 suspicious drive-by URLs in the .ch and .li top-level domains were reported to SWITCH. Security experts from SWITCH-CERT automatically sent requests to these servers and analysed the responses, looking for malicious code injected into the HTML source code. When an expert identified malicious code, the registrar or domain name holder and the web hoster were notified and asked to remove it within one working day. This was done for 1,839 domain names in 2014. In 1,493 (81%) cases, the code was removed by the web hoster or domain holder within one day. For the other 346 domains, the deadline was not met, and the domain name was temporarily suspended to prevent further damage to website visitors. Some 264 (14%) of the infected websites were cleaned of malicious code, with the remaining 82 domain names having to be reactivated after five days, the maximum suspension time by law. A request for identification was sent to the holders of all 82 domains, resulting in an additional 59 (3.2%) of websites being cleaned. A total of 23 (1.3% of all notified) domain names were deleted after 30 days because the domain holder failed to respond to the identification request.

malware2015_E

Compromised .ch and .li websites used for drive-by infections by quarter

Continue reading


Retefe with a new twist

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.
Continue reading


4 Comments

Retefe Bankentrojaner

E-Banking ist seit seiner Entstehung ein attraktives Tummelfeld für Betrüger. Oft wird auf spezielle Schadsoftware, auf sogenannte Bankentrojaner, zurückgegriffen, um arglosen Opfern Geld abzuziehen.

Die meisten dieser Bankentrojaner basieren auf technisch betrachtet ziemlich komplexen Softwarekomponenten: Verschlüsselte Konfigurationen, Man-in-the-Browser-Funktionalität, Persistenz- und Updatemechanismen, um einige zu nennen. Im letzten halben Jahr hat sich eine gänzlich neue Variante behauptet, welche erst im Februar 2014 einen Namen erhielt: Retefe. Nur wenig wurde bis an hin publiziert, einer der Hauptgründe ist sicherlich, dass die Schadsoftware nur in wenigen Ländern (CH, AT, SE, JP) agiert und nur einige ausgewählte Banken angreift. TrendMicro (Blogartikel: Operation Emmental (DE), (EN)) und SWITCH-CERT möchten hiermit nun etwas detaillierter über diesen Trojaner berichten.

Das Besondere am Retefe Bankentrojaner ist seine Schlichtheit. Das infizierte System wird wie folgt manipuliert:

  1. Auf dem PC des Opfers wird der Eintrag des DNS-Servers auf einen bösartigen DNS-Server geändert.
  2. Auf dem PC des Opfers wird ein gefälschtes Root-Zertifikat installiert, siehe auch unser kürzlich veröffentlichten Blogartikel zu diesem Thema.

 

Nach der Infektion löscht sich die Installationsroutine selbst. Ausser dem manipulierten System bleibt nichts zurück, was es schwierig für Antiviren-Programme macht, im Nachhinein eine Infektion festzustellen.

An Eleganz ist diese Schadsoftware schwer zu übertreffen: Sie verzichtet auf die in der Einführung genannten Softwarekomponenten und minimiert damit die Komplexität. Es scheint auch, dass es aus Betrügersicht heutzutage ökonomischer ist, schlicht und einfach neue Opfer-PCs mittels Spam-Kampagnen zu infizieren.

Wie sieht der Modus Operandi konkret aus?

Modus Operandi eines möglichen Schadenfalls

Modus Operandi eines möglichen Schadenfalls

Continue reading