When ransomware takes the snapshots too: the IDCF Cloud attack, and how to keep recovery copies out of reach

At about 3:40 in the morning on October 7, 2026, ransomware hit one region of IDCF Cloud, a Japanese cloud service run by IDC Frontier, a SoftBank Group company. Businesses and local governments rent virtual servers and storage there to run websites, email, phone systems, and back-office software. According to public reporting from BleepingComputer, SDxCentral, and ASCII.jp, servers in four zones of the East Japan Region 1 data center cluster stopped and would not restart, and 495 customers were affected.

IDC Frontier moved quickly. It cut the region off from the network, locked customers out of management consoles in every region while it checked them, and kept publishing updates. The hardest update was about recovery: some customer data may be difficult to get back, and customers should restore from backups they keep themselves. How the attackers got in, and whether they took data with them, is still under investigation.

The attacker left a message in customer consoles claiming the break-in took seven minutes, reached 239 hypervisors (the software layer that runs virtual servers), and wiped 554,153 snapshots. Those numbers come from the attacker. IDC Frontier has not confirmed them.

A snapshot is a saved picture of your data at a moment in time. If ransomware scrambles your files at 4 a.m., you roll back to the 3 a.m. snapshot. That only works if the attacker cannot delete the snapshot first, and deleting backups is now one of the first things ransomware crews do. A victim with nothing to restore from is a victim who pays.

In many environments, the servers, the disks they run on, and the snapshots that protect them are all controlled from one admin console with one set of administrator logins. Whoever takes over that console can switch off the servers and erase the snapshots in the same few minutes. Engineers call the reach of a single compromise its blast radius. In this attack, the blast radius appears to have included the recovery copies.

This could happen almost anywhere. Most private data centers are built the same way, because one console is easier to run. That convenience is exactly what an attacker is counting on.

RackTop BrickStor SP is Cyberstorage: file storage that defends the data it holds instead of waiting for another tool to notice an attack. When RackTop designs a deployment against an attack like this one, the goal is plain. No single stolen login, and no single hijacked console, should be able to destroy both the data and the copies needed to restore it. Six layers do that work.

1. Keep the data away from the system attackers grab first. Files and records live on BrickStor SP and are served over SMB, NFS, S3, and Web Drive, rather than sitting inside virtual machine disks. For this design, BrickStor runs as a physical appliance with its own administrator accounts, separate from the hypervisor’s. Taking over the virtualization console does not hand over the storage. If the virtual servers have to be rebuilt, they reconnect to data that is still there.

2. Stop the attack while it is happening. Active Defense watches every file operation as it happens: every read, write, rename, and delete. When it sees ransomware behavior such as mass encryption or mass deletion, it stops the session, isolates the user, snapshots the affected data, and alerts the security team’s SIEM, all in under a second. The attacker in this case claims to have needed seven minutes. No person can respond that fast, so the storage has to.

3. Take snapshots that administrators cannot delete. BrickStor data protection policies take immutable snapshots on a schedule, with a sub-minute recovery point. Those snapshots cannot be modified or deleted by administrators, so an attacker holding a stolen admin password still cannot erase the history.

4. Replicate to a second BrickStor run by different people. Protected data replicates to a secondary BrickStor SP system, ideally at another site, managed by a separate admin group with separate credentials. Nobody who administers the primary has a login on the secondary. An attacker who fully controls the primary has to break in again, from scratch, to reach the copy.

5. Vault what you cannot afford to lose. For the most critical data, ImmutaVault keeps copies behind a patented virtual air gap. Those copies cannot be modified, encrypted, or deleted, even by an administrator with full system privileges.

6. Recover only what was touched. Intelligent Bulk Remediation (IBR) uses BrickStor’s audit trail to find exactly which files an attack changed, then restores just those from the last good snapshot, in minutes rather than days. The same immutable audit trail answers the question IDCF customers are still waiting on: was anything copied out, and if so, what?

Together this is what NAS ransomware protection should mean in practice: detection on live data, recovery points an attacker cannot reach, and a second system that does not share the first one’s keys.

This design does not promise that nothing goes down. An attacker who takes over a virtualization console can still stop servers, and that is still a bad morning. What changes is what you find when you come back. The data, its history, and a record of what happened are all still there, on systems the attacker never controlled.

Write down every copy you would restore from after ransomware: snapshots, replicas, backups, vaults. Next to each one, write down every login and console that can delete it. If the same login shows up next to your production data and next to a recovery copy, that copy is inside the blast radius.