Ransomware hits SoftBank's IDCF Cloud, 495 orgs offline

At 3:40 a.m. local time on October 7, 2026, the East Japan Region 1 of IDCF Cloud stopped responding. The platform is run by IDC Frontier, a cloud and data-center subsidiary of SoftBank Group, and within hours the company confirmed the cause was a ransomware attack by a third party. By its own count, 495 companies and local governments that rent virtual servers, storage, and networking from the region were knocked offline at once. Among them was Nissui Logistics, the cold-chain arm of seafood group Nissui, which halted nationwide shipping and intake because the systems that run its warehouses lived on the affected region.

The numbers the attacker put on the table are what make this incident stand out, and so does the layer of the stack it hit.

The attacker's scoreboard

Before IDC Frontier revoked access to customer management consoles, several tenants captured screenshots of a message left by the intruders. The note claimed the breach of East Japan Region 1's management plane took seven minutes, and then listed what those minutes bought. IDC Frontier has not independently confirmed any of these figures, and they should be read as the attacker's own claims rather than a verified damage report.

Metric	Claimed figure	What it means for recovery
Time to breach management plane	7 minutes	Orchestration-tier access, not a single server
Hypervisors reached	239	The hosts every tenant VM runs on
Datastores encrypted	225 / 225	Every datastore in the region
Primary storage locked	3.6 PB	The live production data
VM disks sealed	16,600+	Individual virtual machine volumes
Snapshots destroyed	554,153	The in-region restore points
Backup capacity gone	41.5 PB	The recovery tier itself

The single most damaging line is the last one. The intruders claimed to have wiped 41.5 petabytes of backup capacity and 554,153 snapshots, which is roughly eleven times the 3.6 petabytes of primary data they encrypted, and all of it sat inside the same region they had just taken offline. Spread across the 16,600 VM disks, that snapshot count works out to around 35 restore points per disk, an entire rollback history, gone in the same event.

Source: attacker's claimed figures via customer screenshots; IDC Frontier has not confirmed them. Chart: Tech Forum.

This is the mechanism behind the quiet, second headline of the week. Several Japanese municipalities reported that they could not reach their backup data after the outage, because the copies they were counting on lived in the same region that had just been isolated. A backup that shares a blast radius with the thing it is backing up is not a backup, it is a second copy waiting for the same event.

Hypervisor ransomware ends tenant isolation

Most ransomware that reaches a cloud tenant encrypts the guest, the files and databases inside one customer's virtual machines. IDCF Cloud marks the shift to ransomware that seizes the hypervisor layer beneath the guests, where one compromise ends tenant isolation for every customer at once. Reaching 239 hypervisors and all 225 datastores is only possible from the orchestration tier that sits above individual tenants, which is why 495 separate organizations went dark on the same clock tick despite having no connection to one another.

The attack also fits a sharper regional trend. Security firm Macnica logged 119 incidents involving stolen or exposed personal data in Japan in 2026 through October 6, with 83 of those falling between July 1 and that date. For comparison, Macnica counted 84 such incidents in all of 2025 and 62 in 2024. Researchers have tied the acceleration in part to cheap, capable AI tooling that lowers the effort of probing websites and APIs for access-control and authentication weaknesses, which widens the pool of organizations worth attacking.

Seven minutes to encrypt, hours to notice

The intruders' message carried a second claim beyond the scoreboard, a jab at the operations response. It said that in the hours after encryption the team kept power-cycling virtual machines that would never boot again, without finding the 225 ransom notes left across the hypervisors, and that the attackers watched the console activity the whole time. The note opened with the line "YOUR CLOUD IS OURS." Those operational details come from the attacker and from the screenshots circulated by Chinese tech outlet Landian News, so they describe the intruders' version of events rather than a confirmed timeline.

IDC Frontier's own public steps are confirmed and tell the recovery story. The company isolated East Japan Region 1 from the network and shut it down to contain the compromise, then proactively disabled customer access to management consoles across every other region while it verified their security, with access to be restored region by region as each is cleared. It said it was still investigating the intrusion path, the full scope, and whether any personal data was taken.

The blast radius outside IDC Frontier

The most instructive part of this incident is that the victim list is almost entirely made up of organizations that were not themselves breached. Their own networks stayed intact, their business simply stopped because the platform under it went away. Nissui Logistics could not ship or receive goods. The websites of Ibaraki Prefecture, the Ibaraki prefectural police, and the city of Kodaira went dark. Vendors running inventory-sync services for e-commerce sellers and content management systems such as Movable Type reported outages or degraded features. A single provider's bad morning became hundreds of organizations' bad week.

That is the dependency the attack exposed. When core business systems run on one provider in one region, the continuity of the business is only as strong as that provider's defenses, no matter how well the business itself is secured. The practical response that Japanese security firms have converged on is unglamorous: know which provider and which region each critical system actually runs in, keep recovery copies in a different region or a different provider entirely, prefer immutable or write-once backups that an intruder with orchestration access cannot purge, and write down the manual fallback for keeping the business moving while the platform is down. Those recommendations are provided here for reference and are drawn from the cited analyses, not from any engagement with IDC Frontier.

What is still unknown

As of this writing, several questions remain open. IDC Frontier has not confirmed the attacker's figures, has not named the group responsible, and has not stated whether any customer or personal data was exfiltrated before encryption, which would trigger reporting obligations for the affected companies and municipalities under Japanese law. The recovery timeline for East Japan Region 1 has not been set. What is already clear is the shape of the lesson: the attack reached the layer that every tenant shares, and it destroyed the recovery tier in the same stroke as the production tier. For the 495 organizations downstream, the defense that would have mattered was not on IDC Frontier's side of the line at all.

Primary sources: IDC Frontier's second incident advisory, Nissui's statement on the Nissui Logistics outage, ITmedia's report confirming the ransomware cause, and TechEchelon's English account of the 495-client disruption and the attacker's claims.