Shamoon 2

a guest Jan 25th, 2017 675 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Second Wave of Shamoon 2 Attacks Identified
  3. In November 2016, we observed the reemergence of destructive attacks associated with the 2012 Shamoon attack campaign. We covered this attack in detail in our blog titled Shamoon 2: Return of the Disttrack Wiper, which targeted a single organization in Saudi Arabia and was set to wipe systems on November 17, 2016. Since our previous publication, we have found  another, similar but different payload used to target a second organization in Saudi Arabia that was configured to wipe systems twelve days later on November 29, 2016. This latest attack potentially materially impacts one of the primary countermeasures employed against wiper attacks: Virtual Desktop Interface snapshots.
  5. The payload used in this attack was very similar to the November 17, 2016 payload, but exhibited slightly different behaviors and contained hardcoded account credentials specific to the newly targeted organization. The hardcoded account credentials met Windows password complexity requirements, which suggests that the threat actors obtained the credentials through a previous, separate attack, similar to the November 17, 2016 attack.
  7. The most notable thing about this latest sample is that it contains several usernames and passwords from official Huawei documentation related to their virtual desktop infrastructure (VDI) solutions, such as FusionCloud. VDI solutions can provide some protection against a destructive malware like Disttrack through the ability to load snapshots of wiped systems. The fact that the Shamoon attackers had these usernames and passwords may suggest that they intended on gaining access to these technologies at the targeted organization to increase the impact of their destructive attack. If true, this is a major development and organizations should consider adding additional safeguards in protecting the credentials related to their VDI deployment.
  9. At this time, we have no details of the attack we believe preceded this Shamoon attack to obtain credentials. We also have no details on the delivery method used to deliver the new, similar, but different Disttrack payload in this attack.
  11. The Second Shamoon 2 Attack
  12. This second known attack associated with Shamoon 2 also used the Disttrack payload, albeit a new, similar but different one from the original Shamoon 2 attack. Specifically, it used a 64-bit variant that was configured to begin its destructive activities on November 29, 2016. Like the Disttrack sample used in the first reported Shamoon 2 attack, it including a wiper and communications module stored in resources within the executable.
  14. Table 1 below shows that the method the Disttrack payload uses to extract and decrypt the modules from resources is the same; however, the resource names changed from “X509”, “PKCS7” and “PKCS12” to “LANG”, “MENU” and “ICO”.
  16. Component   Resource Name   Offset  Size    Base64 key
  17. Wiper   LANG    94399-14 = 94385    563712  OWRKbTxrleYfLm…
  18. Communications  MENU    218709-14 = 218695  187904  QsCfQA6ze9CoOz…
  19. Unknown ICO Unknown Unknown ijX7buB1FIjSn/0D…
  22. Our efforts to decrypt the “ICO” resource have thus far been unsuccessful as the Disttrack payload has an associated key but does not contain code that decrypts and extracts this resource.
  24. Propagation Inside Compromised Networks
  26. Similar to the previous attack, the Disttrack payload in this attack spreads to other systems on the local network (/24 network specifically) by logging in using legitimate domain account credentials, copying itself to the system and creating a scheduled task that executes the copied payload. While this method is the same as discussed in our previous blog, the account credentials used in this attack were specific to the targeted organization and the file names used when copying the payload to remote systems were different.
  28. Legitimate User Accounts
  30. There were 16 account credentials found hardcoded within the Disttrack payload, appearing to be a mixture of individual user accounts and broader administrator accounts. All but one of the passwords met Windows complexity requirements, specifically, containing uppercase and lowercase characters, and either a number, symbol, or both. One of the general administrator accounts seen in this payload was also in the Disttrack payload in the first Shamoon 2 attack from November 17, 2016, which may not be specific to the targeted organization and instead used as an attempt to guess the login credentials. Based upon the existence of these credentials, it is highly likely the threat actors had carried out a previous attack to obtain these account credentials, as it is unlikely that these passwords were guessed or brute forced.
  32. As noted earlier, a new development with this latest Disttrack payload is that several of the usernames and passwords are found within official documentation as administrator accounts for Huawei’s virtualized desktop infrastructure (VDI) products, such as FusionCloud. This may suggest that the targeted organization used these credentials when deploying Huawei VDI systems. Shamoon actors may have obtained these credentials from a prior attack; however, it is also possible that the actors included these default usernames and passwords as an attempt to guess the login credentials to the VDI infrastructure.
  34. VDI solutions can provide some protection against a destructive malware like Disttrack through the ability to load snapshots of wiped systems. Also, since FusionCloud systems run a Linux operating system, which would not be susceptible to wiping by the Windows-only Disttrack malware, this could be seen as a reasonable countermeasure against attacks like Shamoon. However, if the attacker was able to log into the VDI management interfaces using the account credentials they could manually carry out destructive activities against the VDI deployment, as well as any snapshots. The targeting of VDI solutions with legitimate, stolen or default credential represents an escalation in tactics that administrators should be aware of and take immediate steps to evaluate and address.
  36. New Disttrack Names
  38. The filenames that the payload copies itself to within the System32 folder of the remote system differs from the previously reported attack, specifically using “ntertmgr32.exe” for 32-bit or “ntertmgr64.exe” for 64-bit systems. The scheduled task executes these files on the remote system, which results in the creation of a Disttrack service named “NtertSrv” compared to the service name “ntssrv” created by the Disttrack payload used in the November 17, 2016 attacks. This can be seen in Figure 1.
  40. shamoon_1
  42. Figure 1 Disttrack service created on systems during propagation
  44. Command and Control
  45. The communications module used in this attack is rather hobbled, as it was configured without an operational command and control (C2) server to communicate with. The lack of an operational C2 is much like the November 17, 2016 attack that had the IP address “” within its configuration to use as a C2 server. Unlike the non-operational C2 of “” used in the first Shamoon 2 attack, this communications module completely lacked any IP address or domain name for a C2 server within its configuration.
  47. Also, in this sample, Disttrack did not save its communications module to the system using the filename “netinit.exe” like in the original attack, rather it chose a random name from the following list:
  49. • caiaw00e.exe
  50. • sbuvideo.exe
  51. • caiaw00i.exe
  52. • olvume.exe
  53. • usinwb2.exe
  54. • briaw005.exe
  55. • fpwwlwf.exe
  56. • epiaw003.exe
  57. • briaw002.exe
  58. • olvsnap.exe
  59. • dmwaudio.exe
  60. • briaw006.exe
  61. • miWApRpl.exe
  62. • caiaw00b.exe
  63. • lxiaw003.exe
  65. Lastly, the communications module also uses different file names than the original Shamoon 2 attack. Instead of setting a custom “kill time” in a file named “usbvideo324.pnf” within the “%WINDOWS%\inf” folder, it uses a file name of “dcT21x400i.pnf”. It also would send the C2 server the contents of a file named “vsfnp7_6.pnf” from the folder “%WINDOWS%\inf” instead of “netimm173.pnf”.
  67. Destruction
  69. Much like the initial attacks, the lack of an operational C2 server suggests that the threat actor’s sole intention for carrying out this Shamoon 2 attack was to destroy data and systems. Without an operational C2, the actor would be unable to issue a command to set a custom “kill time” when the Disttrack payload would begin wiping systems, which would force the payload to rely on its hardcoded “kill time”. The hardcoded date suggests that this attack was set to begin wiping systems on November 29, 2016 at 1:30 AM local Saudi Arabia time.
  71. Unlike the previous Shamoon attacks that occurred on a holiday and over a weekend, this kill time occurred during the work week, as November 29, 2016 was a Tuesday. However, it appears this attack attempted to maximize its impact by occurring very early in the morning before the majority of the organization’s staff were on site. This aligns with the Shamoon actors conducting their attacks off-hours to increase the efficacy of the attack by increasing the timeframe of detection and response.
  73. When Disttrack observes the system clock exceeding the “kill time”, it will save its wiper component to the system using one of the following randomly chosen filenames:
  75. • pdwmtphw.exe
  76. • caiaw00a.exe
  77. • sdwprint.exe
  78. • caiaw00d.exe
  79. • kyiaw002.exe
  80. • sdwscdrv.exe
  81. • briaw00a.exe
  82. • saiaw002.exe
  83. • _mvscdsc.exe
  84. • hdvmp32.exe
  85. • _s3wcap32.exe
  86. • hpiaw001.exe
  87. • lxiaw004.exe
  88. • cniaw001.exe
  89. • lxiaw006.exe
  90. • caiaw00f.exe
  91. • newtvsc.exe
  93. When executed, the wiper component will extract a kernel driver from its resource section and decrypt it with a 172-byte XOR key. The wiper saves the kernel driver (SHA256: 5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a) to the “Windows\System32\Drivers” folder in a file named “vdsk911.sys”. The wiper then uses this file to create a kernel driver service named “vdsk911”, as seen in Figure 2.
  95. shamoon_2
  97. Figure 2 RawDisk kernel driver service created by Disttrack wiper
  99. The kernel driver is the 64-bit version of the commercial RawDisk driver by EldoS Corporation, which is the exact same file as the “drdisk.sys” driver extracted from the Disttrack 64-bit payload in the ‘X509’ resource in the first reported Shamoon 2 attack. The Disttrack payload will use this kernel driver to access the master boot record (MBR), partition tables and files and folders on the system to overwrite them with the same image of the deceased Syrian boy as in the previous Shamoon 2 attack.
  101. During our analysis, we again observed the wiper setting the system time to a random date between August 1 and August 20, 2012, as seen in Figure 3. As mentioned in our previous blog, the reason the wiper sets the system time to this random date in August 2012 is due to a temporary license key needed to use the RawDisk kernel driver. The temporary license key used in this attack is the exact same as the first attack.
  103. shamoon_3
  105. Figure 3 Wiper changing the system date to a random date in August 2012
  107. Since our original blog, we’ve successfully decrypted the license key, which can be seen in Figure 4. The expiration date in the temporary license key is an 8-byte field (highlighted by the orange box) that corresponds to Microsoft’s FILETIME structure, which represents the number of 100-nanosecond intervals since January 1, 1601 (UTC). In the temporary license key used in all of the Shamoon related attacks, the expiration date was set to August 30, 2012 at 8:34:29 UTC, which is the reason the wiper sets the system time to a random day between August 1 and August 20, 2012. Also, we found that the temporary license key was registered to “”. We are unsure how this email address is involved with Shamoon, as it was likely compromised back in 2012 and used by the actor to obtain the temporary license for RawDisk.
  109. shamoon_4
  111. Figure 4 RawDisk temporary license decrypted showing August 2012 expiration date
  113. After the MBR, partition tables and files are overwritten, the wiper issues the command of “shutdown -r -f -t 2” to reboot the system, which is the same command as used in the first Shamoon 2 attack. Figure 5 shows the dialog box that pops up as a result of this command, which will be followed by a system reboot.
  115. shamoon_5
  117. Figure 5 The shutdown dialog box opened just before reboot of a Windows 7 system wiped by Disttrack
  119. The purpose of rebooting the system remains the same, as the portions of the hard disk and filesystem needed to successfully boot the system were overwritten with a JPEG image, the system is no longer able to start up. Figure 6 shows the result of this reboot in an analysis virtual machine, as the operating system could no longer be found.
  121. shamoon_6
  123. Figure 6 System unable to find its operating system
  125. The operating system fails to load as the MBR is overwritten with a JPEG image. As seen in Figure 7, sector 0 of the physical hard disk, which normally stores the master boot record now contains the beginning of a JPEG file marked by the “JFIF” magic bytes in the two orange boxes.
  127. shamoon_7
  129. Figure 7 Hexdump of sector 0 of the physical showing the MBR overwritten with a JPEG file
  131. Conclusion
  132. We analyzed a second Disttrack payload associated with Shamoon 2, which suggests that the threat actors targeted a second Saudi Arabian organization in this attack campaign. The actors used the Disttrack payload to spread to other systems on the local network using legitimate credentials. The legitimate credentials were specific to the targeted organization and were complex enough to suggest that the threat actors carried out a previous attack to obtain the credentials. Also, the actors hardcoded credentials found in Huawei’s official documentation for its VDI solutions, suggesting that the threat actors may have had access to appliances hosting the infrastructure. The Disttrack wiper was set to begin overwriting systems on November 29, 2016 at 1:30 AM, which aligns with the Shamoon actor’s tactic to maximize its impact by attacking at a time when the targeted organization would have less staff and resources available onsite.
  134. Palo Alto Networks customers are protected from the Disttrack payload used in this attack:
  136. WildFire properly classifies Disttrack samples as malicious
  137. Threat protection AV signature of Virus/Win32.WGeneric.ktoto detects the new payload.
  138. AutoFocus customers can monitor Disttrack activity using the Disttrack tag
  139. Indicators of Compromise
  140. Hashes
  142. 010d4517c81bcdc438cb36fdf612274498d08db19bba174462ecbede7d9ce6bb (64-bit Disttrack)
  143. efd2f4c3fe4e9f2c9ac680a9c670cca378cef6b8776f2362ed278317bfb1fca8 (Communication)
  144. 113525c6bea55fa2a2c6cf406184092d743f9d099535923a12cdd9b9192009c4 (Wiper)
  145. 5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a (vdsk911.sys)
  147. Filenames
  149. ntertmgr32.exe
  150. ntertmgr64.exe
  151. vdsk911.sys
  152. dcT21x400i.pnf
  153. vsfnp7_6.pnf
  154. caiaw00e.exe
  155. sbuvideo.exe
  156. caiaw00i.exe
  157. olvume.exe
  158. usinwb2.exe
  159. briaw005.exe
  160. fpwwlwf.exe
  161. epiaw003.exe
  162. briaw002.exe
  163. olvsnap.exe
  164. dmwaudio.exe
  165. briaw006.exe
  166. miWApRpl.exe
  167. caiaw00b.exe
  168. lxiaw003.exe
  169. pdwmtphw.exe
  170. caiaw00a.exe
  171. sdwprint.exe
  172. caiaw00d.exe
  173. kyiaw002.exe
  174. sdwscdrv.exe
  175. briaw00a.exe
  176. saiaw002.exe
  177. _mvscdsc.exe
  178. hdvmp32.exe
  179. _s3wcap32.exe
  180. hpiaw001.exe
  181. lxiaw004.exe
  182. cniaw001.exe
  183. lxiaw006.exe
  184. caiaw00f.exe
  185. newtvsc.exe
  187. Service Names
  189. NtertSrv
  190. vdsk911
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand