Skip to main content

Category

Security incident analysis (GMO breach, PHP2Shell, Binance outflow): confirming facts from primary sources, and reading hypotheses apart from defensive design

The commonest errors in incident coverage are mixed-up numbers and causes: servers that could be affected versus servers confirmed compromised, a ransom demand versus a loss, frozen versus recovered versus replenished, a fix versus a configuration mitigation. This cluster goes back to the update history of official notices and to primary sources, separates confirmed, reported, hypothesized and unknown, and then explains what broke in design using generalized reference models. The GMO article covers trust boundaries and who owns which risk; the PHP2Shell article covers the invariants the patch restores and the checks operators can run; the Binance article covers why protecting a key and authorizing a signature are separate problems, with a tested withdrawal policy. The diagrams and code are reference models and do not reconstruct any party's internal architecture. Post-intrusion forensics and crypto custody audits are out of scope.

3 articles in total

Foundational guide

Foundational guide (start here)

セキュリティ
インフラ
アーキテクチャ設計
認証・認可
AWS

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

The GMO Internet 'Onamae.com Desktop Cloud' breach, reconstructed from official notices 1–16. How to read 26,739, how damage can reach trading accounts, the evidence each cause hypothesis would need, who owns which risk, and checks you can run on AWS.

19 min read

Related practical articles