Skip to content
Indene
en

Inteligência de ameaças

Ransomware at a Japanese cloud provider halts 495 clients and tests continuity plans

The attack on IDC Frontier on October 7 left 495 companies and local governments without access to their own machines, including a card issuer. A week later, only some clients had a clear path to recover their data.

By Leonardo Araujo IevaAnalista de segurança ofensiva

4 min read

Rede de pontos ligados por traços finos sobre fundo escuro esverdeado, com um único nó verde aceso, e o título One provider down, many businesses stopped.
Rede de pontos ligados por traços finos sobre fundo escuro esverdeado, com um único nó verde aceso, e o título One provider down, many businesses stopped.

In the early hours of October 7, 2026, a ransomware attack halted part of the cloud run by IDC Frontier, a Japanese provider controlled by SoftBank, and left 495 companies and local governments without access to their own virtual machines, according to the company. A week later, only the clients that used the cloud's own snapshot function had a clear path to recover their data. In Indene's reading, the case shows the limit of a continuity plan that depends on the same provider that failed.

What happened

date fact source
October 7, around 3:40 a.m. unauthorized access to the East 1 region of IDCF Cloud; the same day, the company confirms ransomware and isolates the region IDC Frontier
October 7 495 companies and local governments affected; internet-facing management consoles suspended in every region, including those that kept running IDC Frontier
October 8 the company says data in the four affected zones will likely be hard to recover and that restoration depends on copies kept by the clients themselves IDC Frontier
October 9 Nissui resumes part of the inbound and outbound shipments of its logistics company, a client of the provider Nissui
October 14 backups confirmed intact: 194 of the 495 clients, those that used the snapshot function, can extract their data; no sign that data left the virtual machines; registration records of 48 clients improperly viewed in the portal IDC Frontier

The impact reached clients in different sectors. The Nissui group's logistics company could not move goods for two days. Six Apart stopped waiting and migrated its servers to another provider from its own backups, according to Impress Watch. In the financial sector, ViewCard, the card issuer of the JR East group, reported on October 9 the possible exposure of about 4 million customer email addresses stored in a mailing service hosted at the provider, according to ITmedia and NHK; IDC Frontier later concluded that no data left the virtual machines.

What regulators have already measured

The Japanese case is not isolated. In their 2025 report on major ICT-related incidents under DORA, the European Supervisory Authorities (ESAs) counted 3,383 major incidents in the EU financial sector, and 29% of them were caused by the failure of a third-party provider. About a third had an impact in more than one country.

The 2026 Threat Landscape of ENISA, the EU cybersecurity agency, published on September 22, notes that attacks on supply chains, third-party providers and cloud environments kept producing large-scale incidents. Along the same lines, the European Union began to directly oversee 19 technology providers deemed critical to the financial sector, and the United Kingdom did the same with four major cloud providers from July 2026.

What this means for financial institutions

The first lesson is about redundancy. IDC Frontier markets the separation between its East and West regions as a continuity option. Even so, to contain the attack, it suspended the management console for every region. Servers in the other regions kept running, but clients lost direct control over them: the company itself started turning machines on and off on request. Redundancy within the same provider protects against a data center failure, not against a provider failure.

The second is about copies. Until October 14, the way back went through backups the client kept outside the affected environment, or through a snapshot function that happened to survive. Those who depended only on what was on the stopped machines were left waiting for the provider.

Brazil's rules already require what many of these clients lacked. CMN Resolution No. 4,893 requires institutions to plan continuity alternatives when a relevant cloud service contracted abroad cannot be maintained, to have contracts that guarantee data transfer on exit, and to have a response plan that covers interruption of the contracted service, including replacing the provider. Continuity test results also go into the annual report to the board. The question the Japanese case leaves is whether that test has ever simulated the loss of the whole provider, not just one server.

What to do now

  1. List the relevant cloud services and, for each one, what happens if the provider is unavailable for a week: what stops, what it costs and who decides.
  2. Keep a copy of critical data outside the main provider, or at least outside the same management plane, and test restoring it.
  3. Include in the continuity test the scenario of a full provider outage, with loss of the management console, and record the actual recovery time.
  4. Check whether cloud contracts guarantee data delivery on exit and whether the institution can carry out that exit under pressure.
  5. Map how many critical services depend on the same provider; the concentration Europe now oversees starts with this inventory.

In Indene's reading, the outage of a critical provider is one of the loss scenarios that needs a number: how long operations can hold out, what each day costs and what proof exists that the alternative works. Read the methodology.

References

Topics

Keep reading

All news