Opera Breach – When Cybercriminals take on Targeted Attacks

On June 26 2013, browser manufacturer Opera announced that they had been breached as a result of a targeted attack against their infrastructure. However, this was no ordinary targeted attack. The attackers in this case weren't looking to steal intellectual property. They wanted to use Opera's auto-update mechanism in order to propagate a piece of malware normally associated with financial Trojans.

When attackers breached the Opera network sometime around June 19 2013, they first stole an expired Opera code signing certificate to sign a piece of malware. Signing the malware allowed them to distribute it via Opera's auto-update mechanism. Users would receive the malware as part of a browser update. The malware in question is Downloader.Ponik, a downloader Trojan typically used to propagate cybercrime-related malware, such as financial Trojans and infostealers.

Opera, in their statement, estimates that a few thousand users may have automatically received the malware sometime between 01:00 and 01:36. Opera spotted the breach and were able to halt any further propagation of the malware. As the attackers only had a small window in which to operate they had limited success. Had they had more prolonged access to the Opera network they would have been much more successful. Or would they?

Had the attackers had access to the Opera servers for a longer period they would have been able to propagate their malware to a much larger number of users. However, such an attack would be very noisy, drawing the attention of security companies who would quickly provide protection and lead a concerted effort to take down command-and-control (C&C) servers. All of this would render the malware effectively useless. This is reminiscent of Conficker, a threat which spread to millions of computers and was due to trigger a payload on April 1, 2009. However, by that time, security organizations and hosting providers had worked together to take control of the C&C servers. The threat was being so closely monitored that the attackers were unable to leverage it.

When attackers try aggressive propagation methods they become victims of their own success. For now this attack has been neutralized. Opera recommends that users update their browsers as proactive measure against further attacks. Symantec provides protection for this as Downloader.Ponik. We also recommend that users who think they may have been affected reset their passwords.

Trojan.Tatanarg.B Careful!

There was a recent report on the Opera forums that users were encountering strange certificate behavior when visiting particular services over secured network connections, specifically HTTPS. This occurred while using online banking, webmail services, and social networking sites. Upon further investigation, we discovered a Trojan was intercepting the HTTPS connections, namely Trojan.Tatanarg.B.

Trojan.Tatanarg.B works by installing a proxy in the browser to intercept HTTPS connections by providing its own self-signed certificate to users, in effect revealing all the encrypted traffic between the user and the secure service. The Trojan specifically targets Firefox, Opera, Maxthon, and Internet Explorer. Once the proxy is installed the attacker can sniff important details, make changes to the traffic on the fly, and in most cases this is pretty transparent to the user, depending on which browser you are using.

Figure 1. Opera gives the user the clearest indication that something is afoot

Infection Vector

We are aware of two methods that Trojan.Tatanarg.B is using to install itself. The first method is through an Exploit Kit—one of which we have identified as BlackHole. This can be used as part of a drive-by-download or through a spear-phishing email.

The other method is through an email with a malicious attachment. Here is an example email sent on May 17 that originated from a Russian mail server containing a Trojan that downloads Trojan.Tatanarg.B.

Figure 2. Example email sent May 17


Trojan Tatanarg.B is made up of two main components: a back door component and a proxy component. The components are stored on disk, compressed with bzip2, and XOR encrypted.

The back door component (CommuniFork.dll) has the following functionality:

  • Install botnet module (and other modules using module IDs)
  • Setup autorun scripts and query existing autorun scripts
  • Browse files on the compromised computer
  • Collect system information
  • Connect to a remote location
  • Download and execute additional files
  • Get bot ID
  • Load a module
  • Modify a Web browser home page
  • Remotely stop and start the server or client
  • Run a Web browser
  • Run shellcode
  • Start the back door component as a server or client
  • Store bot-provided URLs in the registry

The proxy component (CeptorFork.dll) intercepts traffic over HTTP and HTTPS using the self-signed certificate to sniff the HTTPS traffic.


Tatanarg.B, unlike the infamous Trojan.Zbot (Zeus), has a far more targeted client base. This is probably for a few reasons. For one, anyone can get their hands on the Zeus source code if they know where to look for it to configure and distribute it, whereas Tatanarg.B appears to be created from a single source, which we can identify from the debug strings found in the various .dll components.

Figure 3. Infections of Tatanarg.B are present in Scandinavia, Germany, the Netherlands, and Italy


Compile Time Debug String
Aug. 2011   X:\fbi\x27\Work\prj\svnmain\Projects\mr.lyle2\CeptorFork\Release\CeptorFork.pdb
Sep. 2011 X:\fbi\x27\Work\prj\svnmain\Projects\mr.lyle\CommuniFork\Release\CommuniFork.pdb
Nov. 2011 C:\projects\astbase\mr.lyle2\CeptorFork\Release\CeptorFork.pdb
Jan. 2012   C:\projects\astbase\mr.lyle2\CommuniFork\Release\CommuniFork.pdb
Apr. 2012 C:\projects\astbase\Projects\HermesCore\Release\HermesCore.pdb

Examining the debug strings, the ‘svmmain’ string suggests that the project is an ongoing development and that the author uses version control. The author has also updated the main communication module from CommuniFork to HermesCore.

This Trojan has been around since at least early 2011, and the recent wave of infections and the longevity of the Trojan indicate that it remains a profitable enterprise for the author, who continues to develop and target users in Europe. Rest assured that we will continue to monitor developments.

Mac App Store exposes users to security risks, claims researcher

The Mac App Store's current version of OperaIf you are using the Apple Mac App Store you might be putting your computer’s security at risk.

That’s the finding of security researcher Joshua Long who has warned that the App Store has not published the latest versions of various applications, despite the fact they can include critical security updates.

Here’s part of Long’s warning:

Third-party Web browser maker Opera has released version 11.11 of its software, which fixes a "critical" security issue.

Mac users who have downloaded Opera through the App Store may find themselves using a copy of Opera that is now two versions old, 11.01, which was released back in March and is vulnerable to the security bug patched in 11.11.

Users who rely on the App Store to tell them whether their software is up-to-date may not be aware of the security risks and may continue to use an unsafe version of the Opera browser.

Opera on the Mac App Store

Long says that he contacted Apple and Opera about the issue. Opera replied saying that they were waiting on Apple to approve the next version of Opera for Mac (Apple’s approval is necessary before anything gets posted in the Mac App Store).

Apple's promotion of App Store updatesPut in simple terms, Apple seems to be falling short of the promise it makes in its promotion of the App Store that it “keeps track of your apps and tells you when an update is available” and that “you’ll always have the latest version of every app you own.”

And, it appears, that Opera is not the only application in the Mac App Store that is out-of-date and might be vulnerable to security flaws. Long points out that Amazon’s Kindle app in the App Store, for instance, hasn’t been updated since January.

So, the key question is, how quickly is Apple going to approve the latest Opera update, and other software which might have been updated to secure against critical security vulnerabilities, for the App Store?

Because if Apple can’t update software containing critical security patches to the App Store in a timely fashion, users might be wiser getting their software via a more conventional route – such as (in the case of Opera) a direct download from the vendor’s own website.