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 source further shows 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’s happening | 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 would assess privileged IAM paths, destructive permissions, account-level administrative concentration and whether identity exposure creates a single point of failure. |
| Credential changes did not stop attacker activity | The commentary highlights that 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 source 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 principal with console or API access, including dormant users, access keys, cross-account trusts and role assumption paths. Confirm incident procedures cover revocation beyond password reset. SkySiege would assess IAM user sprawl, long-lived credentials, root account protections, cross-account role trust and unmanaged administrative access paths. |
| Possible root credential dependence or overuse of persistent privileged identities | The commentary notes the attacker changed passwords rather than simply losing access through user deletion, which may indicate use of root or another highly privileged identity that defenders could not isolate quickly. The source does not explicitly confirm root use, so this remains a risk indicator rather than a proven fact. | 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 would assess root account hygiene indicators, absence of compensating controls around top-tier privileges and overreliance on persistent administrative identities. |
| 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 or logically isolated from the production account, region and credential boundary. Confirm recovery does not depend on the same AWS account being intact. SkySiege would assess backup isolation patterns, shared trust boundaries between production and backup assets and whether snapshot or storage recovery paths can survive account compromise. |
| Detection appears to have occurred late and through visible tampering in the control plane | The commentary notes 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 would assess 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 disaster recovery scenarios that assume full compromise of the primary cloud account, not just infrastructure failure. Test restoration from isolated backups into a separate account. SkySiege would assess whether resilience architecture addresses adversarial deletion, not just accidental outage and whether governance controls validate those assumptions. |
| 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. SkySiege would assess concentration of operational risk in a single cloud account, lack of compensating resilience controls and business impact of unrecoverable service loss. |
This incident is a clear example of cloud control-plane compromise becoming a company-ending event.
Key implications:
Detection gap
The available evidence suggests Code Spaces did not identify the initial access path in time to prevent destructive actions.
If intrusion visibility depended on the attacker visibly altering the control panel, monitoring of IAM activity, console access and destructive API behaviour was inadequate.
In practical terms, this means defenders were reacting to damage, not detecting takeover early.
Visibility gap across AWS identities
The attacker appears to have retained access despite password changes, which points to incomplete visibility into all active credential paths.
That is a common failure when organisations track named users but not access keys, assumed roles, inherited privileges and root-level access.
Without full principal visibility, incident response cannot reliably contain an AWS compromise.
Governance weakness around privileged access
The facts support that a single compromise enabled deletion of production assets at scale.
The commentary also raises a credible concern that highly privileged or root-level access may have remained in use. While root use is not proven by the source, the inability to quickly evict the attacker is consistent with weak governance over top-tier credentials.
This is a governance problem as much as a security problem: privileged access should be minimised, monitored and recoverable under incident conditions.
Backup and resilience control failure
Code Spaces could not restore data, despite marketing a tested recovery capability.
That indicates recovery architecture did not account for the realistic threat of account compromise and malicious deletion.
For enterprise environments, backups that share the same account boundary or administrative trust plane as production are not sufficient for ransomware-style or destructive cloud attacks.
Financial and reputational damage
Code Spaces directly attributed its closure to the combined cost of response, customer refunds and loss of credibility.
This shows how cloud security failures translate immediately into customer churn, contractual exposure and inability to continue operating.
For diligence, this is a material business risk, not just a technical incident.
Compliance and legal exposure
The source does not identify a specific regulatory breach, but destruction of customer-hosted data and inability to recover it would create serious contractual, audit and customer assurance issues.
Any provider holding customer code or business data should expect scrutiny over access control, logging, backup isolation and incident handling evidence.
For security leaders and acquirers, 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.
