Breaches

Ransomware-hit IDCF Cloud says only customer backups can restore data

SoftBank’s IDC Frontier says data in four ransomware-hit IDCF Cloud zones can only be restored from customers’ own backups. Lessons for UK cloud users.

Illustration of a server rack with the headline 'Cloud ransomware leaves customers relying on backups'

A ransomware attack on SoftBank-owned IDC Frontier has left customers of four of its IDCF Cloud zones with data the provider says it probably cannot recover. Anyone without their own backup is now rebuilding from scratch, and downstream victims including JR East are counting the cost.

What happened

IDC Frontier, the cloud and data centre arm of Japan’s SoftBank, has been dealing with an intrusion into its IDCF Cloud platform since around 03:40 Japan time on Wednesday 7 October. In its second update the same day, the company named ransomware as the cause. The damage is concentrated in East Japan Region 1, and IDC Frontier says 495 businesses and local authorities that rent infrastructure there have been affected and are being contacted individually.

The most important development came in the provider’s third report on 8 October. IDC Frontier said customer data held in the tesla, henry, pascal and joule zones of that region looked difficult to extract or restore. In its current view, recovery is only possible from backups that customers keep themselves. Affected customers have been told to stand up a separate environment and rebuild. Customers in the unaffected zones and regions, where no intrusion has been confirmed, have been told to start taking their own backups.

A fourth report on 9 October set out a joint response with the parent company, run from an emergency headquarters opened at 09:00 on 7 October. SoftBank’s enterprise division is now the customer contact point, offering backup instructions and proposals to migrate to other environments, and SoftBank engineers are supporting the forensic and recovery work. The incident has been reported to the supervising ministries and the Tokyo Metropolitan Police.

The technical picture

The intrusion route, the identity of the attackers, any ransom demand and whether data was stolen before encryption all remain undisclosed. IDC Frontier isolated East Japan Region 1 on day one and suspended internet-facing management consoles in every region pending checks.

The attacker’s own account is more dramatic but unverified. According to BleepingComputer and Cybernews, screenshots of a message left by the attacker on the management interface claim the whole operation took seven minutes. The message claims access to 239 hypervisors, encryption of 225 storage systems or databases holding 3.6 petabytes, more than 16,000 sealed virtual machine disks and the deletion of 554,153 snapshots. Neither outlet could confirm these figures, and Cybernews reports that the note does not name any known ransomware brand.

Even if those figures are inflated, the provider’s own recovery statement suggests the attacker reached the virtualisation or storage layer, not just a few tenant machines. Most cloud customers never plan for that.

Downstream customers are now counting the cost. On 9 October JR East said the incident had hit an external email delivery service it uses, so email log data for up to about 1.67 million members of its Ekinet booking service and about 390,000 members of its Otona no Kyujitsu Club may have been viewed or taken. Club members’ membership numbers, card expiry dates and birth dates may also be exposed, though JR East says full card numbers and addresses are not. Cybernews puts the combined JR East and View Card figure at up to 6.09 million records and reports that JR Kyushu disclosed around 1.3 million emails. Six Apart, with 31 Movable Type Cloud servers affected, is migrating them to Sakura Cloud from its own backups. Nissui Logistics reported an outage after suspected unauthorised access at a third-party data centre, but BleepingComputer says no link to IDCF has been established.

Timeline of the IDCF Cloud ransomware incident from 7 to 9 October 2026

Why it matters for UK organisations

IDCF Cloud is a Japanese service, so few UK organisations will be direct customers. The lesson still applies to any UK organisation running workloads on rented infrastructure. Many host with smaller providers, managed service providers or SaaS vendors running on someone else’s hypervisors, and treat the provider’s snapshots as their disaster recovery plan. This incident shows what happens when that assumption fails: the provider tells you, in effect, that your data is gone unless you kept a copy elsewhere.

There is also a supply chain dimension that should concern UK data controllers. JR East’s exposure did not come from its own estate but from an email delivery service that happened to run on the affected platform. Under UK GDPR, a controller remains accountable for personal data its processors handle, and the ICO expects breaches to be reported within 72 hours of the controller becoming aware. Organisations that cannot quickly say which of their suppliers run on which platforms will struggle to meet that clock when a provider two steps down the chain is hit.

The NCSC has published guidance on exactly this problem in its principles for ransomware-resistant cloud backups. The principles call for backups that resist deletion and tampering, for soft-delete protection and for destructive actions to be authorised out of band.

Expert view

In my experience, shared responsibility is well understood on paper and poorly understood in practice. When we review cloud estates, we regularly find that the only copy of production data outside the live volumes is a provider-managed snapshot in the same account, region and control plane. That covers a deleted file or a bad patch, not someone holding the keys to the platform.

The seven-minute claim deserves scepticism, but speed is the real point. Automated destruction across hundreds of hosts leaves no window for a human to intervene, so the only controls that count are the ones already in place: immutability, separation of credentials and copies the attacker cannot reach. IDC Frontier’s advice to rebuild elsewhere is also sound: restoring into infrastructure with an unknown intrusion route risks giving the attacker a second go.

Finally, this is another reminder that concentration risk is not only about the hyperscalers. One mid-sized provider underpinned railway customer emails, web publishing platforms and local government services. The UK’s Cyber Security and Resilience Bill is designed to bring more managed service providers into regulatory scope precisely because of failures like this.

What to do now

  1. Find out where your data really lives. List every IaaS, hosting and SaaS supplier that holds personal or business-critical data, including the platforms your suppliers themselves depend on.
  2. Keep at least one backup outside the provider’s control plane. Use a different provider, account and set of credentials, with immutability or retention locks so it cannot be deleted from a compromised admin session.
  3. Test restoring into a clean environment. Prove you can rebuild critical services somewhere else within your recovery time objective, not just restore files.
  4. Lock down management access. Enforce phishing-resistant MFA and least privilege on cloud consoles and hypervisor management, in line with the Cyber Essentials controls for user access control and secure configuration. Alert on mass snapshot or volume deletion.
  5. Update supplier contracts and incident plans. Require prompt notification from processors and sub-processors, and rehearse your ICO 72-hour reporting decision for a third-party breach.

Bottom line

IDC Frontier’s admission that recovery depends on backups held by customers is the clearest statement yet of where responsibility sits when a cloud platform itself is compromised. If your only backup lives on the same platform as your production data, you should treat it as a convenience, not a recovery plan.

Sources

Related Posts