Japanese railway operator Keio Corporation confirmed (Translation here) that a ransomware attack hit its group servers on September 26, causing system disruptions across some of its businesses.
Keio immediately disconnected portions of its network and is working with police and external experts to investigate the attack. The ransomware disrupted business systems at some Keio Group companies, including hotel and payment services, although railway operations were not affected.
Keio said it has not confirmed that confidential company or customer information was leaked but is continuing to investigate the scope of the incident. The disclosure came the same weekend Tokyo Metro reported a separate cyber incident involving systems containing approximately 59,000 member email addresses. The operators have not indicated that the incidents are connected.
Denis Calderone, CTO, Suzu Labs:
“Keio’s train operations survived this ransomware and all indicators point to network isolation between the rail systems and the corporate network. The hotel reservations, supermarket card payments, bus ticketing, department store loyalty points all went down indicating at least some level of shared infrastructure. We’re intrigued that there were 3 different Japanese transportation related incidents (Tokyo Metro had 59,000 member email addresses compromised through a breached vendor server, and Times Car lost data on 6.6 million accounts including driver’s license images) just days before mandatory cyber incident reporting kicks in for critical infrastructure operators.
“Japan’s National Police Agency reported 123 ransomware incidents in the first half of 2026, the highest six-month count on record. Forescout data shows Japan has gone from the 28th most-attacked country by ransomware groups to 14th in just two years, with attacks rising 39% year over year. VPN appliances were the entry point in roughly 60% of those cases. On October 1, Japan’s Active Cyber Defense law takes effect, requiring 257 designated critical infrastructure operators across 15 sectors, including rail, to report cyber incidents promptly to the government. Keio just became the preview of what that reporting obligation looks like in practice.
“Every critical infrastructure operator should be asking which of their systems would pass the same test if ransomware or some other threats were to hit their corporate or production networks tomorrow. The new reporting law is a step in the right direction, but reporting an incident faster doesn’t prevent one. With VPN appliances as the dominant entry point, the fundamentals matter more than the regulation. You should ensure you patch internet-facing equipment aggressively, segment what actually needs to be isolated, and don’t assume that business systems adjacent to critical operations have earned the same level of protection. As the trends this year have been showing, the best practice right now requires you to reduce the attack surface as much as possible. Reduce what is exposed to ease your defensive efforts.”
Seemant Sehgal, Founder & CEO, BreachLock:
“Keio containing the impact to business systems and keeping railway operations running suggests the segmentation between corporate IT and operational technology held up under real conditions, which is not something every operator in this space can currently claim. The useful question for other transit and logistics companies watching this is whether their own segmentation would perform the same way if tested tomorrow.”
Ransomware can make any business stop dead in its tracks or severely impair it. Thus the best advice is to never let the bad guys in so that you don’t get pwned.
OpenAI Says ‘Oops-Sorry Australia
Posted in Commentary with tags OpenAI on September 29, 2026 by itnerdOpenAI published an open letter to Australia’s government, admitting that several more governments websites that were breached & promising to “do better.”
You can read the letter here. Ryan McCurdy, VP, Liquibase (https://www.liquibase.com/) says this:
“At this point, we have enough examples to know this wasn’t just one agent doing something unexpected against Medicare. Different agents accessed different government systems in ways OpenAI didn’t authorize. We should assume AI agents will occasionally take actions their operators didn’t expect and build around that.
“The agents didn’t need or have malicious intent. It was simply given a normal research task, and when it couldn’t find the information it wanted, found another way into the system, and kept going.
“An agent can be trying to do exactly what it’s asked to do and still make a bad decision. If it has enough access and authority, that decision can become a security incident.
“The open letter aside, I think OpenAI is doing the right things. They’ve restricted live internet access in these environments, expanded monitoring, paused tool-use training and evaluation for their most capable models, and committed to working directly with the affected agencies. But we can’t rely on better models and better monitoring alone. The controls also need to sit outside the agent.
“Pausing its latest top models makes sense while OpenAI figures out what happened and puts additional safeguards in place. But we can’t pause AI every time an agent does something we didn’t expect. We have to start by assuming it’s going to continue to do so.
“AI makes decisions based on probabilities. We can’t let those decisions automatically become actions against critical systems.
“Any company deploying agents needs to decide what an agent can access, what it can change, what it can decide on its own, and where policy or a person needs to make the call.
“Permission and authority are two different things. Design the AI SDLC so the governed path is the easiest path. Give agents the freedom to move quickly while keeping controls over critical systems outside their reach.
“The agent shouldn’t get to decide that its own high-risk action is safe.”
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs (https://suzulabs.com/home-suzu-labs) says this:
“It is good that OpenAI says it will do better, but if the company were truly committed to accountability, we should see full cooperation with law enforcement, preservation of logs and evidence, and consequences for the people responsible for these security failures. If I accidentally hacked one organisation, let alone multiple organisations, I would not expect to get by with a promise to do better. I would expect an investigation. Criminal charges should follow if investigators determine that offences occurred. Until then, OpenAI’s response looks more like an attempt to turn a legal problem into a public-relations exercise.
“OpenAI said it would pause its top models – that’s not enough. If this were a one-off case, I would be more sympathetic, but this is a pattern of behaviour involving OpenAI agents bypassing controls, accessing systems and pursuing objectives beyond their authorised scope. A pause without a clear timeline, independent testing, release criteria or mandatory reporting requirements is little more than a platitude. I view it as an attempt to deflect attention from potential criminal liability and turn what should be a legal and security investigation into a public-relations exercise. Training pauses do not fix the underlying oversight, access-control and accountability failures.”
I personally think that enough is enough. OpenAI has proven that it cannot be trusted. Therefore I hope that Australia punishes them severely. Because punishment isn’t going to come from the USA. Especially given this development over the last hour.
Leave a comment »