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

01Eight 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”.¹ 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.²

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.⁷ 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.³

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.⁹ 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.⁹ The provider says it has had no contact with the attacker and has neither negotiated nor paid.⁷

02The 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”.⁷ 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.¹⁰

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.⁵⁷ For the servers themselves, the finding is plain: 「お客さまの仮想サーバー内のデータの外部への流出はありませんでした」, “there was no leakage of data from customers’ virtual servers to the outside”.⁷

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.⁷

03206 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.³ 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.⁴

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.⁵⁷

04The 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.⁸

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.⁶ 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”.¹¹

05Who 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.