Yesterday the Iranian CERT made an announcement about a new piece of wiper-like malware. We detect these files as Trojan.Win32.Maya.a.

This is an extremely simplistic attack. In essence, the attacker wrote some BAT files and then used a BAT2EXE tool to turn them into Windows PE files. The author seems to have used (a variant of) this particular BAT2EXE tool.

There's no connection to any of the previous wiper-like attacks we've seen. We also don't have any reports of this malware from the wild.

There have been persistent media reports that the Shamoon wiper malware we previously covered is linked to attacks against Saudi Aramco.

The hardcoded date in the body of destructor matches exactly the declaration by a hacker group about the date and time when the Saudi Aramco company would had been hit but we still cannot definitively confirm that Shamoon was to blame for those attacks.

And just about two weeks later, another energy company in the Middle East (RasGas) fell victim to another malware attack and the media has logically asked questions about whether Shamoon was responsible.

We leave the speculation up to others and concentrate strictly on sharing technical details. This is the continuation of our investigation into Shamoon:

NETINIT.EXE

The main Shamoon module has a resource PKCS7:113 that maintains an executable which is saved to disk as %WINDIR%\System32\NETINIT.EXE and this program poses a module to communicate with CNC. This program waits for parameters to be run with. The author was not too creative and coded a handling of just two argument values which can be ?0� or ?1�.

If ?0�, the program takes a second argument and treats it as a data to be passed to CNC. With this argument value, the malware connects to CNC just once and stops executing. We have not located any place in the Shamoon code where netinit.exe would be run with argument ?0�.

But as you would recall, we did locate the place where netinit.exe is launched with a command line ?netinit.exe 1�. The program then enters into a loop until another destructive module creates a file %WINDIR%\ inf\netfb318.pnf signaling that the time has come to wipe data and kill the operating system. While netinit.exe waits for that file it regularly connects to CNC to report itself and receiving commands.

In April 2012, several stories were published about a mysterious malware attack shutting down computer systems at businesses throughout Iran.

Several articles mentioned that a virus named Wiper was responsible. Yet, no samples were available from these attacks, causing many to doubt the accuracy of these reports.

Following these incidents, the International Telecommunication Union (ITU) asked Kaspersky Lab to investigate the incidents and determine the potentially destructive impact of this new malware.

After several weeks of research, we failed to find any malware that shared any known properties with Wiper. However, we did discover the nation-state cyber-espionage campaign now known as Flame and later Gauss.

It is our firm opinion that Wiper was a separate strain of malware that was not Flame. Although Flame was a highly flexible attack platform, we did not see any evidence of very destructive behavior. Given the complexity of Flame, one would expect it to be used for long-term surveillance of targets instead of direct sabotage attacks on computer systems. Of course, it is possible that one of the last stages of the surveillance was the delivery of a Wiper-related payload, but so far we haven-t seen this anywhere.

We continue to analyse the Shamoon malware. This blog contains information about the internals of the malicious samples involved in this campaign.

Samples nesting

The main executable (dropper) includes 3 resources, each maintains a ciphered program. The cipher is pretty simple v xor by dword. This was mentioned in our first blog-post.

Resource PKCS12:112 maintains an encoded executable, xor-ed with key value 0xFB5D7F25. It is saved to disk using a name taken from a hardcoded list in the %WINDIR%\System32 folder during the dropper execution. In turn, this module maintains resource READONE :101 (xor key: 0xF052AF15), a driver decoded and saved to disk as %WINDIR%\System32\Drivers\DRDISK.SYS.

Resource PKCS7:113 maintains an executable, xor-ed with key 0x00BAD417 and saved to disk as %WINDIR%\System32\NETINIT.EXE during dropper execution.

Resource X509:116 maintains an AMD64 version of main the Shamoon executable (dropper) xor-ed with key 0xBB1AC25C. This in turn contains almost the same set of resources as its Win32 counterpart: PKCS12:112 v this file is the AMD64 version of the 1st executable dropped, with an AMD64 version of a driver, and PKCS7:113 v the AMD64 version of NETINIT.EXE. So, 112 and 113 resources have the same xor keys in x86 and AMD64 versions of the dropper, but the drivers- keys are different: the AMD64 version is xored by 0x10CAFFA0 value when x86 is ciphered with 0xF052AF15. This picture is worth a thousand words and sums up these on disk files:

Shamoon samples nesting

So, the Shamoon main executable has been coded to work in 3 modes:

1. the sample is run as a typical program in a 32-bit OS (argument-dependent)
2. the sample is run in a 64-bit OS
3. the sample is run as a service in a 32-bit OS

64-bit environment

First, the program checks if it has been launched in a 64-bit operating system. If so, it drops the AMD64 version of the main executable by decrypting the X509:116 resource and saving the decrypted data to disk as %WINDIR%\System32\trksrv.exe. Then it creates and starts the service ?TrkSvr� using the following command line:

%WINDIR%\System32\cmd.exe /c "ping -n 30 127.0.0.1 >nul && sc config TrkSvr binpath= system32\trksrv.exe && ping -n 10 127.0.0.1 >nul && sc start TrkSvr "

This branch comes to an end and the program exits.

Let-s take a look what the program does if it runs as a typical program in a 32-bit operating system.

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:\Shamoon\ArabianGulf\wiper\release\wiper.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 is a 900KB PE file that contains a number of encrypted resources:

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.