All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Japanese Cloud Giant IDCF Hit by Ransomware: OSS Portal Flaw Nukes 4 AZs, Zero Ransom Paid
Fresh update out of Japan: IDC Frontier (SoftBank's cloud subsidiary) officially published their final comprehensive post-mortem (Report #7) at 16:00 JST today (Oct 27) regarding the massive ransomware outage that started on October 7th:
🔗 Official Incident Report: https://www.idcf.jp/news/topics/20261027001/?bid=gtop
It is a textbook breakdown of why management plane vulnerabilities are fatal for public clouds. Here is the technical summary of what went down.
The Attack Vector (How they got in)
- Initial Breach: The attackers didn't touch hypervisors directly from the public web. They exploited an unpatched open-source software (OSS) vulnerability inside the customer-facing "IDCF Cloud Portal" authentication subsystem.
- Privilege Escalation & Pivot: Through the authenticated portal session, they bridged into the internal management console and hopped straight into the core virtualization infrastructure.
- Execution: Ransomware was unleashed directly against backend storage appliances.
Blast Radius & The Damage
- Physical Disconnect: To stop the bleeding, IDCF physically severed storage arrays across 4 whole zones in East Japan Region 1 (
tesla,henry,pascal, andjoule). - Casualties: 495 corporate and municipal government tenants across those 4 zones were hit. IDCF stated that in-place recovery for these workloads is practically impossible.
- Backup Recovery: Out of 495 affected clients, only 206 tenants had usable snapshot backups that could be salvaged and extracted to alternative environments. The rest lost their volumes unless they maintained off-site backups.
- What Survived: East Japan Region 1 (
radian,newton), as well as East Japan Region 2, Region 3, and West Japan Region 1 were unaffected and remain powered on. - Data Exfiltration: Forensic analysis confirmed no VM disk payload was stolen, though metadata/contact records for up to 71 accounts were illicitly viewed.
- Ransom Stance: IDCF confirmed zero contact and zero ransom paid.
The "Human API" Phase & Portal Rebuild
Because the portal authentication stack was poisoned, IDCF took the nuclear option and severed all cloud portals globally from external networks. They are rebuilding the portal architecture from the ground up: switching to an external IdP, mandating MFA, and restricting management access via IP allowlists.
Until the new portal launches, they are operating in 3 phases:
1. Phase 1 (Active Now): IDCF support staff are literally acting as a "human API," manually executing basic power and firewall changes on behalf of clients via tickets.
2. Phase 2: Support staff will manually process VM creation, resizing, and snapshot requests.
3. Phase 3: Full self-service portal goes live to the public.
Takeaways for Sysadmins
- Same-vendor snapshots != Backups. If the hypervisor control plane or backend SAN cluster gets ransomed, co-located snapshots go down with the ship.
- Any web application sitting directly between the public internet and internal cluster orchestration APIs remains an existential risk.
Did anyone here have active workloads on IDCF? Did your instances manage to survive in the other zones?
