The Retefe Saga

Published on August 3, 2017 11:15 UTC by (permalink)
Last updated on August 3, 2017 11:20 UTC

Surprisingly, there is a lot of media attention going on at the moment on a macOS malware called OSX/Dok. In the recent weeks, various anti-virus vendors and security researchers published blog posts on this threat, presenting their analysis and findings. While some findings where very interesting, others were misleading or simply wrong.

We don’t know where the sudden media interest and the attention from anti-virus vendors on this threat actor are coming from. As a matter of fact, the threat actor behind OSX/Dok, which we call the the Retefe gang or Operation Emmental, has already been around for many years and is tracking their activities since the very beginning (2013). The purpose of this blog post is to put the puzzle pieces together and trying to bust some of the myths that have made the round in the media recently.

Timeline of Retefe Threat (aka Operation Emmental)
Timeline of Retefe Threat (aka Operation Emmental)

Jul 2013 - The early days (Citadel)

The first sign of this threat actor dates back to July 2013, when we identified a malware campaign that was targeting various financial institutions in Switzerland, using an e-banking trojan called Citadel (BotnetID 504 + 510). Citadel is a crimeware kit and a successor of the famous ZeuS Trojan. The malware campaign was usually easy identifiable as the threat actor was always using the same URL structure.

Sample Citadel config URLs:

Sample Citadel dropzone URLs:

Sample Citadel botnet C&C traffic to a config URL
Sample Citadel botnet C&C traffic to a config URL

Citadel was very active between 2010 and 2014. However, after its highs in 2014, most of the cybercriminals turned away from Citadel to other crimeware kits. So did the Retefe gang - the said Citadel campaign disappeared in 2014.

Jun 2014 - Moving forward (Retefe)

In 2014, a few months after Citadel disappeared, a spam campaign hit the Swiss cyberspace. The spam emails pretends to come from well-known Swiss online brands, such as or Zalando, and contain a malicious RTF (Rich Text Format) file. The malicious RTF file contained an embedded windows executable (either a .cpl or .exe file) that, once executed, infected the victim’s machine with malware. The malware was new to us; we have never seen such code before. We could not link it to an existing crimeware kit, so it appeared to be a custom development. Microsoft later named the malware Retefe (we guess because of the way Retefe spreads: a malicious RTF – ReTeFe). Retefe was born!

During our technical analysis, we identified a list of financial institutions in Switzerland for which Retefe redirects the e-banking session to a counterfeit portal. This target-list is identical to the one we have already seen in the Citadel campaigns in 2013 and early 2014. Due to this and the fact that Citadel suddenly disappeared just a few months before the first sign of Retefe, we believe that the same threat actor is behind these two malware campaigns. The gang just moved away from Citadel to a different malware family (as many other cybercriminals did).

What makes Retefe a very interesting piece of malware is the fact that it is not necessarily malware. Unlike Citadel and other malware families, Retefe "just" changes certain settings of the victim’s computer in a hostile way. Hence, most anti-virus software is not able to detect Retefe because the malware is not using any malicious code. In 2014, Retefe changed the following computer settings in order to commit e-banking fraud:

  • Changes the computers DNS settings to make use of a rogue DNS server.
  • Installs a rogue CA (Certificate Authority) certificate.

While this sounds trivial, these changes are very effective and have a big influence on the victim’s surf experience. As the threat actor has now control over the victim’s domain resolution, they can redirect the victim’s e-banking session to a fraudulent copy of the e-banking portal operated by the threat actor. The attacker also issues a SSL certificate using the rogue CA certificate installed on the victim’s computer to avoid that the victim’s web browser (e.g, Firefox, Internet Explorer, or Chrome) throws an SSL certificate error when browsing the fake e-banking portal.

While this modus operandi is very simple and effective, it also has a significant weak point: the rogue DNS. If the rogue DNS disappears, the attacker is not only no longer able to redirect the e-banking session to the forged portal, the victim will de facto also lose the internet connectivity as the computer won’t be able to resolve any domain names anymore. So every time we initiated the takedown of the rogue DNS servers, Retefe victims lost their internet connectivity.

In 2015, the threat actor fixed this “issue” by making use of a malicious proxy auto-config (PAC) in lieu of a rogue DNS. Instead of redirecting the whole DNS traffic of the victim’s computer, only web traffic for certain domain names configured in the PAC published by the attackers would get redirected to a SOCKS proxy. The SOCKS proxy then serves a fake e-banking portal to the victim in order to commit e-banking fraud.

Sample of proxy PAC configuration in Internet Explorer (2014)
Sample of proxy PAC configuration in Internet Explorer (2014)

At that time, Retefe was targeting not only financial institutions in Switzerland but also in Austria, Sweden and Japan. Based on the Geo location of the victim’s IP address, the Proxy PAC URL returned a different proxy configuration. If the victim’s IP address was located in Austria for example, the proxy configuration contained a list of financial institution in Austria for which the e-banking sessions were redirected.

Dec 2015 - The Tinba connection

It was October 2015, when we saw the usual Retefe spam campaigns imitating and Zalando. However, when we analysed the malware that was distributed, we quickly came to the conclusion that it was not Retefe. We identified the malware as Tinba (also known as Tiny Banker). Unlike Retefe, Tinba is another crimeware kit like Citadel. Many threat actors who were using Citadel until 2014 later moved to Tinba. Taking a look at the Tinba configuration file, we noticed that it contained the same target-list as Retefe. Due to this and the fact that the spam campaign that was distributing Tinba at that time was the same as we have seen before distributing Retefe, we believe that this was the same threat actor again.

The Tinba campaign, identified by Campaign ID 946a936b (Version ID: 1b030105), was using a domain generation algorithm (DGA) to calculate a list of possible botnet command and control (C&C) domain names. While using a DGA makes the botnet more resilient against take downs from law enforcement agencies, it also has the disadvantage for the threat actor that security researchers can reverse engineer the code used to generate the DGA domains and predict all possible botnet C&C domains. Sinkhole data revealed that a vast amount of the computers infected with Tinba were indeed located in Switzerland.

Sample Tinba botnet C&C traffic to DGA domain
Sample Tinba botnet C&C traffic to DGA domain

Jan 2016 - Trying something new (ExePhish)

Early 2016, we have seen another spam campaign hitting the Swiss cyberspace. The campaign was weird and apparently only targeting customers of one specific financial institution. The spam emails contained an executable (MD5 d770040d2bf4c12c9dc8fd1bfc23bc9b) that, once executed, opened window that looked like a web browser. The fake “web browser” displayed a counterfeit e-banking portal hosted in the tor network ( We believe that this campaign was orchestrated by the Retefe gang too. However, we have only seen this threat once and we believe it was just an (unsuccessful) test by the threat actor. A nice write-up can be found here.

Feb 2016 – Retefe goes social engineering

But the Retefe Gang is not just using email as an infection vector to compromise their victims. In February 2016, we have received multiple reports from small and medium-sized businesses (SMBs) in Switzerland who got phoned by strangers, pretending, for example, to call e.g. in the name of the Swiss Post. The calling person tried to gain the victim’s email address under a false pretence (e.g. that a postal package couldn’t be delivered and the postal service would like to send further information by email to the victim). If the victim revealed his email address, he would receive an email from the threat actor with a link to Dropbox that served Retefe.

More Information about this modus operandi can be found here (in German, French and Italian):

Mar 2016 - Retefe goes VPN

In March 2016, the Retefe gang tried something new. Instead of using a rogue DNS server or PAC file to redirect e-banking traffic of the victim’s machine, the threat actor started to spam out a version of Retefe that installed a VPN (PPP) connection to a remote host under control of the miscreant (sample: MD5 6abad08fd5d534ae9f5659989c1e0e31). As a result, all internet traffic from the victim’s machine got redirected to a VPN server in Russia ( The threat actor also installed a rogue CA certificate in order to commit e-banking fraud. As the spam campaign was themed as the usual Retefe spam mails, we link this campaign to the Retefe gang.

Like Tinba and ExePhish, this campaign didn’t last long and the threat actor switched back to Retefe again after a handful of days.

April 2017 – Retefe goes MacOS

Going after Windows users apparently wasn’t enough for the Retefe gang. In April 2017, Swiss internet users have seen weird emails hitting their inboxes. Unlike the usual spam emails that clutter internet user’s inboxes every day, these emails weren’t demanding anything from the user: The email didn’t contain any links or attachments the user could click on. However, a short analysis revealed that these emails contained HTML code that would orchestrate the mail client of the recipient to load a tiny 1x1 pixel image from a remote server. In that URL, the recipient’s email address was transmitted to the remote server. By this, the sender of these emails could not only determine whether the recipient’s email address existed but also track what web browser and operating system the recipient has been using.

The purpose of these tracking emails was unknown, until a large spam campaign has hit Switzerland. What was interesting about this spam campaign was that not all recipients received the same payload: Some received a malicious word with an embedded Java- or PowerShell-script (that turned out to be Retefe), others received a Zip-Archive that turned out to be a - drum roll please - MacOS app. Analysing the macOS app confirmed our assumption: It’s a version of Retefe for mac! The very first version we saw, however, has been a Python based RAT called Bella. Shortly afterwards, we saw the typical Retefe elements also in the macOS variant: The macOS App (also known as OSX/Dok) uses social engineering to convince the victim to enter his administrator password, pretending to be a macOS update. If the victim does so, Retefe will download and install certain components (such as a Socat and Tor) using Homebrew. It uses shell scripts to change the computers settings to make use of a PAC file and to drop a rogue certificate. The onion domains used for proxy auto-configuration and redirecting the traffic are hardcoded in the binary, slightly obfuscated by XOR (the current key is 0xFF).

Retefe infecting MacOS (pretending to be a MacOS update)
Retefe infecting MacOS (pretending to be a MacOS update)

MacOS has a security mechanism in place, that only allows Apps to run, which have been signed with a valid code signing certificate (Developer ID) issued by Apple. However, it seems not to be a problem for the threat actor to get such a Developer ID.

codesign -dv --verbose=4
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=479 flags=0x0(none) hashes=17+3 location=embedded
Hash type=sha1 size=20
CandidateCDHash sha1=d5ddda4165784a16384d2e430de08c2b3b4b9a20
Hash choices=sha1
Page size=4096
Signature size=8522
Authority=Developer ID Application: Efe Idemudie (8R5DFRN5PA)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=11.07.2017, 19:08:34
Info.plist entries=24
Sealed Resources version=2 rules=12 files=5
Internal requirements count=1 size=176

Please notice that the Developer ID used by the Retefe gang to sign the malware changes frequently to avoid Apple’s revocation mechanism (as we usually report those to Apple, once we see new Developer IDs).

Retefe on Android

Recently, some anti-virus companies and newspapers reported that Retefe is distributing the Signal App (a secure messenger). Rumours say that the threat actor may use the Signal App as a communication channel with the victim. This is not the case. As a matter of fact, the Signal App is just decoy that the Retefe Gang serves to IP addresses who are not geo located in Switzerland and whose user agent does not correspond to an Android device. If the accessing IP address uses an Android user agent and is geographically located in Switzerland, the APK server will serve an Android trojan that the Retefe gang use to commit e-banking fraud.

The trojan is an SMS stealer which allows the threat actor to steal text messages sent by the bank to the customer for two factor authentication (2FA) and transaction signing (so called mobile TAN or mTAN). To have the victim install the android trojan, the Retefe gang uses social engineering to convince the victim to either enter his mobile phone number where he then receives an SMS from the threat actor with a link to the Android APK, or to scan a QR code displayed by the threat actor in the fake e-banking portal, which also leads to the Android APK. But the Android trojan is more than just an SMS stealer. It is also able to send text messages to other victim’s and uses a sophisticated anti VM detection technique. Unlike Retefe itself, which doesn’t have any botnet C&C channel, the SMS stealer has such one. It uses two hard coded botnet C&Cs which are usually hosted on compromised websites, for example:




As documented, this threat actor has already been around for more than four years. While their tools have changed in the past years, their goal remains the same: committing e-banking fraud in Switzerland and Austria. Their recent expansion to macOS shows that Mac users are not safe from such threats.

The Retefe botnet isn’t big: It usually consists out of 100 – 300 infected computers, while Retefe redirects between 10 and 90 e-banking sessions every day. However, it is apparently big enough to generate enough “income” for the attackers. Otherwise the campaign wouldn’t have lasted for more than four years now.

Number of victims (IPs) whose e-banking sessions got redirected in the past days
Number of victims (IPs) whose e-banking sessions got redirected in the past days

Further reading e-Banking Trojan Retefe still spreading in Switzerland:

SWITCH-CERT: Retefe Bankentrojaner:

2nd part of Tinba Malware analysis: The APK side:

CheckPoint: OSX Malware is Catching Up, and it wants to Read Your HTTPS Traffic (updated):

CheckPoint: OSX/Dok Refuses to Go Away and It’s After Your Money:

Trend Micro: Finding Holes: Operation Emmental:

Linking Retefe to OSX.dok:

F-Secure: Retefe Banking Trojan Targets Both Windows And Mac Users:

Indicator Of Compromise (IOC)

Following an incomplete list of Retefe IOCs

Citadel (2013 - 2015)

Retefe Proxy PAC URLs (2014 – 2016)

Retefe Android malware domains (2014 – 2016)

Retefe Android App MD5 hashes (2014 – 2016)


Retefe Android App botnet C&Cs (2014 – 2016)

Retefe MacOS MD5 hashes (2017)


Back to top