Detailed threat analysis of Shamoon 2.0 Malware

Our Previous post talked about the initial overview of the Shamoon 2.0 sample .This analysis is a continuation of our last post but with a more insight on the working and behavior of the malware.

There are 3 components which are linked with one another which makeup Shamoon 2.0 single malware. We have analyzed each component according to the stages which the Shamoon 2.0 uses for infection on a victim’s machine i.e. Dropper Component⇒ Communication Component⇒ Wiper Component.

When Shamoon 1.0 made its first wave of attack in August 2012, it had not just infected 30,000-35,000 computers but it also had crippled the entire organizations altogether which were infected with it. Its effects were seen post attack as  many computers were still working irregularly and the time that required to restore the organization’s full functionality led to huge loss in not just terms of money but also in terms of company’s reputation too.

The second wave Shamoon which is dubbed as Shamoon 2.0 used the similar approach which it had used previously but this time it is predicted that the amount of infection of computers will be more, since last time the attackers were able to retrieve the credentials of users for various organization, The second wave will be using the stolen credentials from the previous attack and the reason this attack is bound to be success is because of lack of awareness among the employees on securing passwords. One survey about the Middle East reports some of the facts mentioned below:

● More than 70 percent of the users  said that they were storing administrative passwords in plaintext.
● Over 45 percent of the users use the same password for over multiple systems.
● More than 40 percent users share their passwords.
● Only 13 percent users change their passwords once a month.

These facts make the Middle East region more easy as a target for Shamoon 2.0. We have launched a Shamoon detection tool which can detect the new Shamoon 2.0.

Following below is the in-depth analysis that we have done on Shamoon 2.0.

Dropper Component – Disttrack:
Upon computing the hash value of the sample, the SHA256 as 394a7ebad5dfc13d6c75945a61063470dc3b68f7a207613b79ef000e1990909b

Doing a quick VirusTotal search we get the following output:

This assures us that the sample we are analyzing is of Shamoon 2.0. The date of update also tells us that it is the recent Shamoon sample which is dubbed as the Shamoon 2.0.
The sample uses the following evasion techniques for Debugging:

1)    GetLastError
2)    IsDebuggerPresent
3)    Process32FirstW
4)    Process32NextW
5)    TerminateProcess
6)    UnhandledExceptionFilter

The following screenshot gives information of the which compiler was used for compiling the malware, which entry point address is being used, EP section tells us the entry point of the portable executable (PE).

As mentioned earlier above the compiler used is Microsoft Visual C++ v8.0 2005

Malware in general use some basic techniques to obfuscate the code so that it is not easily readable when loaded in any debugger and to make it more difficult to reverse the malware. There are many Hashing methods that can be used. Our sample uses the Hash technique known as Base64.

We know that Shamoon 2.0 was targeted the Middle East region. The following screenshot is the evidence that this malware is specifically looking for Arabic -Yemen [ar] (ar-ye) language settings.

So the malware looks into the keyboard layout and the ID mentioned is in the reference of the keyboard layout, for example ID:1033 corresponds to the English-US [en] (en-us), here we find that the language is of the ID: 9217 i.e.Arabic -Yemen [ar] (ar-ye).

The following file operations that took place during the execution of the malware are listed as following:

1. File-Read
C:\Documents and Settings\student\LocalSettings\Temp\Shamoon-394a7ebad5dfc13d6c75945a61063470dc3b68f7a207613b79ef000e1990909b.bin

2. File-Opened
C:\Documents and Settings\student\LocalSettings\Temp\Shamoon-394a7ebad5dfc13d6c75945a61063470dc3b68f7a207613b79ef000e1990909b.bin

C:\WINDOWS\system32\kernel32.dll

3. Registry Key-Read
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\GRE_Initialize\DisableMetaFiles

Communication Component – Disttrack:

Upon computing the hash value of the sample, the SHA256 as 61c1c8fc8b268127751ac565ed4abd6bdab8d2d0f2ff6074291b2d54b0228842, doing a quick VirusTotal search we verified the sample as a part of the Shamoon 2.0

Following screenshot shows that communication component has the same hash technique as that seen in the dropper component mentioned earlier, i.e. Base64.

Since communication component is a part of the Shamoon 2.0 components it will have same compiler used

For compiling the communication component as well which is shown in the screenshot below:

During our analysis, we found that the communication component made many changes in the Registry values of the infected system, these changes are mentioned below:

Registry Key – Opened

1) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DnsCache\Parameters
2) HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DnsClient
3) HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Rpc
4)HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\ImageFile ExecutionOptions\61c1c8fc8b268127751ac565ed4abd6bdab8d2d0f2ff6074291b2d54b0228842.exe\RpcThreadPoolThrottle
5) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LDAP
6) HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\System\DNSClient
7) HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc
8) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
9) HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\PagedBuffers
10) HKEY_LOCAL_MACHINE\System\Setup
Registry Key – Read

1. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\UseDomainNameDevolution
2. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\ServerPriorityTimeLimit
3. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\MaxRpcSize
4. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\WaitForNameErrorOnAll
5. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DnsQuickQueryTimeouts
6. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DefaultRegistrationRefreshInterval
7. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\RegisterWanAdapters
8. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\DomainNameDevolutionLevel
9. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\AppendToMultiLabelName
10. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DisableAdapterDomainName
11. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\RegisterPrimaryName
12. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\EnableAdapterDomainNameRegistration
13. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\UpdateTopLevelDomainZones
14. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\FilterClusterIp
15. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\DnsTest
16. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\ScreenUnreachableServers
17. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\MulticastListenLevel
18. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\MaxNegativeCacheTtl
19. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\QueryAdapterName
20. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\PrioritizeRecordData
21. HKEY_LOCAL_MACHINE\SYSTEM\Setup\SystemSetupInProgress
22. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize\DisableMetaFiles
23. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DisableReverseAddressRegistrations
24. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\MaxCacheTtl
25. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\UpdateSecurityLevel
26. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\MaxCachedSockets
27. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\RegistrationEnabled
28. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\RegisterAdapterName
29. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\AdapterTimeoutLimit
30. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\UpdateSecurityLevel
31. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\RegistrationMaxAddressCount
32. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DefaultRegistrationTTL
33. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DisableDynamicUpdate
34. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Hostname
35. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\AllowUnqualifiedQuery
36. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\UpdateZoneExcludeFile
37. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\PrioritizeRecordData
38. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\RegistrationTtl
39. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\UseHostsFile
40. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\AllowUnqualifiedQuery
41. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\RegistrationRefreshInterval
42. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DnsQueryTimeouts
43. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\QueryIpMatching
44. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DnsNbtLookupOrder
45. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\MaxCacheSize
46. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\UseDomainNameDevolution
47. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\UseEdns
48. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Domain
49. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\ldap\LdapClientIntegrity
50. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DisableWanDynamicUpdate
51. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DnsMulticastQueryTimeouts
52. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\ScreenBadTlds
53. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\RegisterReverseLookup
54. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\MaxNumberOfAddressesToRegister
55. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\MulticastSendLevel
56. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DomainNameDevolutionLevel

These above results only indicate that the malware sample tries to communicate with the server.
Wiper Component – Disttrack:

The wiper component is the most important component out of the three components of Shamoon 2.0. Upon computing the hash value of the sample, the SHA256 as 128fa5815c6fee68463b18051c1a1ccdf28c599ce321691686b1efa4838a2acd.

A quick look up with VirusTotal confirms that this indeed is a wiper component of the Shamoon 2.0.

Initial analysis shows us that apart from using the anti-debugging techniques this component also uses Anti-VM tricks which was not seen pervious dropper sample and communication sample.

VMCheck.dll is a technique used to check if the sample is in a Virtual machine or not.

Just similar to the Dropper component and Communication component, we find that the Wiper component uses  Microsoft Visual C++ v8.0 2005  shown in the screenshot below.

However, what is different in the Wiper component, which is not present in the dropper or the communication component is it uses and additional hash/crypt function along with the Base64. i.e. CryptEncrypt Function is also used. The screenshot below shows this, which only means that the malware developers really wanted the make this wiper component not more difficult to understand for researchers but also much more obfuscated than the other components that we discussed above, as obfuscated codes are not detected by Antivirus companies easily.

The language component remains same as that of the dropper with the default English option included as shown below:

In context of the registry changes that the Wiper does is same as it did with the Dropper component:

Registry Key-Read
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\GRE_Initialize\DisableMetaFiles

The cryptbase.pdb which contains all the necessary information about the encryption techniques, Keys on encryption and other functions are linked in the following way with the code of the wiper sample:

One more file that we analyzed was which had links to the Shamoon 2.0 was with the SHA256 hash as 5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a.

Doing a VirusTotal lookup gives us the following confirmation that the software is malicious in nature and that the detection ratio is very low as well.

Now the preliminary analysis shows us the following files that were found:

Executable         ntoskrnl.exe
Database           c:\projects\rawdisk\bin\wnet\fre\amd64\elrawdsk.pdb
During the analysis for the file we found the following device name parameters

\#{9A6DB7D2-FECF-41ff-9A92-6EDA696613DF}#
\#{8A6DB7D2-FECF-41ff-9A92-6EDA696613DE}#

The interesting thing is that, this same details were also found in the previous Shamoon attack that took place in 2012.
We also came across these ‘060523170051Z’ and ‘160523171051Z0W1’ strings. The interesting thing about these numbers is that they are found in a different malware which has a file name ‘mimidrv.sys’. The screenshot of that malware is mentioned below.

This malware mentioned above is basically a ‘hacktool’ Trojan as identified by the other Antivirus companies. There are chances that this is another behavior that our sample also behaves like the sample mentioned below.

We find that the Mimikatz malware is related with the PowerShell. We had found out the same PowerShell which we had reported in our previous blog. Hence the Shamoon 2.0 has some behaviour with PowerShell. Following screenshot shows the PowerShell commands that Shamoon 2.0 executes:

From the evidence collected we confirm links between the Shamoon 1.0 to Shamoon 2.0.
Some features that were observed with this sample are that it is using an overlay to hid the packer information:

Analysing further, we found out the MEW 10v1.0 from Northfox packer is used:

Unlike the components that we analyzed so far this particular sample had the CRC16 Hash function which is completely different.

The malware has a SSL certificate embedded within it. The following screenshot gives the SLL certificate information,

The certificate is valid from Monday,January  11, 2010 7:49.26 PM to Friday, January 11 2013 7:49:26 PM

This above date correlates to the hard-coded date inside the program. This hardcoded date allows the program to execute since the date is inside the validity period as mentioned.

The pseudo code explains that Shamoon 2.0 changes the system time, and sets it at random time and date between Monday, January  11, 2010 7:49.26 PM to Friday, January 11 2013 7:49:26 PM.

The above code is derived from this code flow:

The reason for Shamoon 2.0 changes the time and date settings is because we found out that Shamoon 2.0 uses a commercial product which the malware developers are using which is as called RawDisk by EldoS Corporation. This software gives direct access to files, disk and partitions. The temporary license key for this product is between the time mentioned earlier and hence Shamoon 2.0 changes the system time to make the product believe into thinking that it is using a valid key, and thus the overwrite function can take place.
The MBR-Overwriting Techniques that Shamoon 2.0 Implements:

Before explaining the MBR overwriting that the Shamoon 2.0 does we need to understand what is an MBR or the Master Boot Record (MBR). MBR usually is the first 512 bytes of the disk which consists of all the important and crucial information about the data in the disk. The breakdown of the 512 bytes is as shown below:
The reason of overwriting the first 512 bytes of data is

Bootstrap code area	446 bytes
Partition entry 1 Partition entry 2 Partition entry 3 Partition entry 4	Partition table (for primary partitions)  16 bytes x 4 (partitions)
Boot signatureBoot signature	2 bytes
Total	512 bytes

 
So, that in simple terms mean that target the MBR and lose all data rather than wiping the entire drive all-together.

The following screenshot is a pseudo-code for the MBR-overwrite method that the Shamoon 2.0 uses.

As seen the code above there is a comparison of a variable with ‘69’.  The ASCII equivalent of 69 is ‘E’

So, the way the code works in 3 simple steps:

1. Reads the data from the location to overwrite.
2. Uses an XOR table to corrupt the data
3. Write back the XOR’ed values to the location where it read the original data from.

The Above code is derived from the following structure of code:

And the XOR operations which are responsible for overwriting/wiping the data are in the cascading representations as shown in the image below:

One more module code that we can observe is from the ElRawDisk sample is shown below that shows the correlation between the actual code and the functionality and working in a pseudo – c code.

This particular snippet shows how the IoDeleteDevice routine removes a device object from the system, once the MBR is overwritten. This IODeleteDevice routine sends a message to the system notifying that a hard-drive or device is removed, this message is sent because after the MBR is overwritten the system cannot read the drive and this routine tells the system that the device is disconnected from the system and hence the system does not further communicate with the drive. Therefore, the drive is no longer visible on the system.

Conclusion

From the whole analysis, we now can say the following behaviour. The Shamoon sample that is currently spreading is not very different from what spread in its first attack of August 2012. There is a lot of similarity in the previous sample and the new sample. But the new sample is more destructive than the older one. The modules which are split into Dropper, Communication, Wiper are independent and yet linked with one another. From the analysis, we can say that the wiper component is the most important out of the three.

Source:https://www.vinransomware.com