When your cloud provider gets locked too: IDCF Cloud ransomware lessons on backups and suppliers

In the early hours of Wednesday, 7 October 2026, at around 03:40 Japan time, virtual machines in four zones of IDCF Cloud's East Japan Region 1 stopped and could not be restarted. IDC Frontier, the SoftBank subsidiary that rents out virtual servers, storage, and networking, confirmed the cause was a ransomware attack. 495 customer organisations were affected.

The most important sentence came in the company's third report a day later. Customer data in the affected zones was expected to be difficult to retrieve or restore, and in IDC Frontier's view at that point, restoration was only possible from backups held by customers themselves.

For many businesses, that sentence overturns an old assumption: "the data is in the cloud, so it's safe."

What happened, and what is still unconfirmed

After detecting the attack, IDC Frontier cut the region off from the network and shut down the customer management console, including in regions that were not hit, while it checked their security. While the console was down, IDC Frontier started and stopped customer servers on request.

Screenshots circulating from the customer console carry the attacker's claims: getting in within seven minutes, reaching 239 hypervisors, encrypting 225 databases holding 3.6 petabytes, sealing more than 16,000 virtual machine disks, and wiping 554,153 snapshots. These are unverified attacker claims, but they illustrate one point well: snapshots that live on the same platform were within the attacker's reach.

On 14 October, IDC Frontier's fifth report said it found no trace of data inside the virtual machines being taken out. Working with an external security firm, it also confirmed that backups for the 194 customers who used the snapshot feature could be retrieved, with whether they can be restored handled case by case. The report did not mention customers who had not used snapshots. In the customer portal, registration details of 48 companies had been accessed without authorisation. On 18 October, the backup service reopened for unaffected zones, so data can be restored to another cloud or to on-premises servers. The snapshot feature remains suspended.

What separated back-in-a-day from still-waiting

The impact on operations was immediate. Nissui Logistics, which had outsourced its system operations to IDC Frontier, stopped receiving and shipping goods at all of its warehouses. Partial operations resumed on 9 October, and a new system on other servers was expected to run normally in the week of 19 October. ITmedia compiled announcements from more than a dozen affected companies as of 19 October, and the pattern is clear.

• Their own backup, somewhere else. Six Apart used a backup from 01:00 on 7 October and moved its 31 servers to Sakura Cloud by 21:00 the next day. CareNet judged that recovery on IDCF could not be relied on and rebuilt its services at another provider from its latest pre-attack backup. Its site was back on 11 October, four days after the incident.
• Backup age decides what data comes back. Greenwich's marketplace stock-sync service "Rakuraku Zaiko" recovered on 9 October, but from a 30 August backup. Orders placed during the outage were not imported, and shops using it were asked to update their stock counts before turning sync back on.
• Core functions separated from supporting ones. Mouse Computer did not keep order and payment data on the platform, so its online shop stayed open even though its newsletter stopped. E-commerce platform FutureShop had placed only an email-sending server on IDCF, with data encrypted and automatically deleted 14 days after sending. Email sending moved to another data centre on 9 October.
• Indirect dependencies. JR East, Takashimaya, and View Card did not subscribe to IDCF themselves, but their email delivery vendors ran on it. At JR Central's online shop, authentication emails that never arrived meant customers could not log in and buy.

This is not a rare case. ITmedia cites an ITR survey from March 2025: 47% of companies hit by ransomware found their backup data encrypted as well.

What it means for businesses in Indonesia

Many businesses in Indonesia, from online shops, distributors, and private clinics to logistics companies, rent VPS or local cloud capacity and use a stack of SaaS tools: email blasts, WhatsApp blasts, marketplace stock sync, POS, accounting. That is a sensible choice. The problem starts when nobody knows exactly where the data sits and how to bring it back if the provider goes down.

Seven steps you can start this week:

1. Map dependencies to the second layer. For each system and SaaS vendor, ask: whose cloud does it run on, in which region, and what stops in your business if it is down for three days? This incident shows your email vendor can become the point where logins and transactions fail.
2. Keep at least one backup outside the same provider and account. Snapshots on the same platform help with misconfiguration, not with an attack that takes over the platform. Use a separate account, separate credentials, and ideally a different provider, plus a copy that cannot be changed or deleted for a set period.
3. Set RPO and RTO per system, then check them against reality. How many hours of data can you lose, and how long can the service be down? The Greenwich case shows a loose backup schedule turning directly into lost orders and stock that has to be recounted.
4. Practise recovery into another environment, not just file restores. Six Apart could move in under two days because its backup and a destination were ready. Test DNS, application secrets, certificates, and the written runbook too, at least for your most critical systems.
5. Separate core functions from supporting ones. Orders, payments, and stock data should not go down because a marketing system went down. This matches the lesson on redundancy that must not be removed all at once.
6. Give vendors only the data they need. Limit the fields and how long they are kept, like FutureShop's 14-day automatic deletion. The less data a vendor holds, the smaller the impact when that vendor is attacked.
7. Write the exit into the contract and prepare communications. Secure the right to export data in open formats, incident notification duties, and disclosure of hosting subcontractors. On formats, see an exit plan built on open data formats. Prepare customer notice templates too, because JR Central warned of possible fake emails, SMS, and phone calls riding on this incident.

Servers being back up does not mean the business has recovered, as we discussed in the Boston Scientific incident lessons. The right measure is orders flowing in again, stock being accurate again, and customers able to log in again.

How MarkasDev helps

MarkasDev works as a Technology Partner for operational reliability, in three phases:

• Diagnose: mapping systems, vendors, and hosting locations down to the second layer, assessing existing backups against the RPO and RTO the business needs, and setting priorities for fixes.
• Deliver: building backups outside the main provider, separating core from supporting functions, and preparing a tested recovery environment, with written milestones and acceptance criteria.
• Operate: a retainer with SLAs and monitoring to run regular recovery drills and make sure backups actually work. We explain how this differs from fixing things when they break in Maintenance vs Operate.

If you are not sure your backups would survive your cloud provider getting locked as well, book a Diagnose session to review your dependency map and recovery plan.

Sources

• IDC Frontier, third report on the IDCF Cloud incident (8 October 2026, Japanese): https://www.idcf.jp/news/topics/20261008001
• IDC Frontier, sixth report, backup service resumed (18 October 2026, Japanese): https://www.idcf.jp/news/topics/20261018001
• ITmedia Enterprise, summary of impact and recovery at IDCF Cloud customers (20 October 2026, Japanese): https://www.itmedia.co.jp/enterprise/articles/2610/16/news098.html
• ASCII.jp English Edition, "IDC Frontier: Backup Data Now Retrievable for 194 Customers" (15 October 2026): https://ascii.jp/en/elem/000/004/442/4442704/
• BleepingComputer, "Ransomware attack disrupts Japan's IDCF Cloud" (8 October 2026): https://www.bleepingcomputer.com/news/security/ransomware-attack-disrupts-japans-idcf-cloud-used-by-govt-clients/
• Cybernews, "Cyberattack on Japanese cloud firm hits railways, police and food suppliers" (9 October 2026, updated 12 October): https://cybernews.com/security/japanese-cloud-cyberattack-railways-police-495-organizations-idcf/