APT (Targeted attacks)

Earlier today, we received an interesting collection of samples from colleagues at another anti-malware company. The samples are especially interesting because they contain a module with the following string: C:ShamoonArabianGulfwiperreleasewiper.pdb Of course, the ‘wiper’ reference immediately reminds us of the Iranian computer-wiping incidents from April 2012 that led to the discovery of Flame. The malware

There are many remaining mysteries in the Gauss and Flame stories. For instance, how do people get infected with the malware? Or, what is the purpose of the uniquely named “Palida Narrow” font that Gauss installs?
Perhaps the most interesting mystery is Gauss’ encrypted warhead. Gauss contains a module named “UsbDisk” that features an encrypted payload. The malware tries to decrypt this payload using several strings from the system and, upon success, executes it. Despite our best efforts, we were unable to break the encryption. So today we are presenting all the available information about the payload in the hope that someone can find a solution and unlock its secrets. We are asking anyone interested in cryptology and mathematics to join us in solving the mystery and extracting the hidden payload.

After the publication of our whitepaper about the Gauss cyber-attack, we have been asked if there is an easy way for users to check their system for infection. Of course the most reliable way is to download and install our antivirus solution, but if someone needs to double-check or for some reason cannot download full antivirus package, we offer a quick and easy way to check for the presence of Gauss component.

While analyzing the Flame malware that we detected in May 2012, Kaspersky Lab experts identified some distinguishing features of Flame’s modules.

Gauss is the most recent cyber-surveillance operation in the Stuxnet, Duqu and Flame saga. It was probably created in mid-2011 and deployed for the first time in August-September 2011. Gauss was discovered during the course of the ongoing effort initiated by the International Telecommunications Union (ITU), following the discovery of Flame, which is part of a sustained effort to mitigate the risk posed by cyber-weapons.

On 17 July, we published a blog about Madi. Here is the follow up with a detailed analysis of the infostealer used in the campaign.

The Madi infrastructure performs its surveillance operations and communications with a simple implementation as well. Five command and control (C2) web servers are currently up and running Microsoft IIS v7.0 web server along with exposed Microsoft Terminal service for RDP access, all maintaining identical copies of the server manager software. These servers also act as the stolen data drops. The stolen data seems to be poorly organized on the server side, requiring multiple operators to log in and investigate the data per each of the compromised systems that they are managing over time. This post will explore the Madi infrastructure, communications, data collection, and victims.

Last night, we received a new version of the #Madi malware, which we previously covered in our blog.

Following the shutdown of the Madi command and control domains last week, we thought the operation is now dead. Looks like we were wrong.

The new version appears to have been compiled on July 25th.

For almost a year, an ongoing campaign to infiltrate computer systems throughout the Middle East has targeted individuals across Iran, Israel, Afghanistan and others scattered across the globe.
Together with our partner, Seculert, we’ve thoroughly investigated this operation and named it the “Madi Campaign”, based on certain strings and handles used by the attackers.

On July 3rd, we’ve noticed a new APT campaign entitled “Dalai Lama’s birthday on July 6 to be low-key affair”

Two days ago we intercepted a new APT campaign using a new MacOS X backdoor variant targeted at Uyghur activists. The application is actually a new, mostly undetected version of the MaControl backdoor (Universal Binary), which supports both i386 and PowerPC Macs.

Deep inside one of Stuxnet’s configuration blocks, a certain 8 bytes variable holds a number which, if read as a date, points to June 24th, 2012. This is actually the date when Stuxnet’s LNK replication sub-routines (https://securelist.com/myrtus-and-guava-episode-1/29614/) stop working and the worm stops infecting USB memory sticks.

Two weeks ago, when we announced the discovery of the Flame malware we said that we saw no strong similarity between its code and programming style with that of the Tilded platform (https://securelist.com/stuxnetduqu-the-evolution-of-drivers/36462/) which Stuxnet and Duqu are based on.

The Flame malware uses several methods to replicate itself. The most interesting one is the use of the Microsoft Windows Update service.

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