Keep a forex trading robot running around the clock without leaving your home PC switched on: that is what GMO Internet's Onamae.com Desktop Cloud was built for. In October 2026, attackers broke into the service and took the brokerage logins that customers had saved inside their trading software. One man in Kanagawa lost more than 4 million yen (about $25,000) in roughly two seconds, according to the Asahi Shimbun, and more than 6 million yen (about $38,000) once his later trades were counted.

The attackers demanded $50 million (about 8 billion yen), and GMO refused. Then, on October 25, GMO Internet Group CEO Masatoshi Kumagai wrote on his blog that the company's own white-hat hackers had flagged problems with the service before the attack.

What happened

Onamae.com Desktop Cloud is a Windows virtual private server (VPS) for running forex auto-trading software such as MetaTrader 4 and 5, with plans from 2,640 yen (about $17) a month. Customers store the usernames and passwords for their brokerage and forex accounts inside the trading tools on the server.

According to GMO, a customer inquiry on October 19 started the investigation. The next day the company found a malicious program planted on some customer servers, and from 4 a.m. on October 21 it began shutting down servers on every plan. The number of servers that may have been affected is 26,739; GMO stresses that this is not the number of confirmed break-ins.

GMO's first notice on October 21 said no leak or misuse of personal information had been confirmed. Three days later, the fourth notice told a different story: the system had a security problem, and customer information had been taken out. The attackers are threatening to keep manipulating customer accounts at more than 70 securities and forex firms in Japan and abroad. GMO has not published total losses or the number of victims.

A demand for 8 billion yen, and a 5,000-yen apology

Kumagai's blog says the first ransom letter arrived on October 21 and asked for $50 million. Japanese broadcaster ANN later reported that the attackers appeared to be demanding $1 million (about 157 million yen) by noon on October 27, Japan time. In its seventh notice, GMO itself confirmed it had been warned that customer data would be published and a ransomware attack launched at that hour.

GMO's answer has not changed. It will not pay, because paying would not guarantee that stolen data is deleted or that misuse stops. It has handed communication logs and other evidence to the police. Refusing to pay is not an unusual choice for a Japanese company (related: why Japanese companies don't pay ransoms).

Toward customers, GMO moved quickly. Every current user gets a flat 5,000 yen (about $32), whether or not they lost money. For trades GMO confirms were caused by the breach, it will cover realized losses, meaning the trading loss plus fees. Losses from market moves and profits customers might have made are not covered. Kumagai wrote that GMO will pay the full covered loss even if brokers refuse to refund. The breached platform will not simply be restarted; users can move to a replacement service on a separate cloud platform, free for six months.

"Flagged in advance"

Kumagai explained why it wasn't prevented, saying he was stating facts, not making excuses. For this service too, he wrote, in-house white-hat hackers had pointed out problems that needed fixing, and the team on the ground accepted the findings and was working on them. But it moved carefully, weighing the impact on the service's availability and other priorities. As a result, the response fell short in depth and speed, and the attackers got in through that gap.

For a service sold on round-the-clock trading, taking servers offline to patch them also stops customers' trading.

The warning came from the company's own experts. GMO Internet Group owns GMO Cybersecurity by Ierae, a security firm with a large team of white-hat hackers, and Kumagai says the group as a whole has about 200 security specialists.

What the blog does not say is when the problems were flagged, what they were, or whether they match how the attackers got in. ITmedia noted that GMO has not disclosed what the issues were or how the fix came to be delayed.

What the attackers claim, and a setting that reaches home PCs

On a website they set up themselves, the attackers claim they got in by exploiting configuration mistakes on GMO's side. According to ITmedia, they say every server shared a common administrator account, and that by default, a user's local PC drives were visible from the server once the user connected.

The drive setting is the part that overlaps with GMO's own documentation. The service's official guide explains how to share files with your own PC, then notes that the connection file (an RDP file) downloaded from the control panel already comes set up for file sharing.

With that feature on, a user's local drives show up as folders inside the server while they are connected. Whoever has taken over the server can read what is on that PC, and may be able to write files to it too. The attackers are threatening to publish data from users' PCs and hit them with ransomware. That is why the damage may not stay inside the servers.

Still, GMO has not disclosed how the attackers got in or how its servers were configured, so there is no way to confirm whether they actually reached users' PCs this way. In its fourth notice, GMO warned that the attackers might publish material that includes false information. At the same time, from October 24 the company asked users to run full scans of their own PCs and smartphones and back them up, and on October 26 it began analyzing devices borrowed from customers. Whether the damage reached beyond the servers is not yet known.

Asking to be "case No. 1"

On October 24, GMO asked the government to apply "active cyber defense." Under laws that partly took effect on October 1, the state can access servers being used for serious cyberattacks on the country or critical infrastructure and neutralize them, for example by deleting malicious programs. GMO described its case as the first in which those powers should be used.

But this is not something a company can switch on by asking. Chief Cabinet Secretary Minoru Kihara said on October 26 that the police and the Defense Ministry and Self-Defense Forces will decide on neutralization under the legal requirements, whether or not a victim requests it. GMO is also not a "specified essential infrastructure operator" under the law, the category that covers businesses such as power and gas utilities. Business+IT pointed to legal questions about using the tool after damage has already been done, and to the possibility that announcing the request put the attackers on guard.

Online, the reaction was cool. ITmedia reported that on X, criticism dominated: users said GMO should first examine its own configuration and decisions, and asked whether it was shifting blame to the state. Defenders were a minority. Kumagai wrote that he made the request understanding the legal limits, that GMO is not trying to pass its responsibility to the government, and that it will pay all costs for compensation, the replacement platform and the system overhaul itself.

Not the group's only breach this autumn

Other GMO breach announcements came before this one. On September 20, GMO Internet said a malicious program had been planted in the web server space of 426 customers of its ConoHa WING rental server service. On October 14, GMO Research & AI said it had confirmed that 894,082 members' records containing personal information had been taken from its survey site infoQ. No link to the Desktop Cloud case has been shown.

Fix it, or keep it running?

As of October 27, GMO's latest update is its seventh notice, issued on the night of October 26. The cause is still being investigated with outside experts, and what the white-hat hackers flagged remains unknown.

A team gets a finding, looks for a way to fix it without taking the service down, and time runs out. That is the failure GMO has admitted to, and it could happen at almost any company.

Where you work, when a security finding collides with a promise never to go offline, which one wins?

References