Related to the series on Japan’s cybersecurity blind spot. Start with the overview, Japan cyberattacks in 2026: what the breach wave reveals, or read the latest part, Nobody had to hack Japan’s earthquake warning. I keep the public incident list on the Japan breach tracker.

In August 2025, two people checked into a hotel in Kobe, connected a computer to the room’s Wi-Fi, hid it in a corner of the room, and checked out. Police believe an accomplice controlled it remotely. The computer sent at least several hundred thousand phishing emails. Those messages led people to fake sites built to collect credit card details. The mail went out through the hotel’s internet connection, which hid where it really came from. The hotel consulted the police, who found the computer still connected. The pair have since been indicted.

That account is from a FrontierStack article published on 16 October 2026. It reports a Tokyo Reporter story from this week, citing NHK, and it places the check-in in August last year, meaning August 2025. The account above is the article’s. From here, this is my reading of it.

Police arrested the same couple on 15 October over a second Kobe hotel: a PC hidden behind a room’s refrigerator in May 2025, with about 480,000 phishing emails in its send history, by the police count. A recipient traced the mail to the hotel’s IP address and contacted the hotel. In Japanese. Video: ホテルのWi-Fiで48万件の偽メール送信　中国籍の夫婦逮捕　冷蔵庫裏にパソコン隠す【知っておきたい！】【グッド！モーニング】(2026年10月16日) from ANNnewsCH.

Guest Wi-Fi did the only job it has, which is to put a stranger’s device on the internet. Nobody had to break in. The missing piece was someone watching what that device did next. That is a monitoring gap. A hotel, a serviced apartment, a coworking space, or an office can close it.

I advise on IT infrastructure from Tokyo. The same pattern fits a hotel, a serviced apartment, a coworking space, or an office: anywhere the network is shared with people who are not staff. The computer does not have to defeat a control that was never there. It only has to be allowed on, and then left alone.

What the network would have shown

Four signals are visible from the network, without opening the machine.

Mail goes straight out to other people’s mail servers. Phones and laptops send mail through their own provider, on the encrypted ports 587 or 465, or through webmail. They do not open connections to dozens of different mail servers on port 25. Port 25 is the old direct path from one mail server to another. A guest laptop has no honest reason to use it. A device on a guest network that does is the signature of a spam bot.

The device never leaves. Guests come and go. A device that stays on the guest network for weeks, through every checkout, is not a guest.

The business’s own address can land on a blocklist. Mail providers report spam sources to lists such as Spamhaus and SpamCop. The listing names the public IP address the mail came from. When that address is the hotel’s, or the office’s, the listing can stop the business’s own legitimate email, booking confirmations included, from being delivered. The computer was using the hotel’s connection to hide its origin. If the public address is listed, the cost lands on the network it borrowed.

Traffic stays high when the room should be quiet. Several hundred thousand messages means steady traffic around the clock, possibly from a room that is empty. A router that has a normal week already knows what a quiet night looks like. Steady traffic through those hours is the odd part.

The checks I run

FrontierStack is one of the tools I use to secure my operations. It is also how I manage the rest of that working stack: what each tool is for, and how work moves between tools. That is the description on my Ultra Stack page.

The write-up of the Kobe case describes checks that watch for the same four signals, from the router and from the internet. Nothing is installed on a guest’s phone or laptop, which you could not do anyway.

The mail check, Rogue Device Watch, reads the connection table on an OPNsense, pfSense, MikroTik RouterOS, or OpenWrt router every ten minutes. When a device that is not one of your approved mail servers contacts five or more different outside mail servers on port 25 within an hour, it raises an alert and names the device: the IP address, the MAC address, and, where the router knows it, the hostname from the DHCP leases. Mail arriving at your own mail server does not count, and the threshold can be changed. The article says a computer sending mail the way a spam bot does sets that alert off within ten minutes of the first batch.

It can also flag a device that never leaves. You mark which networks are for guests. A device that stays connected for more than seven days raises an alert. That window can be changed. The check stays off until you turn it on. A smart TV, a room controller, or another fixture can be acknowledged once so it stays quiet.

A separate check looks up your domains, your mail servers, and your routers’ public IP addresses on the major blocklists, on a schedule you choose. A listing raises an alert with a link to that list’s lookup and removal page. If a list refuses to answer, the result is shown as inconclusive. It is not shown as “listed”.

Router usage alerts learn each router’s normal traffic for every hour of the week. A sustained spike raises one alert. Several days well above the four-week median raises another, titled “possible unauthorised use”, which also compares the number of connected devices with normal.

Those are the checks as that article describes them. I run them on my own operations. The Kobe hotel was not a network I operated.

Close the door first

Watching the network is the second step. The first is to make the guest network a poor place to send spam.

  • Block outbound port 25 from guest networks. Guests do not need it. Only your own mail server does. If a guest phone cannot reach port 25, a hidden computer on that same network cannot use the direct path this one used. On OPNsense and pfSense, the mail check I use can read the firewall rules and say whether the guest network can still reach port 25. It does not change the rules.
  • Turn on client isolation on the guest Wi-Fi, so one guest’s device cannot reach other guests, the staff network, or your own systems.
  • Change the guest Wi-Fi password on a schedule. A password that never changes is effectively public after a few months of guests. A new password also cuts off any device that only knows the old one, including one left in a corner.
  • Watch the public IP address on the blocklists. Weekly is plenty. You want the listing to show up on your own check, before a guest asks why a confirmation never arrived.
  • Watch the router’s traffic against its own baseline for each hour of the week. A line that stays busy around the clock, or a room that is empty and still talking to the internet, is the thing to look at before anyone calls the incident sophisticated.

If the computer is still there

  1. Identify the device. The useful names are the MAC address and which access point it is joined to. The access point’s client list narrows the search to a floor or a wing. On a wired network with managed switches, the switch port for that MAC address does the same narrowing.
  2. Cut its network access, not its power. Block the MAC address on the router or the access point, and change that network’s Wi-Fi password. Leave the machine where it is.
  3. Contact the police before anyone handles it. In Kobe, the hotel’s call to the police is what led to the computer being found still connected.
  4. Once the sending has stopped, ask the blocklists to remove the address. Many lists drop a listing after the spam stops, some on their own and some when you request it. Booking mail and ordinary business mail stay at risk until that public address is clean.

If the sender turns out to be a real system, such as a property management system that sends its own confirmations, add it to the approved list. The next alert should be about a stranger.

The same mail, from the other end

This check-in was in August 2025. The indictment is the part that surfaced now. The mail itself is the kind already moving through Japan this autumn: a message that leads to a fake site and a request for card details. The supply side of that mail is what I covered the same day in Quoted in The Japan Times on Japan’s phishing kit crackdown: the shops that sold the kits, and the steps a person can take without waiting for the next takedown.

I keep a row for every organization in Japan that has published a cyber incident notice, on the Japan breach tracker. The series overview, Japan cyberattacks in 2026: what the breach wave reveals, is the longer account of how those disclosures fit together. In Nobody had to hack Japan’s earthquake warning I wrote about the other end of the same problem. Addresses leaked from a local-government alert service, and phishing was already sent to them. One side is a computer hidden on a borrowed connection. The other side is a person whose address was taken, opening a message that looks like a warning or a receipt.

A hotel can become part of the path without being the target. The connection on the way out is the hotel’s. The card form belongs to someone else. The monitoring gap is what joins them.

Where I come in

I’m an IT infrastructure advisor in Tokyo, with 14 years in Japan and fluent Japanese. I help organizations see what is actually on their networks, and close the ordinary gaps that let a stranger’s computer send mail in their name.

A good place to start is my external exposure check: up to three domains, public information only, with a written report in five business days and a 30-minute debrief, for ¥100,000 + tax. That check is the outside view: email authentication, DNS, the website, public login pages, and certificates. It will not see a computer hidden in a guest room. Diagnostics goes further, into the vendors, accounts, and access paths behind your systems. Write to me at matt@mkultraman.com, in English or Japanese.

Sources