Code Spaces: the AWS attack that deleted its backups

Code Spaces was a code-hosting company. Software teams kept their source code and project files on its service [4]. On 17 June 2014 it was hit by a distributed denial-of-service (DDoS) attack, a flood of traffic from many machines at once that makes a service too busy to answer real users [2][5].

While it dealt with the flood, the company found something worse. Someone had got into the Amazon EC2 control panel it used to run its cloud servers [1]. The intruder left messages asking Code Spaces to get in touch through a Hotmail address, and demanded a large fee to stop the DDoS [1][3].

Code Spaces changed its EC2 passwords. It didn’t help. The company said the attacker had already created backup logins to the panel [1]. When the attacker saw the company trying to take the account back, they started deleting things at random from the panel [2].

The company said most of its data, backups, machine configurations and offsite backups were partially or completely deleted [1]. Reports at the time put the whole thing at about 12 hours [3]. Code Spaces then said it would not be able to operate beyond that point. The cost of fixing the damage and refunding customers left it with, in its words, “no alternative but to cease trading” [1][2].

The painful detail is what the company had promised. Code Spaces had advertised full redundancy, real-time backups to several off-site locations, and a recovery plan it said was proven and practised [4]. The backups existed. They were just in reach of the same control panel the attacker now held.

Code Spaces said no machine had been accessed, because the intruder didn’t have its private keys [1]. A private key is the secret file that lets someone log in to a server. It sounds reassuring. Bradley’s video explains why it wasn’t.

AWS, Amazon Web Services, is Amazon’s cloud: companies rent computing power, storage and networking instead of buying the hardware. Amazon EC2 is the AWS service for renting virtual servers, and the AWS console is the web page for creating and managing them [7]. Logging in to a server means getting inside the machine. Using the console means working on the machine from outside: starting it, stopping it, or deleting it outright.

Think of the private keys as the keys to each flat in a building, and the console as the building’s management office. Without the keys you can’t get into the flats. From the office you can still have the whole building knocked down.

In the console, every one of those is something you can delete. So is every login. The account that runs the servers can also delete the backups of those servers, unless someone has deliberately set things up so it can’t. Code Spaces hadn’t.

Bradley’s view in the video is that the DDoS was smoke and mirrors. The deletion didn’t happen because the traffic was heavy. It happened because the attacker had the control panel. One attack made Code Spaces hard to reach. The other erased the way back.

Step 3 is the one incident responders dread. Removing one way in does nothing if the attacker has already made several more. Code Spaces was still trying to lock the account while the attacker carried on working.

No one has ever been identified as the attacker [5]. So unlike many breaches, there is no indictment or court record to check the story against. Almost everything comes from the company’s own statement, as quoted at the time [1][6].

Every move the attacker made in the panel was an AWS API call, so today each one would leave a record in CloudTrail, AWS’s log of actions taken in an account [11]. We don’t know what logging Code Spaces had in 2014, so read this as what you can have now, not as what they missed.

GuardDuty is AWS’s managed threat detection service. It reads CloudTrail and raises findings like the ones above [22]. EventBridge passes events, such as a new login being created, to wherever you want them: an email, a chat channel or a ticket [20].

Bradley’s lesson is not to avoid AWS. It is defence in depth to control the blast radius: how much damage one stolen login can do. His fixes are MFA, least privilege, backups in a separate account and a vault lock. Here is each one as real settings, plus two safety nets. Swap the example account numbers, Region, names and IDs for your own.

Fix 1: MFA on every human login. Multi-factor authentication (MFA) means a password alone isn’t enough to sign in. You also need a code or a security key. AWS recommends it for everyone with console access, and says to keep the root user, the all-powerful owner login of an account, for the few jobs that need it [12]. Since 17 June 2025 AWS has enforced MFA for root users in every type of account [13]. Check the root user has MFA and no access keys, then find any person who signs in with a password but no MFA [15].

Fix 2: an everyday login can’t delete a recovery asset. Bradley says the most powerful credentials shouldn’t be treated like normal logins. This policy refuses the destructive actions from this attack unless the person signed in with MFA [14]. Attach it to the groups your people belong to, not to automation roles, which never carry MFA and would be blocked.

This slows an attacker who has a password or an access key. It won’t stop one who has a full MFA session, which is why the next fix matters most.

Fix 3: keep a copy in another account, and lock it. Bradley calls backups within the attacker’s reach the major architectural flaw in this story. AWS Backup can copy each backup into a vault, a container for backups, in a separate AWS account [16]. The breach catalogue gives the same lesson: keep a copy of critical data in an account that doesn’t run your workloads [5]. Both accounts must be in the same AWS Organizations organisation, and the copy’s vault can’t be the default vault [16].

Then lock the vault. Vault Lock in compliance mode sets a grace time of at least 3 days. After that, the lock can’t be changed or removed by the customer, the account owner or AWS while the vault holds recovery points [17]. Any attempt to delete a backup in a locked vault is refused, even from the root user [17]. Test it in governance mode first if you’re unsure: leaving out the grace time gives governance mode, which people with the right permission can still remove [17].

In the workload account, a backup plan takes a nightly backup into a local vault and copies it to the locked vault. If your resources use a customer managed KMS key, share that key with the backup account [16].

If the originals are deleted, copy the backup from the backup account back to the workload account, then restore it as normal [16]. An attacker who takes over the workload account, as happened to Code Spaces, can’t reach the copies at all.

Safety net: Recycle Bin. Recycle Bin keeps deleted EBS snapshots and AMIs for a set time, so they can be recovered [18]. A rule with no tags covers the whole Region. Locking the rule means it can’t be changed or deleted until an unlock delay of 7 to 30 days has passed [19]. Snapshots and AMIs can be kept for 1 to 365 days [18].

Safety net: alarms on the moves this attacker made. IAM changes, such as a new user or a new password, reach EventBridge through CloudTrail in US East (N. Virginia), whichever Region you work in, so the rule goes there [20]. Save this pattern as iam-changes.json.

The SNS topic’s access policy must allow events.amazonaws.com to publish to it. For a burst of deletes, send CloudTrail to CloudWatch Logs and count the destructive calls [21]. Five in five minutes is a starting point. Set it above what your own automation does on a normal day.

These checks only read settings. They change nothing, so they are safe to run in production.

Bradley ends the video on this. In AWS, servers, disks, server images, buckets, users and backups all become buttons. That is powerful, and just as dangerous. The question isn’t whether one control will protect you. It is how you lock down each part, so that one lost login can’t press every button at once.