CyphrQ
Menu

Shamoon and Saudi Aramco 2012: What the Wiper Destroyed

What the Shamoon wiper did to Saudi Aramco in 2012, how destructive malware works, what Aramco says it learned, and the controls to check.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

Incident: August 20129 min read

What was the Shamoon attack on Saudi Aramco? In August 2012, as the Eid holiday began, Saudi Aramco was hit by what its CEO later called "a serious virus attack." Shamoon is a wiper: malware built to destroy data and make computers unbootable, not to steal or ransom it. Aramco says its core operations continued and "not a single process or product was affected."

This is a case file. It separates what Aramco and government sources say from what we could not confirm, and it ends with what to check in your own organisation.

Case file

Field Value
Organisation Saudi Arabian Oil Company (Saudi Aramco)
Region Saudi Arabia
Breach date August 2012. Aramco's CEO: "In August 2012, as the Eid holiday was starting, Saudi Aramco was hit by a serious virus attack" (Aramco, 2020 speech)
Disclosed Aramco's own account that we could read is a retrospective speech given on 4 February 2020. We could not open its 2012 press statement (see below)
People affected No count of people, records or computers is given in the Aramco page we read. Not a data theft: the malware's purpose was destruction
Data types Not a personal-data breach as described by Aramco. MITRE describes the malware as overwriting operating-system files and disk structures (MITRE ATT&CK S0140)
Penalty/action No penalty or action appears in what we read
Regulator Our sources name no regulator. The US government published a joint security awareness report on the malware, JSAR-12-241-01B (CISA)
Status Historical. Later variants are described by MITRE; the 2012 attacker is not identified in the sources we read

When did Shamoon hit Saudi Aramco, and what do we know?

Aramco's CEO, Amin H. Nasser, described the attack at the first Global Cybersecurity Forum in Riyadh on 4 February 2020: "In August 2012, as the Eid holiday was starting, Saudi Aramco was hit by a serious virus attack" (Aramco).

He credited contingency and business continuity plans, and the company's broader resilience. His words: "our core operations continued and not a single process or product was affected."

That is the primary account we could read in full. The speech does not name the malware, and it gives no figures for downtime, cost or number of machines.

What numbers are missing from this case file, and why?

Press coverage in 2012 put a number on the affected workstations. We have left it out. We could not open Aramco's original 2012 statement on aramco.com (the address we tried returned an error), and our rule is that no figure goes in unless we read it on the page we cite. If you have a copy of that statement, the owner can add the number with a link.

We also did not find a government advisory that names Aramco. The US report we could confirm exists, JSAR-12-241-01B, "Shamoon/DistTrack Malware (Update B)", appears as a link on a CISA page listing historical cyber campaigns. The CISA page does not name a threat actor, and we could not open the report itself (CISA).

What does the Shamoon wiper actually destroy?

MITRE ATT&CK keeps a profile of the malware as software entry S0140 (MITRE). It describes the malware as overwriting operating-system files and disk structures, then rebooting the infected system when the wiping finishes.

In plain terms, a computer needs a few small structures to start up. The best known is the master boot record (MBR): the first sector of a disk, which tells the machine where its operating system is. Destroy that and the machine won't boot, even if some files survive. ATT&CK's page on this technique says adversaries damage "the disk structures a system needs to boot, such as the master boot record (MBR) or partition table," and that this can target "many systems across a network to disrupt availability" (MITRE T1561.002).

Three details from the Shamoon profile matter for planning:

  • It waits. The malware checks the system time and activates only after a preset date.
  • It spreads inside the network. It copies itself to other machines over Windows administrative shares, and where its current rights fail it uses hard-coded domain credentials gathered earlier.
  • Later variants changed the payload. ATT&CK says a later variant overwrote data with randomly generated content instead of an image, and that the malware has a mode that encrypts instead of overwriting. Newer versions use service names such as "MaintenaceSrv" and "hdv_725x".

The first two are the planning lessons. A date-triggered wiper means a quiet intrusion can sit for a while. Domain credentials mean it can reach many machines at once.

How is a wiper different from ransomware?

Ransomware encrypts your data and offers a way back for a fee. A wiper offers no way back. The attacker's goal is the outage itself.

That changes your response plan. You can't negotiate or buy a key. Recovery depends entirely on what you can rebuild and restore: clean images, offline backups and a tested order for bringing systems back. Aramco's own summary of its resilience is the one that matters here: the business kept running because it had plans for exactly this.

What did Saudi Aramco say it learned from Shamoon?

The 2020 speech lists three lessons, in the CEO's words (Aramco):

  1. "Perfect cybersecurity does not exist."
  2. "Like managing blood pressure, our battle with this equally silent killer is continuous."
  3. "And we need to do all we can to stay a step ahead."

Those are Aramco's. What follows is our reading, not Aramco's or any regulator's: a destructive attack is an availability problem as much as a security problem. The question for a board is not only "can we keep attackers out?" but "how long can we operate if every office computer stops?"

What should security teams take from the Shamoon attack on Aramco?

The structure of the Aramco incident, as Aramco describes it, is: a destructive attack on a large corporate environment, with core operations continuing. We don't have the technical details of what separated the two inside Aramco, because its own page doesn't say. What we can say is which general controls US government guidance recommends against destructive malware, and that these map to the way Shamoon behaves.

Going deeper: for security and IT teams

Threat model. A wiper operator wants disruption, not data. They need a foothold, credentials with wide reach, and a way to run code on many machines at about the same time. What they get is a timed outage across the estate. Shamoon's profile fits that: a preset activation date, spread over network shares, and credentials gathered earlier (MITRE S0140).

ATT&CK mapping. We opened the Shamoon software page and the Disk Structure Wipe technique page. The IDs below come from those pages. We did not open the other technique pages, so we only list their names as ATT&CK gives them for this malware.

Behaviour on the Shamoon profile ATT&CK ID Opened technique page?
Overwrites the MBR and other disk structures T1561.002 Disk Structure Wipe Yes
Overwrites files with image or random data T1485 Data Destruction No
Spreads through admin shares T1021.002 SMB/Windows Admin Shares No
Copies itself to other hosts T1570 Lateral Tool Transfer No
Runs as a service ("ntssrv") masquerading as a time service T1543.003, T1036.004 No
Uses gathered domain credentials T1078.002 Valid Accounts: Domain Accounts No
Waits for a preset date T1124 System Time Discovery No
Reboots after wiping T1529 System Shutdown/Reboot No

Detection. ATT&CK's detection strategy for Disk Structure Wipe (DET0297) includes analytic AN0827: flag processes that access raw disks, such as \\.\PhysicalDrive, to overwrite the MBR or partition table, correlating process creation, privilege escalation and raw sector writes in Sysmon and Security logs (MITRE). That is a late signal. By then the wipe is under way, so pair it with earlier signals:

  • new services created across many hosts in a short window, especially with names imitating Windows components
  • admin-share (SMB) writes of an executable from one host to many
  • a domain account authenticating to an unusual number of machines
  • a scheduled task created remotely on endpoints that do not normally receive one

Controls. MITRE lists one mitigation for the wipe technique itself: M1053 Data Backup, meaning regular off-system backups protected from adversary access. CISA's alert on a different destructive-malware incident, TA14-353A (December 2014, about a major entertainment company), gives a broader list (CISA). That alert does not mention Shamoon, so treat it as a parallel case, not as Shamoon guidance. Its wiper also overwrites the MBR and spreads through Windows shares. Its recommendations include:

  • daily backups and periodic offline backups of critical files
  • isolating critical networks from business systems
  • restricting account privileges, using standard accounts for daily work, and rotating admin passwords
  • limiting credential caching
  • segmenting networks with VLANs to limit spread
  • two-factor authentication for privileged accounts
  • centralised, actively monitored logging
  • application whitelisting and software restriction policies

The alert also points to CISA's Security Tip ST13-003, "Handling Destructive Malware", for planning and response.

Why Aramco's continuity matters technically. Aramco says core operations kept running. We can't tell you which segmentation or architecture decisions made that possible, because its page doesn't say. For your own estate, make it testable: can the systems that produce or deliver your product keep running if every corporate Windows machine is wiped?

What to verify or ask.

  • Where are our last known-good backups, and can a compromised domain admin reach them?
  • If our directory service is wiped, can we rebuild identity first, and how long does that take? Have we tested it?
  • Do we have clean machine images and an order of recovery written down?
  • Which accounts can write to admin shares on every workstation? Should any single account be able to?
  • Do we alert on mass service creation or raw-disk writes, and who is paged?
  • Do our suppliers and managed service providers hold credentials with that reach?

How do you prepare for a wiper in the next 90 days?

  1. Pick the three systems you could not run without. Write down how you would restore each from nothing.
  2. Take one offline backup of them and do a restore test. Time it.
  3. List accounts with local admin or share-write rights on many machines. Cut the list.
  4. Turn on logging that would show a service or scheduled task appearing on many hosts at once.
  5. Run a short tabletop exercise: "Every office computer won't boot on Monday morning. What do we do first?"

Learn more

Key takeaways

  • Shamoon is a wiper. It destroys data and disk structures so machines won't boot; there is no ransom and no key.
  • Aramco's CEO says the August 2012 attack hit as Eid began, and that "not a single process or product was affected."
  • We could not read Aramco's 2012 statement, so this case file gives no machine count. Aramco's 2020 speech gives none.
  • MITRE describes later Shamoon variants with new payloads, including overwriting with random data.
  • Aramco's lessons: perfect cybersecurity does not exist, the effort is continuous, and you need to stay a step ahead.
  • The cheapest preparation is a restore test of your critical systems and a limit on how many accounts can reach many machines.

For other breach case files from the region, see the Middle East and North Africa breaches page.

Sources