During our research on the Winnti group we discovered a considerable amount of Winnti samples targeting different gaming companies. Using this sophisticated malicious program cybercriminals gained remote access to infected workstations and then carried out further activity manually.

Naturally, we were keen to find out how the malicious libraries spread across a local network. To do so, we tracked the attackers- activity on an infected computer.

1^st attempt: virtual machine #1

At the beginning of the investigation we ran the malicious programs on a virtual machine, which worked fairly well - we even spotted some cybercriminal activity. But they quickly realized it wasn-t a computer they wanted to net. Once that was the case, the attackers- servers stopped responding to requests from bots working on virtual machines.

This is what we managed to learn at this stage of our monitoring.

First of all, the perpetrators looked at what was happening on the victim-s desktop. After that they enabled the remote command line and used it to browse the root folder of the current disk, searched for the file winmm.dll, and checked the operating system version. The ListFileManager plugin then came into play. It works with the file system and the attackers used it to browse the folders C:\Windows and C:\Work. Then they tried to restart the computer, but made a mistake in the parameters of the ?shutdown� command, having typed ?shutdown /t /r 1� (the computer should have been restarted in 1 second), but after a while they shut the computer down completely with the use of the correct command ?shutdown /s /t 1�.

We�ve recently experienced yet another case of a root certificate authority (CA from now on) losing control of its own certificates. And yet again, we have been waiting for either the CA or the browser to do something about it. This whole mess stems, once again, from both a governance and a technical problem. First, only the very same CA that issued a certificate can later revoke it. Second, although web browsers implement several techniques to check the certificate�s revocation status, errors in the procedure are rarely considered hard failures.

How easy is it for bad guys to buy valid digital certificates from CAs using fake data and then start signing Trojan bankers with them? In Brazil it appears to be very easy.

Today most software developers digitally sign their programs. The process involves Certification Authorities (CAs) that must verify the authenticity of the files and issue a certificate to the developers.

As we know, valid or stolen digital certificates are used by some malware authors to create files that can go undetected for some time and be recognized as legitimate. Now Brazilian cybercriminals have started using this technique in their malware in an attempt to gain more time to spread files undetected. Recently we found a Trojan banker signed with a valid digital certificate issued by a CA. It appears that fake company data was used to obtain the certificate.

How easy is it for a CA to check if the data they receive is legitimate or not? Brazilian cybercriminals registered a domain called gastecnology.org, copying the name of a well-known and trusted local software company. This is the data used to register the domain:

In our FAQ on Flame posted on May 28, 2012, we postulated there might be a still undiscovered zero-day vulnerability in Flame:

“At the moment, we haven’t seen use of any 0-days; however, the worm is known to have infected fully-patched Windows 7 systems through the network, which might indicate the presence of a high risk 0-day.”

Our suspicion was heightened because fully patched Windows 7 machines were being infected over the network in a very suspicious manner.

We can now confirm this is the main purpose of a special module of Flame called “Gadget” together with another module called “Munch”.

(NOTE: It’s important to understand that the initial Flame infection could still be happening through zero-day vulnerabilities. The “Gadget” module is simply used to spread within a network from a machine that is already infected with the malware).

The “Gadget” and “Munch” modules implement an interesting man-in-the-middle attack against other computers in a network.

When a machine tries to connect to Microsoft’s Windows Update, it redirects the connection through an infected machine and it sends a fake, malicious Windows Update to the client.

The fake update claims to be the following:

“update description="Allows you to display gadgets on your desktop."
displayName="Desktop Gadget Platform" name="WindowsGadgetPlatform">

In the process of infecting a client, 8 CAB files are used. One of them contains a specifically built program called WuSetupV.exe:

This program (also detected as Worm.Win32.Flame.a), which is 28KB in size, has been signed by a fake Microsoft certificate:

This allows it to run in the victim’s machine without any warnings.

The Flame “Gadget” downloader was compiled on December 27th, 2010. It was signed on December 28 and it was finally put into the CAB archive on Jan 11, 2011.

The following is exactly how the process occurs: the infected machine sets up a fake server by the name “MSHOME-F3BE293C”, which hosts a script that serves a full body of the Flame malware to victim machines. This is done by the module called “Munch”.

When a victim updates itself via Windows Update, the query is intercepted and the fake update is pushed. The fake update proceeds to download the main body and infect the computer.

Gadget plugin downloads the main body of the malware

The interception of the query to the official Windows Update (the man-in-the-middle attack) is done by announcing the infected machine as a proxy for the domain. This is done via WPAD. To get infected, the machines do need however to have their System Proxy settings configured to “Auto”.

As we continue our investigation of Flame, more and more details appear which indicate our initial statement: this is one of the most interesting and complex malicious programs we have ever seen.

Important information: One June 4th, 2012, Microsoft released a number of blog posts and an Update for Windows which is blocking three fraudulent certificates used by Flame. We recommend that Windows users apply this update immediately.

Microsoft SRD blog:http://blogs.technet.com/b/srd/archive/2012/06/03/microsoft-certification-authority-signing-certificates-added-to-the-untrusted-certificate-store.aspx

Microsoft security advisory 2718704:http://technet.microsoft.com/en-us/security/advisory/2718704

MSRC blog:http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-releases-security-advisory-2718704.aspx

Post was updated 19.03.2012 (see below)

In the last few days a malicious program has been discovered with a valid signature. The malware is a 32- or 64-bit dropper that is detected by Kaspersky Lab as Trojan-Dropper.Win32.Mediyes or Trojan-Dropper.Win64.Mediyes respectively.

Numerous dropper files have been identified that were signed on various dates between December 2011 and 7 March 2012. In all those cases a certificate was used that was issued for the Swiss company Conpavi AG. The company is known to work with Swiss government agencies such as municipalities and cantons.

Information about the Trojan-Dropper.Win32.Mediyes digital signature

A very important “internet trust” discussion is underway that has been hidden behind closed doors for years and in part, still is. While the Comodo , Diginotar, and Verisign Certificate Authority breaches forced discussion and action into the open, this time, this “dissolution of trust” discussion trigger seems to have been volunteered by Trustwave's policy clarification, and followup discussions on Mozilla's bugzilla tracking and mozilla.dev.security.policy .

The issue at hand is the willful issuance of subordinate CAs from trusted roots for 'managing encrypted traffic', used for MitM eavesdropping, or wiretapping, of SSL/TLS encrypted communications. In other words, individuals attempting to communicate over twitter, gmail, facebook, their banking website, and other sensitive sites with their browser may have their secure communications unknowingly sniffed - even their browser or applications are fooled. An active marketplace of hardware devices has been developed and built up around tapping these communications. In certain lawful situations, this may be argued as legitimate, as with certain known DLP solutions within corporations. But even then, there are other ways for corporate organizations to implement DLP. Why even have CA's if their trust is so easily co-opted? And the arbitrary issuance of these certificates without proper oversight or auditing in light of browser (and other software implemented in many servers and on desktops, like NSS ) vendor policies is at the heart of the matter. Should browser, OS and server software vendors continue to extend trust to these Certificate Authorities when the CA’s activities conflict with the software vendors’ CA policies?

In this webcast, Kaspersky Lab senior security researcher Roel Schouwenberg talks about the Diginotar certificate authority breach and the implications for trust on the Internet. Schouwenberg also provides a key suggestion for all major Web browser vendors.

Dutch Certificate Authority KPN/Getronics has announced the suspension of the issuance of digital certificates.

The reason for this is that a breach has been discovered on a KPN web server related to PKI. The attack dates back no less than four years.

KPN, best known for its telecom business, acquired Getronics four years ago. Former Getronics has a certificate authority similar to Diginotar. Like Diginotar, KPN is allowed to issue 'special' certificates for the Dutch government and public services. In fact, many organizations affected by the Diginotar incident switched to KPN certificates.

The SSL PKI has been in use and implemented for 15 years now to secure online communications. From its initial proprosals and immediate growth, the need for secured online communications has been met with challenges. The infrastructure and protocol itself is showing signs of wear, with multiple attacks and corrections to the scheme itself. And in its 15th year, an alternative to the Cerificate Authority infrastructure is finally being given some competition with the release and debate around Convergence, an open source alternative to the current system of Certificate Authorities. Feel free to right click and download for the full sized version; the graphic below provides a list of some of the major events for SSL/TLS PKI in the past 15 years.

Our investigation and research of Duqu malware continues. In our previous report, we made two points:

• there are more drivers than it was previously thought;
• it is possible that there are additional modules.

Besides those key points, we concluded that unlike the massive Stuxnet infections, Duqu attacks are limited to an extremely small number of targets.

But before informing you about our new findings, I would like to pay tribute to the Hungarian research laboratory Crysys for their work. They were the first who analyzed Duqu components and generated an excellent report. It was later provided to antivirus vendors and became the basis of further investigations. (Unfortunately, our company was not the first to receive this report, but now it's even more interesting to find out everything about Duqu)

Our experts continue to conduct in-depth analysis of all Duqu components, and are finding more evidence of similarities between Duqu and Stuxnet. A detailed report with our experts' analysis of files and their structure is in progress and will be published later. This part of our research is not the most urgent. It is much more important to understand the details of the attacks and the facts, which will be discussed here.