Ransomware hits Japan’s IDCF Cloud, cutting 495 companies and governments from their data
On October 7, 2026, ransomware hit IDCF Cloud, the infrastructure of SoftBank subsidiary IDC Frontier, causing a regional outage that cut 495 companies and local governments off from their data. The attacker claims 3.6 PB encrypted and 16,000 VM disks sealed — a reminder that your cloud provider is a single point of failure.
October 7, 2026, 3:40 AM. Ransomware hits IDCF Cloud, the infrastructure of IDC Frontier, a SoftBank Group subsidiary. 495 Japanese companies and local governments are cut off from their data. 3.6 PB of databases encrypted and 554,153 snapshots wiped, according to the attacker’s claim. Why it matters: a cloud provider is a single point of failure, and this attack shows the exact price of that.
A regional outage, consoles shut everywhere
IDC Frontier confirmed the incident without hedging: “Our investigation has determined that a disruption in East Japan Region 1 was caused by a ransomware attack by a third party.” The attack began on October 7 at 3:40 AM local time and forced the shutdown of the region’s network and systems.
The operator’s response is notable. IDC Frontier isolated and powered down the affected systems in East Japan Region 1 to stop the spread, then disabled management-console access for all regions — not just the one hit — while it verified their security. Access will be restored only once safety is confirmed. That is the right containment decision, but it carries an immediate cost: even customers in other regions temporarily lose control of their resources.
The attack affects 495 companies and local governments. IDCF Cloud rents virtual servers, storage and networking to customers running websites, applications and business systems in Japanese data centers — a customer profile that includes public administration, for whom a cloud outage is also a public-service outage.
What the attacker claims
Before customers were locked out of the console, circulating screenshots showed the threat actor’s message. Its numbers, if accurate, convey the scale of the compromise.
- 7 minutes to breach East Japan Region 1 infrastructure.
- 225 databases encrypted, representing 3.6 PB of data.
- 239 hypervisors reached.
- 16,000 virtual machine disks sealed.
- 554,153 snapshots wiped.
The claimed speed — seven minutes from intrusion to mass encryption — is the most worrying detail. It does not match an actor feeling their way around: it suggests a prepared compromise, with access already in hand or an escalation path mastered in advance. This sequence has become the norm for mature ransomware groups, which automate exfiltration and encryption once a foothold is obtained.
IDC Frontier has not confirmed these figures and says it is still investigating the precise cause and the scope of the impact. The fact that consoles in every region are down shows the operator itself does not yet have a complete picture of what was touched.
That uncertainty is itself the point: for the 495 affected customers, the immediate problem is not whether the attacker’s numbers are exact, but that they cannot yet distinguish what was encrypted from what was merely disrupted. Recovery planning has to begin before that distinction is known.
A cloud provider is a single point of failure
The incident illustrates a risk many teams underestimate: concentration on a single provider. Your cloud backups, VMs and snapshots live with the same operator as your production workloads. If the operator is compromised, an attacker can reach all three at once — which is exactly what the claim describes, between sealed disks and wiped snapshots.
The domino effect already extends beyond IDCF Cloud’s perimeter. Seafood group Nissui, with about 11,500 employees, announced that its logistics subsidiary Nissui Logistics suffered a system outage due to suspected unauthorized access to a third-party data center it uses, halting shipments and receipts. The link to the IDCF Cloud attack is not established, but the mechanism is identical: an organization can be paralyzed by an attack that never targeted it directly, simply because it shares a provider with the victim.
That is the deeper lesson: resilience is not declared after the fact, it is designed into the architecture — backups outside the provider’s perimeter, tested restore, and for critical workloads a second region or a second provider.
A Japanese context deteriorating fast
The attack is part of a trend that Macnica’s numbers make tangible. Researcher Yutaka Sejiyama counts 119 cybersecurity incidents involving personal data theft or exposure in Japan since the start of the year, including 83 between July 1 and October 6. By comparison, Macnica logged 84 in all of 2025, and 62 in 2024.
Analysis of these incidents points to attackers probing websites and APIs for access-control, configuration and authentication weaknesses, and exploiting known — n-day — vulnerabilities. Sejiyama links the acceleration to the rise of capable, cheap AI tools, which make broad, detailed exploration of targets economically viable when they previously were not worth the effort. The ransomware against IDCF Cloud is just one point on that curve — but a heavy one, because it hits a shared provider.
The numbers also carry a warning for defenders outside Japan: the same economics — cheap, AI-assisted probing of exposed surfaces — apply in every region. A provider outage like this rarely stays a local story for long.
The immediate response, on the customer side
When a cloud provider is compromised, the customer has little leverage over the cause but a great deal over the consequences. The first hours break down into three moves.
First, cut off and preserve. Until the operator confirms the scope of the intrusion, prudence says to suspend integrations that write toward the provider — backup pipelines, replications, synchronizations. An attacker with a hand on the hypervisors can also reach whatever arrives continuously. Preserving also means freezing the logs and captures that will later explain what was touched.
Second, check the backups elsewhere. The claim — sealed disks and wiped snapshots — is a reminder that backups hosted with the same operator are not backups. The real test is to restore a sample from storage outside the provider’s perimeter and measure how long it takes. It is that duration, not the backup’s existence, that determines your recovery.
Third, communicate early. The 495 affected organizations are not all encryption victims: some only suffer the console outage. Saying quickly what is affected — and what is not — stops a provider outage from becoming a trust crisis with your own customers.
The common thread of these three moves: none of them depends on how fast the operator’s investigation moves. That is what makes them useful.
Verdict
If you are a customer of IDCF Cloud or a comparable provider, the incident should trigger an immediate check: confirm your backups are outside the operator’s perimeter, and test that you can actually restore them — a backup sealed by the same ransomware is worthless. If your critical workloads depend on a single region of a single provider, this is the moment to price a failover and prepare one, even a reduced one. For everyone, remember the claimed speed: seven minutes between intrusion and mass encryption leaves no room for an improvised response — the only credible defense is an architecture that survives the provider’s compromise, not a faster reaction plan.