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 ? 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 ? this file is the AMD64 version of the 1st executable dropped, with an AMD64 version of a driver, and PKCS7:113 ? 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:
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:
\\
\\
\\
\\
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.
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 ? 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 ? 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%\Windows\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.
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.
Leave a reply
