Anatomy of a Real AWS Breach: Code Spaces, 2014

On June 17, 2014, Code Spaces, a project hosting and source code management service, was hit with a distributed denial-of-service attack. That alone would have been an ordinary, survivable incident. What actually ended the company, permanently, within about 12 hours, was that the same attacker had also gained access to Code Spaces' AWS control panel.

What Happened

Alongside the DDoS, the attacker left extortion demands in Code Spaces' AWS EC2 console, along with a contact address, and demanded payment to stop the attack. When Code Spaces' team attempted to regain control of the account instead of paying, they discovered the attacker had already created several backup logins of their own inside the account. Watching the recovery attempt in real time, the attacker began deleting resources: Elastic Block Store (EBS) snapshots, Amazon S3 buckets, Amazon Machine Images (AMIs), and a number of EC2 instances, largely at random, across the account.

By the time Code Spaces regained exclusive control, most of their data, including their backups, was gone. The company never recovered and shut down permanently.

Why This Wasn't Really About AWS

It's tempting to read this as "AWS let a company get destroyed." That's not what happened. Every action the attacker took, deleting snapshots, buckets, AMIs, instances, was a legitimate action available to whoever held valid, authenticated access to that AWS account. The infrastructure worked exactly as designed. The failure was entirely on the access-control and architecture side, and it's a failure still worth studying because the same two root causes show up constantly today.

The Two Root Causes

1. A Single, Compromised Point of Access

However the attacker initially obtained access to the AWS console, the account did not have layered protection strong enough to prevent one compromised credential from granting full, unrestricted control. Multi-factor authentication on the root and administrative access, combined with IAM users scoped to only what each person or system actually needs, turns "one stolen password" from a company-ending event into a contained incident.

2. Backups Living in the Same Blast Radius as Production

This is the lesson that outlived the company. Code Spaces' backup strategy relied on the same AWS account, and largely the same access, as their production infrastructure. Once the attacker had administrative access to the account, there was no independent, isolated copy of the data left to recover from. A backup that can be deleted by the same compromised credentials protecting production isn't really a backup, it's just another copy inside the same blast radius.

The Specific Controls That Would Have Prevented This

• MFA enforced on root and all privileged IAM users. This alone would very likely have stopped the attacker from ever reaching the console in the first place.
• Least-privilege IAM, no single credential with account-wide delete access. Separating who can delete production resources from who can delete backups limits how much damage any single compromised credential can do.
• Backups isolated from the primary account's blast radius, a separate AWS account with tightly restricted cross-account access, immutable/versioned storage, or offline copies, so a compromise of the primary account can't reach the recovery path.
• Alerting on anomalous administrative activity, mass resource deletion is exactly the kind of pattern that should trigger an immediate, automated alert, not be discovered after the fact.

A decade later, "our backups live in the same account as production, protected by the same credentials" is still one of the most common gaps a real AWS security review finds. Code Spaces is the case study for why that specific gap is existential, not theoretical.

Sources: contemporaneous reporting from The Hacker News, CSO Online, and PCWorld (June-July 2014), and Code Spaces' own public statement at the time of the incident.