{
	"id": "bf700c3a-7430-4c13-8d8b-0878000756ce",
	"created_at": "2026-04-06T00:08:04.213968Z",
	"updated_at": "2026-04-10T03:21:08.975045Z",
	"deleted_at": null,
	"sha1_hash": "ae49f7d2f9c2ca17387060d0ebdb501b020e87dd",
	"title": "Second Wave of Shamoon 2 Attacks Identified",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 715313,
	"plain_text": "Second Wave of Shamoon 2 Attacks Identified\r\nBy Robert Falcone\r\nPublished: 2017-01-09 · Archived: 2026-04-05 16:21:39 UTC\r\nIn November 2016, we observed the reemergence of destructive attacks associated with the 2012 Shamoon attack\r\ncampaign. We covered this attack in detail in our blog titled Shamoon 2: Return of the Disttrack Wiper, which\r\ntargeted a single organization in Saudi Arabia and was set to wipe systems on November 17, 2016. Since our\r\nprevious publication, we have found  another, similar but different payload used to target a second organization in\r\nSaudi Arabia that was configured to wipe systems twelve days later on November 29, 2016. This latest attack\r\npotentially materially impacts one of the primary countermeasures employed against wiper attacks: Virtual\r\nDesktop Interface snapshots.\r\nThe payload used in this attack was very similar to the November 17, 2016 payload, but exhibited slightly\r\ndifferent behaviors and contained hardcoded account credentials specific to the newly targeted organization. The\r\nhardcoded account credentials met Windows password complexity requirements, which suggests that the threat\r\nactors obtained the credentials through a previous, separate attack, similar to the November 17, 2016 attack.\r\nThe most notable thing about this latest sample is that it contains several usernames and passwords from official\r\nHuawei documentation related to their virtual desktop infrastructure (VDI) solutions, such as FusionCloud. VDI\r\nsolutions can provide some protection against a destructive malware like Disttrack through the ability to load\r\nsnapshots of wiped systems. The fact that the Shamoon attackers had these usernames and passwords may suggest\r\nthat they intended on gaining access to these technologies at the targeted organization to increase the impact of\r\ntheir destructive attack. If true, this is a major development and organizations should consider adding additional\r\nsafeguards in protecting the credentials related to their VDI deployment.\r\nAt this time, we have no details of the attack we believe preceded this Shamoon attack to obtain credentials. We\r\nalso have no details on the delivery method used to deliver the new, similar, but different Disttrack payload in this\r\nattack.\r\nThe Second Shamoon 2 Attack\r\nThis second known attack associated with Shamoon 2 also used the Disttrack payload, albeit a new, similar but\r\ndifferent one from the original Shamoon 2 attack. Specifically, it used a 64-bit variant that was configured to begin\r\nits destructive activities on November 29, 2016. Like the Disttrack sample used in the first reported Shamoon 2\r\nattack, it including a wiper and communications module stored in resources within the executable.\r\nTable 1 below shows that the method the Disttrack payload uses to extract and decrypt the modules from resources\r\nis the same; however, the resource names changed from “X509”, “PKCS7” and “PKCS12” to “LANG”, “MENU”\r\nand “ICO”.\r\nComponent Resource Name Offset Size Base64 key\r\nhttps://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/\r\nPage 1 of 10\n\nWiper LANG 94399-14 = 94385 563712 OWRKbTxrleYfLm…\r\nCommunications MENU 218709-14 = 218695 187904 QsCfQA6ze9CoOz…\r\nUnknown ICO Unknown Unknown ijX7buB1FIjSn/0D…\r\nOur efforts to decrypt the “ICO” resource have thus far been unsuccessful as the Disttrack payload has an\r\nassociated key but does not contain code that decrypts and extracts this resource.\r\nPropagation Inside Compromised Networks\r\nSimilar to the previous attack, the Disttrack payload in this attack spreads to other systems on the local network\r\n(/24 network specifically) by logging in using legitimate domain account credentials, copying itself to the system\r\nand creating a scheduled task that executes the copied payload. While this method is the same as discussed in our\r\nprevious blog, the account credentials used in this attack were specific to the targeted organization and the file\r\nnames used when copying the payload to remote systems were different.\r\nLegitimate User Accounts\r\nThere were 16 account credentials found hardcoded within the Disttrack payload, appearing to be a mixture of\r\nindividual user accounts and broader administrator accounts. All but one of the passwords met Windows\r\ncomplexity requirements, specifically, containing uppercase and lowercase characters, and either a number,\r\nsymbol, or both. One of the general administrator accounts seen in this payload was also in the Disttrack payload\r\nin the first Shamoon 2 attack from November 17, 2016, which may not be specific to the targeted organization and\r\ninstead used as an attempt to guess the login credentials. Based upon the existence of these credentials, it is highly\r\nlikely the threat actors had carried out a previous attack to obtain these account credentials, as it is unlikely that\r\nthese passwords were guessed or brute forced.\r\nAs noted earlier, a new development with this latest Disttrack payload is that several of the usernames and\r\npasswords are found within official documentation as administrator accounts for Huawei’s virtualized desktop\r\ninfrastructure (VDI) products, such as FusionCloud. This may suggest that the targeted organization used these\r\ncredentials when deploying Huawei VDI systems. Shamoon actors may have obtained these credentials from a\r\nprior attack; however, it is also possible that the actors included these default usernames and passwords as an\r\nattempt to guess the login credentials to the VDI infrastructure.\r\nVDI solutions can provide some protection against a destructive malware like Disttrack through the ability to load\r\nsnapshots of wiped systems. Also, since FusionCloud systems run a Linux operating system, which would not be\r\nsusceptible to wiping by the Windows-only Disttrack malware, this could be seen as a reasonable countermeasure\r\nagainst attacks like Shamoon. However, if the attacker was able to log into the VDI management interfaces using\r\nthe account credentials they could manually carry out destructive activities against the VDI deployment, as well as\r\nany snapshots. The targeting of VDI solutions with legitimate, stolen or default credential represents an escalation\r\nin tactics that administrators should be aware of and take immediate steps to evaluate and address.\r\nNew Disttrack Names\r\nhttps://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/\r\nPage 2 of 10\n\nThe filenames that the payload copies itself to within the System32 folder of the remote system differs from the\r\npreviously reported attack, specifically using “ntertmgr32.exe” for 32-bit or “ntertmgr64.exe” for 64-bit systems.\r\nThe scheduled task executes these files on the remote system, which results in the creation of a Disttrack service\r\nnamed “NtertSrv” compared to the service name “ntssrv” created by the Disttrack payload used in the November\r\n17, 2016 attacks. This can be seen in Figure 1.\r\nFigure 1 Disttrack service created on systems during propagation\r\nCommand and Control\r\nThe communications module used in this attack is rather hobbled, as it was configured without an operational\r\ncommand and control (C2) server to communicate with. The lack of an operational C2 is much like the November\r\n17, 2016 attack that had the IP address “1.1.1.1” within its configuration to use as a C2 server. Unlike the non-operational C2 of “1.1.1.1” used in the first Shamoon 2 attack, this communications module completely lacked\r\nany IP address or domain name for a C2 server within its configuration.\r\nAlso, in this sample, Disttrack did not save its communications module to the system using the filename\r\n“netinit.exe” like in the original attack, rather it chose a random name from the following list:\r\nhttps://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/\r\nPage 3 of 10\n\n• caiaw00e.exe\r\n• sbuvideo.exe\r\n• caiaw00i.exe\r\n• olvume.exe\r\n• usinwb2.exe\r\n• briaw005.exe\r\n• fpwwlwf.exe\r\n• epiaw003.exe\r\n• briaw002.exe\r\n• olvsnap.exe\r\n• dmwaudio.exe\r\n• briaw006.exe\r\n• miWApRpl.exe\r\n• caiaw00b.exe\r\n• lxiaw003.exe\r\nLastly, the communications module also uses different file names than the original Shamoon 2 attack. Instead of\r\nsetting a custom “kill time” in a file named “usbvideo324.pnf” within the “%WINDOWS%\\inf” folder, it uses a\r\nfile name of “dcT21x400i.pnf”. It also would send the C2 server the contents of a file named “vsfnp7_6.pnf” from\r\nthe folder “%WINDOWS%\\inf” instead of “netimm173.pnf”.\r\nDestruction\r\nMuch like the initial attacks, the lack of an operational C2 server suggests that the threat actor’s sole intention for\r\ncarrying out this Shamoon 2 attack was to destroy data and systems. Without an operational C2, the actor would\r\nbe unable to issue a command to set a custom “kill time” when the Disttrack payload would begin wiping systems,\r\nwhich would force the payload to rely on its hardcoded “kill time”. The hardcoded date suggests that this attack\r\nwas set to begin wiping systems on November 29, 2016 at 1:30 AM local Saudi Arabia time.\r\nUnlike the previous Shamoon attacks that occurred on a holiday and over a weekend, this kill time occurred\r\nduring the work week, as November 29, 2016 was a Tuesday. However, it appears this attack attempted to\r\nmaximize its impact by occurring very early in the morning before the majority of the organization’s staff were on\r\nsite. This aligns with the Shamoon actors conducting their attacks off-hours to increase the efficacy of the attack\r\nby increasing the timeframe of detection and response.\r\nWhen Disttrack observes the system clock exceeding the “kill time”, it will save its wiper component to the\r\nsystem using one of the following randomly chosen filenames:\r\n• pdwmtphw.exe\r\n• caiaw00a.exe\r\n• sdwprint.exe\r\n• caiaw00d.exe\r\n• kyiaw002.exe\r\n• sdwscdrv.exe\r\nhttps://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/\r\nPage 4 of 10\n\n• briaw00a.exe\r\n• saiaw002.exe\r\n• _mvscdsc.exe\r\n• hdvmp32.exe\r\n• _s3wcap32.exe\r\n• hpiaw001.exe\r\n• lxiaw004.exe\r\n• cniaw001.exe\r\n• lxiaw006.exe\r\n• caiaw00f.exe\r\n• newtvsc.exe\r\nWhen executed, the wiper component will extract a kernel driver from its resource section and decrypt it with a\r\n172-byte XOR key. The wiper saves the kernel driver (SHA256:\r\n5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a) to the “Windows\\System32\\Drivers”\r\nfolder in a file named “vdsk911.sys”. The wiper then uses this file to create a kernel driver service named\r\n“vdsk911”, as seen in Figure 2.\r\nFigure 2 RawDisk kernel driver service created by Disttrack wiper\r\nhttps://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/\r\nPage 5 of 10\n\nThe kernel driver is the 64-bit version of the commercial RawDisk driver by EldoS Corporation, which is the\r\nexact same file as the “drdisk.sys” driver extracted from the Disttrack 64-bit payload in the ‘X509’ resource in the\r\nfirst reported Shamoon 2 attack. The Disttrack payload will use this kernel driver to access the master boot record\r\n(MBR), partition tables and files and folders on the system to overwrite them with the same image of the deceased\r\nSyrian boy as in the previous Shamoon 2 attack.\r\nDuring our analysis, we again observed the wiper setting the system time to a random date between August 1 and\r\nAugust 20, 2012, as seen in Figure 3. As mentioned in our previous blog, the reason the wiper sets the system time\r\nto this random date in August 2012 is due to a temporary license key needed to use the RawDisk kernel driver.\r\nThe temporary license key used in this attack is the exact same as the first attack.\r\nFigure 3 Wiper changing the system date to a random date in August 2012\r\nSince our original blog, we’ve successfully decrypted the license key, which can be seen in Figure 4. The\r\nexpiration date in the temporary license key is an 8-byte field (highlighted by the orange box) that corresponds to\r\nMicrosoft’s FILETIME structure, which represents the number of 100-nanosecond intervals since January 1, 1601\r\n(UTC). In the temporary license key used in all of the Shamoon related attacks, the expiration date was set to\r\nAugust 30, 2012 at 8:34:29 UTC, which is the reason the wiper sets the system time to a random day between\r\nAugust 1 and August 20, 2012. Also, we found that the temporary license key was registered to\r\n“binnatova@bsunanotechnology.com”. We are unsure how this email address is involved with Shamoon, as it was\r\nlikely compromised back in 2012 and used by the actor to obtain the temporary license for RawDisk.\r\nhttps://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/\r\nPage 6 of 10\n\nFigure 4 RawDisk temporary license decrypted showing August 2012 expiration date\r\nAfter the MBR, partition tables and files are overwritten, the wiper issues the command of “shutdown -r -f -t 2” to\r\nreboot the system, which is the same command as used in the first Shamoon 2 attack. Figure 5 shows the dialog\r\nbox that pops up as a result of this command, which will be followed by a system reboot.\r\nFigure 5 The shutdown dialog box opened just before reboot of a Windows 7 system wiped by Disttrack\r\nThe purpose of rebooting the system remains the same, as the portions of the hard disk and filesystem needed to\r\nsuccessfully boot the system were overwritten with a JPEG image, the system is no longer able to start up. Figure\r\n6 shows the result of this reboot in an analysis virtual machine, as the operating system could no longer be found.\r\nhttps://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/\r\nPage 7 of 10\n\nFigure 6 System unable to find its operating system\r\nThe operating system fails to load as the MBR is overwritten with a JPEG image. As seen in Figure 7, sector 0 of\r\nthe physical hard disk, which normally stores the master boot record now contains the beginning of a JPEG file\r\nmarked by the “JFIF” magic bytes in the two orange boxes.\r\nFigure 7 Hexdump of sector 0 of the physical showing the MBR overwritten with a JPEG file\r\nConclusion\r\nWe analyzed a second Disttrack payload associated with Shamoon 2, which suggests that the threat actors targeted\r\na second Saudi Arabian organization in this attack campaign. The actors used the Disttrack payload to spread to\r\nother systems on the local network using legitimate credentials. The legitimate credentials were specific to the\r\ntargeted organization and were complex enough to suggest that the threat actors carried out a previous attack to\r\nobtain the credentials. Also, the actors hardcoded credentials found in Huawei’s official documentation for its VDI\r\nsolutions, suggesting that the threat actors may have had access to appliances hosting the infrastructure. The\r\nDisttrack wiper was set to begin overwriting systems on November 29, 2016 at 1:30 AM, which aligns with the\r\nhttps://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/\r\nPage 8 of 10\n\nShamoon actor’s tactic to maximize its impact by attacking at a time when the targeted organization would have\r\nless staff and resources available onsite.\r\nPalo Alto Networks customers are protected from the Disttrack payload used in this attack:\r\nWildFire properly classifies Disttrack samples as malicious\r\nThreat protection AV signature of Virus/Win32.WGeneric.ktoto detects the new payload.\r\nAutoFocus customers can monitor Disttrack activity using the Disttrack tag\r\nIndicators of Compromise\r\nHashes\r\n010d4517c81bcdc438cb36fdf612274498d08db19bba174462ecbede7d9ce6bb (64-bit Disttrack)\r\nefd2f4c3fe4e9f2c9ac680a9c670cca378cef6b8776f2362ed278317bfb1fca8 (Communication)\r\n113525c6bea55fa2a2c6cf406184092d743f9d099535923a12cdd9b9192009c4 (Wiper)\r\n5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a (vdsk911.sys)\r\nFilenames\r\nntertmgr32.exe\r\nntertmgr64.exe\r\nvdsk911.sys\r\ndcT21x400i.pnf\r\nvsfnp7_6.pnf\r\ncaiaw00e.exe\r\nsbuvideo.exe\r\ncaiaw00i.exe\r\nolvume.exe\r\nusinwb2.exe\r\nbriaw005.exe\r\nfpwwlwf.exe\r\nepiaw003.exe\r\nbriaw002.exe\r\nolvsnap.exe\r\ndmwaudio.exe\r\nbriaw006.exe\r\nmiWApRpl.exe\r\ncaiaw00b.exe\r\nlxiaw003.exe\r\npdwmtphw.exe\r\ncaiaw00a.exe\r\nsdwprint.exe\r\ncaiaw00d.exe\r\nkyiaw002.exe\r\nhttps://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/\r\nPage 9 of 10\n\nsdwscdrv.exe\r\nbriaw00a.exe\r\nsaiaw002.exe\r\n_mvscdsc.exe\r\nhdvmp32.exe\r\n_s3wcap32.exe\r\nhpiaw001.exe\r\nlxiaw004.exe\r\ncniaw001.exe\r\nlxiaw006.exe\r\ncaiaw00f.exe\r\nnewtvsc.exe\r\nService Names\r\nNtertSrv\r\nvdsk911\r\nSource: https://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/\r\nhttps://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/"
	],
	"report_names": [
		"unit42-second-wave-shamoon-2-attacks-identified"
	],
	"threat_actors": [],
	"ts_created_at": 1775434084,
	"ts_updated_at": 1775791268,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ae49f7d2f9c2ca17387060d0ebdb501b020e87dd.pdf",
		"text": "https://archive.orkl.eu/ae49f7d2f9c2ca17387060d0ebdb501b020e87dd.txt",
		"img": "https://archive.orkl.eu/ae49f7d2f9c2ca17387060d0ebdb501b020e87dd.jpg"
	}
}