Onamae Desktop Cloud Breach Turns Remote Sessions Into Trading Risk

GMO Internet has confirmed that security weaknesses in Onamae.com Desktop Cloud allowed unauthorized access and the removal of customer information. The company found malicious programs in some customer server environments and received reports of trading-account activity that customers did not recognize. It lists 26,739 servers as potentially affected, but explicitly says that figure is not a count of confirmed intrusions or confirmed data theft. The exact intrusion route, number of compromised servers, and customer-by-customer data scope remain under investigation.

Customers should respond from a device that was not used for trading: change every trading and stored-service credential, force termination of all active sessions through the broker where necessary, enable strong multifactor authentication, review balances and transaction history, and preserve objective records of suspicious trades. GMO says it will not restart the affected platform unchanged. It plans to move willing customers to a separate cloud foundation after safety checks, which is the correct trust boundary for recovery because a password change cannot establish that a compromised remote desktop is clean.

The incident record changed materially over four days. GMO began investigating after a customer inquiry on October 19. On October 20, it confirmed that a third party had installed malicious programs in some customer server environments, stopped new applications, and disabled the control panel. From 04:00 JST on October 21, the company began shutting down servers across every Onamae Desktop Cloud plan. The first notice described possible viewing of information; later notices confirmed that information left the company environment.

By October 22, GMO had received reports of unauthorized operations in trading accounts associated with tools running on the service. Its October 24 statement says the service had security vulnerabilities, its environment was accessed without authorization, and customer information was exfiltrated. Customers reported trades they did not recognize. These are confirmed vendor statements. They do not establish that every potentially affected server lost data or that every reported trade has completed forensic attribution to this incident.

The scope figure needs careful wording. GMO lists 26,739 servers across all plans as potentially affected and expressly warns that this is not a confirmed count of unauthorized access or information acquisition. Potentially exposed material includes whatever customers stored on their virtual desktops, including login details saved by MT4, MT5, browsers, or other trading tools. GMO says its own payment information, including credit-card data, was not stored on these servers, but customer-saved data remains in scope.

A hosted desktop often stays signed in so automated trading software can run continuously. That convenience concentrates several forms of authority: account identifiers, locally stored passwords, browser credentials, application configuration, active session tokens, broker server details, trading scripts, and records of positions or strategies. Malware with access to the desktop may not need to defeat the broker's login screen if a session is already authenticated or a client has stored reusable credentials.

This is why GMO's third report distinguishes password change from session termination. Some brokers or exchanges may keep existing connections alive after a password changes. The vendor tells customers to disconnect every active session themselves or ask the financial provider to do it, even if the password was already replaced. That action closes a live authorization channel; the new password protects only future authentication attempts. Customers should request written or ticketed confirmation where the broker can provide it.

Two-factor authentication helps at login, transaction, and withdrawal boundaries, but its effect depends on the broker's implementation. It cannot retroactively invalidate a stolen session and may not protect an unattended trading API or terminal that was previously authorized. Japan's Financial Services Agency separately recommends multifactor authentication, transaction notifications, unique passwords, direct navigation to legitimate provider sites, and routine account review. Those controls reduce follow-on risk without proving this incident's individual exposure.

Do not use the affected remote desktop to create replacement credentials. GMO instructs customers to use a smartphone or different PC that was not used for FX trading. Start by contacting the broker or exchange through a bookmarked official site or known telephone number. Change the account and trading-tool passwords, terminate all sessions, enable the strongest available multifactor method, and review whether recovery email, phone, withdrawal settings, linked accounts, API keys, or trusted devices changed.

Expand the inventory beyond the trading account. Rotate credentials for email, cloud storage, source control, password managers, exchanges, wallets, remote-access tools, messaging accounts, and any other service saved in the virtual machine or browser. Revoke application passwords, API tokens, and remembered devices at their issuers. If the same password was reused elsewhere, replace it with a unique value. Do not respond to messages claiming to be the attacker or a compensation agent, and do not open their links or files.

GMO also asks customers to run a full security scan on their own PCs and phones and to back up data cautiously while it investigates possible endpoint impact. The company labels this precautionary. Its public notices do not confirm that malware spread from the hosted desktop to customer devices. Preserve that distinction: scanning and backup are sensible containment measures, but a scan result should not be presented as proof of how the server compromise occurred or which local files were exposed.

Capture the account state before normal activity obscures it. Export transaction history, order history, login history, notifications, positions, fees, balance changes, and timestamps in the broker's available format. Record the time zone. Save the broker case number, relevant emails, screenshots, and any statement that identifies an unauthorized order. Avoid editing the original files, and keep a separate chronology of when passwords changed, sessions ended, and the provider acknowledged the report.

GMO says it will compensate realized losses, including trading losses and fees, when its investigation confirms that unauthorized transactions resulted from this incident. It excludes market-movement losses, hypothetical profit, and other indirect damage. The company may use transaction records, access logs, identity documents, and a dedicated view-only trading password to assess claims. It plans to publish the application procedure, required documents, window, and payment schedule by November 6.

That promise does not replace immediate broker contact. GMO directs customers to ask the exchange or broker whether trades can be canceled or refunded, and says any provider refund will be deducted from its compensation for the same loss. Customers should follow official channels and preserve objective records rather than rely on an attacker post or social-media claim. GMO also announced a separate JPY 5,000 payment for current customers, regardless of financial loss, with contact details due by October 30.

GMO says it will not restart the compromised system foundation unchanged. It has decided on a fundamental security-architecture replacement and will offer customers who still need a Windows desktop an alternative service running on an independent cloud foundation. The proposed replacement will be free for six months, with safety validation, feature differences, migration precautions, coverage, later pricing, and contract terms presented before opt-in. Customers will not be moved without consent.

An independent foundation is a necessary starting point, not automatic proof of trust. Customers should ask whether machine images, user profiles, trading scripts, browser data, and saved credentials will be copied from the old environment. A blind lift-and-shift can move persistence or contaminated configuration into a clean control plane. Prefer rebuilding the desktop from a known-good image, reinstalling trading tools from verified sources, importing only required data, and creating fresh credentials after the new environment is established.

Before resuming automation, compare broker endpoints, expert advisers or scripts, scheduled tasks, startup entries, firewall policy, remote-access configuration, local administrators, and outbound connections with a trusted baseline. Restrict the new desktop to the minimum broker and update destinations, avoid storing withdrawal or email credentials where the trading process can read them, and separate monitoring from the server it observes. A second channel should alert the customer when sessions, orders, or balances change.

GMO says a person believed to be the attacker demanded money and threatened continued manipulation of accounts at more than 70 domestic and overseas financial companies, publication of information, and ransomware activity. The company says it refused, provided communications to police, asked providers to block access through the service and terminate sessions, and cut network paths to affected systems. Those statements document the vendor's response and the claimed threats; they do not validate every assertion made by the extortionist.

The public record still lacks the intrusion route, vulnerability details, malicious-file names or hashes, command-and-control indicators, first compromise time, server-by-server impact, exact data fields taken, confirmed trade count, total loss, and evidence about customer endpoint infection. GMO says it is working with an external security company and authorities. Until it publishes a technical report, defenders should avoid attributing the incident to a named group or inventing a common malware signature.

The durable lesson is about authority placement. A remote desktop used for unattended financial operations should not also be a durable password vault, recovery inbox, and general browser. Trading providers should support immediate global session revocation, phishing-resistant authentication, narrowly scoped automation credentials, transaction confirmation, and independent alerts. Hosting operators should isolate tenants, protect management and image pipelines, retain useful audit records, and make a clean migration path part of incident planning before customers' live sessions become the recovery boundary.