The Onamae timeline shows why provider incidents need a customer-side evidence clock
Provider notices often arrive after the decisive events. In the Onamae.com Desktop Cloud incident, GMO says its investigation began on October 19, 2026 after a customer inquiry, malicious programs were confirmed on October 20, and servers across all plans began shutting down from 04:00 on October 21. A customer reading the first notice a day later already has a window to reconstruct.
The company's reports provide a useful chronology. It confirmed malicious programs in some customer server environments, suspended new applications and the control panel, began service-wide server shutdowns, consulted police, reported customer information taken outside the company, received a threatening email demanding approximately 8 billion yen, and later confirmed that attackers published claimed company and customer data. It also asked customers to change credentials and revoke sessions.
Record decisions, not only alerts
An incident timeline should include the moment a control was applied alongside the moment a notice was published. When did the customer first see the provider email? Who authorized credential rotation? Which brokers were contacted? When did each session actually terminate? Did the customer continue using a backup desktop or alternate account during the outage? Those decisions can change exposure even when the provider's root cause remains unknown.
Create one record for each source. A provider email, broker statement, endpoint alert, user interview, and firewall log should keep their original timestamp and time zone. Add a normalized UTC time and an evidence owner. Do not overwrite a user's recollection with a later summary.
The provider's 26,739 figure should enter the timeline as a service-wide estimate. It is the number of servers that may have been affected, not a confirmed count of compromised machines. Likewise, a customer's report of an unauthorized trade is a lead for reconciliation, not by itself proof of how the login occurred.
Put the root-cause gap on the record
GMO's fourth report says the service systems had security vulnerabilities and the environment was accessed without authorization. The public notices reviewed through October 30 do not identify the vulnerable component, the entry path, a malware family, or a CVE. This gap matters because customers may otherwise anchor every later event to the first plausible explanation.
Preserve an open question until the provider supplies evidence. Ask for access logs, management-plane activity, image or configuration changes, server status, and the timing of containment. If GMO cannot attribute a customer event to the intrusion, state that. A negative finding is still an investigation result.
Measure public exposure at a fixed time
External observations become more useful when they are timestamped. AutoPR's four Onamae queries all succeeded on November 1, 2026. They returned 0 all-asset observations for domain="onamae-desktop.com", 40 for domain="onamae.com", 96 for ssl="onamae.com", and 427 for ssl="onamae".
Those values are snapshots, not a time series. A single 0 does not establish that the product never had public infrastructure, and a later 427 does not show growth caused by the incident. The queries use different matching rules. The product-domain search is narrower than the brand-domain search, and both differ from certificate-text matching.
The correct record includes the exact normalized dork, all-asset scope, query time, result ID when available, and the conclusion. A useful conclusion is that certificate text containing Onamae was visible in 427 indexed observations. An unsupported conclusion is that the service had 427 exposed servers or that those observations represented customers.
Close with evidence
The customer side of the timeline can close only when access revocation, endpoint review, broker reconciliation, and restoration have supporting records. Provider containment alone is not a closure. GMO's reports through October 30 had not supplied a service resumption date, and the public record still lacked the root cause. Customers should carry those open items into each recovery decision.
A methodical evidence clock does two jobs. It prevents a later notice from erasing earlier uncertainty, and it gives legal, technical, and business teams a common account of what they knew and when they acted. In a shared-service incident, that record is often more durable than the provider's first explanation.
Top comments (0)