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

Shamoon the Wiper in details

Dmitry Tarakanov
Kaspersky Lab Expert
Posted August 21, 22:30  GMT
Tags: Targeted Attacks, Wiper
0.6
 

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.

32-bit environment: usual run, arguments are present

It turned out that the program expects arguments which are treated like a list of IP-addresses. These are IP-addresses of computers that the malicious program will try to infect. If the first argument poses a single character text then the program tries infecting computers from the local network, enumerating the last value of infected computer-s IP-address from 1 to 254. For the particular IP-address, the program tries opening the file using the following paths:

\\\ADMIN$\System32\csrss.exe
\\\C$\Windows\System32\csrss.exe
\\\D$\Windows\System32\csrss.exe
\\\E$\Windows\System32\csrss.exe

In other words, the program attempts to gain access to the system directory of available computers on the local (sub-) network (or computers with specified IP-addresses in the arguments). If the malicious program is able to open that csrss.exe file, it creates a copy of itself on the remote computer in the accessible System32 folder under a randomly-selected name taken from a hardcoded list:

caclsrv.exe
certutl.exe
clean.exe
ctrl.exe
dfrag.exe
dnslookup.exe
dvdquery.exe
event.exe
findfile.exe
gpget.exe
ipsecure.exe
iissrv.exe
msinit.exe
ntfrsutil.exe
ntdsutl.exe
power.exe
rdsadmin.exe
regsys.exe
sigver.exe
routeman.exe
rrasrv.exe
sacses.exe
sfmsc.exe
smbinit.exe
wcscript.exe
ntnw.exe
netx.exe
fsutl.exe
extract.exe

Then the dropper tries to run this copy by creating a scheduled task on the remote computer. In case of a failure to infect the remote computer/computers when creating the scheduled task, the malicious program also renames its copy (created when the scheduled task is initiated) as ?trksvr.exe and tries to create and start the service ?TrkSvr (visible name: ?Distributed Link Tracking Server?) related to this executable on the remote computer.

Example of the propagation routine

32-bit environment: usual run, no arguments

When the program is run without arguments it installs the ?TrkSvr (visible name: ?Distributed Link Tracking Server?) service locally (copies itself into %WINDIR%\System32\trksvr.exe and creates a corresponding service) and starts it. At that stage, the author has used an interesting trick to ensure malware persistence across reboots: it changes the configuration of the ?LanmanWorkstation service (visible name: ?Workstation). It makes this service dependent on the ?TrkSvr. This means that whenever ?Workstation starts, it also runs the ?TrkSvr". But, usually the ?Workstation is run automatically when the operating system loads.

There is an easier way to force the OS to run a service at startup v just set up the appropriate option of a particular service. Moreover, ?TrkSvr gets created by malware with that option adjusted to start automatically. Why the author followed this method, with dependencies, is difficult to understand.

32-bit environment: run as a service

And finally we come to the last condition v the dropper is launched as a service. At first the dropper saves the resource PKCS7:113 as %WINDIR%\System32\netinit.exe and launches it with an argument ?1 in one of two ways:

1. it creates a scheduled task to launch ?netinit.exe 1
2. it runs ?netinit.exe 1 directly by calling the CreateProcess function

The watchdog ?TrkSvr service constantly checks to see if the netinit.exe process is running and re-launches it if it stops working (that is, if it-s missing from the process list).

The malicious service deletes in a loop all the executables from the hardcoded list (see above) in the local %WINDIR%\System32 folder. As part of this loop the program checks one further condition before passing to the final stage of its execution.

The dropper determines whether a specified date has come or not. The date is either read from the ?%WINDIR%\inf\netft429.pnf file or (if this fails) a hardcoded value is used. The hardcoded date is 15th August 2012 08:08 UTC. It seems that the function to check the date works incorrectly. If the intention is to divide the timeline into ?before and ?after a particular checkpoint, then the author has failed. The condition contains a corrupted logic to do this.

Date comparison

For example, if the year is 2013 but the current month is less than the target month (say February), then the condition would return a result as if the current date lies before the August 2012 checkpoint value. In fact, this logic is simply flawed and incorrect. This error indirectly confirms our initial conclusion that the Shamoon malware is not the Wiper malware that attacked Iranian systems. Wiper is presumed to be a cyber-weapon and, if so, it should have been developed by a team of professionals. But experienced programmers would hardly be expected to mess up a date comparison routine.

Nevertheless, the condition (though not in all intended cases) works out and the dropper proceeds to its finalizing routine. The most substantial action performed in this procedure is to save the PKCS12:112 resource as an executable file using a name taken from the hardcoded list in the %WINDIR%\System32 folder and launch it (this component performs the destructive measures of the Shamoon malware). Also we see here that the program uses the odd hardcoded text:

?kijjjjnsnjbnncbknbkjadc
kjsdjbhjsdbhfcbsjkhdf jhg jkhg hjk hjk
slkdfjkhsbdfjbsdf
klsjdfjhsdkufskjdfh.

Also at this stage the program checks if the ?c:\windows\temp\out17626867.txt file exists on the target system and loads the image ?myimage12767 from its resources. The ?out17626867.txt file is not saved by the dropper itself and so far we have not located any references to this file in other components of the malware. As well, the dropper does not contain the image ?myimage12767 in its resources. So we don-t know why it checks for this file, what the .txt file is related to, and what the purpose of the missing ?myimage12767 resource could be. We find that this part of the code, which works with the strange text, the ?out17626867.txt file and the ?myimage12767 image, is needless and maintains no added functionality.

That-s all about the initial Shamoon executable. We-ll bring you more details about other components of this malware soon.

p.s. Thanks go to my colleagues David Emm and Kurt Baumgartner for their valuable comments and editing.

4 comments

Oldest first
Threaded view
 

drakster

2012 Aug 22, 13:50
0
 

Shamoon is using a commercial driver to wipe ?

I read a post from an Eldo developer that Shamoon use in fact one their component (a signed driver) to wipe (named rawdata). Are you in touch with them ? If not it may help you to go faster in the analysis if it's true ! Moreover the guy seems to say they are able to search for the customer from where the signed driver is coming (they provide a license key which is necessary to use the driver... but maybe the so said copy control was hacked too :)

Here is the post :

http://mayevski.blogspot.fr/2012/08/about-utter-incompetence-of-malware.html

Hope this helps

Reply    

Aleks

2012 Aug 22, 19:01
0
 

Re: Shamoon is using a commercial driver to wipe ?

As we said in first blogpost - "the driver is signed by EldoS Corporation" + "The disk driver itself does not appear to be malicious. However, it is used for raw disk access by the malware components to wipe the MBR of infected systems".

So, it's clear that attackers used legit EldoS driver. If EldoS can track source of this file - ok, we can provide them the sample, but i think they already have it.

Reply    

MarkDLP

2012 Aug 30, 17:13
-1
 

I don't understand

...WHY are you saying what the hacker SHOULD have done?!? "There is an easier way to force the OS to run a service at startup – just set up the appropriate option of a particular service." WHY would a company that is supposed to be against hackers and their ilk CRITIQUE them on your website as if you're their professor?

Reply    

c0de3

2012 Sep 01, 03:38
0
 

Re: I don't understand

He simply writes it is unknown and interesting why he has done it this way. The attacker would have to be completely brain dead to not know the easier method.

I guess the attacker may have picked this trick up at some point to help keep their services hidden. For example when looking for suspicious services it is not uncommon to filter by start up type 'automatic' 'delayed start' - in this case the service would not show up. Why it wasn't implemented in all run types is anyone's guess.

Reply    
If you would like to comment on this article you must first
login


Bookmark and Share
Share

Related Links

Analysis

Blog