APT (Targeted attacks)

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

For the past weeks, Kaspersky Lab has been closely monitoring the C&C infrastructure of Flame.

As already mentioned in the previous blog post about Flame, the volume of its code and functionality are so great that it will take several months for a complete analysis. We’re planning on continually disclosing in our publications the most important and interesting details of its functionality as we reveal them.

Flame is a sophisticated attack toolkit, which is a lot more complex than Duqu. It is a backdoor, a Trojan, and it has worm-like features, allowing it to replicate in a local network and on removable media if it is commanded so by its master.

Late last week, we found evidence of a possible link between a Mac OS X backdoor trojan and an APT attack known as LuckyCat.

we can confirm yet another Mac malware in the wild – Backdoor.OSX.SabPub.a being spread through Java exploits.

This new threat is a custom OS X backdoor, which appears to have been designed for use in targeted attacks. After it is activated on an infected system, it connects to a remote website in typical C&C fashion to fetch instructions. The backdoor contains functionality to make screenshots of the user’s current session and execute commands on the infected machine.

At the end of the last year the authors of Duqu and Stuxnet tried to eliminate all traces of their activity. They wiped all servers that they used since 2009 or even earlier. The cleanup happened on October 20.

There were virtually no traces of Duqu since then. But several days ago our colleagues in Symantec announced that they found a new in-the-wild driver that is very similar to known Duqu drivers. Previous modifications of Duqu drivers were compiled on Nov 3 2010 and Oct 17 2011, and the new driver was compiled on Feb 23 2012.
So, the authors of Duqu are back after a 4 month break.