Breaches

GMO refuses $50m demand as alleged Desktop Cloud data leaks

GMO Internet refused a ¥8bn demand after its Onamae.com Desktop Cloud was breached and trading logins abused. Alleged data is now online.

Illustration of a server rack representing the breach of GMO's Onamae.com Desktop Cloud hosted desktop service

Japan’s GMO Internet has refused a demand of roughly ¥8 billion (about $50m) after an intruder compromised its Onamae.com Desktop Cloud service and stole customer data, and on 27 October it confirmed that material purporting to be company and customer data had been published online. The case shows how much damage one hosted desktop platform can do, and how expensive it is to delay fixing weaknesses your own testers have already reported.

What happened

Onamae.com Desktop Cloud is a hosted Windows desktop service from GMO Internet, a major Japanese registrar within GMO Internet Group. GMO has marketed it as a place to run automated foreign exchange trading, and many customers used it to keep MetaTrader 4 and MetaTrader 5 running around the clock.

According to GMO’s own incident reports, the investigation began on 19 October after a customer inquiry. On 20 October staff found an unauthorised program in some customers’ server environments and suspended new sign-ups and the control panel. From 04:00 on 21 October the company shut down servers across every plan. It listed 26,739 servers as potentially affected and warned that data stored on them, including trading account logins saved in trading tools, could have been exposed. Customers soon reported trades on their accounts that they had not placed.

In its fourth report, published on 24 October, GMO admitted that the service had security vulnerabilities, that its environment had been accessed without authorisation, and that customer information had been taken out of the company. CybersecurityNews reports that the extortion email arrived on 21 October and demanded about ¥8 billion. GMO says the attacker also threatened to leak data, deploy ransomware and keep placing fraudulent orders at more than 70 brokers. The company refused to pay, saying payment would not guarantee the data was deleted or stop it being misused.

Before a threatened noon deadline on 27 October, GMO told customers to back up their data, disconnect from the network, power down and unplug their PCs. It later confirmed that material described as company and customer data had appeared online, and it is checking whether that material is genuine. A 13:55 update said no ransomware attack had been confirmed at that point. GMO is working with Trend Micro and has threatened legal action against anyone who spreads the leaked data.

The technical picture

GMO has not said how the attacker got in, and none of the reporting so far names a group behind it. Its notices describe three linked problems. Malicious code ended up inside customer-facing virtual servers. Credentials stored on those servers were harvested and used against third-party brokers. GMO also feared, correctly or not, that customers’ own PCs could be reached from the hosted environment.

Hosted desktops are usually reached over remote desktop protocols, and features such as drive and clipboard redirection open a path from the server back to the client. Asking customers to scan and disconnect their own devices suggests GMO feared that path, though it has confirmed no infected endpoint.

Much of the financial harm happened on the broker side. GMO warned that some trading platforms keep existing sessions alive after a password change, so changing a password alone would not lock out an attacker who already held a valid session. It asked brokers to end active sessions, watch for unusual trades and block orders coming from the Desktop Cloud environment.

Timeline of the GMO Onamae.com Desktop Cloud incident from 19 to 27 October 2026

Why it matters for UK organisations

This is a Japanese incident, but the pattern applies to the UK. Many UK businesses, traders and small firms rent hosted desktops, virtual private servers or managed workspaces, and leave credentials for banks, brokers, payment portals and cloud consoles saved inside them. If the platform is compromised, every one of those secrets has to be treated as exposed, along with every service they unlock.

The case also shows how a single provider can multiply the damage. Tens of thousands of customer environments sat behind one operator, and the stolen data put accounts at dozens of financial firms at risk. It is exactly the concentration risk that the UK critical third parties regime and the Cyber Security and Resilience Bill’s supply chain provisions aim to reduce.

Reporting duties do not move to the provider either. Under UK GDPR a personal data breach likely to pose a risk to people must be reported to the ICO within 72 hours, and FCA-regulated firms have their own notification obligations.

Expert view

For me the most significant detail is in a blog post by GMO’s chief executive, Masatoshi Kumagai, as reported by The Register. He wrote that the company’s in-house white-hat hackers had already pointed out areas for improvement and that the team was working on countermeasures. In his words, the response “lacked sufficient depth and speed”. Any penetration tester will recognise that.

In my experience, the findings that hurt clients are rarely ones nobody had spotted. They are usually findings that were spotted, accepted as risk, and then left behind more urgent work because fixing them meant downtime or customer disruption. GMO’s own explanation, that it moved cautiously to protect availability, describes exactly that trade-off. Availability matters, but an unfixed weakness on a multi-tenant platform holding financial credentials should not stay on a backlog for months.

GMO’s refusal to pay is the right call and matches the position of the NCSC and UK law enforcement. Being open with customers about the threat and what to do also left the extortionist with less leverage. Its pledge to cover verified trading losses and move customers to a separate cloud platform, rather than restart the compromised one, is also worth noting.

What to do now

  1. Inventory hosted desktops and VPS estates. Identify every rented virtual desktop or server, who uses it and which credentials are saved inside it. Treat saved browser passwords and application logins as part of your attack surface.
  2. Revoke sessions, not just passwords. If a platform is compromised, change credentials from a clean device and then explicitly end all active sessions and API tokens at each linked service. Confirm the revocation with the provider.
  3. Enforce multi-factor authentication everywhere it is offered, especially for financial, broker and administrative accounts. This maps to the Cyber Essentials user access control requirements.
  4. Restrict remote desktop redirection. Turn off drive, clipboard and device redirection to hosted desktops unless there is a business need, which supports the secure configuration control.
  5. Put deadlines on penetration test findings. Give high-risk issues an owner and a fix date, and require board-level sign-off for any risk acceptance that runs past that date.
  6. Ask suppliers hard questions about tenant isolation, patching speed and incident notification, and write the answers into contracts.
  7. Rehearse the extortion scenario. Decide your ransom position, legal approach and customer messaging in advance, and keep offline backups that you have tested.

Bottom line

A single compromised hosted desktop platform led to stolen trading credentials, fraudulent trades, a demand of about $50m and a leak of what is claimed to be company and customer data. GMO is responding well now, but its own specialists had warned it. UK organisations should review what they keep on rented desktops, revoke sessions rather than only changing passwords, and close out test findings before an attacker finds them.

Sources

Related Posts