Official Blog

Leaked Accounts

Published on 2017-08-29 08:00:00 UTC by (permalink)
Last updated on 2017-08-29 08:00:00 UTC

MELANI/GovCERT has been informed about potentially leaked accounts that are in danger of being abused. MELANI/GovCERT provides a tool for checking whether your account might be affected:

We would like to give some technical information about the tool:

  • We only transfer a SHA256 hash that is created on the client side using JavaScript. Thus we don't know the queried eMail addresses or account name.
  • No eMail addresses or account names are stored on the server, just the hashes.
  • All traffic is being transferred using SSL/TLS.

If we get additional eMail addresses or account names from other sources, we are going to update the database and inform about it using this blog and Twitter. If you have any technical questions, do not hesitate to contact us at outreach [at] govcert [dot] ch or via Twitter:


Q: Why do we use Cloudflare?
A: We considered the risk of DDoS attacks to be very high. Cloudflare is an experienced DDoS mitigation provider. We decided to use a DDoS mitigation provider, not only for the protection of the tool itself, but also for the ISP where our server is located.

Q: Does that mean that the server is located in an US cloud?
A: No, the server with the hashes is located in Switzerland. We just use Cloudflares network for DDoS mitigation. The IP address you see, when doing a lookup is the front-end server in the cloudflare network. This server does not store any data, but passes the requests to our backend system.

Q: Who does have access to the actual eMail addresses or account names?
A: No one except us. The eMail addresses and account names provided to us, are not on the server. We just stored the hashes on the server. Only hashes are transferred from the client to server. If you enter the eMail address or account name, it is immediately hashed on the client side and never stored.

Q: Why can’t I search for a whole domain or with a wildcard?
A: We did not store eMail addresses or account names on the system, only hashes. This makes a wildcard search impossible by design. Apart from that, we have privacy concerns, if one can basically have a look at all eMail addresses or account names. If a provider or organization would like to have a search for a whole domain, we can do that offline. Please provide some proof that you are really responsible for the domain.

Q: Why did you do this? Why did you not just pass the information to a site like
A: We were not in the position to pass the raw data to another organization.

Q: For how long did you know about this data?
A: We received the dataset last week.

Q: What else do you have to say?
A: Always use good passwords (long enough), choose different passwords for every account, use a 2 factor authentication whenever possible.

Share on Twitter Share on Facebook

The Retefe Saga

Published on 2017-08-03 11:15:00 UTC by (permalink)
Last updated on 2017-08-03 11:20:26 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)

Share on Twitter Share on Facebook

Notes About The NotPetya Ransomware

Published on 2017-06-28 00:00:00 UTC by (permalink)
Last updated on 2017-06-28 09:03:43 UTC

NotPetya Ransomware

A new ransomware, currently named NotPetya, has begun spreading yesterday. There are many victims, especially in Ukraine, but also large companies have been hit hard such as Maersk or Merck. There are infections in Switzerland as well. As many others we have analyzed the malware and tried to harden evidence about its functioning. As there are many good papers already published, we do not want to repeat all these things but to highlight a few important facts that now can be considered being hardened evidence. [1], [2], [3]

What is NotPetya?

NotPetya is a ransomware that has some familiarity with Petya/Misha that has hit the Internet starting 2016. What was special about Petya was the fact that Petya did encrypt the Master Boot Record. This is only possible with appropriate permissions. If these were not available, the other part of this malware family took over, Misha, which did a normal file encryption.

What is so special with NotPetya / How does it spread?

NotPetya behaves similar in the way it encrypts the computer (MBR) but it also encrypts files directly. What is new and why it is not just another version of Petya is the way it can spread further. The attackers have built in several ways how the malware can propagate in an internal network:

  • Using the vulnerability already known from WannaCry (EternalBlue, MS17-010) [4]
  • Using wmic or psexec and accessing admin shares ($ shares). It enumerates the local network and tries to infect other devices.
  • The malware has the ability to dump credential hashes (LSA Dump) in order to get credentials [5].

Especially the second vector makes NotPetya worse than WannaCry as no actual vulnerability is being exploited. Even though there are possible precautionary measures that would have made an infection less likely, the second attack vector makes it much harder to protect against this threat. The initial infection vector is not yet confirmed. There are however indications that the first infection vector could have been an email or a compromised update server of an Ukrainian firm distributing the malware. However this is unconfirmed and must be treated with caution [5].

What actions did MELANI take?

MELANI did inform its constituency, the National Critical Infrastructures, 27th in the afternoon and provided them with a regularly updated stream of information about how the malware works. As always with such outbreaks, there is a lot of information swirling around that needs to be checked.

What is the impact of NotPetya in Switzerland?

We have been informed by several companies based in Switzerland that they have been hit by the malware. Currently we do not see a larger distribution as we have had in the past with other malware waves such as Locky or Cerber.

How can I protect myself?

Apart from the usual ransomware protection - please see: MELANI Recommendations - and the measures we proposed in the blog post about WannaCry (see: GovCERT Blog ), the following countermeasures can be applied:

Is there a kill switch?

There is a possibility to stop the malware from infecting a device via the wmic/psexec vector by placing a file in the Windows directory [6]: A file named perfc.dat (or just perfc) must be placed in %windir% (e.g. c:windows). You should alter its permission to be read-only. This however does only protect machines that are not yet infected and it does only work with the NotPetya version that has been spreading yesterday. Please note that this is not a "killswitch" such as with WannaCry but more of a vaccination of a device that must be done locally and for every device in a network. Here is the relevant code snippet in pseudo code from IDA:

int __stdcall sub_10008320(LPWSTR pszDest)
  signed int v1; // esi@1
  const WCHAR *v2; // eax@1
  LPWSTR v3; // eax@2

  v1 = 0;
  v2 = PathFindFileNameW(&pszPath);
  if ( PathCombineW(pszDest, L"C:Windows", v2) )
    v3 = PathFindExtensionW(pszDest);
    if ( v3 )
      *v3 = 0;
      v1 = 1;
  return v1;

Other protection measures?

  • A more thorough approach for blocking the spreading via psexec / wmic is to apply AppLocker settings that stop users from starting remote processes. Please take care as - depending on your environment - this might have unwanted side-effects.
  • Another approach is using a GPO to block administrative shares (e.g. c$). This would stop this threat as well as other threats. But as with the other countermeasures, this is likely to have side effects.
  • If not yet done, patch MS17-010 immediately!

Detection possibilities for enterprises?

There are a few detection possibilities:

  • The malware is quite noisy when it comes to networking activity. Therefore it is possible to have an internal IDS/IPS to listen for ARP requests that enumerate the subnet and to disconnect the source of these requests from the network. Again, take care as this can have side effects.
  • If you monitor your Windows Event Logs, a newly infected device can be spotted easily as the malware erases the Eventlog using wevtutil. If you see wevutil erasing all event logs on a system, this is a good trigger that could be used to disconnect the affected device from the network and/or remove it from the domain.

Notes about paying the ransom

We generally recommend never paying a ransom as this only fuels the "criminal industry" with additional funds. In this case, it is not even possible to contact the attackers any more as posteo took down the contact email address being displayed in the ransom note.



Share on Twitter Share on Facebook

Back to top