Ransomware

In the early hours of Saturday, September 26, Keio Corporation found ransomware on its group's servers. Keio runs 84.7 km of railway and 69 stations in western Tokyo, and around the railway it owns supermarkets, hotels and a bus company. The trains kept running. The subsidiaries did not fare as well: some Keio Store supermarkets could not take cards, e-money or QR code payments, and some were still cash-only on Sunday. Keio Presso Inn stopped taking new reservations, Keio Plaza Hotel warned that replies to booking inquiries would be delayed, and Keio Bus could not take credit cards at its commuter pass counters.

Keio cut network connections to stop the spread, reported the attack to the police and brought in outside specialists. It says it has found no evidence of data theft so far and is still checking whether customer or business information was taken. At the time of reporting no ransomware group had claimed the attack. For any business made up of several companies that share IT, the useful part of this story is the pattern of what stopped and what kept working.

How one attack reached four businesses

Keio has not said how the attackers got in or which systems were encrypted, and this post does not guess. What it did say is telling. Its first notice describes an attack on "our group's servers" that disrupted the business systems of "some group companies". Nikkei reported Keio's explanation for the railway: the servers that run train operations are on a separate system, so they were not affected.

That is the conglomerate blast radius. Groups like Keio often centralise IT to save money: one Active Directory domain, one data centre or virtualisation cluster, one backup platform and one payment switch serving every shop and hotel. Ransomware operators who get domain administrator rights on a shared environment can push their encryptor to every server that trusts it, usually through Group Policy, remote service creation or the hypervisor console. Whatever shares those things goes down together, and whatever sits on a genuinely separate system, like Keio's train control, carries on.

Payments show the dependency most clearly. A card terminal in a supermarket usually sends each authorisation through the store's network to a central payment gateway, and loyalty points are looked up on a central server. When the head office network is cut, the terminal has nowhere to send the request, so the store falls back to cash. Some terminals support an offline mode (store-and-forward, where transactions are queued and sent later), but the merchant carries the risk of declined cards, and it only works if it was agreed with the card acquirer beforehand.

What happened after detection

The response followed the order most incident plans lay down:

• Early on September 26, Keio confirmed the ransomware and began disconnecting networks to stop it spreading.
• The same day it notified the police, engaged external specialists to trace the route in, and published a notice. Keio Plaza Hotel, Keio Presso Inn and Keio Bus posted their own notices.
• On September 27 Keio Store announced the payment and points outage, and Nikkei reported some stores still accepting cash only.
• As of the latest reporting, Keio had not confirmed any data leak and no group had claimed the attack.

Shutting the network down is blunt but effective. It stops the encryptor from reaching more servers and cuts the attacker's remote access, at the cost of taking healthy systems offline too. The narrower your segments, the less you have to switch off to contain an attack.

Tokyo Metro disclosed a separate incident the same weekend, in which about 59,000 member email addresses were exposed through an email distribution server. BleepingComputer says it is unclear whether the two are connected.

What to do

These steps are for any organisation that runs several businesses, brands or sites on shared IT.

1. Map what the subsidiaries share. List the Active Directory forests and domains, hypervisor clusters and their management consoles (vCenter, Hyper-V hosts), backup servers, remote management and EDR consoles, file servers and the payment switch. For each one, write down which businesses stop if it is encrypted.
2. Separate the shared layers. Put each business unit in its own network zone with firewall rules that allow only named flows between them. Keep hypervisor and backup management off the everyday domain, with separate admin accounts. On Active Directory, use a tiered admin model so an account that manages shop PCs cannot log on to domain controllers.
3. Plan containment by segment. Decide in advance which switch, firewall rule or VPN you would cut to isolate each business, and test that cutting it leaves the others running.
4. Give payments a way to work without head office. Ask your acquirer whether your terminals support offline authorisation and what floor limit applies. Consider terminals that reach the acquirer over their own cellular connection, so a store network shutdown does not stop cards. Keep a cash float and a script for staff.
5. Keep bookings readable offline. Export upcoming reservations and guest lists daily to a place that does not depend on the main network, so a hotel can check guests in with the reservation system down.
6. Protect the backups. Keep at least one copy offline or immutable, with credentials that are not in the main domain, and test a full restore of one business unit.
7. Rehearse across companies. Run a tabletop where one subsidiary is encrypted and the others have to decide, within the hour, whether to cut their links.

To check for the early signs of a ransomware operator on your network, look in the Security log of your domain controllers for accounts added to Domain Admins or Administrators (event IDs 4728 and 4732) and Group Policy changes (5136). On servers, look in the System log for new services (7045), and for vssadmin delete shadows or wbadmin delete catalog in process creation logs (Security 4688 or Sysmon event 1). All of these usually happen shortly before encryption.

The wider lesson

Keio's railway survived because it was kept apart from the rest of the group. The same thinking can be applied to anything a business cannot afford to lose for a weekend, such as payments, reservations or payroll. Giving each of those its own path, and rehearsing the switch-off, is what decides whether an attack stops one business or all of them.

Our network penetration testing can start from a foothold in one business unit and show how far an attacker could get across a shared network, and our security operations team watches for the privilege changes and backup tampering that come before encryption. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Keio Corporation notice, Keio company profile, BleepingComputer, ITmedia NEWS, Nikkei, RusTourismNews, Rankiteo, Innovatopia.