Shamoon 2.0
Abstract
Shamoon 1.0 was the first iteration of a destructive disk-wiping attack, first occurring in 2012. Saudi Arabia companies were targeted and lost massive amounts of data. More recently in 2016 a new wave of similar attacks took place (referred to as Shamoon 2.0), once again targeting Saudi companies. Shamoon 2.0 shared many similarities with its predecessor, but with improved qualities (more stealth and autonomic capabilities, among other improvements). The Shamoon attacks join a growing and worrying trend of “slash and burn” attacks, where no data is withheld for ransom - rather, massive amounts of data are simply destroyed.
Disclosure of an attack; Response and Analysis
On 08/15/2012, Saudi Aramco employees across the globe scrambled to disconnect their computers from the network. A virus was sweeping through the oil company’s vast communications infrastructure, simultaneously wiping machines in a coordinated attack on the company. The virus left the incapacitated and disabled, unable to boot. Later that day, a group calling themselves “Cutting Sword of Justice” took responsibility in a Pastebin post2 (08/15/2012 at 2:01pm). They described themselves as an “anti-oppression hacker group”, and stated that they retaliating against the al-Saud regime by targeting their main source of income: the oil industry. They described the general premise of their wiping attack, stating that it had begun at 11:08 am Saudi local time and should be complete in a few hours. The group had waited to attack on one of the holiest days of the Muslim calendar, ensuring that few employees would be at work to interfere with the coordinated wipe.
Statements of the attack from Aramco on the day of the attack downplayed the damage and offered few details, but the company stated that they were taking their networks down as a “preventive measure”. A team from Symantec was flown in from California and began analyzing recovered attack code. Initial reports the following day by security teams at Symantec and Kaspersky described the software in detail. The name “Shamoon” emerged from a string found left behind in the debug code: C:\Shamoon\ArabianGulf\wiper\release\wiper.pdb.
The team at Kaspersky derided it as “copycat, the work of a script kiddie” inspired by the “Wiper” attacks in April of that same year. Each security group however noted the original use of a legitimate 3rd party disk driver, which was used to wipe the master boot record and the partition tables with garbage data to prevent the computer from booting. The teams also remarked on the relative rarity of such targeted, destructive malware. At this time the actual damage incurred by the attack had not been revealed.
In the days following, the full scope of the attack became apparent. Over 35,000 machines had been disabled, with nearly 75% of their network destroyed and the remaining portion offline. Networks related to actual oil production were unaffected, but the entire business side was crippled, resorting to fax machines, type writers, and physical mail while the tens of thousands of new hard drives could be purchased and installed. US intelligence officials quickly pointed fingers at Iran, but offered no evidence. Iran had recently been the target of serious cyberattacks including Stuxnet, Duqu, Gauss, and Flame. A few hints suggested otherwise: traces like language settings (“Arabic-Yemen”) and the use of “Arabian Gulf” (rather than “Persian Gulf”) indicated Yemen as a possible origin, but all available details were recognized as possible false flags. Aramco recovered and brought their communications network back up after a few weeks of rebuilding.
Time Passes; Attack Reemerges Stronger Than Ever
Four years passed without any related activity. Targeted destructive attacks grew in popularity with Sony (“Sony Pictures Hack” in 2014) and South Korea (“Dark Seoul” hack in 2013). In November of 2016 however, two waves of attacks struck again at Saudi infrastructure. Now targeting civilian agencies like the Ministry of Labor as well as petroleum companies (Sandara), the software displayed significant advances from its first, crude iteration. Shamoon 2.0 still targets MS Windows networks using the legit 3rd party disk wiper strategy. Shamoon 2.0 was designed to be much more independent than 1.0, moving itself through the process of infection and wiping without requiring outside command and control servers. It also had hard coded user and admin credentials, allowing it to destroy virtual disk images meant to help recovery from a wiping attack and well as spread itself without needing to escalate privileges through exploit. Shamoon 2.0 featured strong defenses that guarded against detection as well as post-attack analysis.
Technical Issues: A foot in the door
After investigation, X-Force IRIs, which is IBM’s Incident Response and Intelligence Services team, found that the attacker’s point of entry was through a spear phishing email. The attackers using Shamoon relied heavily on weaponized documents built to leverage PowerShell to establish their initial network foothold and subsequent operations. These weaponized documents used macros to run malicious code in the background once the unsuspecting victim opened the file and gave permission to run macros. Had this not been done the attack would have not been possible.
A brief walkthrough of how the attackers gain their unrestricted access to the network is as follows:
-
The attackers send a spear phishing email to employees at the target organization. The email contains a Microsoft Office document as an attachment.
-
Opening the attachment from the email invokes PowerShell and enables command line access to the compromised machine.
-
Attackers can now communicate with the compromised machine and remotely execute commands on it.
-
The attackers use their access to deploy additional tools and malware to other endpoints or escalate privileges in the network.
-
Attackers study the network by connecting to additional systems and locating critical servers.
-
The attackers deploy the Shamoon malware.
-
A coordinated Shamoon outbreak begins and computer hard drives across the organization are permanently wiped.
In this attack, the attackers impersonated the Saudi Arabia’s Ministry of Commerce and Investment and the Egyptian software company IT Worx. Both parties do regular business with Saudi Aramco so the emails did not look out of place at all.
Technical Issues: The Infection
Once a given computer_0 has been infected with the malicious code (installed with a batch file as a service), it is executed by scheduling itself as a task with Windows Task Scheduler. Now, the worm (malicious code) determines its attack space (the other computers/workstations it can interact with) by targeting all computers within the IPv4 address range ( computers with the same first three bytes of the victim’s IP and the last byte in the range from 0 to 255).
Once a given computer_X has been found, the worm attempts to connect to the remote machine’s registry, using low level credentials (a regular worker’s credentials). The infection is first attempted with low level credentials instead of the high level credentials, so that usage of the high level credentials stays limited, so as to maintain a level of stealth.
If it can connect to the remote registry, it disables remote UAC by setting the LocalAccountTokenFilterPolicy registry key value to 1. Once remote UAC is disabled, full remote administrator capabilities are unlocked, and the worm is installed onto the remote machine. Once the worm has been copied onto the remote machine, the infection has successfully propagated, and it will run again - spreading the infection.
If the remote registry can’t be accessed (disabled and couldn’t be restarted), the worm will reconnect with a hardcoded set of administrator credentials and will copy itself directly into the system32 folder, and then subsequently schedule itself as a service task to be run, using Windows Task Scheduler.
Technical Issues: The Wipe
Once the pre-set date and time is reached, the payload is activated simultaneously on all infected machines. The payload consists of a trial version of the ELDOS disk driver software, which allows the malware direct low-level access to the disk, bypassing the Windows disk access API. In order to use the trial version of the software the malware first sets the system date and time to a random date in August 2012, so as to put it in the trial period for the software. Once the ELDOS driver is loaded, it proceeds to wipe the entire hard disk. In the case of the attacks in November ‘16 and January ‘17, the disk was wiped using a photograph of Alan Kurdi, but the wiper can also be configured to wipe the disk with random data. Additionally, the payload includes a public key file which seems to indicate the malware may have ransomware capabilities.
Attack Prevention
The main vector of infection for both the credential theft and the malware installation was malicious Windows Macros contained within spear-phishing emails. As such, a good way to prevent similar attacks would be to restrict, sandbox, or disable Windows Macros, to deny the malware an opportunity to gain a foothold. Additionally, educating users on how to identify and respond to malicious emails would further restrict the malware’s ability to obtain an initial infection.
Frequent password changes, especially to administrator-privileged accounts, would blunt the malware’s ability to spread, considering the amount of time the malware spends spreading the infection before activating. The malware may also be caught by frequently auditing the log-in records for the admin accounts, with the intention of looking for any unusual authorizations for things like file transfers.
Possible Incentives:
The attacks appear to have been politically motivated. Nothing appears to have been stolen and the ransomware capabilities were unused, so there is no clear financial gain for the attackers. Additionally, the photograph used to wipe the disk is of a three-year-old Syrian refugee named Alan Kurdi who died trying to escape from Turkey to Greece. Combined these make it apparent the attack was some kind of politically-motivated revenge on Saudi Arabia, for backing the anti-Assad rebels in Saudi Arabia. The Saudi government says the attacks were backed by Iran, but there is no concrete evidence of this.
The exact financial impact of this attack is not entirely known at the time, and a full list of all the organizations attacked has not been released. However, based on the financial impact on Saudi Aramco in 2012, the damages caused by Shamoon 2.0 could be significant.
Legal and Ethical Issues:
This attack was very clearly illegal and unethical, as it attacked a company and destroyed unknown (likely massive) amounts of data.
Acknowledgements:
This was done without any outside collaboration.
References:
https://arstechnica.com/security/2016/12/shamoon-wiper-malware-returns-with-a-vengeance/
https://securelist.com/files/2017/03/Report_Shamoon_StoneDrill_final.pdf
https://www.scmagazineuk.com/ibm-security-researchers-see-the-whole-of-shamoon/article/638730/