Keep Your Recovery Path Outside the Cloud
IDC Frontier’s 7 October report attributes disruption in IDCF Cloud’s East Japan Region 1 to ransomware, affecting 495 companies and local authorities. It isolated the region and stopped systems.
New backup routes, not full recovery
Update, 18 October 2026: the provider’s sixth report says IDCF Cloud Backup is resuming after safety checks. Customers still running virtual servers in radian, newton, East Japan Regions 2 and 3 and West Japan Region 1 can obtain backups and restore into another cloud or on-premises. The snapshot function remains suspended. This is not restoration of the four affected zones.
On 14 October, the fifth report said safe snapshot data were retrievable for 194 of 495 affected customers; restorability and delivery required individual contact. Retrieval is not a completed restore.
Unauthorised portal queries affected 48 companies: company names, login IDs, difficult-to-reverse random password hashes, notification emails and total monthly charges. Two companies each had one possibly personally named email address. IDC Frontier found no evidence of external removal. It separately found no evidence of viewing or external removal of affected virtual-server data, concluding no leakage. These remain the provider’s findings.
Keep the early recovery forecast in its original context
The 8 October third report named tesla, henry, pascal and joule, where virtual servers had stopped and could not restart. It then expected retrieval or restoration to be difficult and advised rebuilding elsewhere from customer-held backups. None of these reports establishes universal permanent data loss or a completed recovery for everyone.
Use the response channel without mistaking it for recovery
In its 9 October fourth report, IDC Frontier said it formed an emergency headquarters at 09:00 JST on 7 October, coordinating with parent SoftBank. SoftBank’s enterprise division provides backup-procedure guidance, migration proposals and requested virtual-server start/stop assistance. The provider described technical recovery planning and execution with SoftBank and an external security specialist, plus reports to and consultation with regulators and police. It did not disclose an attacker identity, ransom demand or restoration timetable.
BlackTree advice: use the provider’s official contact form to request a migration proposal and agree the exact virtual server actions before authorising them. Treat assistance as an operational response path, not proof of recovery. Keep an independent change log, preserve backup evidence and verify each rebuilt workload before reconnecting it.
Map the service before rebuilding it
A recovery team needs more than a list of virtual machines. BlackTree recommends building a dependency map for each affected service before choosing the order of restoration. Record the application owner, recovery objective, data store, network path, DNS record, certificate, identity dependency, external integration and downstream consumer.
That map separates urgent business services from systems that can wait. It also exposes hidden dependencies that could make a technically successful server restore produce an unusable application.
Protect the backups you still have
BlackTree recommends freezing the relevant backup sets and documenting their creation time, storage location, retention state and access controls. Do not overwrite the most recent copies while the incident window remains uncertain. Keep at least one recovery candidate isolated from the environment being rebuilt.
A backup is not yet a recovery. Test a selected restore in an isolated environment, confirm that the data can be read, and compare application-level records against an independent source where one exists. Record every exception rather than silently filling gaps with a newer, unverified copy.
Rebuild cleanly, then restore trust
BlackTree recommends making that move a clean reconstruction: create fresh administrative access, rebuild from known configuration, restore only verified data, and reconnect external services in a controlled sequence.
A successful boot is not a closure test. Check application integrity, privileged accounts, scheduled tasks, network routes, certificates, secrets and monitoring before returning traffic. BlackTree’s earlier control-plane recovery guidance explains why restarting infrastructure cannot by itself establish that trust has been restored.
Credential rotation should follow the evidence. Prioritise identities and secrets that the affected management, storage or workload boundary could reach. A blanket reset without a map can break recovery while missing machine identities embedded in automation.
Recovery beyond the affected zones
The third report said it had confirmed no unauthorised access outside the four named zones; management consoles were stopped and customers asked to make backups. Type S and Private Cloud were excluded. The newer backup route above does not widen the affected-zone boundary.
Customers outside the four named zones should preserve current backups, confirm the recovery access available to them and watch for a changed boundary. A narrower impact statement is not a clean bill of health for every dependency.
Questions that still matter
For each workload, distinguish data that are unavailable, encrypted, corrupted and confirmed lost. Establish which recovered copies produce a usable application. Ask about the earliest attacker access, affected control-plane and storage components, recovery-asset integrity and the region-by-region recovery sequence.
Until those questions are resolved for the particular workload, the defensible priority is continuity with evidence: preserve what remains, rebuild the services that matter most, verify restored data and keep assumptions out of incident communications.
Source chronology: 7 October, 8 October, 9 October, 14 October and 18 October 2026.
