Part 16 of a series on Japan’s cybersecurity blind spot. Start with the overview, Japan cyberattacks in 2026: what the breach wave reveals, or read the previous part, Japan asks for security. Nobody has to do it..

Status as of 26 October 2026: GMO has confirmed customer information was taken and has not published how the attackers got in.

TL;DR: From 20 October, attackers broke into Onamae.com Desktop Cloud, a GMO Internet service that rents cloud desktops for automated currency trading, and used the brokerage passwords customers had stored there to drain their FX accounts in seconds. GMO has admitted a security problem in its own system and confirmed customer information was taken. Its CEO says the company’s in-house ethical hackers had flagged issues with the service beforehand, and the fixes were moving carefully, to protect uptime and other priorities, when the attackers got in. GMO’s response since then has been unusually honest. The lesson for every company is about the step after finding a problem: give it an owner and a deadline, and know where your working passwords are stored.

On the afternoon of 21 October, a 44-year-old office worker in Kanagawa happened to be looking at his foreign-exchange trading screen when it started losing money on its own. In about two seconds he was down more than ¥4 million, and the trades kept coming for nearly two more minutes until the loss passed ¥6 million, Asahi reported. Then an email arrived, in Japanese, from someone calling themselves the “Hacking Team.” It said they had destroyed his entire balance. A woman in Osaka told the Yomiuri her account dropped from about ¥3 million to about ¥1.2 million overnight. Neither of them had been phished. Neither of them had given anyone a password. They had rented a server.

The server belonged to “Onamae.com Desktop Cloud” (お名前.com デスクトップクラウド), a service run by GMO Internet, one of Japan’s largest internet infrastructure companies and the owner of the Onamae.com domain registrar. It rents out Windows desktops in the cloud so that traders can run automated trading software such as MetaTrader around the clock without leaving a home PC switched on. To do that job, the trading software has to stay logged in to the customer’s brokerage or FX account. So the servers held exactly what an attacker wants: live, working credentials to real money, at more than seventy brokers and FX firms in Japan and abroad.

This is Part 16 of the series, and it is the first case this autumn where the damage is counted in yen drained from ordinary people’s accounts rather than in records exposed. It is also the clearest case yet of something I have been writing about since Part 12: the problem was known, inside the company, before the attack.

What GMO has confirmed

GMO has published five notices so far, and they are worth reading in order because the story gets worse with each one. In the first, posted at 4 a.m. on 21 October, the company said it had found malicious programs placed on some customers’ servers the day before, that up to 26,739 servers might have had their contents viewed, and that it was shutting every plan down. At that point it said no leak or misuse of personal information had been confirmed. The second notice, on 22 October, said trading-account login details stored in the trading software on those servers may have been taken and misused, after customers reported trades they never made. The third, on 23 October, added a detail every security person should notice: changing the password might not be enough, because some brokers keep existing sessions alive for a while, so an attacker could go on trading after the password changed. Customers were told to cut every session as well.

TBS NEWS DIG, 22 October, in Japanese, on the break-in and the reports of unauthorized trades. Video: GMO「お名前.com デスクトップクラウド」に不正アクセス　FX口座で不正操作の報告も｜TBS NEWS DIG from TBS NEWS DIG Powered by JNN.

The fourth notice, on 24 October, is the one that matters most. GMO wrote that “a security problem existed in the system of this service” (本サービスのシステムにセキュリティ上の問題が存在し), and that it had confirmed both unauthorized access and that customer information was taken out. That is a plain admission, and plain admissions are rare in Japanese breach notices. The same notice says the attackers are demanding money and threatening to keep manipulating accounts, publish data about customers and their connected PCs, carry out ransomware attacks, and publish information about GMO’s own systems. GMO says it will not pay, because paying would not guarantee the data is deleted or the attacks stop.

Two numbers need care. The 26,739 servers are the servers that could have been affected; GMO says this is not a count of confirmed intrusions. And the attackers’ own claims about how much money they “destroyed” are claims, not findings. GMO has not published a total for the losses, and it has not said how the attackers got in.

The warning came from inside

On 25 October, GMO Internet Group’s CEO, Masatoshi Kumagai, published a long post on his own site. Most of it is about why GMO asked the government for help, which I come to below. But in the middle is a section headed “Why couldn’t we prevent it? Reflection as management,” and it contains the most important sentences anyone has published about this breach. “This is not an excuse; I am telling you as fact,” he wrote. “Regarding the security of this service, too, our in-house white-hat hackers had pointed out issues to be improved to the front-line team in advance. The team accepted those findings and was working on countermeasures.”

Then the reason it wasn’t finished: “As a result of proceeding carefully while considering the impact on the service’s availability and its priority relative to other matters, the depth and speed of that response were not sufficient, and the attackers exploited that gap.” Availability means keeping the service running for paying customers. Priority means everything else on the list. Those are the two forces that delay every security fix at every company I have ever worked with, and here the head of a listed company has named them in public as the reason his customers lost money.

I want to be fair about what this does and doesn’t tell us. Kumagai doesn’t say what the weakness was, whether it was the one the attackers used, or how long ago it was flagged. It is possible the attackers came in some other way entirely. He also mentions, in another part of the post, that a serious PHP vulnerability was recently exploited at scale with the help of AI, but he offers that as an example of the times, not as the cause here, and GMO hasn’t linked this breach to it, so neither will I. What his post does establish is the pattern: a known problem, a team working on it, and a decision, made reasonably and in good faith, to move carefully rather than fast.

That is technical debt, described by the person who owns it. In Part 12 I argued that the October shutdowns were what happens when deferred upgrades come due all at once. GMO is the same story at the scale of a single service. The fix existed as a plan. The interest on the delay was paid by customers, in seconds.

A vault of other people’s keys

The second lesson is about what was on those servers. In Part 14, attackers placed trades in IwaiCosmo Securities customers’ accounts without stealing a single customer password; they went through a misconfigured administrative function at the vendor that runs the trading system. The front door held and the back office didn’t. GMO is the same shape from a different angle. The brokers’ own logins weren’t broken. The attackers walked in with correct passwords that customers had saved on a third party’s servers so their software could trade for them.

Nobody did anything strange here. Storing the login is the whole point of the service. But it means one company’s servers held working keys to tens of thousands of accounts at dozens of other companies, and none of those brokers could see or control how those keys were protected. Japan’s brokerages spent 2025 and 2026 making customers switch to passkeys after the account-takeover wave; an automated trading tool that sits logged in all day goes around that protection by design. The more convenient the setup, the more the safety of the money depends on a company the account holder never chose as a security provider.

Every business has a smaller version of this. The accounting software logged in to the bank. The website plugin holding the payment API key. The shared spreadsheet with the supplier portal password in cell A1. The vendor’s remote-support tool that never logs out. The question GMO’s customers couldn’t answer in time is the question every company should be able to answer today: where are our working credentials stored, and who else’s systems are they sitting on?

Credit where it’s due

For all that, GMO’s response has been better than most this autumn, and it should get credit. It shut down every server within about a day of finding the malicious programs, accepting the cost of a full outage. It published successive notices with specific instructions, including the session warning, which many companies would have left out. In the fourth notice it admitted a security problem in its own system, offered every current user ¥5,000 whether or not they lost money, and promised to compensate realized losses from fraudulent trades it confirms, even when the broker refuses a refund. It will not restart the compromised platform; customers who want to keep a Windows desktop will be offered a separate, independent service, free for six months. And it has refused to pay the extortionists.

The compensation has limits worth knowing. It covers realized trading losses and fees that GMO confirms came from the attack, not market movements or profits a customer might have made, and customers will need to submit records and ask their broker for a reversal first. Details are due by 6 November. But compare it with the many Japanese breach notices that never get past “no misuse has been confirmed at this time,” and GMO’s is the more honest document.

Asking the government, again

The last part of the story is about the state. On 22 October, the Financial Services Agency sent a notice to FX firms through their self-regulatory body, the Financial Futures Association of Japan, asking them to urge customers to change passwords, check for unrecognized trades, and step up monitoring for suspicious activity, Asahi reported. Several brokers had already moved on their own; OANDA Japan and AI Gold Securities told customers the same day to change passwords, turn on two-step login, and check their histories. In Part 15 I wrote that Japan’s security policy runs on requests that nobody is required to follow. This one was sensible and quick. It was also a request, sent through an industry association, after the money was gone.

GMO went further and asked the government to treat the case as the first use of Japan’s new active cyber defense powers, which allow the state to track and neutralize attackers’ infrastructure and came into force on 1 October. Kumagai’s post acknowledges the two obvious objections: GMO is not one of the critical-infrastructure operators the law was written for, and the government decides when to act, not a company. He asks anyway, arguing that what matters is the real effect on people’s savings, not the formal category, and he says GMO will bear the full cost of compensation and rebuilding itself. Whether the government acts is its decision. But the request makes a point the series keeps returning to. Once the money has moved, the state can chase the attackers. It can’t undo the delay that let them in.

What this means for your company

GMO had what most Japanese companies don’t: its own team of professional ethical hackers, who looked at the service and found problems. That is the hard part, and they did it. What failed was the step after finding: turning a finding into a finished fix, on a deadline, when the fix competes with keeping customers happy today. That step is a management decision, which is why Kumagai framed it as a failure of management rather than of the engineers.

Three things follow for any business, with or without its own security team. First, when someone flags a security problem, give it an owner and a date, and treat “we’re working on it carefully” as a status that expires. Second, know where your working credentials are stored, especially on systems you don’t run, and remove the ones that don’t need to be there. Third, know what your vendors can reach, and what you would do in the first hour if one of them told you their servers had been compromised. GMO’s customers who could answer that hour well were the ones who changed passwords and cut sessions from a different device before the second notice even arrived.

This is the work I do with clients. Diagnostics maps what a company runs, who can change it, where its keys and accounts live, and which outside services sit in the middle of its money and data. If you want to start smaller, the Domain Exposure Report shows what your company already shows the outside world, for ¥5,000 + tax. Neither requires a breach to be worth doing. GMO’s own experts saw this one coming. The goal is to make sure the people who see it coming are also the ones who get to decide how fast it gets fixed.

What should companies learn from the GMO Onamae.com Desktop Cloud breach?

The GMO breach teaches two lessons for any company. First, a finding is not a fix. GMO Internet’s CEO wrote that in-house ethical hackers had flagged issues with Onamae.com Desktop Cloud before attackers broke in from 20 October 2026, and that the response moved carefully to protect availability and other priorities. Give every flagged security problem an owner and a date, and treat “we are working on it carefully” as a status that expires. Second, know where your working credentials are stored, especially on systems you do not run. The service held traders’ saved brokerage logins so automated software could trade around the clock, and attackers used those passwords to drain FX accounts in seconds, at more than seventy brokers. Every business has a smaller version: accounting software logged in to the bank, or a supplier password in a shared spreadsheet. Remove the ones that do not need to be there, and plan the first hour after a vendor reports a compromise.

The next part, Don’t wait for the government. Fix the flaws before AI finds them., looks at Japan’s AI and policy response to the breach wave, and why companies should not wait for it.

Sources as of 12:00 JST, 26 October 2026. If GMO publishes the cause or the government responds to its request, this article will get a dated update.