IDCF Cloud ransomware: 495 customers, and only their own backups can save them
On October 7, 2026, at 3:40 a.m. local time, ransomware hit IDCF Cloud, the cloud service of IDC Frontier, a SoftBank subsidiary and one of Japan’s main domestic alternatives to AWS, Azure and Google Cloud. The toll: 495 companies and local governments affected, according to the provider. Then came the sentence every SMB that hosts servers in the cloud should think about:
“At this time, our view is that data restoration will only be possible from backup data held by the customer themselves.”
IDC Frontier customer update, quoted by Cybernews
This cloud ransomware attack is a reminder of a simple truth: hosting in the cloud is not the same as having a backup.
What we know (and what’s still unconfirmed)
| Item | Status |
|---|---|
| 495 companies and local governments affected | Confirmed by IDC Frontier |
| Four cloud zones so badly damaged that customers will need to rebuild elsewhere from their own backups | Confirmed by IDC Frontier (October 8 update) |
| Management console access disabled in all regions as a precaution | Confirmed by IDC Frontier |
| Up to 6.09 million records possibly accessed at JR East and View Card via email-delivery services hosted on IDCF; card numbers, addresses and phone numbers not exposed, according to the companies | Reported by affected companies |
| Breach done in 7 minutes, 225 databases (3.6 PB) encrypted, over 16,000 VM disks sealed, 554,153 snapshots wiped | Claimed by the attackers, unconfirmed |
| Entry point, group responsible, ransom demand | Unknown so far |
Even treating the attackers’ numbers with caution, one detail stands out: snapshots stored on the same platform were targeted. A snapshot in the same cloud, managed with the same credentials, is not an independent backup.
Who protects what? The shared responsibility split
What your cloud provider protects
- Buildings, power, hardware
- Platform availability (per its contract)
- The security of its own infrastructure… until the day it fails
What remains your responsibility
- A copy of your data outside that platform
- An immutable or offline copy no one can delete with just a password
- Regular restore tests
- A plan to restart elsewhere if the platform doesn’t come back
That’s true for a rented server or a virtual machine, but also for Microsoft 365 or Google Workspace: the provider keeps the service running, not necessarily your data safe from everything.
The 5-step restore drill
The best way to know whether you’d be among the IDCF customers able to restart: try it, calmly, on a quiet Tuesday.
- 1
Take inventory
Which servers, databases and cloud services run the business? Where are they hosted?
- 2
Find your copies
For each one: is there a copy at another provider, or offline? The 3-2-1 rule remains the benchmark: 3 copies, 2 different media, 1 offsite.
- 3
Check who can delete
Can the account that manages your servers also delete your backups? If so, an attacker who steals it can wipe everything at once.
- 4
Restore for real
Pick an important system and restore it into a test environment. Time it.
- 5
Write the plan
Who calls whom, what restarts in which order, how many days the business can hold out. One page is enough.
To go further, see our backup and disaster recovery service, and read why backup servers themselves have become targets. Our automated 24/7 monitoring with on-call technician response can also flag mass backup deletions or abnormal behaviour before it’s too late.
Book your free cyber check
Would your backups survive losing your hosting provider entirely? We’ll check with you where your copies are, who can delete them and how long a restore would take.
Call us at 438-476-2322 or email info@neotechcloudsolutions.com.
Sources
- BleepingComputer — Ransomware attack disrupts Japan’s IDCF Cloud used by govt clients (Oct 8, 2026)
- Cybernews — Cyberattack on Japanese cloud firm hits railways, police and food suppliers, 495 organizations exposed (Oct 9, 2026)
Photo: panumas nikhomkhai, Pexels (Pexels licence).