IDCF Cloud ransomware: 194 of 495 IDC Frontier customers may recover their snapshots

On 8 October 2026 IDC Frontier told 495 Japanese companies and local authorities that, as things stood, the data they held on IDCF Cloud could be restored only from backups they had kept themselves. On 14 October it revised that assessment. The 194 customers using the snapshot feature might get their copies back, and the company would confirm with each one whether restoration was feasible.

Behind both notices is a ransomware attack on IDCF Cloud, the public cloud run by this SoftBank group subsidiary, which began in the early hours of 7 October. By compromising the shared platform, the attacker halted services for all 495 customers at once.

What happened in the IDCF Cloud ransomware attack?

The attack began at around 3.40am Japan time on 7 October 2026 in IDCF Cloud's East Japan Region 1, according to IDC Frontier's third notice. That day the company took the region, home to the four affected zones (tesla, henry, pascal and joule), off the network and suspended the customer management console in every region. It also reported the incident to the relevant ministries and the Tokyo Metropolitan Police.

IDCF Cloud TypeS and IDCF Private Cloud were not affected. In its notice of 14 October, the company added that no other zone or region had suffered a service interruption.

On 8 October BleepingComputer reported screenshots, circulating on social media, that showed the attacker's note inside the customer console. In them the attackers claim to have reached 239 hypervisors, encrypted 225 virtualisation datastores holding 3.6 PB and destroyed 554,153 snapshots. IDC Frontier has not verified these figures and, according to the incident timeline kept by Japanese analyst piyolog, was checking whether the image was genuine. No group has been publicly named.

IDC Frontier's fifth notice, issued on 14 October, says an outside security firm found no evidence that customer data in the four zones had been viewed or exfiltrated. It did find unauthorised queries, made through the IDCF Cloud portal, to the registration records of 48 companies, covering company name, login ID, hashed password, notification email addresses and monthly charges. The company found no evidence that those records left the platform, and the route in has still not been disclosed.

How did the attack affect IDCF Cloud customers?

How many IDCF Cloud customers can recover their snapshots?

Up to 194 of the 495 affected customers, those using the snapshot feature, will be able to recover their copies, according to IDC Frontier's notice of 14 October 2026. The company will tell each of them whether restoration is feasible and how the data will be delivered, Impress Watch reports. In its notice of 8 October it had said that extracting or restoring data from the affected zones looked difficult.

For that week, the 194 customers did not know whether their snapshots still existed, and they are still waiting for individual confirmation. For the other 301, the notice describes no route to recovery beyond whatever each kept elsewhere.

How did Six Apart recover using backups outside the provider?

Six Apart, which runs the cloud edition of Movable Type, began moving its 31 servers from the affected region to Sakura Cloud using backups held with another provider. According to its customer notice of 8 October, each server kept seven generations of daily backups on Google Cloud, and the migration started from the 1am backup of 7 October.

Six Apart warns in the same notice that IP addresses change, that some specifications such as storage may not match the previous plan and that migration takes time. Changes made between 1am and the start of the incident, at around 3.40am, are not in that backup.

Why did the IDCF Cloud console become a second point of exposure?

The IDCF Cloud customer console exposed the registration records of 48 companies and, once suspended, left customers in every region without management access, including those in zones that were still running. According to the notice of 8 October, IDC Frontier itself started and stopped virtual servers at each customer's request while the console was down. The notice of 14 October adds that the email addresses of two of those 48 companies may include individuals' names.

When could JR East rule out a data leak?

JR East, whose email delivery contractor ran on IDC Frontier's platform, announced on 15 October that the contractor had ruled out a leak of personal data, six days after its first notice. In its statement of 9 October, the rail operator could not rule out access to the email addresses of up to 1.67 million Eki-net members. For around 390,000 members of its Otona no Kyujitsu club, the data at risk also included membership numbers, credit card expiry dates and dates of birth.

Both the mail contractor and JR East depended on IDC Frontier's investigation to decide what to disclose and when. We have seen this pattern before in breach notices whose root cause lay with a third party. When the decisive facts sit with another company, meeting notification deadlines such as those in NIS2 becomes harder.

Are attackers targeting cloud providers' hypervisors?

Attackers are starting to target providers' virtualisation layer, where a single foothold affects many customers. In September we examined how a malicious Virtualizor update, delivered after a BGP hijack, gave root access to hosting providers' hypervisors. If the attacker's figures are confirmed, IDCF Cloud would be another case of damage inflicted at the provider's hypervisor.

In Japan, security firm Macnica counts 119 incidents involving stolen or exposed personal data in 2026, 83 of them between 1 July and 6 October, against 84 in the whole of 2025 and 62 in 2024, according to BleepingComputer.

Why is a snapshot with the same cloud provider not a safe backup?

A snapshot stored on the same platform shares the management console, the credentials and often the physical location with the original machine, so anyone who controls the platform can reach it. It can undo human error or a failed disk. Under the public cloud's shared responsibility model, the provider protects the platform and the recoverability of data is the customer's job.

IDC Frontier's notice of 8 October made this plain for its own case. It stated that "in our current assessment, data can only be restored from backup data held by customers themselves." On 14 October the company announced that it is preparing a simpler way for customers in unaffected zones to back up their data.

Where should backups be kept outside the cloud provider?

A backup that survives the loss of the cloud provider meets these conditions:

• A copy in another account, another provider or another location, with credentials that cannot be obtained from the production environment. The 3-2-1-1-0 rule requires this separation, which distinguishes it from replication, as we explain in our guide to ransomware-resilient backups.
• Retention locked in compliance mode on that external copy, which makes it an immutable backup. Not even a compromised administrator can delete it early.
• Infrastructure as code rehearsed on a second provider, with the changes to IP addresses, DNS and certificates already worked into the procedure.
• A recovery point objective (RPO) that has been measured and accepted by management. For Six Apart, the 2 hours and 40 minutes between the 1am backup and the start of the incident fell outside the copy, and with daily backups the worst case would have approached a full day.
• Contract terms with the provider on notification deadlines and access to forensic findings that affect the customer's data, because the customer's own notification depends on them.

These measures belong in a business continuity plan that can be rehearsed, supported by a business continuity and disaster recovery service and by third-party risk management for the contractual side. Phishing-resistant multi-factor authentication (MFA) on cloud consoles and network segmentation that limits what a single foothold can reach are still needed.

Does cloud provider redundancy count as a backup?

Replication between a cloud provider's zones protects against a fire or a power cut, but an adversary with access to management can encrypt or delete the replica as easily as the original. An availability SLA measures uptime and does not cover data integrity.

What do DORA, NIS2 and the ENS require on backups and cloud exit plans?

Article 12 of DORA requires financial entities to have documented backup policies and to test restoration periodically. When they restore using their own systems, those systems must be physically and logically segregated from the source. Article 28(8) requires documented and tested exit strategies for ICT services that support critical or important functions.

Article 21(2) of the NIS2 Directive includes business continuity, with backup management and disaster recovery, alongside supply chain security. Spain's National Security Framework (ENS), which binds the Spanish public sector and its suppliers, covers backups in measure mp.info.6.

For entities under DORA, an exit plan that has never been rehearsed is likely to become an audit finding. Within the scope of NIS2, the same can be expected of backups that have never been restored.

What is still unknown about the IDCF Cloud attack?

IDC Frontier has not explained how the attacker got in, nor confirmed the figures for hypervisors and snapshots destroyed. It is also unclear how many of the 301 customers without snapshots kept copies outside the platform. As of 16 October 2026, the company has given no date for confirming individual recovery to the 194 snapshot customers.

Sources and attribution: the facts described draw on public notices from IDC Frontier, JR East and Six Apart and on coverage by specialist media. They reflect the information available on 16 October 2026.

No mention implies a security flaw in the products cited while the intrusion route remains undisclosed. The figures attributed to the attacker are unverified, and attribution to a group may change as the investigation progresses.

Analysis notice: this article interprets third-party information for general purposes and does not constitute legal advice. How DORA, NIS2 or the ENS applies to each organisation should be assessed case by case.