The Onamae.com Desktop Cloud Breach (October 2026): 26,739 Is Not a Compromise Count — Trust Boundaries in Cloud RDP and How Damage Reaches Trading Accounts

In October 2026, GMO Internet disclosed unauthorized access to Onamae.com Desktop Cloud — a service that gives you a Windows desktop in the cloud, widely used to keep FX trading tools running around the clock.

This article sets out the facts and then covers what most coverage leaves out:

• How to read "26,739" and "about ¥8 billion" correctly
• Why a cloud compromise can reach trading accounts at brokerages
• What would have to be shown to support each cause hypothesis, given that the cause has not been published
• Where the line of responsibility sits between user and provider, and what you can verify yourself

Scope and sourcing. This article relies on GMO's official notices 1–16 and its disclosures of 23 and 28 October, as available on 1 November 2026 (JST); the latest official information is dated 30 October. It separates facts confirmed in official notices, attacker claims and press reports, and the author's inference. Diagrams, tables and configuration examples are a generalized reference model and not a reconstruction of GMO's internal architecture. Official statements are paraphrased for readability — check the original notice before quoting any number or date.

Key points in 30 seconds

• What happened: GMO began investigating on 19 October after a customer inquiry. On 20 October it confirmed that a third party had planted a malicious program in some customers' server environments, and stopped new sign-ups and the control panel. From 04:00 on 21 October it shut down servers on all plans in sequence.
• What "26,739" means: servers that could be affected — not a count of confirmed compromises.
• What GMO acknowledged (notice 4): there is a security problem in the service's systems, and unauthorized access to the environment and the exfiltration of customer information were confirmed.
• The money: the attacker demanded about ¥8 billion (US$50 million). GMO says it will never comply, and the financial impact has not been calculated. Compensation is a flat ¥5,000 goodwill payment plus actual losses from trades GMO judges unauthorized.
• Still unknown: the intrusion date, the entry route, what the program is, how many servers were actually compromised, how many records were taken or published, and the number and value of unauthorized trades.

Confirmed facts and timeline

Times are Japan Standard Time, as stated in each notice.

How to read the numbers: don't mix four of them up

Two further limits:

• "No malware found on analyzed devices" refers to customers' own PCs handed over for analysis, not the cloud-side servers. GMO itself says it has not confirmed the safety of all devices.
• "No ransomware attack confirmed" is the finding as of 13:55 on 27 October.

What is still unknown

• When the intrusion happened (19 October is when the investigation started)
• The entry route, and what the "security problem" in notice 4 is
• What the malicious program does and how many servers it was planted on
• The number of servers where compromise was confirmed
• The kinds and counts of information taken or published
• The number and value of unauthorized trades. Press reports attribute to Japan's financial regulator a statement that five firms reported customer damage; the author could not confirm a primary source
• Online theories — drive sharing as the route, Active Directory — are expert inference and attacker claims; GMO has not confirmed them

The group CEO wrote on 30 October that internal white-hat hackers had pointed out issues beforehand, and that the depth and speed of the response were insufficient and the attacker exploited the gap. That acknowledges a known weakness; it does not say the weakness was the entry route here.

Background: what you hand over with a cloud desktop

The rented-office analogy

A cloud desktop is like a locked private room in a building run by a management company.

• You enter your own room (a virtual machine, VM) and work as if at your own PC
• Each tenant has a different key (login credentials)
• The master key, the security cameras and the entry log belong to the management company

Safety is not set by the strength of your room key alone. It also depends on whether the master key has been stolen, whether the walls between rooms hold, and how you treat valuables you leave in the room (account passwords).

Two terms

• Control plane: the management side — creating, stopping, rebooting and reconfiguring rooms.
• Data plane: what the user actually works in — the contents of the room.

If the management side is breached, other rooms may be reachable too. If only one room is breached, the damage is what is inside that room. GMO has not said which it is.

Trust boundaries: a reference architecture

Note: the diagram below is a generic reference model of a cloud remote-desktop environment. It is not a reconstruction of GMO's internal design; it is a tool for asking what happens when each boundary fails.

[User device] ──RDP(3389)/gateway──▶ ┌─ Boundary A: entry (authentication, connection control)
                                       │
        ┌──────────────────────────────┘
        ▼
  ┌── Boundary B: customer VM (data plane) ───────────┐
  │  Windows / trading tool (MT4/MT5) / stored credentials │
  │  Isolated per customer (separate VM, separate network)  │
  └───────────────▲──────────────────────────────────┘
                  │ create, start, stop, reconfigure, snapshot
  ┌── Boundary C: management (control plane) ─────────┐
  │  Admin privileges / console / hypervisor            │
  │  Strong privileges that reach every customer VM     │
  └───────────────┬──────────────────────────────────┘
                  ▼
        Boundary D: outbound traffic (egress) ── brokers' servers

From the fact that 26,739 were put in scope at once, the author treats involvement of Boundary C or a shared component (a common image, a common management tool) as one hypothesis. That is the author's inference and is not in the official notices. Many servers can also be reached by guessing credentials one at a time.

Why damage can reach trading accounts

The most important point of this incident is the condition under which a cloud compromise becomes damage to an account at another company (a brokerage).

The room held the keys to other safes

Notice 2 states that trading-tool (MT4/MT5 and similar) and account credentials stored on the servers may have been viewed. By analogy, someone left the key to a bank safe-deposit box in the rented room. Whoever gets into the room can use that key to open a safe in another building.

To the brokerage this looks like a login with the correct ID and password. The broker's system was not breached; a legitimate key was stolen and used.

Conditions for spread, and where each can be stopped

This is why "make the password strong" is not enough: a stolen key works however strong it was. What you can do is not keep the key, limit where it can be used, and notice quickly when it is.

The author's view: zero trust only means something as concrete controls

"Zero trust" often stays a slogan. The core of NIST SP 800-207 is not trusting based on network location, verifying subject, device and context per request, and granting only minimum privilege. Applied here, that becomes:

1. Operations on the management plane use short-lived, per-person privileges, not standing shared admin accounts
2. Customer VMs expose as little as possible to the management plane, and customer credentials do not appear in management-side logs or settings
3. Egress is allow-listed, and unexpected destinations are blocked and logged
4. Sessions can be revoked — all of them at once when compromise is suspected

This is also what the author prioritises when designing multi-account AWS environments and authentication platforms. Whether GMO met these has not been published.

Cause hypotheses: what evidence would support what

Without an official cause, an article cannot assert one. It can show which evidence would support or rule out each hypothesis — a yardstick for reading follow-up reports.

These hypotheses are generic. None is confirmed in GMO's notices.

For example: if a follow-up says the malicious program was the same file everywhere and installed at nearly the same time, that strengthens H1–H3 (shared mechanism) and weakens H4. If intrusion times are spread over weeks by machine, that strengthens H4.

A reference mapping to MITRE ATT&CK

Mapping a typical attack on a cloud RDP environment to ATT&CK techniques. These are not techniques observed at GMO; it is a way of organizing the questions.

Structuring with STRIDE

For executives: how much of this is your risk when you run trading tools in the cloud?

Responsibility is set by what the contract says

Cloud services usually split responsibility: the provider for the safety of the platform, the user for what is inside (data, credentials, settings). The line differs by service and contract. Even when a "platform-side" problem is suspected, how credentials placed inside are handled is the user's decision.

Three questions to decide

1. Can you confirm it in writing? Are admin privileges, customer isolation, log retention and disclosure, incident notification time and compensation scope in the contract and spec? Verbal explanations are not evidence.
2. If it stops, can you continue? Here all plans have been stopped since 21 October with no restart date as of 1 November. For operations that cannot pause, prepare another provider or method before a stop.
3. Assuming compromise, can you confine the damage? Can one account's compromise be kept from reaching every account and asset (per-account privileges, limits, alerts)?

Mind the compensation scope too. GMO's compensation covers realized losses on trades it judges unauthorized; market losses, lost profits and indirect damage are excluded. Compensation does not necessarily guarantee full recovery.

For engineers: which boundary to verify, with which setting, log or test

Below are read-only checks you can run in an AWS environment you own. Do not run them against accounts you do not own, and review the output (it contains identifiers) before sharing.

1. Entry: is RDP open to the world?

# List security groups that open port 3389 to 0.0.0.0/0 (read-only)
aws ec2 describe-security-groups \
  --filters Name=ip-permission.from-port,Values=3389 \
            Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query 'SecurityGroups[].{id:GroupId,name:GroupName}' --output table

A non-empty result means RDP is reachable directly from the internet. Consider moving to a non-public design (Systems Manager Session Manager or Fleet Manager, a VPN, or a gateway).

An empty result does not mean you are safe. This filter only catches IPv4 rules that name port 3389 on its own. It does not see all-traffic rules (protocol -1), ranges such as 3000-4000, IPv6 ::/0 (query ip-permission.ipv6-cidr separately), or other regions and accounts.

2. Management privileges: long-lived credentials and missing MFA

# Pull the credential report (read-only)
aws iam generate-credential-report >/dev/null
report=$(aws iam get-credential-report --query Content --output text | base64 -d)

# (a) users with a console password but no MFA
#     columns: user, password_enabled, mfa_active
echo "$report" | awk -F, 'NR==1 || ($4=="true" && $8=="false") {print $1","$4","$8}'

# (b) active access key 1 and when it was last rotated (look for old ones)
#     columns: user, access_key_1_active, access_key_1_last_rotated
echo "$report" | awk -F, 'NR==1 || $9=="true" {print $1","$9","$10}'

A user listed in (a), or an access key in (b) that has not been rotated for a long time, means the entrance to Boundary C (the management side) is weak. An empty output does not prove safety. The root account's row has password_enabled set to not_supported, so it never appears in (a) (check root MFA separately). The command also does not look at a second access key (the access_key_2_* columns) or at IAM Identity Center users. That is why management privileges and credentials matter in an incident like this: one administrative privilege reaches many environments.

3. Session revocation: do you know which connections are live?

# Active Session Manager sessions (who, to which instance)
aws ssm describe-sessions --state Active \
  --query 'Sessions[].{owner:Owner,target:Target,start:StartDate}' --output table

Test in peacetime that you can cut every session at once when compromise is suspected, or that a procedure exists. GMO's own guidance to users includes "disconnect all logged-in sessions".

4. Audit logs: can you trace administrative operations afterward?

# Recent console logins (read-only). Any unfamiliar source?
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin \
  --max-results 20 \
  --query 'Events[].{time:EventTime,user:Username}' --output table

Check that CloudTrail is enabled across all regions and accounts, that logs are stored in a separate account where they are hard to tamper with, and that retention is long enough. The "management audit log" row in the hypothesis table is something nobody can verify without it.

5. Detection and egress

• EDR detects suspicious child processes, credential reads and unfamiliar outbound traffic inside a VM. It cannot see a compromise of the management plane itself, which needs management-operation logs and separate monitoring.
• Egress control lets a customer VM reach only allowed destinations. For a trading-tool use case that can be the brokers' servers and update endpoints. It makes both exfiltration and use of the machine as a relay for logging in to accounts harder.
• Unusual management operations (many VMs touched in a short time, privilege changes at night) should alert on deviation from a baseline, not a fixed threshold.

Incident response: what, and in which order

NIST SP 800-61 Rev. 3 treats preparation through lessons learned as one loop. The points for a case like this:

1. Preserve evidence at the same time as (or before) containment: take memory, disk snapshots and logs before stopping, rebooting or deleting. Shutting down every server was a damage-limiting decision, and reconciling that with evidence preservation is hard.
2. Contain broadly while scope is unsettled: GMO stopped all plans.
3. Rotate credentials wholesale: treat every credential in a possibly compromised environment as leaked, and change them from a different device (GMO's guidance says the same).
4. Recover: do not restore the original image as it was. Reopening while the entry route is unknown invites reinfection.
5. Prevent recurrence and disclose: publish cause, impact, countermeasures and compensation, separating confirmed from unconfirmed.

Checklists

Users (individuals and businesses running trading tools in the cloud)

• I listed the account and tool credentials stored on the server and deleted what I don't need
• My trading account uses two-factor authentication, IP restrictions, fill notifications and withdrawal limits
• I don't reuse passwords across services
• I run regular full scans of the PCs and phones I connect from
• I have an alternative and a procedure for when the provider stops
• I regularly check trade history and balance from a device other than the server

Providers and infrastructure staff

• Operations on the management plane use per-person, short-lived privileges, with no standing shared administrator
• Management audit logs are kept for long enough in a place hard to tamper with
• Traffic between customer VMs, and between customer VMs and the management plane, is denied by default
• The integrity of common images and deployment tools is verified (signatures, hashes)
• There is a procedure to revoke all sessions at once, and it has been rehearsed
• Outbound traffic from customer VMs is allow-listed and logged
• Internal findings (vulnerability assessments, red teams) have owners and deadlines

Conclusion and what to watch next

• What can be said as fact: a malicious program was installed, customer information was taken out and published by the attacker, all plans were stopped, and unauthorized operations on trading accounts were reported.
• What cannot yet be said: the entry route, the number of compromised servers, the amount of damage. "26,739 servers were compromised" and "about ¥8 billion in damage" are both wrong.
• The technical lesson: safety depends less on password strength than on admin privileges, where credentials live, isolation between customers, session revocation, audit logs and trust boundaries to outside services. A stored key is usable however strong it is.

In follow-ups, watch for GMO's technical findings (the entry route and what the "security problem" is), the confirmed compromise count, the conditions and date for resuming service, and any report to regulators.

If you want your cloud, authentication or privilege boundaries reviewed

The author has designed and built multi-account AWS environments, authentication hubs, least-privilege IAM, and audit-log and detection pipelines. From the viewpoint of this article, a design review of your cloud and authentication platform's trust boundaries and privileges is something I can do.

What I can and cannot do, up front:

• I can: review the design of admin privileges, credentials, environment isolation, logging and egress from architecture diagrams and settings, with a prioritized improvement plan
• I cannot: carry out forensic investigation of an incident like this one. If you suspect compromise, contact a specialist incident-response firm first
• I cannot promise you will be "completely secure". I report what was found and what was not examined, as it is

See the scope and pricing through the button below.