At 3:40 AM on October 7, ransomware began taking down part of IDCF Cloud, the cloud service run by SoftBank subsidiary IDC Frontier. By the time the company finished counting, 495 companies and local governments were affected, according to BleepingComputer. The IDCF Cloud ransomware attack ended with a message no IT leader wants to receive from a vendor: prepare a separate environment and rebuild, ideally from your own backups.
I run design teams, not data centers, but this story landed on my desk because every product team I work with depends on someone else’s infrastructure. The question it raises is simple. If your provider’s region disappears on a Wednesday morning, what do you have that the provider does not control?
What happened in East Japan Region 1
IDC Frontier says a third party’s ransomware attack caused the disruption. Virtual servers in four availability zones of East Japan Region 1 stopped and would not restart, and the company warned that retrieving or restoring customer data from that infrastructure would be difficult, per SDxCentral. It isolated the region and, according to BleepingComputer, disabled customer access to management consoles in every region while it checked their security.
The customer list shows how far one cloud region reaches. Cybernews reports railways, police, food logistics, travel and e-commerce services among the affected. SDxCentral adds that Fibergate lost its Wi-Fi authentication service and Medialink’s cloud telephony went offline. JR East’s email service was hit too, and JR East and its card subsidiary View Card said up to 6.09 million records may have been accessed (Cybernews describes this as possible exposure, not confirmed theft).
A caveat on the numbers. The attacker’s console message claims the breach took about seven minutes, reached roughly 240 hypervisors and destroyed more than 554,000 snapshots. Those figures are the attacker’s own and IDCF is still investigating. The company has not said how the intruders got in or who they are.
Why snapshots in the same cloud are not a backup
The detail that matters most is what the attacker allegedly went after. SDxCentral says the intruder claims to have removed 41.5 PB of backup capacity along with the snapshots. If that is accurate, it fits a pattern Google researchers have described: virtualization infrastructure was targeted in about 43% of the ransomware intrusions Google responded to in 2025, up from 29% in 2024. Attackers script their way across many ESXi hosts, shut the VMs down, delete snapshots and backups, then deploy the ransomware.
That sequence defeats any backup that lives under the same administrative control as the thing it protects. A snapshot is a convenience feature. It sits in the same control plane, often behind the same credentials, and it disappears in the same incident. Many teams treat it as a recovery plan because the console labels it that way.
Where shared responsibility actually starts
Cloud contracts split responsibility in a familiar way: the provider runs the platform, you run what you put on it. Recovery falls in the gap. Plenty of customers assume that because the provider hosts the servers, the provider can bring them back. IDCF’s own advice shows otherwise. The data in the four zones can only come back from copies the customers hold themselves.
The recovery itself has been slow for a mundane reason. With the customer management console down, SDxCentral describes virtual servers being restored manually, client by client. If you are customer number 400 in that queue, your plan is a spreadsheet and a lot of patience unless you have somewhere else to go.
A restore-readiness checklist for IT leaders
None of this requires a new budget line for a second cloud. It requires honesty about what you have tested. Start with these checks:
- Keep at least one backup copy outside the provider’s account, region and credentials, and make it immutable so a stolen admin login cannot delete it.
- Write down the rebuild path from zero: infrastructure as code, secrets, DNS, identity. If the console is unavailable, can you still deploy somewhere else?
- Run a timed restore into a clean environment at least twice a year and record the real hours, not the hoped-for ones.
- Map which business services depend on a single region, including the quiet ones like Wi-Fi authentication, telephony and email.
- Check that the people who know the restore procedure are not the same people whose accounts an attacker would take first.
Questions for your providers and outsourcing partners
If you work with an outsourcing or nearshore team that operates your infrastructure, put the same questions to them. Who holds the backups, and under whose credentials? What recovery time is written into the contract, and does it still apply when the provider’s own tooling is down? Can the partner show a recent restore test instead of a policy document?
A good partner will have answers ready and will not be offended that you asked. A vague one has just told you something useful before an incident does.
The backup you have never restored is a hope
The IDCF story will keep producing details as the investigation moves forward, and some of today’s claims will change. The lesson already stands. Pick one critical system this week, find where its only backup lives, and ask whether an attacker with the same admin rights could erase both. What would you find?