---
title: "Ransomware hit a cloud provider: 206 of 495 customers had a copy it could return"
summary: "IDC Frontier's seven notices on the IDCF Cloud attack, 7 to 27 October, Telangana's TG-iPASS outage from 22 October, and who holds the backup when the provider itself is hit."
url: https://www.thetechbag.com/blog/cloud-provider-ransomware-idc-frontier
format: Analysis
desk: "Security"
area: "Threats & vulnerabilities"
region: Global
published: 2026-11-02
facts_checked: 2026-11-02
author: TechBag (The TechBag Journal)
tags: ["ransomware","IDC Frontier","IDCF Cloud","cloud provider","hypervisor","snapshots","backup","shared responsibility","TG-iPASS","Cloud4C","CERT-In","Japan"]
cover: https://www.thetechbag.com/blog/covers/cloud-provider-ransomware-idc-frontier.png
---

# Ransomware hit a cloud provider: 206 of 495 customers had a copy it could return

*IDC Frontier's seven notices on the IDCF Cloud attack, 7 to 27 October, Telangana's TG-iPASS outage from 22 October, and who holds the backup when the provider itself is hit.*

Analysis · Security · Threats & vulnerabilities · By TechBag · Published 2026-11-02 · Facts checked 2026-11-02 · Canonical: https://www.thetechbag.com/blog/cloud-provider-ransomware-idc-frontier

The short version

1. Ransomware encrypted virtual servers belonging to 495 companies and local governments on IDC Frontier’s IDCF Cloud in Japan on 7 October. The day after, the provider said data could be restored “only” from backups customers held themselves.[2][3]
2. IDC Frontier could retrieve snapshot backups for 206 of the 495 by 20 October. It found no data taken from customers’ servers, and on 27 October named the way in: an open-source flaw in its customer portal’s login, then administrator rights over the virtualisation platform.[7]
3. The provider’s terms already put the backup on the customer. In India, CERT-In’s six-hour reporting duty falls on the provider and the customer alike. Settle who restores, and from where, before the provider is the one hit.[8][16]

Most ransomware planning assumes the attacker reaches your servers. On 7 October an attacker reached the layer underneath them: the platform a cloud provider uses to run every customer’s servers at once. When that happens, the provider’s own snapshots can be inside the same blast radius, and the question a buyer has to answer is short. Who owns the backup, and who restores? This piece reads IDC Frontier’s seven notices in the original Japanese, sets them beside its contract terms and an Indian case from the same month, and ends with the questions to put to a provider now.

## Eight hours from the first failure to the word ransomware

At about 03:40 Japan time on Wednesday 7 October, virtual servers in four zones of IDCF Cloud’s East Japan Region 1 (tesla, henry, pascal and joule) stopped and could not be restarted. IDC Frontier’s first notice that day was titled 「当社サービスの一部システムに対する不正アクセスについて」, “On unauthorised access to some systems of our service”.[1] Its second, the same day, called it 「第三者からのランサムウェア攻撃」, “a ransomware attack by a third party”, affecting 495 companies and local governments that contract IDCF Cloud. It had disconnected the region from the network and shut its systems down.[2]

The final report of 27 October gives the hours. The provider began investigating a possible cyberattack at about 06:20, stopped the region’s customer portal at 06:48 and disconnected the four zones’ storage at 07:00. It identified ransomware at 11:42, then between 12:15 and 14:05 stopped the portals in every other region and cut their external network links. An outside security firm joined at 16:00.[7] The region’s other two zones (radian and newton), East Japan Regions 2 and 3, and West Japan Region 1 had no confirmed unauthorised access.[3]

**Figure: Customers were told to restore from their own copies on day two; the cause was named on day twenty**

*IDC Frontier's notices on the IDCF Cloud attack, 7 to 27 October 2026 (dates in Japan time)*

| Date | Event | Detail |
| --- | --- | --- |
| 7 Oct 2026 | Encrypted: 495 customers | Four zones of East Japan Region 1 stop at about 03:40; ransomware identified at 11:42 |
| 8 Oct 2026 | “Only your own backups” | Third report: restoration possible only from backups customers hold themselves |
| 10 Oct 2026 | Migration guidance | Procedures for moving to an alternative environment |
| 14 Oct 2026 | No data taken; 194 retrievable | No exfiltration from customer servers; snapshot backups retrievable for 194 |
| 17 Oct 2026 | Backup handover begins | Retrieved backup data handed to customers |
| 18 Oct 2026 | Backup service resumes | IDCF Cloud Backup back; the snapshot function stays suspended |
| 20 Oct 2026 | 206 retrievable | Twelve more customers' snapshot backups confirmed |
| 27 Oct 2026 | Cause named | Open-source flaw in the portal's login; up to 71 portal accounts queried |

Source: IDC Frontier, notices 1 to 7 (第1報 to 第7報), idcf.jp · as of 27 October 2026

Japanese coverage tracked the customers who spoke up. Ibaraki Prefecture’s website went down at about 04:00, and Nissui Logistics said all 17 of its sites were back to normal on 20 October, 13 days after the attack.[9] Images that circulated on social media claimed the attacker had encrypted every datastore and destroyed hundreds of thousands of snapshots. IDC Frontier has not confirmed those figures, and we leave them out of every chart.[9] The provider says it has had no contact with the attacker and has neither negotiated nor paid.[7]

## The way in: the customer portal, then the platform under every server

The seventh report gives the cause in one sentence: a vulnerability in open-source software used by the IDCF Cloud Portal’s authentication system was exploited. From there the attacker 「管理コンソールを経由して仮想化基盤の管理者権限を不正に取得し」, “illegitimately obtained administrator rights over the virtualisation platform via the management console”.[7] IDC Frontier does not name the software or a CVE. ITmedia’s @IT reports speculation on social media about which component it was and says the provider has not identified it.[10]

**Figure: One login flaw led to administrator rights over the layer that runs every customer's servers**

*The attack path as IDC Frontier described it in its final report, 27 October 2026*

1. 01A flaw in the portal's loginOpen-source software in the IDCF Cloud Portal’s authentication system is exploited. The component is not named.
2. 02Into the management consoleFrom the authentication system, the attacker reaches the console that operators use to run the platform.
3. 03Administrator of the virtualisation platformAdministrator rights over the layer beneath the virtual servers, not over any one customer’s machine.
4. 04Four zones encryptedVirtual servers of 495 customers in tesla, henry, pascal and joule stop. Separately, registration details of up to 71 companies are improperly looked up.

Source: IDC Frontier, seventh report (第7報), 27 October 2026 · as of 27 October 2026

The portal side was a separate, smaller exposure. IDC Frontier found improper look-ups of registration information for up to 71 companies, up from the 48 it reported on 14 October; up to 31 of those records may include a person’s name in an email address, and up to four customers had their portal passwords changed by the attacker, since reset.[5][7] For the servers themselves, the finding is plain: 「お客さまの仮想サーバー内のデータの外部への流出はありませんでした」, “there was no leakage of data from customers’ virtual servers to the outside”.[7]

The fixes it lists: the portal rebuilt in a new environment, every portal server credential changed, the compromised authentication system replaced by an external identity provider, access limited to customers’ IP addresses, and multi-factor authentication required. It also says it will scan open-source components on a fixed schedule using SoftBank’s patching service and keep a company-wide software bill of materials.[7]

## 206 of 495 customers had copies the provider could hand back

On 8 October the third report set the terms of recovery for the four zones. Extracting or restoring data there was expected to be difficult, and 「データの復元はお客さま自身が保持しているバックアップデータからのみ可能となります」: “data can be restored only from backup data that customers hold themselves”. Affected customers were asked to rebuild in a separate environment.[3] From 9 October the provider proposed migration environments and would start or stop a customer’s virtual servers on request, since the self-service consoles were off.[4]

Six days later the picture improved for some. Among customers who had used IDCF Cloud’s snapshot function, the fifth report confirmed backup data could be retrieved for 194; by 20 October that was 206. Handover of retrieved data began on 17 October.[5][7]

**Figure: The provider could retrieve snapshot backups for about four in ten affected customers**

*Customers whose snapshot backup data IDC Frontier confirmed as retrievable, share of the 495 affected, 14 and 20 October 2026*

39.2%

Retrievable by 14 October

194 of 495 customers

41.6%

Retrievable by 20 October

206 of 495 customers

Source: IDC Frontier, fifth and seventh reports; shares computed by TechBag · as of 27 October 2026 · The remaining customers are not known to have lost data: IDC Frontier has not said how many held their own backups

TechBag countTechBag count

194 ÷ 495 = 39.2% and 206 ÷ 495 = 41.6%, rounded to one decimal place. That leaves 289 customers whose recovery depended on a copy outside the provider’s snapshot function. IDC Frontier has published no count of how many of the 289 had one, so we do not call them data losses.

## The terms put the backup on the customer, and the attack tested that line

None of this departs from IDC Frontier’s published service conditions. They say data a customer builds belongs to the customer (「構築したアプリケーション等のデータはお客さまに帰属いたします」), and that 「これらのデータの保管はお客さまの責任の下、バックアップなどを行うものとします」: “the customer, under its own responsibility, keeps this data, including by taking backups”. The same page excludes liability for damage caused by data being altered, deleted, lost or erased.[8]

The snapshot function is the provider’s convenience, not the customer’s backup. When IDCF Cloud Backup resumed on 18 October, the snapshot function was still suspended for safety checks; the resumed service was offered so customers could copy data out and restore it to another cloud or on-premises.[6] Provider-level copies have been lost before. In August 2023 the Danish hosts CloudNordic and AzeroCloud said attackers had encrypted all server disks, primary and secondary backups included, after servers were joined to the wider network during a data centre migration; “the majority of our customers have consequently lost all their data with us”.[11]

**Figure: A provider's snapshot sits inside the platform that was attacked; a customer-held copy is the restore path the provider named**

*What each kind of copy did in the IDCF Cloud attack, 7 to 27 October 2026, against the provider's service conditions*

The provider's snapshot

- Lives on the attacked platform; the snapshot function was still suspended on 18 October
- Retrieved by the provider on its schedule: handover began on 17 October, day 10
- Retrievable for 206 customers, all of whom had used the function
- Service conditions exclude liability for data altered, deleted or lost

A copy the customer holds off the platform

- The only restore path IDC Frontier named on 8 October for the four zones
- Restorable to another cloud or on-premises, where affected customers had to rebuild
- What the service conditions already ask of the customer
- Safe only if it sits outside the provider's admin plane, unlike CloudNordic's backups in 2023

Source: IDC Frontier, third, sixth and seventh reports and service conditions; BleepingComputer on CloudNordic · as of 27 October 2026

## Who restores: six questions to settle before your provider is hit

The IDCF case turns the usual cloud diagram upside down. By IDC Frontier’s account, the way in was not through any customer’s own servers, yet customers lost the use of them for days, because the compromise sat in a layer a customer cannot see or patch. What a customer does control is where its copies live and who can reach them.

**Figure: Six questions settle who restores before the provider is the one hit**

*TechBag's checklist for a cloud or hosting contract, drawn from the IDCF Cloud notices, October 2026*

Step 1 of 6

1. Where do the provider's snapshots live?

Same storage and same admin plane as your servers, or separate? Ask for the answer in writing; IDC Frontier suspended its snapshot function after the attack.

Source: IDC Frontier notices and service conditions; CERT-In Directions of 28 April 2022; TechBag analysis · as of 2 November 2026

Our view

Our view: “the provider has snapshots” answers a different question from “we can restore”. The test is a restore drill into an environment the provider does not run, done before renewal, with the result written into the contract file. On 8 October IDC Frontier named one route back for the four zones, and it ran through copies the customers already held.

What this means in India

India had its own provider-hosted ransomware case the same month. Telangana’s TG-iPASS, the state’s single-window portal for industrial approvals, went down on 22 October. Officials found the database encrypted, file names changed to a “.vgb” extension and a ransom note that gave an email address but named no sum. The Telangana Cyber Security Bureau registered a case under sections 43 and 66 of the IT Act on a complaint from a joint director of the Industries Department, and officials said backups were available.[12] The complaint, as reported, puts the outage at about 11:36 pm and the database server with Cloud4C, a hosting provider.[13] On 25 October, Commissioner of Industries Nikhil Chakravarthi J told The Times of India the database had been decrypted that Sunday; data on 28,000 companies, and 7,000 more that had sought renewal, had been encrypted. No data loss was reported.[14][15] We found no statement from Cloud4C, no finding on how the attacker got in, and no official date for the portal’s full return.

The reporting duty does not move to the provider when the provider is hit. CERT-In’s Directions of 28 April 2022 require “any service provider, intermediary, data centre, body corporate and Government organisation” to report listed incidents “within 6 hours of noticing such incidents or being brought to notice about such incidents”. The list includes ransomware and attacks on cloud computing systems. Logs must be kept for a rolling 180 days within India.[16] Our reading: a provider’s notice to you is the moment the incident is “brought to notice”, so your six hours can start with its email, and the logs CERT-In may ask for may sit on the provider’s platform. Agree in the contract who files, and who hands over which logs. TechBag’s [cyber recovery guide](https://www.thetechbag.com/browse/backup-cyber-resilience/cyber-recovery) compares the products that keep an isolated copy.

How we did this

Figures as of 2 November 2026

The IDCF Cloud facts are from IDC Frontier’s seven notices on idcf.jp (7 to 27 October 2026) and its service conditions page. Japanese quotations are from those notices; the English translations are ours. Times are Japan Standard Time. The 39.2% and 41.6% shares are TechBag’s arithmetic on IDC Frontier’s counts. Customer impacts (Ibaraki Prefecture, Nissui Logistics) and the social-media claims are as compiled by Japan Cyber Watch; the claims are unverified and charted nowhere. TG-iPASS facts are as reported by Telangana Today, Urban Acres and The Times of India; we could not open a Telangana government statement, and the 28,000 and 7,000 counts are the Commissioner’s as reported. Left out: the hypervisor product and version, the exploited component, any count of encrypted virtual machines, and any compensation, none of which IDC Frontier has published.

Spotted an error? Write to us; corrections are published at the foot of the piece.

Sources

1. [IDC Frontier, 当社サービスの一部システムに対する不正アクセスについて (first notice)](https://www.idcf.jp/news/topics/20261007001) — 7 October 2026
2. [IDC Frontier, 【第2報】当社サービスの一部システムに対する不正アクセスについて (second report)](https://www.idcf.jp/news/topics/20261007002) — 7 October 2026
3. [IDC Frontier, 【第3報】当社サービスの一部システムへの不正アクセスによる障害について (third report)](https://www.idcf.jp/news/topics/20261008001) — 8 October 2026
4. [IDC Frontier, 【第4報】不正アクセスによる障害への対応体制について (fourth report)](https://www.idcf.jp/news/topics/20261009001) — 9 October 2026
5. [IDC Frontier, 【第5報】不正アクセスによる障害に関する調査の進捗について (fifth report)](https://www.idcf.jp/news/topics/20261014001) — 14 October 2026
6. [IDC Frontier, 【第6報】バックアップサービスの提供再開について (sixth report)](https://www.idcf.jp/news/topics/20261018001) — 18 October 2026
7. [IDC Frontier, 【第7報】不正アクセスに関する調査結果および今後の対応について (seventh report: findings and measures)](https://www.idcf.jp/news/topics/20261027001) — 27 October 2026
8. [IDC Frontier, サービス提供条件 (IDCF Cloud service conditions)](https://www.idcf.jp/cloud/spec/notice/) — undated; current version
9. [Japan Cyber Watch, IDCF Cloud unauthorised access and outage (timeline, customer disclosures, unverified attacker claims)](https://japancyberwatch.com/articles/idcf-cloud-unauthorized-access-outage-2026) — 7 October 2026, updated 27 October
10. [@IT (ITmedia), クラウドの「中枢」を奪われたら何が起きる? 495社の仮想サーバを止めたIDCFランサムウェア攻撃の全容](https://atmarkit.itmedia.co.jp/ait/articles/2610/29/news044.html) — 29 October 2026
11. [BleepingComputer, Hosting firm says it lost all customer data after ransomware attack (CloudNordic, AzeroCloud)](https://www.bleepingcomputer.com/news/security/hosting-firm-says-it-lost-all-customer-data-after-ransomware-attack/) — 23 August 2023
12. [Telangana Today, TG-iPASS portal services disrupted since October 22 after suspected ransomware attack](https://telanganatoday.com/tg-ipass-portal-services-disrupted-since-october-22-after-suspected-ransomware-attack) — 26 October 2026
13. [Urban Acres, TG-iPASS cyberattack exposes Telangana's digital governance risk (complaint details: time, Cloud4C)](https://urbanacres.in/tg-ipass-cyberattack-exposes-telanganas-digital-governance-risk/) — 25 October 2026
14. [The Times of India, TG-iPASS recovers data after ransomware attack](https://timesofindia.indiatimes.com/city/hyderabad/tg-ipass-recovers-data-after-ransomware-attack/articleshow/135197177.cms) — 25 October 2026
15. [VERIS Community Database, incident record summarising the TOI report (TG-iPASS, Cloud4C)](https://github.com/vz-risk/VCDB/issues/24649) — 27 October 2026
16. [CERT-In, Directions under section 70B(6) of the IT Act (six-hour reporting, Annexure I, 180-day logs)](https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf) — 28 April 2022

Related on TechBag: the [backup and recovery guide](https://www.thetechbag.com/browse/backup-cyber-resilience/backup-recovery), the [disaster recovery guide](https://www.thetechbag.com/browse/backup-cyber-resilience/disaster-recovery), and our earlier piece on [attackers going for the backups](https://www.thetechbag.com/blog/321-backup-rule-essential-data-protection).

**Disclosure.** TechBag is a software reseller: it earns a margin when a reader buys through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view.

Go deeper on TechBag

- [Cyber recovery guide](https://www.thetechbag.com/browse/backup-cyber-resilience/cyber-recovery) — products that keep an isolated copy outside the platform that was attacked
- [Backup and recovery guide](https://www.thetechbag.com/browse/backup-cyber-resilience/backup-recovery) — who backs up what, and where it can be restored to
- [Disaster recovery guide](https://www.thetechbag.com/browse/backup-cyber-resilience/disaster-recovery) — rebuilding in a second environment when the first one is gone