Book a Security Consultation
Executive Risk & Board Advisory

26,739 Servers. More Than 70 Brokers. GMO's Own Help Page Says File Sharing Came Pre-Set.

Blog Meta Icon
Dipan Mann
Founder, CEO & CTO
Blog Meta Icon
October 27, 2026
Blog Meta Icon
30 min read
Blog Main Image

A hacked GMO hosting service let an extortionist trade away customers' balances at Japanese FX brokers. GMO's own help page says the connection file it hands customers comes with file sharing to their PCs pre-set.

10:00 PM Central

At 10:00 PM Central on Monday, October 26, it was noon on Tuesday in Tokyo. Two hours earlier, an internet company had asked its customers, people who trade currencies for a living or for a hobby, to do something no hosting provider likes to ask. Back up your files. Disconnect your home computer from the network. Switch it off. Pull the cables out of the back.

The request came from GMO Internet, one of Japan's largest internet infrastructure companies, in its eighth incident report on a service called Onamae.com Desktop Cloud. The wording was plain: "Before 12:00 on Tuesday, October 27, back up your data, disconnect from the network, power off, and unplug the cables connected to your PC." The reason was a deadline set by whoever had broken into the service. If GMO did not pay, the attacker had said, customer information would be published and ransomware would be launched at noon.

GMO says it confirmed at 12:30 PM Tokyo time, 10:30 PM Central, that the attacker had posted information it said came from GMO and its customers. Yomiuri and ANN reported that the first post covered one person, with a name and contact details, and promised more every day at noon. GMO's tenth report, issued at 1:55 PM Tokyo, said no ransomware attack had been confirmed as of that time. Its eleventh asked the public not to spread what had been posted.

Behind those reports sits an incident unlike most that cross this desk. Onamae.com Desktop Cloud rents Windows virtual private servers to retail and semi-professional foreign exchange traders who want their automated trading programs to run around the clock. GMO says up to 26,739 of those servers may have been affected. Someone planted programs on them. GMO says trading logins saved on the servers may have been obtained, and brokers say the unauthorized logins and orders that followed used credentials leaked from those servers. GMO's own words for what the attacker threatened to keep doing: "tampering with customers' accounts at more than 70 securities and FX firms in Japan and abroad, destroying balances through unauthorized orders."

On the morning of October 27 in Tokyo, Satsuki Katayama, the cabinet minister responsible for financial services, told reporters that five FX firms had reported customer losses believed to be GMO-related: Goldenway Japan (which trades as FXTF), OANDA Securities, AvaTrade Japan, Gaitame Finest and Dukascopy Japan. None of those brokers says its own systems were breached. The money left through the front door, with valid passwords.

The incident is not the story. Hosting companies get breached. The story is three documents that sit side by side on GMO's own websites tonight. One is a help page, still live, that tells customers the remote-desktop file GMO hands them comes with file sharing to their home computer already switched on. Another is a blog post in which GMO's chairman writes that the group's own in-house white-hat hackers had flagged issues with this service before the attack, and that the fixes were not fast enough. The third is the product page, which still advertises "peace-of-mind security" above the banner telling customers to unplug their PCs. Read together with a December 2025 industry guideline that told Japanese FX brokers to require phishing-resistant authentication on every trading tool, they describe a vendor-to-broker side door that nobody owned, a fix that was public for years, and an extortion model that has finally found the account balances it was always going to look for.

What we verified, and what the first reports could not

Cloudskope ran passive checks against public web pages and DNS between 1:56 and 2:20 AM Central on Tuesday, October 27. We did not log in to anything, download a remote-desktop file, connect to any GMO server, or visit the attacker's site. We did not view, download or describe any data the attacker published. Where we rely on another outlet, we name it.

GMO's reports are live and say what is quoted here. At 2:12 AM Central we retrieved GMO's first report (onamae.com, October 21), its fourth (internet.gmo, October 24), its eleventh (group.gmo, October 27), the chairman's blog post on kumagai.com, and two broker notices, from OANDA Securities and FXTF. All returned HTTP 200. We recorded a hash of each in our evidence file, and checked every GMO passage quoted in this piece against the Japanese on GMO's own pages.

The help page says the drive sharing is pre-set. At 2:15 AM Central, the Onamae.com Desktop Cloud user guide on onamae-desktop.com answered the question "Can I share files between my PC and the server?" by walking the customer through the Windows Remote Desktop Connection settings: Local Resources, Local devices and resources, tick Drives. Then it adds: "When you connect using the RDP file downloaded from the control panel, file sharing is already configured in advance, so you do not need to make the setting above." The same page says the downloadable file also arrives pre-set to use the customer's USB printer, and describes the file as one that stores "account information" for the connection in advance. In Remote Desktop terms, what that page describes is drive redirection: the customer's local disks are mounted inside the remote server for the length of the session. Whoever controls the server can read and write them.

That matters because of what the attacker says it did. On October 24, according to summaries by the Japanese security blog セキュリティ対策Lab, a note.com analyst and ITmedia NEWS, the attacker posted a message addressed to GMO claiming, among other things, that GMO-distributed .rdp files had drive redirection enabled by default and that this let it reach users' own PCs. セキュリティ対策Lab reports that the attacker also published logs labelled as client-drive extraction, showing file-copy operations against \\tsclient\C, which is the path under which a redirected client drive appears inside a Windows remote session. We have not seen those logs and do not vouch for them. What we can say is narrower and firmer: GMO's own help page, today, confirms that file sharing comes pre-set in the connection file GMO distributes, which is consistent with the configuration the attacker describes.

The product page still sells safety. At 2:13 AM Central, onamae-desktop.com returned HTTP 200 through Cloudflare. The page opens with the incident banner: exfiltration confirmed, the noon threat, the request to unplug, an instruction to change trading passwords "from a device you do not use for FX trading" and to have the broker "disconnect all sessions." Below the banner, the marketing copy is unchanged. It promises "peace-of-mind security," "no VPN needed, safe remote connection," a quality guarantee of "99.99% or higher" and a track record of "more than 200,000" contracts.

GMO pre-installed the brokers' software. A page on the same site, captured at 2:14 AM Central, says GMO provides servers "with MT4 from nine domestic securities companies pre-installed," and recommends one of them, FXTF, as the account to open for first-time automated traders. FXTF is one of the five brokers Minister Katayama named. That page is how the relationship between this vendor and the brokers whose customers lost money looks from the outside: not arm's length, but a storefront.

The infrastructure is GMO's own. DNS over HTTPS resolves onamae-desktop.com to Cloudflare addresses (172.64.150.186 and 104.18.37.70), with name servers ns1.cf.gmointernet.jp and ns2.cf.gmointernet.jp and mail at mx.gmo.jp. RDAP shows the domain registered on July 8, 2010 and last changed on June 22, 2026. Nothing in the public DNS points to a third-party operator.

No leak-site listing. The ransomware.live tracker, queried at 1:56 AM Central, shows no entry for GMO. The attacker runs its own Japanese-language site and calls itself "HackingTeam" in emails to victims, according to TBS and Asahi. It is not on the established ransomware brands' leak sites that tracker indexes.

What the first English reports could not see. BleepingComputer's October 21 story covered GMO's first report: 26,739 servers, a shutdown, change your passwords. The Register's October 27 story, by Simon Sharwood, led with the chairman's admission that fixes were slow. TNW and Nikkei Asia covered the request for government action. Finance Magnates, in two pieces by Damian Chmiel, did the most thorough work on the brokers. The Register quoted both GMO's first and fourth reports. None of the English coverage we could read reported the help page or the pre-installed broker software. (Nikkei Asia's October 26 piece on remote-access settings was paywalled, and we did not read its full text.) One English-language story, Tokyo Reporter's of October 26, dates GMO's first announcement and both ransom deadlines to June. Those dates are wrong; every GMO document places them in October.

What GMO said, one report at a time

GMO has published eleven numbered reports, the chairman's blog post and a set of customer notices in seven days. Read in order, they move in one direction.

October 21, 4:00 AM Tokyo (2:00 PM Central, October 20). Report No. 1. "We confirmed that unauthorized programs were installed in some customers' server environments. Information stored on the servers may have been viewed." And: "At present, we have not confirmed any leak of the personal information entrusted to us or any misuse of viewed information." Servers on every plan would be shut down from that hour. The number of servers possibly affected: 26,739.

Read what that does not contain. It does not say how the programs got there. It does not say when they were installed. It distinguishes, carefully, between the personal information GMO holds and the information stored on customers' servers, which is where the trading logins were. The reassurance covers the first. The risk was in the second.

October 21, 11:57 AM Tokyo (9:57 PM Central, October 20). Eight hours after the first report, by GMO's own later timeline, an extortion message arrived. According to the image of the demand that Kumagai later posted, as reported by J-CAST, it asked for $50 million in cryptocurrency by 5:00 PM that day. GMO did not disclose the amount for five more days.

October 22, 4:59 PM Tokyo (2:59 AM Central). Report No. 2. The first mention of MetaTrader. Login details saved in trading tools on the servers may have been obtained. Change them.

October 23, 4:10 PM Tokyo (2:10 AM Central). Report No. 3. Two sentences that should be read by every risk officer at every broker. First, the 26,739 figure "is the number of servers that could be in scope, not the number where unauthorized access or data theft has been confirmed." Second: "Depending on the specifications of the securities or FX firm's servers, even after a password change, existing sessions may stay alive for some time, letting a third party keep trading." (OANDA, for its part, says a password change at OANDA ends all sessions immediately.) GMO had shut its servers down two days earlier. The attacker did not need them any more. It had the credentials, and in some cases live sessions, at the brokers.

October 24, 11:50 AM Tokyo (9:50 PM Central, October 23). Report No. 4. The reversal. "A security problem existed in the Service's system, and we have confirmed unauthorized access to the Service's environment and that customer information was taken outside the company." Three days after "no leak confirmed," GMO confirmed exfiltration. The same report disclosed the extortion without naming a figure, listed the attacker's three threats, offered a flat ¥5,000 (about $32) to every current customer "whether or not they suffered financial loss," promised to cover realized trading losses and fees even where a broker refuses to refund, excluded market losses and lost profits, promised a claims process by Friday, November 6, said the compromised platform would not be restarted, and asked the government to treat the case as the "first activation" of Japan's new active cyber defense law.

Read what that does not contain either. It names no vulnerability, no component, no date of first access, no count of customers whose credentials were taken, no count of accounts traded and no total loss. It refers to "a security problem" in the system and says GMO sincerely acknowledges its own deficiencies. That is the only technical description of cause in GMO's reports.

October 25. The chairman's blog. Masatoshi Kumagai, who founded the group and runs it as chairman and chief executive, published a long post titled, in translation, "Now is the time to protect Japan through public and private cooperation." It is unusually candid, and its key paragraph deserves to be quoted in full:

"Regarding this service's security, in-house white-hat hackers had flagged issues to the team beforehand. The team took the findings on board and was working on countermeasures. But because we proceeded cautiously, weighing the impact on service availability and other priorities, our response lacked depth and speed, and the attackers exploited that gap."

The Japanese word is 課題, issues to be improved, not 脆弱性, vulnerability. (English renderings of the same passage, including the one The Register quoted, use "vulnerability.") The post does not say what the issues were, when they were raised, or how long they stayed open. It does say who raised them: the group's own security professionals. And it says why they were not fixed in time: availability and priorities. That is the most common sentence in post-incident reviews, and almost never one a chairman writes in public.

On October 26 Kumagai added two lines: the demand was for $50 million, about ¥8 billion, received at 11:57 on October 21. "We have not met these demands and have made no payment whatsoever."

October 26 and 27. Reports No. 6 to No. 11. Report No. 7 disclosed the noon deadline. Report No. 8 told customers to unplug, and was later revised to name Trend Micro among the companies helping. Report No. 9 said no malware, including ransomware, had been found on the customer devices analyzed so far, and promised a replacement PC to anyone hit by ransomware. Report No. 10 confirmed publication by the attacker and warned that visiting the attacker's site would expose the visitor's own information. Report No. 11 asked people not to spread the data.

Across all eleven reports, the technical cause is still one phrase. The number of victims is still unknown. And the reassurance of Report No. 1 has quietly become its opposite.

💡 Key Insight

The vendor was breached, the losses were booked at the brokers, and the fixes were public: Microsoft's 2024 warning that named Japan, and an industry rule requiring phishing-resistant logins on every trading tool.

The extortion did not encrypt anything. It traded.

Ransomware crews have spent a decade looking for pressure that does not depend on a victim's backups. They moved from encryption to data theft, from data theft to calling executives, from executives to customers. In Tokyo last week, someone found the next step: the victim's customers' brokerage accounts, operated live, as a hostage.

The mechanics, as GMO describes them, are not exotic. Traders rent a Windows server so that MetaTrader, the most widely used retail currency-trading platform, can run their automated strategies, known as expert advisors or EAs, without their home PC staying on. MetaTrader logs in to the broker with an account number and password, and the server keeps them so the strategy can reconnect after a restart. GMO's second report says the login details "saved in trading tools" on its servers may have been obtained. Once an attacker has those, it does not need the server. It can log in to the broker from anywhere and place orders.

TBS's news23 programme, in a report published on October 24, showed what that looks like from the other end. A 44-year-old trader with ten years of FX experience noticed at about 4:30 PM on October 21 that his balance was zero. The trade history TBS broadcast shows three entries time-stamped 10:22:12 and 10:22:13: minus ¥864,336, minus ¥1,767,186, minus ¥1,527,716. More than ¥4 million, about $26,000, in two seconds, with fees generated by a burst of trades he did not place. Asahi Shimbun, describing what appears to be the same Kanagawa trader with the same three amounts, places the trades at about 4:22 PM Tokyo time on October 21, which suggests the 10:22 stamps are the trading platform's server clock. Asahi reports the unauthorized trading continued for nearly two more minutes and the losses exceeded ¥6 million. About two hours after he noticed, an email arrived: "We are HackingTeam. Because GMO refused to negotiate with us, we have erased all account balances as warned." The deadline in the ransom demand GMO received had been 5:00 PM that day.

Asahi Shimbun reported a second case, a 29-year-old woman in Aichi whose account lost about ¥4.3 million in trades that began shortly before 5:00 AM on October 22, leaving ¥6,768. The attacker's own site, TBS reported, claimed to have "destroyed accounts worth about ¥7.7 billion in 24 hours." That figure is the extortionist's and should be treated as advertising. No broker, regulator or GMO document has published a total.

GMO's fourth report calls this "an extremely malicious and unprecedented method: unauthorized operation and destruction of assets targeting ordinary citizens' trading accounts (financial assets), going beyond encryption and data theft." On the narrow point, GMO is right. Fraudulent trading on hijacked brokerage accounts is not new in Japan; what is new is using it as the extortion lever against a third party, the vendor, which does not own the accounts and cannot stop the trades.

In MITRE ATT&CK terms the chain, as far as it is public, looks like this. Credentials from saved application stores on the servers (T1555, Credentials from Password Stores), reused as valid accounts at brokers (T1078, Valid Accounts), to commit T1657, Financial Theft. If the attacker's claims about home PCs are true, add T1021.001, Remote Services: Remote Desktop Protocol, used in reverse, and T1199, Trusted Relationship, which describes a customer who connects to a vendor's server because it is the vendor's server. How the attacker first got onto GMO's platform has not been disclosed, so the initial-access technique cannot be mapped.

Switching off the servers did not switch off the passwords

GMO began a rolling shutdown of every server at 4:00 AM Tokyo on October 21. That should have limited what the attacker could collect from the servers GMO stopped, though GMO has not said so, and the attacker claims cancelled servers were left running. Either way, it did nothing about what had already been collected, and the losses kept arriving.

GMO's third report explains why: depending on the broker's systems, sessions can survive a password change. Its customer instructions, still on the product page tonight, tell traders to change their trading password "from a device you do not use for FX trading" and to have the broker cut "all sessions," and add, "even if you have already changed it." GMO's fourth report says it asked major exchanges and securities firms to block access coming through the service and force-disconnect all active sessions. Minister Katayama said the brokers had suspended trading for affected customers, reset passwords and blocked unauthorized orders from overseas. Gaitame Finest restricted affected accounts on October 21. OANDA Securities warned on October 22 that MetaTrader logins might have been viewed, briefly held withdrawals, and confirmed unauthorized logins and trades on October 26.

Every one of those is a broker-side control. That is the part that should hold the attention of anyone who sits on a broker's board, in Tokyo or anywhere else. The vendor was breached. The losses were booked at the brokers. And the controls that would have stopped them, or did eventually stop them, were all the brokers' to apply.

The guideline said every trading tool

In December 2025, Japan's FX industry rewrote its authentication rules in response to credential theft. The Financial Futures Association of Japan hosts a guideline titled "Guideline on Preventing Unauthorized Access in Internet Trading," first issued in 2021 after 2020 intrusions that included unauthorized withdrawals from brokerage accounts and, in the FX sector, a breach at a member's outsourcing contractor that leaked customer data. Its cover shows a partial amendment on December 23, 2025. We retrieved the PDF at 2:15 AM Central and read its standard for login, trading and withdrawal. Two sentences matter.

"Where internet trading is offered through multiple trading tools, such as websites and applications, each trading tool must implement features and specifications of the same level."

"For important operations such as login, withdrawal and changing the withdrawal bank account, implement phishing-resistant multi-factor authentication (e.g., passkey authentication, PKI-based authentication) and make it mandatory (set as the default)."

A footnote to "important operations" adds: "Where there are multiple routes for login, note the need to check cross-impacts, such as whether there are vulnerabilities between trading tools."

That footnote describes this incident almost exactly. MetaTrader is a trading tool. A password saved inside it on a rented server is a route for login. If a broker required a passkey or a certificate for every MetaTrader login, a stolen password would not have been enough to trade.

The amendment did not arrive out of nowhere. In the spring of 2025, Japan's online brokerages were hit by a wave of account takeovers. Finance Magnates, citing the Financial Services Agency, reports that fraudulent trades on hijacked securities accounts exceeded ¥500 billion in value across nearly 6,000 incidents between March and May 2025. That is the value of trades placed, not losses. Regulators and industry bodies responded with the phishing-resistant authentication standard. The guideline itself contains a transition clause describing interim measures "until phishing-resistant MFA is implemented and made mandatory," and we did not find a hard compliance date in the text we read. So we do not say any broker was in breach of it.

What the brokers' own announcements say since October 21 is instructive anyway. According to Finance Magnates, OANDA Securities had offered passkey logins as an option since June and will now make them compulsory; OANDA's own notices show those passkeys apply to its web account login, and for MT4 and MT5 it asks customers to turn on two-factor authentication, which has been optional. FXTF, with more than 280,000 client accounts, will make one-time passwords mandatory on MT4 and MT5. Gaitame.com plans passkey logins across its services around December. IG's Japanese unit made two-factor authentication compulsory by June 2026. The inference, which is ours: ten months after the industry standard said "every trading tool, by default," at least some brokers were still accepting a password alone on MetaTrader. That is the attestation gap at the broker layer, and it is the one most directly connected to the losses.

Microsoft wrote this warning two years ago, and named Japan

The other half of the story, the threat to customers' home computers, rests on a Windows feature that has been documented, abused and patched in public for years.

When you connect to a remote Windows machine, you can choose to bring your own resources with you: your clipboard, your printer, your local disks. Microsoft calls this redirection. It is convenient. It also means the remote machine can see your disks for as long as you are connected. Security researchers have treated a malicious or compromised remote server as a threat to the connecting client for at least seven years. In February 2019, Check Point's Eyal Itkin published "Reverse RDP," research showing that a malicious RDP server could attack the client that connected to it; an August 2019 follow-up showed the same through clipboard file transfer in Microsoft's own client (CVE-2019-0887).

On October 29, 2024, Microsoft Threat Intelligence published a warning about Midnight Blizzard, the Russian intelligence actor, sending signed .rdp files to "thousands of targets in over 100 organizations." The files connected victims to attacker-controlled servers with redirection switched on. Microsoft's description of what that exposes is the paragraph every vendor that distributes .rdp files should have pinned to a wall: resources sent to the server "may include, but are not limited to, all logical hard disks, clipboard contents," printers, peripherals and authentication features. The campaign's stated geographic focus included "the United Kingdom, Europe, Australia, and Japan."

In April 2026, Microsoft changed Windows. According to BleepingComputer's Lawrence Abrams, the April cumulative updates for Windows 10 and 11 added a dialog that appears whenever a user opens an .rdp file, shows whether the file is signed, lists every redirection the file requests, and leaves all of them disabled by default. The change applies to connections launched from .rdp files, not to connections typed into the Remote Desktop client by hand.

So the fix has two layers, and both were public before last week. The vendor layer: do not ship a connection file that maps the customer's drives by default, especially for a product whose server will hold trading credentials, and especially not after Microsoft has told the world, with Japan named, how such files are abused. The client layer: a fully patched Windows PC opening that file after April 2026 should have shown the customer a warning and left drive redirection off unless the customer ticked the box. Whether the customers the attacker says it reached were unpatched, used another client, or ticked the box because GMO's guide had told them that file sharing came pre-configured, nobody outside GMO's investigation can say. GMO's ninth report says no malware has been found on the customer PCs it has analyzed so far. That is good news and an incomplete answer.

What the attacker claims, and why to discount it

The attacker's October 24 message to GMO, as summarized by the Japanese security blog セキュリティ対策Lab, a note.com analyst and ITmedia NEWS reporter Yuka Okada, makes four technical claims. That the server fleet was managed through Active Directory with an administrator account valid on every server. That administrator credentials could be harvested when support staff connected to customer machines. That GMO's .rdp files mapped customers' drives by default, a configuration the attacker says dates from 2019. And that servers belonging to customers who had cancelled kept running for months, thousands at a time.

Extortionists exaggerate for a living, and these are claims made to put pressure on a company that refused to pay. GMO has said that anything the attacker publishes may be partly false. We can test only one of the four claims from the outside, and the help page is consistent with it. The Active Directory claim, if true, would explain how one intrusion reached tens of thousands of servers that were sold as individual machines. Nikkei Asia reported on October 26 that the investigation indicates unauthorized access may have been enabled through remote access and virtual server partitioning. A GMO source told Yomiuri there was a vulnerability on the system side. Neither confirms the attacker's architecture.

The second extortion demand is murkier. Japanese outlets ANN and Jiji, citing the security firm S&J, reported a second demand of $1 million posted on the attacker's site, in exchange for sparing users further attacks. GMO's own documents mention only the $50 million demand. We treat the $1 million figure as reported, not confirmed.

26,739
Servers GMO says may be in scope of the Onamae.com Desktop Cloud intrusion. Its own third report says that is the number that could be affected, not the number confirmed. GMO has still not published how many customers' trading logins were taken or how many accounts were traded.
2 Seconds
The time it took, according to the trade history TBS broadcast, for one 44-year-old trader to lose more than ¥4 million in three entries stamped 10:22:12 and 10:22:13. Asahi Shimbun puts his total loss above ¥6 million. About two hours after he noticed, an email signed HackingTeam told him GMO had refused to negotiate.
10 Months
The gap between December 23, 2025, when Japan's FX industry guideline was amended to require phishing-resistant MFA by default on every trading tool, and the first unauthorized trades using MetaTrader logins taken from GMO's servers. FXTF now says it will make one-time passwords mandatory on MT4 and MT5.

GMO had already been here this month

The Desktop Cloud attack was the second security incident at the GMO group in October, and the timing is the part shareholders will notice.

On October 5, GMO Research & AI, the group's survey company, announced unauthorized access to its consumer panel site, infoQ. Its second report, on October 14, put the number of personal-information records taken outside the company at 894,082, according to ScanNetSecurity, and said some members' reward points had been exchanged for Amazon gift codes without their consent. On October 9, between those two reports, Kumagai said every service in the group would be inspected, according to Nikkei as reported by Finance Magnates. Eleven days after that pledge, GMO confirmed unauthorized programs on Desktop Cloud servers. Nothing published links the two incidents. The pledge and the gap are a matter of record.

It is not the group's first payment-adjacent incident either. In March 2017, GMO Payment Gateway disclosed that about 720,000 card-related records from two client payment sites, one of them the Tokyo Metropolitan Government's tax payment site, may have leaked through the Apache Struts 2 vulnerability that also figured in that year's Equifax breach.

And the group sells security. GMO Cybersecurity by Ierae, which joined the group in 2022, is one of Japan's best-known penetration-testing firms. Its website advertises vulnerability assessment, incident response and AI security. In May 2026 it set up a subsidiary, GMO National Security, to serve government and critical infrastructure clients under security clearance, according to ScanNetSecurity. On October 19, the day GMO says a customer inquiry started the Desktop Cloud investigation, Ierae published research on ARTEX, an autonomous AI penetration-testing tool it had found being misused against Japanese companies. Kumagai's blog cites that work, describing about 20 Japanese companies targeted from one attack source, as evidence of what he calls "AI cyber saturation attacks." Nikkei, reporting the same research, said at least about 80 companies were targeted. Microsoft has separately tied ARTEX to Storm-0940, the actor it says compromised ConnectWise's cloud backup service this month.

Kumagai does not say ARTEX was used against Desktop Cloud. Nobody has. We note it because the chairman chose to put it in the same post as his admission about unfixed findings, and because readers will connect them whether or not the evidence does.

The admission is the stronger fact. A group that employs some of the country's best white-hat hackers, and sells their work to other companies, had those people flag issues in its own product, and the product team weighed the fixes against uptime. Kumagai now says about 200 people from Ierae and GMO Flatt Security are working the incident, including former Interpol staff. The talent was always in the building. The decision about when to use it was made somewhere else.

Asking the state to strike back

GMO's request that the government use its new active cyber defense powers is the part of this story that has drawn the most English-language coverage, and it deserves a careful reading.

Japan's active cyber defense framework began operating on October 1, 2026, under a law that, according to Jiji, allows police and the Self-Defense Forces to break into attackers' servers and disable them. GMO asked the government to treat this case as the framework's "first activation." Kumagai's blog responds to the two objections already raised by media and experts: "GMO is not a 'specified social infrastructure operator' under the law," and active cyber defense "is not something triggered at a private company's request." He accepts both and asks for the substance to be weighed over the category. Chief Cabinet Secretary Minoru Kihara declined to say whether the powers would be used, saying it would tell the attackers how the government was responding, according to Jiji. Experts quoted by Jiji called applying the law here a stretch given its purpose.

There is a fair case on GMO's side: the losses fall on ordinary people's financial accounts at regulated firms, which is closer to critical infrastructure than a hosting product sounds. There is also a fair reading that a company asking the state to go on offense, in the same week it discloses that its own team had flagged issues in the service, is asking for the public to carry part of a risk it priced as acceptable. Both are true. Neither changes what the brokers' boards should be doing this week.

Whose incident is it?

For GMO Internet Group, the parent, listed on the Tokyo Stock Exchange Prime market under 9449, Desktop Cloud is one product line among many. The market's reaction was not small: Kyodo reported the parent's shares closed down ¥590 at ¥3,179 on October 26, a fall of about 16 percent, and Kabutan reported the operating subsidiary, GMO Internet, listed under 4784, closed down 14.9 percent at ¥418. GMO says it cannot yet estimate the effect on earnings.

For the brokers, it is the opposite asymmetry. Their own systems were not breached, by their own accounts. Their customers' balances were traded away through their front doors with valid credentials. They are the ones the regulator asked to warn and monitor, through the Financial Futures Association, on October 22. They are the ones the minister named. Under GMO's compensation terms, a customer may claim from GMO whether or not the broker refunds, and OANDA has told its customers to go to GMO directly. That is generous of GMO, and it leaves the broker's regulatory relationship and reputation exactly where they were.

For the customers, it is their savings and, if the attacker's claims are right, their home computers. The ¥5,000 payment, which Kumagai calls "a token of our initial sincerity," is about $32.

This is the shape Cloudskope keeps finding in vendor incidents: immaterial to the vendor's consolidated results, material to the regulated firms downstream, and devastating to the individuals at the end of the chain.

Why this reaches U.S. boards

No U.S. broker has been named in this incident. OANDA, one of the five, is a global group with offices in New York, though its Japanese entity is the one that reported losses. The reason to read this closely in New York, Boston or Dallas is that the architecture is not Japanese. It is everywhere.

Rented Windows desktops reached over Remote Desktop, with a connection file the vendor supplies, are how a large share of professional services runs. Hosted desktops for accounting and tax software. Virtual desktops for wealth managers and their outsourced operations staff. Managed service providers that hand a branch office a .rdp file and a password. Trading VPS providers that sit next to broker data centers so a small fund's algorithms can run all night. In each case the question GMO's help page answers is the same: when your people connect, does the vendor's file bring their local drives along? If it does, a compromise of the vendor's server is a compromise of every device that connected to it.

U.S. rules already reach part of this. The SEC's amended Regulation S-P, with compliance dates of December 3, 2025 for larger broker-dealers and advisers and June 3, 2026 for smaller ones, requires covered firms to oversee service providers and to require them to give notice of a breach within 72 hours. The FTC's Safeguards Rule requires tax preparers and other non-bank financial institutions to oversee their service providers. Neither reaches the vendor a client chooses for itself and connects to with the firm's credentials. That is the gap GMO's customers fell through: the vendor was the customer's choice, the credentials were the broker's, and the broker's authentication was the only control both sides relied on.

What GMO should have done by now

  1. Name the cause. "A security problem" is not a cause. Say which component, whether it was among the issues the in-house team had flagged, and when those issues were first raised.
  2. Give the dates. When the attacker first had access, when the first programs were planted, and whether the attacker's claim of client-drive copying on October 14 matches GMO's own logs.
  3. Publish the counts. Customers whose credentials were exposed, accounts traded, brokers affected and total realized losses, even as a range.
  4. Say what the .rdp file did. GMO's help page says file sharing was pre-configured. Say whether that is drive redirection, how long it has been the default, whether files were signed, and whether GMO changed the default after Microsoft's October 2024 warning or its April 2026 Windows change.
  5. Tell every customer exactly what to check on their own PC, in one page, with the indicators GMO's own analysts have seen, rather than asking them to unplug and wait.
  6. Give the brokers a list. Every broker whose MT4 GMO pre-installed on its servers, and every broker whose customers' sessions came from GMO's address space, should already have it. Say publicly that they do.
  7. Fix the product page. A banner that says customer information was taken should not sit above copy that says "peace-of-mind security."

Seven items. None depends on the government's decision about active cyber defense.

What boards should be asking this week

For boards and risk committees of brokers, banks, wealth managers and funds:

First, which third parties do our customers or our staff connect to with our credentials, and do we require phishing-resistant authentication on every one of those routes, including the desktop and API tools, not only the website and app? Ask for the list by tool.

Second, if a customer's password were stolen from a vendor's server tonight, how long would an existing session survive a password reset at our firm, and who can kill every session in one action?

Third, do we have commercial relationships with vendors our customers use to reach us: affiliate fees, pre-installed software, co-marketing? If so, is that vendor in our third-party risk program, or only in our marketing budget?

For every board, about remote access:

Fourth, which vendors give our people .rdp files or hosted desktops, and do those files redirect local drives by default? Ask IT for the answer in writing, by vendor.

Fifth, are our Windows endpoints on the April 2026 cumulative updates that warn on .rdp files and disable redirection by default, and has anyone switched that protection off by policy?

Sixth, when a vendor tells us it is "not aware of misuse," do we know whether that sentence covers the data the vendor holds or the data our people stored on the vendor's systems? GMO's first report covered only the first.

For sponsors and acquirers

Three points for deal teams.

First, customer-side vendors belong in diligence when the target makes money from them. A brokerage, payments or wealth platform that pre-installs its software on a partner's servers, pays affiliate fees or recommends a hosting provider has a relationship that regulators and customers will treat as the target's problem the day it fails. Ask for every such arrangement and the security terms attached to it.

Second, authentication parity across channels is a diligence item, not an IT detail. Ask whether the target's strongest login control applies to every route into an account, including legacy desktop platforms. A clean penetration test of the website says nothing about the MetaTrader server or the API key.

Third, ownership changes are when these gaps survive. OANDA, one of the five brokers named, was owned by CVC Asia Fund IV from 2018 until FTMO completed its purchase on December 1, 2025, according to FTMO's announcement. Nothing suggests the ownership change had anything to do with this incident. It is a reminder that a buyer inherits not only the platform but every customer-side route into it, and that the first year after closing is when those routes are least likely to have been inventoried.

What we are not saying

We are not saying any broker named here was breached. Each says its own systems were not, and we have no evidence otherwise.

We are not saying any broker violated the Financial Futures Association guideline. The guideline anticipates a transition period, and we found no hard compliance date in the text we read.

We are not saying the attacker reached customers' home computers through drive redirection. We are saying GMO's own help page confirms that file sharing was pre-set in the connection file it distributes, consistent with the configuration the attacker describes, and that GMO has not yet found malware on the customer PCs it has analyzed.

We are not saying ARTEX, Storm-0940 or any other named tool or actor was involved. No one has made that link, including GMO.

We are not saying the attacker's figures are accurate. The ¥7.7 billion claim, the $1 million second demand and the architectural claims are the attacker's or third parties' accounts, labelled as such.

We are not saying the infoQ incident and the Desktop Cloud incident are connected.

We are not saying any U.S. firm was affected.

We did not ask GMO for comment before publication. If GMO, any broker named here or the Financial Futures Association of Japan would like to correct anything, this page will be updated the same day.

Our record of these incidents

Sources

Conclusion

A help page that pre-sets file sharing to the customer's PC. A Microsoft warning in October 2024 that named Japan. A Windows change in April 2026. An industry guideline on December 23, 2025 that said every trading tool, by default. A chairman's pledge on October 9 to inspect every service in the group. A first report on October 21 that found no leak, and a fourth on October 24 that found one. A noon deadline on October 27, and customers pulling the cables out of their PCs. GMO was the name on the extortion note. The brokers' front doors were where the money went.

CLOUDSKOPE VIEW

Cloudskope advises boards, deal teams and general counsel on exactly this exposure: which vendors your customers and staff reach you through, whether your strongest login control covers every one of those routes, and what a vendor's remote-desktop file brings home with it.

TAGS