The part of the report IDC Frontier published today that actually hurts is not the ransomware. It is the order of the sentences. They exploited a vulnerability in an open-source component used by the authentication system behind its customer portal. From the authentication system they reached the management console. And from the management console they obtained administrator rights over the virtualisation platform. Four jumps, and on the last one sat the machines of 495 companies and public bodies. The question it leaves on the table is not about Japan: in your own setup, how many jumps are there between a login form published on the internet and the credential that can delete your backups?
What the report says, in its own words
IDC Frontier is a Japanese datacenter and cloud provider, a SoftBank subsidiary. On 7 October 2026, at around 3:40 in the morning, the virtual servers in part of its "East Japan Region 1" — the tesla, henry, pascal and joule zones — stopped and could not be restarted. The count of affected customers has not moved since: 495 companies and public bodies. What has moved, report after report, is the explanation. Today, 27 October, they published the seventh, closing the investigation and confirming the cause.
Two sentences. In the first we are at the public edge, on a login form anybody can load. In the second we are already on the layer that starts and stops everybody's machines. Between them there was nothing the report considers worth mentioning. Two things it does rule out, and they deserve saying before we go on: the investigation found no data leaving customer virtual servers, and the company states it never made contact with the attacker and neither paid nor negotiated any ransom.
The four jumps
It is worth breaking it into stretches, because every stretch has an exact equivalent in a twenty-machine setup. Two warnings before the table. The third column does not come from the report: it is what we look at when we review a platform. And the fourth jump is not in there either: the report describes three boundaries and confirms that the machines were stopped and encrypted. That the attack also reached the restore points is the attacker's claim, not the company's; we put it in the table because it is the boundary we consider decisive, not because it is established there.
Jump four is the one that turns an incident into a catastrophe. The first three leave you without service; the fourth leaves you without a way back. And it is by far the cheapest to break, because on most platforms the backup is taken by the same console that manages the machine, with the same account, and lives on the same box. It is the infrastructure variant of something we have already written about in its identity version: the backup server joined to the same domain is the same circular dependency wearing different clothes.
The number that matters is not 495
The 495 are the affected. The interesting figure is another one, and it took three weeks to settle. On 8 October, in the third report, the provider said data in the four zones was unlikely to be retrievable or restorable. On 14 October, in the fifth, it qualified that: backup data had been confirmed safe and could be retrieved for 194 customers. Today's report records that on 20 October that figure rose to 206.
Two hundred and six out of four hundred and ninety-five. Four in ten. For the other six in ten, what the provider put in writing as early as 8 October is: stand up a separate environment and rebuild there using whatever backup each customer holds themselves. That is not a cruel line or an attempt to dodge responsibility. It is, literally, the only way out left when the restore point lives inside the blast radius. Today, with SoftBank alongside, they are supporting that move and operating the platform themselves on the customer's behalf while the portal stays closed; but the restore still comes from whatever copy each customer had.
It is worth being honest about what that 206 does not say. We do not know how many of the remaining 289 had the snapshot service and lost it, and how many simply did not have it. The report does not break that down. But for the decision you have to make it is irrelevant: from the customer's chair, "my backup did not exist" and "my backup existed and went down with everything else" are the same Monday morning.
And then there is the clock. Earlier today we published that, out of more than eight hundred client engagements measured in the field, only four came close to the 24-to-48-hour objective each attacked company had documented: how long a recovery actually takes. Here, three weeks on, handover of backup data began on 17 October and the management portal has still not reopened: for now the provider runs the operations on the customer's behalf. The two clocks tell the same story from opposite ends.
What the attacker wrote on the console
An aside, properly labelled. From 7 October, screenshots circulated on X of what looked like IDCF's own console carrying a message in English from the attacker, which ITmedia renders in Japanese as "we have seized the infrastructure" and "your cloud is ours", plus an inventory of the damage: 239 hypervisors reached, 225 datastores encrypted, more than 16,600 virtual machine disks, 3.6 PB of primary storage, 41.5 PB of backup capacity lost and 554,153 snapshots destroyed, all of it in seven minutes. Asked about it, the company said it had seen several images that appear to match what was displayed on its console, but has not confirmed any of the figures, and today's report does not reproduce them either.
We treat them as what they are: the attacker's version, unverified, with every incentive to sound enormous. But there is a detail that does not depend on whether the number is 554,153 or half that. If restore points are deleted from the layer that creates them, the time it takes has nothing to do with how many there are: it is a catalogue operation. Five hundred thousand or five thousand, same thing. Which is why no strategy built on "we will see it in monitoring and stop it" survives contact. There is no detection window worth anything against a bulk-delete API call. The only thing that works is that the call cannot reach the copy.
The sentence that is not in the report
The report says "a vulnerability in open-source software". It does not say which. No product name, no version, no vulnerability identifier. That is a defensible call while anybody is still unpatched, and they are under no obligation to publish it. But it leaves a gap with consequences: no reader can check whether that same component is also running in their own house.
Which carries its own irony, because the second measure they announce so it does not happen again is exactly that: centralising software composition information company-wide, previously managed department by department, and automating the matching against vulnerability feeds. A dependency inventory, in other words. The same one needed to answer whether a given library sits inside something you installed without knowing: the inventory with no line for the library that matters.
The prevention plan was written by the victim
This is the genuinely useful part. A set of measures published after paying for the incident is worth more than any best-practice catalogue, because it was written by somebody who already knows what failed. These are theirs, summarised from today's report, turned into questions you can ask your provider — or ask yourself, if the provider is you:
- Who owns security. They have set up an independent organisation dedicated to nothing else, pulling in outside experts alongside the security people they already had. Translated: in your house, is security somebody's job, or the spare time of whoever keeps production running?
- Plan and frequency of vulnerability scanning, written into internal policy, with scope extended to open-source software. The second half is the relevant one: a scan that does not look at third-party dependencies would not have found this.
- A unified software composition inventory (they call it an SBOM), automatically matched against vulnerability advisories. Without it, "does this affect us?" gets answered by hand and late.
- Replacing their own authentication system with an external identity provider. Verbatim: "renewing the authentication system that was the cause of the intrusion". Running your own login means running your own attack surface, on your own patch calendar.
- Restricting portal access to customer IP addresses and making the second factor mandatory. Two textbook controls that, applied to the management plane and not just to email, would have made jump two far more expensive.
Notice what is not on that list: not a single new technology, not one product to buy. It is a list of boundaries and owners. The genuinely expensive part was never the tooling; it was deciding that the customer portal and the virtualisation platform do not touch.
When this does NOT mean signing a second provider
The reflex these days is "we need to be on two clouds". It is almost always the wrong answer, and an expensive one. Doubling the provider doubles contracts, teams, procedures and attack surface, and solves nothing if both clouds hang off the same identity source or are administered from the same laptop: that is one failure domain with two invoices.
What does change the ending is far cheaper, and fits in one sentence: a copy that lives outside the control plane managing the machine. Another account, another place, retention that cannot be shortened from the inside, and restored in full at least once onto hardware other than the original. That copy is the difference between being one of the 206 and being one of the others. You do not need a second provider to have it; you need it not to be taken by the same credential that can delete it.
And a clarification that lands squarely on us: we are also somebody's provider. We run our own hardware in datacenters, with management consoles and portals. This five-point list is not something we only point outwards when auditing a third party; it is the one we apply to ourselves, and the boundary between jump three and jump four is the one that has made us rethink the most. Writing a post pointing at a provider that went down without saying this would be fairly cheap.
Where this fits into what we do
The part of our work that speaks to this is disaster recovery: where the second copy lives, which credential writes it, how long it takes to bring up and onto what hardware. We run managed backups with Proxmox Backup Server and Veeam, on a 3-2-1 philosophy with immutable retention, precisely so that jump four does not exist. The other half is zero trust, which is what we call jumps two and three: the management plane not being reachable just because a login was passed, portal and platform identities not being the same thing, and no permission escalating on its own. If you want us to draw those four jumps over your own infrastructure — especially the fourth — write to us.
Sources. The confirmed facts (date and time of the attack, the four zones, the 495 customers, the vulnerability in the open-source software of the portal authentication system, the escalation to virtualisation-platform administrator by way of the management console, the 206 customers with retrievable backup data, the absence of data exfiltration from customer virtual servers, improper queries against registration information of up to 71 companies — with names or email addresses for up to 31 — and the 4 login passwords altered) come from IDC Frontier's seventh official report, published on 27 October 2026; the intermediate figure of 194 customers and the "unlikely to be retrievable" assessment come from their 14 and 8 October reports, carried over in the same document. The set of measures is summarised from sections 4 (independent security organisation, vulnerability scanning extended to open source, centralised SBOM) and 5 (portal reopening: external identity provider and customer IP restriction with mandatory MFA) of that report. The instruction to prepare a separate environment and restore from whatever backup each customer holds comes from the third report, of 8 October. The attacker's figures (239 hypervisors, 225 datastores, more than 16,600 VM disks, 3.6 PB, 41.5 PB of backup capacity, 554,153 snapshots and seven minutes) come from screenshots circulated on social media and reported by ITmedia NEWS on 9 October 2026: they are unverified, the company has only said it saw images that appear to match what was displayed on its console and has not confirmed the numbers; we quote them as the attacker's version and the argument of this post does not rest on them. The 7 October 3:40 timestamp and the count of 495 also appear in Security NEXT's coverage. Ours — the four-jump table, reading the victim's plan as a list of questions, and the view on second providers — is how we work, not a recommendation from the report cited. Photo: "Cage Quelle EMC HostCo GmbH" by Virtuo Doc, Wikimedia Commons, CC BY-SA 4.0.
Microsoft 365
ES 
CAT 
EN