English
The Internet threat alert status is currently normal. At present, no major epidemics or other serious incidents have been recorded by Kaspersky Lab’s monitoring service. Internet threat level: 1
Latest posting
By rating
By popularity

Join our blog

You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.

Virus Watch|Agent.btz: a source of inspiration?

Aleks
Kaspersky Lab Expert
Posted March 12, 15:01  GMT
Tags: Botnets, Targeted Attacks, Cyber espionage
0.5
 

The past few days has seen an extensive discussion within the IT security industry about a cyberespionage campaign called Turla, aka Snake and Uroburos, which, according to G-DATA experts, may have been created by Russian special services.

One of the main conclusions also pointed out by research from BAE SYSTEMS, is a connection between the authors of Turla and those of another malicious program, known as Agent.BTZ, which infected the local networks of US military operations in the Middle East in 2008.

We first became aware of this targeted campaign in March 2013. This became apparent when we investigated an incident which involved a highly sophisticated rootkit. We called it the ‘Sun rootkit’, based on a filename used as a virtual file system: sunstore.dmp, also accessible as \\.\Sundrive1 and \\.\Sundrive2. The ‘Sun rootkit’ and Uroburos are the same.

We are still actively investigating Turla, and we believe it is far more complex and versatile than the already published materials suggest.

At this point, I would like to discuss the connection between Turla and Agent.btz in a little more detail.

Agent.btz: a global epidemic or a targeted attack?

The story of Agent.btz began back in 2007 and was extensively covered by the mass media in late 2008 when it was used to infect US military networks.

Here is what Wikipedia has to say about it: “The 2008 cyberattack on the United States was the ‘worst breach of U.S. military computers in history’. The defense against the attack was named ‘Operation Buckshot Yankee’. It led to the creation of the United States Cyber Command.

It started when a USB flash drive infected by a foreign intelligence agency was left in the parking lot of a Department of Defense facility at a base in the Middle East. It contained malicious code and was put into a USB port from a laptop computer that was attached to United States Central Command.

The Pentagon spent nearly 14 months cleaning the worm, named Agent.btz, from military networks. Agent.btz, a variant of the SillyFDC worm, has the ability ‘to scan computers for data, open backdoors, and send through those backdoors to a remote command and control server’.”

We do not know how accurate is the story with the USB flash drive left in the parking lot. We have also heard a number of other versions of this story, which may, or may not be right. However, the important fact here is that Agent.btz was a self replicating computer worm, not just a Trojan. Another important fact is that the malware has dozens of different variants.

We believe that the initial variants of the worm were created back in 2007. By 2011 a large number of its modifications had been detected. Today, most variants are detected by Kaspersky products as Worm.Win32.Orbina.

Curiously, in accordance with the naming convention used by PC Tools, the worm is also named Voronezh.1600 – possibly a reference to the mythical Voronezh school of hackers, in Russia.

In any event, it is quite obvious that the US military were not the only victims of the worm. Copying itself from one USB flash drive to another, it rapidly spread globally. Although no new variants of the malware have been created for several years and the vulnerability enabling the worm to launch from USB flash drives using “autorun.inf” have long since been closed in newer versions of Windows, according to our data Agent.btz was detected 13,832 times in 107 countries across the globe in 2013 alone!

The dynamics of the worm’s epidemic are also worth noting. Over three years – from 2011 to 2013 – the number of infections caused by Agent.btz steadily declined; however, the top 10 affected countries changed very little.

Agent.BTZ detections (unique users) 2011
1 Russian Federation 24111
2 Spain 9423
3 Italy 5560
4 Kazakhstan 4412
5 Germany 3186
6 Poland 3068
7 Latvia 2805
8 Lithuania 2016
9 United Kingdom 761
10 Ukraine 629
  Total countries 147
  Total users 63021


Agent.BTZ detections (unique users) 2012
1 Russian Federation 11211
2 Spain 5195
3 Italy 3052
4 Germany 2185
5 Kazakhstan 1929
6 Poland 1664
7 Latvia 1282
8 Lithuania 861
9 United Kingdom 335
10 Ukraine 263
  Total countries 130
  Total users 30923


Agent.BTZ detections (unique users) 2013
1 Russian Federation 4566
2 Spain 2687
3 Germany 1261
4 Italy 1067
5 Kazakhstan 868
6 Poland 752
7 Latvia 562
8 Lithuania 458
9 Portugal 157
10 United Kingdom 123
  Total countries 107
  Total users 13832


The statistics presented above are based on the following Kaspersky Anti-Virus verdicts: Worm.Win32.Autorun.j, Worm.Win32.Autorun.bsu, Worm.Win32.Autorun.bve, Trojan-Downloader.Win32.Agent.sxi, Worm.Win32.AutoRun.lqb, Trojan.Win32.Agent.bve, Worm.Win32.Orbina

To summarize the above, the Agent.btz worm has clearly spread all over the world, with Russia leading in terms of the number of infections for several years.



Map of infections caused by different modifications of “Agent.btz” in 2011-2013

For detailed information on the modus operandi of Agent.btz, I recommend reading an excellent report prepared by Sergey Shevchenko from ThreatExpert, back in November 2008.

On infected systems, the worm creates a file named ‘thumb.dd’ on all USB flash drives connected to the computer, using it to store a CAB file containing the following files: “winview.ocx”, “wmcache.nld” and “mswmpdat.tlb”. These files contain information about the infected system and the worm’s activity logs for that system. Essentially, “thumb.dd” is a container for data which is saved on the flash drive, unless it can be sent directly over the Internet to the C&C server.

If such a flash drive is inserted into another computer infected with Orbina, the file “thumb.dd” will be copied to the computer under the name “mssysmgr.ocx”.

Given this functionality and the global scale of the epidemic caused by the worm, we believe that there are tens of thousands of USB flash drives in the world containing files named “thumb.dd” created by Agent.btz at some point in time and containing information about systems infected by the worm.

Red October: a data collector?

Over one year ago, we analyzed dozens of modules used by Red October, an extremely sophisticated cyber espionage operation. While performing the analysis, we noticed that the list of files that a module named “USB Stealer” searches for on USB flash drives connected to infected computers included the names of files created by Agent.btz “mssysmgr.ocx” and “thumb.dd”.

This means that Red October developers were actively looking for data collected several years previously by Agent.btz. All the USB Stealer modules known to us were created in 2010-2011.

Both Red October and Agent.btz were, in all probability, created by Russian-speaking malware writers. One program “knew” about the files created by the other and tried to make use of them. Are these facts sufficient to conclude that there was a direct connection between the developers of the two malicious programs?

I believe they are not.

First and foremost, it should be noted that the fact that the file “thumb.dd” contains data from Agent.btz-infected systems was publicly known. It is not impossible that the developers of Red October, who must have been aware of the large number of infections caused by Agent.btz and of the fact that the worm had infected US military networks, simply tried to take advantage of other people’s work to collect additional data. It should also be remembered that Red October was a tool for highly targeted pinpoint attacks, whereas Agent.btz was a worm, by definition designed to spread uncontrollably and “collect” any data it could access.

Basically, any malware writer could add scanning of USB flash drives for “thumb.dd” files and the theft of those files to their Trojan functionality. Why not steal additional data without too much additional effort? However, decrypting the data stolen requires one other thing – the encryption key.

Agent.btz and Turla/Uroburos

The connection between Turla and Agent.btz is more direct, although not sufficiently so to conclude that the two programs have the same origin.

Turla uses the same file names as Agent.btz – “mswmpdat.tlb”, “winview.ocx” and “wmcache.nld” for its log files stored on infected systems.

All the overlapping file names are presented in the table below:

Agent.btz Red October Turla
Log files thumb.dd thumb.dd  
  winview.ocx   winview.ocx
  mssysmgr.ocx mssysmgr.ocx  
  wmcache.nld   wmcache.nld
  mswmpdat.tlb   mswmpdat.tlb
  fa.tmp   fa.tmp


In addition, Agent.btz and Turla use the same XOR key to encrypt their log files:

1dM3uu4j7Fw4sjnbcwlDqet4F7JyuUi4m5Imnxl1pzxI6
as80cbLnmz54cs5Ldn4ri3do5L6gs923HL34x2f5cvd0fk6c1a0s

The key is not a secret, either: it was discovered and published back in 2008 and anybody who had an interest in the Agent.btz story knew about the key. Is it possible that the developers of Turla decided to use somebody else’s key to encrypt their logs? We are as yet unable to determine at what point in time this particular key was adopted for Turla. It is present in the latest samples (dated 2013-2014), but according to some data the development of Turla began back in 2006 – before the earliest known variant of Agent.btz was created.

Red October and Turla

Now we have determined that Red October “knew” about the file names used by Agent.btz and searched for them. We have also determined that Turla used the same file names and encryption key as Agent.btz.

So what about a possible connection between Red October and Turla? Is there one? Having analyzed all the data at our disposal, we do not see any overlapping between the two projects. They do not “know” about each other, they do not communicate between themselves in any way, they are different in terms of their architecture and the technologies used.

The only thing they really have in common is that the developers of both Rocra and Turla appear to have Russian as their native language.

What about Flame?

Back in 2012, while analyzing Flame and its cousins Gauss and MiniFlame, we noticed some similarities between them and Agent.btz (Orbina). The first thing we noticed was the analogous naming convention applied, with a predominance of use of files with the .ocx extension. Let’s take as an example the name of the main module of Flame – “mssecmgr.ocx”. In Agent.btz a very similar name was used for the log-file container on the infected system – “mssysmgr.ocx”. And in Gauss all modules were in the form of files with names *.ocx.

Feature Flame Gauss
Encryption methods XOR XOR
Using USB as storage Yes (hub001.dat) Yes (.thumbs.db)


The Kurt/Godel module in Gauss contains the following functionality: when a drive contains a '.thumbs.db' file, its contents are read and checked for the magic number 0xEB397F2B. If found, the module creates %commonprogramfiles%\system\wabdat.dat and writes the data to this file, and then deletes the '.thumbs.db' file.

This is a container for data stolen by the 'dskapi' payload.

Besides, MiniFlame (module icsvnt32) also ‘knew’ about the ‘.thumbs.db’ file, and conducted a search for it on USB sticks.

If we recall how our data indicate that the development of both Flame and Gauss started back in 2008, it can’t be ruled out that the developers of these programs were well acquainted with the analysis of Agent.btz and possibly used some ideas taken from it in their development activities.

All together now

The data can be presented in the form of a diagram showing the interrelations among all the analyzed malicious programs:

As can be seen in the diagram, the developers of all three (even four, if we include Gauss) spy programs knew about Agent.btz, i.e., about how it works and what filenames it uses, and used that information either to directly adopt the functionality, ideas and even filename, or attempted to use the results of the work of Agent.btz.

Summarizing all the above, it is possible to regard Agent.btz as a certain starting point in the chain of creation of several different cyber-espionage projects. The well-publicized story of how US military networks were infected could have served as the model for new espionage programs having similar objectives, while its technologies were clearly studied in great detail by all interested parties. Were the people behind all these programs all the same? It’s possible, but the facts can’t prove it.

Comment      Link
0.4
 

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 which Stuxnet and Duqu are based on.

Flame and Tilded are completely different projects based on different architectures and each with their own distinct characteristics. For instance, Flame never uses system drivers, while Stuxnet and Duqu’s main method of loading modules for execution is via a kernel driver.

But it turns out we were wrong. Wrong, in that we believed Flame and Stuxnet were two unrelated projects.

Our research unearthed some previously unknown facts that completely transform the current view of how Stuxnet was created and its link with Flame.

The Flame inside Stuxnet

First of all, let’s recap the Stuxnet story. We managed to recover just three different variants of the worm, created in June 2009, and in March and April 2010.

The March 2010 variant was responsible for the greatest number of infections and was detected in June 2010 by specialists from the company VirusBlokAda in Belarus. This particular version was subjected to the most detailed analysis by anti-malware companies.

Shortly afterwards, when news of Stuxnet had already become widespread, files related to its June 2009 incarnation were detected. This version, the so-called Stuxnet.A (1.0), differed considerably from the 2010 variants.

The main differences were:

  • The 2009 variant didn’t use the MS10-046 LNK file vulnerability
  • In 2009, Stuxnet only had one driver file; in 2010 there were two (the second was added specifically to work with the LNK vulnerability)
  • In 2009, Stuxnet used a special trick with the “autorun.inf” file to infect USB drives.
All the other differences involve minor modifications to Stuxnet’s internal structure – some modules were deleted and their functions transferred to other modules.

The most significant of those changes involved “resource 207”.

Resource “207” is 520,192 bytes in size and can be found in the 2009 version of Stuxnet. It was later dropped altogether in the 2010 version, its code merged into other modules.

List of resources in the March 2010 variant of Stuxnet

List of resources in the 2009 variant of Stuxnet

Despite the fact that Stuxnet has been the subject of in-depth analysis by numerous companies and experts and lots has been written about its structure, for some reason, the mysterious “resource 207” from 2009 has gone largely unnoticed. But it turns out that this is the missing link between Flame and Stuxnet, two seemingly completely unrelated projects.

The Tocy story

In October 2010, our automatic system received a sample from the wild. It analyzed the file thoroughly and classified it as a new Stuxnet variant, Worm.Win32.Stuxnet.s.

With Stuxnet being such a big thing, we looked at the sample to see what it was! Sadly, it didn’t look like Stuxnet at all, it was quite different. So we decided to rename it to Tocy.a and thought “silly automatic systems!”.

When Flame was discovered in 2012, we started looking for older samples that we might have received. Between samples that looked almost identical to Flame, we found Tocy.a.

Going through the sample processing system logs, we noticed it was originally classified as Stuxnet. We thought, how was it possible? Why did the system think that this Flame sample was related to Stuxnet? Checking the logs, we discovered that the Tocy.a, an early module of Flame, was actually similar to “resource 207” from Stuxnet. It was actually so similar, that it made our automatic system classify it as Stuxnet. Practically, Tocy.a was similar to Stuxnet alone and to no other sample from our collection.

Going back to the story, this is how we discovered the incredible link between Flame and Stuxnet.

0.6
 

The Flame malware uses several methods to replicate itself. The most interesting one is the use of the Microsoft Windows Update service. This is implemented in Flame’s “SNACK”, “MUNCH” and “GADGET” modules. Being parts of Flame, these modules are easily reconfigurable. The behavior of these modules is controlled by Flame’s global registry, the database that contains thousands of configuration options.

SNACK: NBNS spoofing

The SNACK module creates a RAW network socket for either all or pre-set network interfaces and begins receiving all network packets. It looks for NBNS packets of other machines looking for local network names. When such a packet is received, it is written to an encrypted log file (“%windir%\temp\~DEB93D.tmp”) and passed on for further processing.

When a name in the NBNS request matches the expression “wpad*” or “MSHOME-F3BE293C”, it responds with its own IP address. If “SNACK.USE_ATTACK_LIST” variable is set to “True”, it also checks whether packets originate from IP addresses specified in its “SNACK.ATTACK_LIST” and responds to machines with these addresses.

“Wpad” is a name used for automatic proxy detection. By responding to “wpad” name requests with its own IP address, the SNACK module announces the infected machine as a proxy server for its local network.

SNACK and MUNCH also communicate with the GADGET unit that provides facilities for handling different events that come from other modules. The Flame’s registry contains LUA modules for processing events like “MUNCH_ATTACKED”, “SNACK_ENTITY.ATTACK_NOW”.

MUNCH: Spoofing proxy detection and Windows Update request

“MUNCH” is the name of the HTTP server module in Flame. It is started only if “MUNCH.SHOULD_RUN” variable is set to “True” and there are no running programs that can alert the victim. These programs (anti-virus, firewalls, network sniffers etc.) are defined in the Flame’s registry in a list called “SECURITY.BAD_PROGRAMS”

When MUNCH is started, it reads a buffer from the “MUNCH.WPAD_DATA” variable, replaces the pattern “%%DEFAULT%%” with the IP address of its best suitable network interface and waits for HTTP requests.

Contents of the “MUNCH.WPAD_DATA” variable

The “MUNCH.WPAD_DATA” buffer is actually a WPAD file that is requested by network clients that implement automatic proxy server detection. The code in the WPAD file matches the MD5 hash of the hostname that the client is connecting to against its own list, and if found, offers itself as a HTTP proxy. We were able to identify the hashes:

download.windowsupdate.com
download.microsoft.com
update.microsoft.com
www.update.microsoft.com
v5.windowsupdate.microsoft.com
windowsupdate.microsoft.com
www.download.windowsupdate.com
v5stats.windowsupdate.microsoft.com
v4stats.windowsupdate.microsoft.com
v9stats.windowsupdate.microsoft.com
v5.windowsupdate.com
v7stats.windowsupdate.microsoft.com
v6stats.windowsupdate.microsoft.com
v8stats.windowsupdate.microsoft.com
v5.download.windowsupdate.com

So, when a machine configured with automatic proxy detection tries to access one of the Windows Update hosts, it receives an IP address of the infected machine from SNACK, and then receives the IP address of the same machine as a proxy server from “wpad.dat” provided by MUNCH. From then, requests to the Windows Update service are passed through the MUNCH server.

When a network client connects to the MUNCH server and requests an URI other than “/wpad.dat” and “/ view.php”, the server :

1) Runs “MUNCH.SHOULD_ATTACK_SCRIPT” – Lua script that checks if the User-Agent header matches at least one of the patterns specified in “MUNCH.USER_AGENTS.CAB_PATTERN_*”. The Flame registry files that we have contained the following patterns:

MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.*
MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.*
MUNCH.USER_AGENTS.CAB_PATTERN_2 : Industry Update.*
MUNCH.USER_AGENTS.CAB_PATTERN_1 : Microsoft SUS.*

2) Checks if the requested URI matches any pattern specified in the list of strings called “MUNCH.GENERIC_BUFFERS.*.data.PATTERN”. If one of the expressions match, it then gets the buffer specified in the corresponding “MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA” value, reads the payload value called “MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA” and sends it to the client.

All the payloads are listed in the Flame’s registry with names starting with “MUNCH.GENERIC_BUFFERS_CONTENT.payload_name”, and are encoded with a fixed 104-byte RC4 key.

0.7
 

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

comments      Link
0.9
 

On Sunday, May 27 2012, the Iranian MAHER CERT posted a note announcing the discovery of a new targeted attack dubbed “Flamer”. On Monday 28 May 2012 aat 9am EST, after an investigation prompted and supported by the International Telecommunication Union, Kaspersky Lab and CrySyS Lab from Hungary announced the discovery of Flame (aka Skywiper), a sophisticated cyber-espionage toolkit primarily targeting Windows computers in the Middle East.

Several hours later, around 4PM GMT, the Flame command-and-control infrastructure, which had been operating for years, went dark.

For the past weeks, Kaspersky Lab has been closely monitoring the C&C infrastructure of Flame. In collaboration with GoDaddy and OpenDNS, we succeeded in sinkholing most of the malicious domains used by Flame for C&C and gain a unique perspective into the operation.

Before going further, Kaspersky Lab would like to thank the “GoDaddy Network Abuse Department” and to William MacArthur for their fast reaction and exceptional support of this investigation. The OpenDNS security research team also offered invaluable assistance during the course of this investigation.

Our findings from analysing the infrastructure can be found below.

Introduction

Since both Flame and Duqu appear to be targeting similar geographical regions and have been created with similar goals in mind, we will provide an analysis from the point of view of comparing the Flame C&C infrastructure with the Duqu infrastructure.

In the past, Kaspersky Lab analyzed the Duqu C&C infrastructure and found several important details, such as the attackers’ preference for CentOS, the use of SharpSSH to control the proxy servers and the huge number of hacked proxies used to hide the true identity of the attackers.

In the case of Flame, we performed a similar analysis. First of all, it’s interesting to point out a big difference from Duqu: while all the Duqu C&C proxies were CentOS Linux hosts, all of the known Flame C&C are running Ubuntu.

Additionally, while Duqu used the super stealthy way of hiding the true IP of the mothership using SSH port forwarding, Flame’s scripts are simply running on the respective servers. The reason is simple — on Monday May 28, all control scripts started returning 403/404 errors. In the case of Duqu, the real malware scripts were on a remote server and were never found.

From this point of view, we can state that the Duqu attackers were a lot more careful about hiding their activities compared to the Flame operators.

Here’s a comparison of the Duqu and Flame C&C infrastructure:

Duqu Flame
Server OS CentOS Linux Ubuntu Linux
Control scripts Running on remote server, shielded through SSH port forwarding Running on servers
Number of victims per server 2-3 50+
Encryption of connections to server SSL + proprietary AES-based encryption SSL
Compression of connections No Yes, Zlib and modified PPMD
Number of known C&C’s domains n/a 80+
Number of known C&C IPs 5 15+
Number of proxies used to hide identity 10+ Unknown
Time zone of C&C operator GMT+2 / GMT+3 Unknown
Infrastructure programming .NET Unknown
Locations of servers India, Vietnam, Belgium, UK, Netherlands, Switzerland, Korea, etc... Germany, Netherlands, UK, Switzerland, Hong Kong, Turkey, etc...
Number of built-in C&C IPs/domain in malware 1 5, can update list
SSL certificate self-signed self-signed
Servers status Most likely hacked Most likely bought
SSH connections no yes

Incidents|Flame: Bunny, Frog, Munch and BeetleJuice…

Aleks
Kaspersky Lab Expert
Posted May 29, 20:30  GMT
Tags: Flame, Cyber weapon, Cyber espionage
0.9
 

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.

At the moment we are receiving many inquiries about how to check systems for a Flame infection. Of course the simplest answer, for us, is to advise to use Kaspersky Lab Antivirus or Internet Security. We successfully detect and delete all possible modifications of the main module and extra components of Flame.

However, for those who want to carry out a detailed check themselves, at the end of this article we will give the necessary recommendations and advice.

MSSECMGR.OCX

The main module of Flame is a DLL file called mssecmgr.ocx. We’ve discovered two modifications of this module. Most of the infected machines contained its “big” version, 6 Mb in size, and carrying and deploying additional modules. The smaller version’s size is only 900 Kb and contains no additional modules. After installation, the small module connects to one of the C&C servers and tries to download and install the remaining components from there.

Mssecmgr may be called different names on actual infected machines, depending on the method of infection and the current internal state of the malware (installation, replication, upgrade), e.g., wavesup3.drv, ~zff042.ocx, msdclr64.ocx, etc.

Complete analysis of the mssecmgr module will follow in our upcoming blog posts.

The first activation of this file is initiated by one of the external features - either Windows WMI tools using a MOF file if the MS10-061 exploit is used, or using a BAT file:

s1 = new ActiveXObject("Wscript.Shell");
s1.Run("%SYSTEMROOT%\\system32\\rundll32.exe msdclr64.ocx,DDEnumCallback");

(source code of MOF file, svchostevt.mof)

1.8
 

Duqu and Stuxnet raised the stakes in the cyber battles being fought in the Middle East – but now we’ve found what might be the most sophisticated cyber weapon yet unleashed. The ‘Flame’ cyber espionage worm came to the attention of our experts at Kaspersky Lab after the UN’s International Telecommunication Union came to us for help in finding an unknown piece of malware which was deleting sensitive information across the Middle East. While searching for that code – nicknamed Wiper – we discovered a new malware codenamed Worm.Win32.Flame.

Flame shares many characteristics with notorious cyber weapons Duqu and Stuxnet: while its features are different, the geography and careful targeting of attacks coupled with the usage of specific software vulnerabilities seems to put it alongside those familiar ‘super-weapons’ currently deployed in the Middle East by unknown perpetrators. Flame can easily be described as one of the most complex threats ever discovered. It’s big and incredibly sophisticated. It pretty much redefines the notion of cyberwar and cyberespionage.

For the full low-down on this advanced threat, read on…

General Questions

What exactly is Flame? A worm? A backdoor? What does it do?

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.

The initial point of entry of Flame is unknown - we suspect it is deployed through targeted attacks; however, we haven’t seen the original vector of how it spreads. We have some suspicions about possible use of the MS10-033 vulnerability, but we cannot confirm this now.

Once a system is infected, Flame begins a complex set of operations, including sniffing the network traffic, taking screenshots, recording audio conversations, intercepting the keyboard, and so on. All this data is available to the operators through the link to Flame’s command-and-control servers.

Later, the operators can choose to upload further modules, which expand Flame’s functionality. There are about 20 modules in total and the purpose of most of them is still being investigated.

Incidents|Flashfake Removal Tool and online-checking site

Aleks
Kaspersky Lab Expert
Posted April 09, 22:08  GMT
Tags: Botnets, Apple, Flashfake
0.8
 

After intercepting one of the domain names used by the Flashback/Flashfake Mac Trojan and setting up a special sinkhole server last Friday, we managed to gather stats on the scale and geographic distribution of the related botnet. We published information on this in our previous blog entry.

We continued to intercept domain names after setting up the sinkhole server and we are currently still monitoring how big the botnet is. We have now recorded a total of 670,000 unique bots. Over the weekend (7-8 April) we saw a significant fall in the number of connected bots:

This doesn’t mean, however, that the botnet is shrinking rapidly – these are merely the numbers for the weekend.

Over the last few days our server has registered all the data sent by bots from the infected computers and recorded their UUIDs in a dedicated database. Based on this information we have set up an online resource where all users of Mac OS X can check if their computer has been infected by Flashback.

To find out if your computer is infected and what to do if it is, visit: flashbackcheck.com

Also users can check if they’re infected with Flashfake by using Kaspersky Lab’s free removal tool.

comments      Link

Incidents|The mystery of Duqu: Part Ten

Aleks
Kaspersky Lab Expert
Posted March 27, 15:48  GMT
Tags: Targeted Attacks, Duqu
0.4
 

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 months break.

Duqu is back

The newly discovered driver does not contain any new functionality compared to its previous versions. The code contains only minor modifications, and they were most likely done to evade detection from antivirus programs and detection tools such as the CrySyS Duqu Toolkit. Here’s a list of changes compared to older versions:

  • The code was compiled with different optimization settings and/or inline attributes of functions.
  • The size of the EXE stub that is injected with the PNF DLL was increased by 32 bytes.
  • The LoadImageNotifyRoutine routine now compares the module name with “KERNEL32.DLL” using hash checksums instead of simple string comparison.
  • The size of the encrypted configuration block was increased from 428 to 574 bytes. There are no new fields in in the block, but the size of the registry value name (“FILTER”) field was increased. This makes the registry value name easily modifiable - probably for future use.
  • The algorithm of the two subroutines that decrypt the encrypted config block, registry value and PNF DLL has been changed. This is the third known algorithm used in the Duqu encryption subroutines.
  • The algorithm of the hash function for the APIs has changed. All the hash values were changed correspondingly.

Old hash function, used in previous versions of the Duqu driver:

New hash function:

The fact that the new driver was found in Iran confirms that most of Duqu incidents are related to this country.

Incidents|The Mystery of Duqu: Part Seven (Back to Stuxnet)

Aleks
Kaspersky Lab Expert
Posted December 28, 16:37  GMT
Tags: Targeted Attacks, Stuxnet, Duqu
0.5
 

We have been studying the Duqu Trojan for two months now, exploring how it emerged, where it was distributed and how it operates. Despite the large volume of data obtained (most of which has yet to be published), we still lack the answer to the fundamental question - who is behind Duqu?

In addition, there are other issues, mostly to do with the creation of the Trojan, or rather the platform used to implement Duqu as well as Stuxnet.

In terms of architecture, the platform used to create Duqu and Stuxnet is the same. This is a driver file which loads a main module designed as an encrypted library. At the same time, there is a separate configuration file for the whole malicious complex and an encrypted block in the system registry that defines the location of the module being loaded and name of the process for injection.

This platform can be conventionally named as ‘Tilded’ as its authors are, for some reason, inclined to use file names which start with "~d".

We believe Duqu and Stuxnet were simultaneous projects supported by the same team of developers.

Several other details have been uncovered which suggest there was possibly at least one further spyware module based on the same platform in 2007-2008, and several other programs whose functionality was unclear between 2008 and 2010.

These facts significantly challenge the existing "official" history of Stuxnet. We will try to cover them in this publication, but let us first recap the story so far.

Continue reading

comments      Link