> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Iranian strikes on AWS facilities left customer data beyond recovery in Bahrain, UAE - URL: https://f4n6.co.uk/security-feed/iranian-strikes-on-aws-facilities-left-customer-data-beyond-recovery-in-bahrain-uae/ - Published: 2026-09-17T13:58:18.000Z - Updated: 2026-09-17T13:58:18.000Z - Author: Jeff Davies - Tags: #security-feed, Iran ## 1\. Executive summary On 15 September 2026 AWS confirmed that customer data and resources hosted exclusively in its Middle East (Bahrain) region (`me-south-1`) and in one availability zone of its Middle East (UAE) region (`mec1-az2`) are permanently unrecoverable, six months after drone strikes damaged the underlying facilities. No CVE, CVSS score or CISA KEV entry applies to this item: this is a kinetic/physical event, not a software exploitation campaign, and there is no malware, exploited component or atomic indicator set to hunt on. EMEA financial services firms whose only copy of data sat in `me-south-1` or `mec1-az2` have suffered unrecoverable data loss and must treat it as an incident, not an outage. The material risk is concentration: an entire cloud region proved to be a single point of failure, and AWS states the Bahrain damage exceeded what its redundancy design could withstand. Attribution of the strikes to Iran is reported by the source; our reference data holds no MITRE ATT&CK profile for that actor, so actor-level attribution is treated as unconfirmed. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 29: preliminary assessment of ICT concentration risk | AWS states it cannot restore data hosted exclusively in me-south-1, and that Bahrain damage "exceeded what its redundancy design could withstand" — an entire region failed as a unit | Concentration assessments that model provider outage but not physical destruction of a whole region/AZ are now demonstrably incomplete; the assessment must be re-run with a physical/geopolitical destruction scenario and documented | | DORA Art. 30: key contractual provisions with ICT third-party providers | Permanent, unrecoverable loss of customer data in a named region and AZ — the scenario contractual provisions on data return, exit and continuity are written for | Clients must test whether their AWS agreement actually addresses permanent loss: data return/deletion, exit assistance, service credits, termination rights, and what AWS owes when restoration is declared impossible | | DORA Art. 19: reporting of major ICT-related incidents to competent authorities | Where a client's own data was hosted exclusively in me-south-1 or mec1-az2 and is now unrecoverable, that is an ICT-related incident affecting the client, not merely a supplier outage | Such clients must run the incident through their classification process and, if it meets major-incident criteria, follow competent-authority reporting — the six-month lag between the March strikes and the September confirmation does not reset the obligation | ## 3\. Technical analysis & attack chain **This is not a cyber intrusion.** There is no initial access vector, no exploited component, no CVE, no payload, no persistence, no command-and-control, no lateral movement and no exfiltration to describe. The failure mode is physical destruction of data-centre infrastructure, and the defender-relevant consequence is architectural: data whose only copy lived in the affected footprint is gone. **How the operation unfolded (source facts).** Iran's strikes began in early March 2026, in retaliation for a joint US-Israeli military campaign against the country. Gulf states hosting American military bases, including the UAE and Bahrain, became targets. In the UAE, two AWS facilities were directly struck. In Bahrain, a drone strike in close proximity to one AWS facility caused physical impacts to the infrastructure. AWS's own contemporaneous statement described structural damage, disrupted power delivery to its infrastructure, and in some cases fire suppression activities that resulted in additional water damage. Bahrain's situation deteriorated in the weeks that followed: a second availability zone was disrupted in April 2026, taking the region completely offline. **The 15 September 2026 confirmation.** In two updates, AWS stated it can no longer recover customer data and resources stored in: - **`me-south-1` (Middle East / Bahrain)** — AWS is "unable to restore access to the resources and data hosted exclusively in this Region." Damage spread across multiple availability zones and exceeded what its redundancy design could withstand. AWS says it "will share a further update in early 2027." - **`mec1-az2` (Middle East / UAE, one of three AZs)** — AWS is "unable to restore access to the resources and data hosted exclusively in mec1-az2." Work continues on `mec1-az1`, `mec1-az3` and shared regional infrastructure. AWS says it is working on replacing the affected infrastructure and will update on service restoration "in the coming months," and that it has notified the relevant authorities. **Scope of the loss.** The loss is bounded by residency, not by account: it applies to resources and data hosted *exclusively* in the affected locations. Data replicated out of the region, or backed up to a target outside the affected footprint, is not covered by the AWS statement. AWS says most customers in both regions had already relocated before the losses became permanent, "using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data." **Defender-relevant reading.** Two points matter more than the incident narrative. First, same-region AZ failover is not a safe assumption for `me-central-1` while `mec1-az1`, `mec1-az3` and shared regional infrastructure remain under restoration. Second, "backup job succeeded" is not evidence of recoverability — the only meaningful test is a restore from a copy that was physically outside the destroyed footprint. **Confidence caveats.** This entire item is **single-sourced**: one Help Net Security article quoting AWS dashboard updates dated 15 September 2026\. Adverse Trace has not independently retrieved the AWS dashboard text, and the quoted wording should be verified against the AWS Health Dashboard before it is relied on in a regulatory filing. Attribution of the strikes to Iran is as reported by the source; our reference data contains **no MITRE ATT&CK profile for "Iran"**, so we offer no actor mapping and treat actor-level attribution as unconfirmed. The source's closing assessment that AWS Middle East data centres are "unlikely to be spared further attacks" is the publication's judgement, not an AWS statement, and should be treated as forecast rather than fact. ## 4\. Mitigation & containment There is no vendor patch for this item and no software fix. Remediation is architectural and contractual. ### P1 — within 24 hours - Enumerate every workload, S3 bucket, RDS/Aurora instance, EBS snapshot, EFS file system, DynamoDB table and customer-managed backup whose primary or sole residency is `me-south-1` or `me-central-1` (specifically `mec1-az2`). Use AWS Resource Explorer, AWS Config, and a Cost & Usage Report filtered by region to catch resources that no CMDB entry knows about. - Determine whether any data exists **only** in the affected footprint. If yes, escalate through your ICT incident management process immediately and assess against your major-incident classification criteria — do not wait for AWS to declare final state. - **Test a restore, do not read a backup report.** Restore a representative dataset from an out-of-region copy and confirm the backup target itself was not inside the affected region or AZ. A backup job that wrote into `me-south-1` is not a backup. - Freeze decommissioning or cleanup of any affected resources until AWS confirms the final recoverable state, so that evidence and residual data are not destroyed. ### P2 — within 72 hours - Obtain **written** confirmation from your AWS account team of what is recoverable for your specific account and resources. Do not rely on the public dashboard wording, which is region-scoped and not account-scoped. - Re-validate DR runbooks: any plan that fails over to another AZ within `me-central-1` is currently unsound, because `mec1-az1`, `mec1-az3` and shared regional infrastructure are still under restoration. - Review the AWS agreement against the permanent-loss scenario: data return and deletion, exit assistance, service credits, termination rights, and the provider's obligations when restoration is declared impossible (DORA Art. 30). - If you are a DORA-scoped entity and the loss meets major-incident criteria, initiate competent-authority reporting through your existing process (DORA Art. 19). ### P3 — within 7 days - Re-run the ICT concentration risk assessment with physical destruction and geopolitical scenarios included, not just provider outage (DORA Art. 29). Document the outcome. - Re-evaluate residency decisions: any dataset whose only copy sits in a single region or a single AZ is a single point of failure irrespective of provider. - Enforce cross-region replication with **tested** restores, and immutable backups held outside the primary provider's footprint where the data classification warrants it. - Tabletop the scenario end-to-end: detection of region loss, declaration, restore from out-of-region copy, customer and regulator communication. ## 5\. Indicators of compromise No indicators of compromise available in the source material. This is a kinetic/physical event. The sources describe no malware, no exploited component, no command-and-control infrastructure and no atomic artefacts. There are therefore no network, file or host indicators to publish, and no behavioural indicators observable in endpoint or authentication telemetry — the only observable signal is AWS service-health and region-status notification, which is a provider status channel rather than a threat indicator. ## 6\. Detection Insufficient indicators to author detection rules. ## 7\. Sources - Help Net Security — *Iranian strikes on AWS facilities left customer data beyond recovery in Bahrain, UAE* — https://www.helpnetsecurity.com/2026/09/17/aws-middle-east-outage-permanent-data-loss-bahrain-uae/ — 2026-09-17 - AWS Health Dashboard updates of 2026-09-15, as quoted within the above article. No direct URL for the dashboard updates was provided in the source material supplied to Adverse Trace; retrieve and verify the primary text before relying on the quoted wording. ## 8\. Adverse Trace position We assess this as a **high-impact resilience event with no cyber-severity rating attached** — there is no CVE, no CVSS score and no CISA KEV entry, and we will not manufacture one. Client impact is binary and residency-dependent: firms with data hosted exclusively in `me-south-1` or `mec1-az2` have lost it permanently and should be in incident management now; firms with out-of-region copies are largely unaffected operationally but should be re-examining concentration risk and contract terms. The whole item is **single-sourced** to one Help Net Security article quoting AWS dashboard updates, so the quoted AWS wording should be verified against the primary dashboard before it is cited in a regulatory filing, and actor-level attribution to Iran remains unconfirmed in our reference data. We will monitor AWS's stated restoration work on `mec1-az1`, `mec1-az3` and shared regional infrastructure, the Bahrain update AWS says will come in early 2027, and any further strikes against Middle East data-centre infrastructure, and will reissue if the recoverability position changes. --- [Read the original source →](https://www.helpnetsecurity.com/2026/09/17/aws-middle-east-outage-permanent-data-loss-bahrain-uae/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*