Code Spaces shut down after an unauthorised party accessed its AWS account and permanently deleted most customer data, including Apache Subversion repositories, Elastic Block Store volumes and all virtual machines, leaving the company unable to restore service.
Code Spaces said the financial cost of response and customer refunds, combined with loss of credibility, made continued operation impossible. The incident shows that a claimed recovery plan is not meaningful if identity access is not tightly controlled, monitored and recoverable during an account-level compromise. The available evidence also raises concern that the attacker retained destructive access even after password changes, indicating weak visibility into AWS users and roles and possible use of highly privileged credentials. The report further showed there were no isolated external backups capable of surviving compromise of the primary AWS account. Detection also appears to have been weak: the intrusion was noticed only after the attacker could log in and leave messages on the control panel, suggesting poor audit visibility into the initial access path and subsequent privilege use. For cloud-dependent businesses, this is both a security failure and a governance failure with direct existential business impact.
| What Happened | Cause | Action |
|---|---|---|
| AWS account compromise led to full environment destruction | Code Spaces reported unauthorised access to its AWS account, followed by deletion of most repositories, EBS volumes and all virtual machines. The available evidence indicates the attacker had broad destructive permissions at the account level. | Validate all high-privilege AWS identities, including root, IAM users and assumable roles. Confirm no single identity can delete core infrastructure and backup assets without additional controls. SkySiege assesses privileged IAM paths, destructive permissions, account-level administrative concentration and whether identity exposure creates a single point of failure including root accounts. |
| Credential changes did not stop attacker activity | The attacker worked around changed passwords. That indicates weak visibility into all usable access paths, including IAM users, roles, access keys or root access. The report does not confirm the exact mechanism, but continued access despite password changes is evidence of incomplete identity containment. | Validate inventory and monitoring of every AWS identity with console or API access, including dormant users, access keys, cross-account trusts and role assumption paths. SkySiege surfaces IAM user sprawl, long-lived credentials, root account protections, cross-account role trust and unmanaged administrative access paths for maximum visibility to avoid these issues. |
| Possible root credential dependence or overuse of persistent privileged identities | The report states that the attacker changed passwords rather than simply losing or gaining access through user deletion or creation, which may indicate use of root AWS account user usage. | Validate whether the AWS root user is protected with MFA, unused for operations and excluded from day-to-day administration. Confirm break-glass controls are documented and monitored. SkySiege actively tests the controls on the AWS root user for this reason. |
| Recovery plan failed because backups were not isolated from the compromised account | Code Spaces said it had no way to restore the data after the destructive activity. That directly indicates backups and recovery assets were either deleted, inaccessible, insufficient or not isolated from the compromised AWS control plane. | Validate that backups are immutable and logically isolated from the production account, region and credential boundary. Confirm recovery does not depend on the same AWS account being intact. |
| Detection appears to have occurred late and through visible tampering in the control plane | The attacker was able to log in and leave messages on the control panel, likely through renamed tags and that this was how the intrusion was noticed. This suggests limited visibility into the initial compromise and delayed detection of destructive actions. | Validate CloudTrail coverage, retention, alerting for IAM changes, mass deletion activity, console logins and anomalous tagging or resource renaming. Confirm detections trigger before destructive impact. SkySiege assesses cloud audit coverage, logging gaps, lack of detections for privilege misuse and whether customer environments can identify account takeover before widespread deletion. |
| Business continuity depended on claims rather than tested resilience under account takeover | Code Spaces publicly promoted a “full recovery plan” that was “practiced,” yet the company could not recover after the AWS compromise. The failure was not only technical recovery but recovery from hostile control-plane takeover. | Validate and action disaster recovery scenarios that include full compromise of the primary cloud account, not just infrastructure failure. Test restoration from isolated backups into a separate account. |
| The company faced immediate financial and credibility collapse after the incident | Code Spaces said response costs, expected customer refunds and ongoing credibility damage made continued operation impossible. This shows direct linkage between cloud control failure and enterprise viability. | Validate that risk ownership includes existential cloud dependency scenarios, contractual exposure and customer restitution risk. |
This incident is a clear example of cloud control-plane compromise becoming a company-ending event.
For security leaders, acquirers and potential acquisition targets with a presence in the cloud, the lesson is clear: recovery claims, least-privilege claims and IAM governance claims must be validated against the scenario that matters most-compromise of the cloud account itself. If privileged identities are not fully visible and backups are not isolated outside the blast radius of that account, the organisation may not be able to recover at all.
