はじめに(この記事で分かること)#
Silk Roadの運営者は、ハンドル名と実名のGmailアドレスを同じ掲示板に書いていた。AlphaBayの運営者は、サイトが自動送信するメールに私用のHotmailアドレスを載せていた。どちらの事例でもTorは設計どおりに動いていて、崩れたのは運用だった。OPSECのカテゴリには、この「道具は健全でも運用が崩れる」という見方で書いた記事が、このハブを除いて14本ある。総論、構造の分析、個別の事例、失敗の型のカタログ、そして自分の運用を書き出して点検する実践記事だ。
本数が増えると、どこから読めばよいかが分かりにくくなる。事例記事だけを読むと他人の失敗談で終わり、実践記事だけを読むと、なぜその行を点検するのかが見えない。このハブは、各記事が何に答えるかを一行ずつ示し、立場ごとの読む順番と、事例から自分の点検表へ戻るまでの道筋を示す。新しい事実はほとんど足さず、根拠はリンク先の各記事に委ねている。
前提: 脅威モデルの整理#
脅威モデル入門は、隠す相手をISP、プラットフォーム、広告網・データブローカー、法執行機関、標的型攻撃者の5種類に分けた。このカテゴリの事例記事に出てくる相手は、ほぼすべて法執行機関である。令状で事業者の記録を集め、端末を押収し、ときにはサーバーそのものを運営する相手で、一般の読者がここまで強い相手に個人として狙われることはまずない。
それでも事例を読む理由は二つある。匿名性が実際にどう崩れたかを、令状申立書や訴状という検証できる形で残している記録がほかにほとんどないこと。そして崩れ方の型が、ストーカーによる割り出しやSNSの発信者情報開示のような身近な相手の場合と共通していることだ。強い相手に通用した手口は、ずっと弱い相手にも通用する。以下は、各相手に対してこのカテゴリのどの記事が判断を変えるかの見取り図である。
| 相手 | このカテゴリで変わること | 中心になる記事 |
|---|---|---|
| ISP | 通信内容を隠しても「いつ、どの道具を使ったか」は回線側に残る。回線と時刻も区画の一部として扱う | ミスカタログの型4、カンパートメント化の設計書の回線の行 |
| プラットフォーム | 復旧用メール・電話番号・テスト送信・同一IPのログインが、事業者の記録の上で区画をつなぐ | アカウント復旧経路、匿名メールとSNSの連結 |
| 広告網・データブローカー | 名前ではなく共通の値で同じ人に束ねられる。識別子の棚卸しがそのまま対策になる | カンパートメント化の設計書、自己点検 |
| 法執行機関 | 事例記事のほぼすべて。読者が手を打てる範囲は狭いが、どこが崩壊点になったかの記録が最も厚い | 総論と個別事例、6層の解剖 |
| 標的型攻撃者 | 令状は要らず、端末もパスコードも知っている相手。設定を急に変えること自体が危険になりうる | 同居人・元交際相手から守る匿名性 |
法執行機関の列が「読む価値はあるが、対策の手応えは最も小さい」ことは、このカテゴリ全体の前提として覚えておいてほしい。
読む順番#
初めて読む人は、総論から始める。匿名性が崩れる4つの経路(エンドポイント侵害、OPSEC失敗、金融の痕跡、行動パターン)と、闇市場の販売者1,733人のOPSECを測ったUSENIX Security 2021の研究がここにまとまっている。次の一本はカンパートメント化の設計書。事例を何本も読む前に、自分の区画と識別子を表に書き出してしまうほうが、その後の事例が「自分の表のどの行の話か」として読める。匿名のSNSアカウントを一つ持っているだけなら、設計書のまとめにあるとおり、まず復旧経路の行だけを確かめれば足りる。
取材源や相談者を守る立場の人は、匿名メールとSNSの連結を最初に読むとよい。DIA職員Laatschの匿名アカウントは、宣誓供述書が「possibly a test email」と書いた実名アカウントからのメールと、同じ自宅IPからのログインで実名側とつながっていた。守る対象が自分ではなく相手との関係である人にとって、これがいちばん身近な崩れ方だ。次の一本はOxyMonster事例で、国境の二次検査で端末のパスワードを申告した場面が、取材で国境を越える人への直接の教訓になる。そのあとアカウント復旧経路で、取材用アカウントから電話番号を外せるかを確かめる。
サーバーやサービスを運営する立場の人は、Wall Street Market事例から読む。管理者側のVPN接続が切れたままアクセスが続き、実際のIPアドレスがWSM側のサーバーに記録された経緯と、別の運営者の自宅回線の接続時間帯が管理操作の時間帯と重なっていた経緯が、訴状に沿って整理されている。次の一本はPlaypen事件とNIT。押収されたサーバーが訪問者を狙う配布元に変わった事件で、運営者が「自分のサイトが訪問者に何を配っているか」を検証できる状態を保つ理由がここにある。インフラ側の具体的な設計は匿名インフラの総合ガイドへ渡す。
どの立場でも、最後は自己点検に行き着く。読んだ事例の数より、自分の端末と表を一度通して点検したかどうかのほうが、結果を左右する。
記事マップ#
総論と構造#
| 記事 | 扱う境界 | 主に想定する相手 | この記事が答える問い |
|---|---|---|---|
| 匿名性が暴かれた実例集(総論) | 全体 | 法執行機関(教訓は全読者向け) | 匿名性はどの経路で崩れるのか。平均的なOPSECはどの水準か |
| サイバー犯罪者はどう匿名化しているのか | 通信・インフラ・金融・運営・端末・組織の6層 | 法執行機関 | 匿名化はどう組み立てられ、どの層の継ぎ目から崩れたか |
| 徹底的に匿名化する高度な犯罪者 | 組織・提供者・管轄 | 法執行機関 | 徹底した運用でも崩れたのはどこか。役割の分離と長期運営は何を守り、何を守らなかったか |
| 暴かれた犯罪者のミスカタログ | 失敗の型11種 | 法執行機関(教訓は全読者向け) | 失敗をどの粒度で並べれば、自分の運用に当てはめられるか |
個別事例#
| 記事 | 主な経路 | 崩壊点 | この記事が答える問い |
|---|---|---|---|
| Wall Street Market事例 | OPSEC失敗、行動パターン | VPN切断中のアクセス、UMTSスティック、接続時間帯の重なり | 何重にも対策した運営者が、どの継ぎ目から特定されたか |
| OxyMonster事例 | 金融、行動パターン、OPSEC失敗 | 投げ銭の送金先、文体、国境での端末検査 | 性質の違う痕跡は、どの順で積み重なって一人に収束したか |
| パスワードとPGP鍵の再利用 | OPSEC失敗 | Hansaで得た認証情報、2FA未設定、掲載公開鍵の差し替え | 再利用はアカウントの乗っ取りを超えて何を失わせるか |
| Ennetcomの罠 | OPSEC失敗(鍵の預託) | 鍵がサーバー側にあったとする当局の説明(弁護側は争う) | 「暗号化されている」という説明は、鍵の所在を確かめずに信じてよいか |
| 匿名メールとSNSの連結 | OPSEC失敗、行動パターン | テスト送信とみられるメール、同一IP、身分証画像、古いニックネーム | 匿名アカウントは作成ではなく運用のどこで崩れるか |
| Playpen事件とNIT | エンドポイント侵害 | ブラウザの脆弱性を突いたとみられるコード | Torの経路が破られないまま、なぜ実IPが送られたのか |
実践#
| 記事 | 扱う境界 | 主に想定する相手 | この記事が答える問い |
|---|---|---|---|
| カンパートメント化の設計書 | 名義の区画と識別子 | 広告網、プラットフォーム、標的型攻撃者 | 自分の運用のどこに橋が架かっているかを、どう書き出して見つけるか |
| アカウント復旧経路が「橋」になる | 復旧用メール・電話番号・SSO・2FAのバックアップ | プラットフォーム、標的型攻撃者 | 見えない復旧経路をどう点検し、どこまで切るか |
| 同居人・元交際相手から守る匿名性 | 端末共有・位置共有・追跡タグ・ストーカーウェア | 標的型攻撃者 | 相手に気づかれずに、どの順で何を確かめるか |
| 自分の匿名性を自己点検する | 接続・DNS・WebRTC・IPv6・指紋・メタデータ・復旧経路・公開情報 | 全種類(点検できない層を含めて明示) | 今の自分の端末は外からどう見えているか |
他カテゴリでこのカテゴリと地続きになっているのは、文体と時間帯の痕跡を扱う文章からの特定、ハンドル名や公開情報の連結を扱うOSINTによる特定、4経路から外したタイミング相関を扱う通信のタイミング相関、そして開示手続きで回線の記録がたどられる仕組みを扱うIPアドレスから個人を特定される仕組みの4本だ。
事例シリーズの読み方#
個別事例の記事は、どれも「事例の概要 → タイムライン → 特定はどうやって進んだか → どうすれば防げたか → 脅威モデル別の教訓」という同じ形で書いている。読むときに気をつけてほしいのは、「特定はどうやって進んだか」の節の断定の強さが、出典の性格に合わせてあることだ。訴状や宣誓供述書は捜査側の主張で、裁判で争われる部分がある。Ennetcomでは弁護側が当局の説明に異議を唱えたと報じられ、Guccifer 2.0がVPNを有効にし忘れたという話は1人の匿名の情報源に基づく報道だった。
もう一つは、記録に書かれていないことを補って読まないことだ。Wall Street Market事例の訴状は、VPN接続が切れた原因も、運営者がキルスイッチのような仕組みを使っていたかどうかも書いていない。事例記事の対策表でキルスイッチに触れているのは、その経路を塞ぐ一般的な手段としてであり、推測であることを明記してある。同じように、Playpenで使われた脆弱性は公開資料の範囲では特定されていないので、記事は「最新版に更新していれば防げた」とは書いていない。
読み終えたら、「どうすれば防げたか」の表の一行を、自分の設計書のどの行に当たるかに置き換える。事例シリーズは、この置き換えをして初めて自分の役に立つ。
4経路・6層・11の型の関係#
このカテゴリには、崩れ方を分ける枠組みが三つある。総論の4経路は、捜査がどの方向から入ってきたかの分類で、いちばん粗い。6層の解剖は、匿名化の仕組みのどこ(通信、インフラ、金融、運営と通信手段、端末と物理、組織と人)で崩れたかという場所の分類だ。ミスカタログの11の型は、何をしたから崩れたかという行為の分類で、いちばん細かい。
三つは置き換えではなく、同じ事例を別の角度から見たものだ。たとえばWall Street MarketのVPN切断は、4経路ではOPSEC失敗、6層では通信層とインフラ層の継ぎ目、11の型では型4(ネットワークの切れ目)にあたる。下の表の「4経路」の列はカタログ自身の対応表をそのまま写した。「6層」の列は、各記事の事例がどの層の節で扱われているかをもとにこのハブが対応づけたもので、6層の記事が直接扱っていない型には括弧で注記した。最後の列は、その型を自分の運用で点検する場所である。
| 11の型 | 4経路(カタログの対応表) | 6層(このハブの対応づけ) | 自分の運用で点検する場所 |
|---|---|---|---|
| 1識別子の連結 | OPSEC失敗、行動パターン | (層の外。名義の区画の継ぎ目) | 設計書のメール・ハンドル名の行、OSINT |
| 2認証情報の再利用 | OPSEC失敗 | (層の外。名義の区画の継ぎ目) | 設計書の鍵とパスワードの行 |
| 3メタデータの漏れ | OPSEC失敗 | インフラ(サイトの自動送信メール) | 復旧経路、自己点検のファイルの節 |
| 4ネットワークの切れ目 | OPSEC失敗、行動パターン | 通信とインフラの継ぎ目 | 設計書の回線の行、キルスイッチ |
| 5金融の出口 | 金融の痕跡 | 金融 | 設計書の支払い手段の行 |
| 6端末と物理 | OPSEC失敗 | 端末と物理 | 設計書のブラウザと端末の行 |
| 7提供者への委託 | OPSEC失敗 | 通信 | 鍵を誰が持つか(Ennetcom) |
| 8内輪の崩壊 | OPSEC失敗(他人の) | 運営、組織と人 | 共同作業者や委託先の運用を自分のリスクとして数える |
| 9誇示と余計な出力 | 行動パターン | 運営(外へ出す出力) | 外に出すファイルを出す前に読む(自己点検) |
| 10公記録による列挙 | OPSEC失敗(他人の連鎖) | 組織と人 | 自分では制御できない入力として数える |
| 11時間 | 金融の痕跡、エンドポイント | 全層(押収データは後で読まれる) | 設計書の見直し日 |
表を縦に見ると、4経路の列はOPSEC失敗に寄り、点検の列はほとんどが設計書の行に戻ってくる。カタログが「縦に見ると、OPSEC失敗の列に多くの型が寄る」と書き、総論の事例表でも同じ列だけがほぼ埋まっていたのと同じ観察だ。型8・型10・型11の三つは、自分の表をどれだけ整えても塞げない入力で、カタログ自身もこの3種を立てたのは原典ではなくサイトの読みだと断っている。
よくある誤解#
「Torは破られた」。事件の見出しではよくそう書かれるが、総論が裁判記録から拾った事例では、破られていたのはTorではなく運用だった。いちばん道具に近いPlaypen事件でさえ、控訴審判決はFBIがサーバーを掌握した後も訪問者はTorに隠されていたと書いており、実IPが漏れたのは経路の手前の端末が乗っ取られたからだった(Playpen事件とNIT)。経路の匿名性と端末の安全は別の問題として扱う必要がある。
「捕まるのは間抜けだけで、本物のプロは消えている」。USENIX Security 2021の研究では、安全でない慣行はすべての販売者タイプに広くみられ、最も成功した販売者の層にもあった(総論)。役割を分け、7年続いたHydraのような市場も、サーバーの物理的な所在から崩れた(高度な犯罪者)。逆に「平均を少し上回れば安全」とも言えない。総論が書くとおり、相対的な安全が意味を持つのは相手が大勢の中から手の届く対象を拾う場合だけで、すでに個人として狙われているなら周りの平均は関係がない。
「パスワードをかけた端末なら、中身は守られる」。OxyMonsterのノートPCはパスワードで保護されていたが、本人が国境の二次検査で係官にパスワードを伝え、その場で開かれた(OxyMonster事例)。区画の鍵と認証情報とウォレットが1台に同居していたため、一回の申告ですべてが開いた。暗号化は鍵を渡した時点で守りにならず、区画ごとに端末を分けることは暗号化とは別の対策になる。
「VPNが切れたのはキルスイッチがなかったから」。Wall Street Market事例はキルスイッチの話として紹介されることが多いが、訴状には切断の原因もキルスイッチの有無も書かれていない(Wall Street Market事例)。記録から言えるのは、切れたままアクセスが続き、実際のIPアドレスがWSM側のサーバーに記録されたところまでだ。自分のVPNが切れた瞬間に何が起きるかは、キルスイッチの記事の手順で自分で切って確かめるのが確実である。
限界と残るリスク#
このカテゴリの事例は、捕まり、しかも手法が公になったものに限られる。成功した匿名化は記録を残さず、捜査機関が明かしていない手法は事例に現れない。「OPSEC失敗が最も多い」という観察には、技術的な手法ほど公にされにくいという事情が混じっている可能性がある。どの事例の教訓を取り入れても、強い相手に個人として狙われた場合の安全は保証されない。このカテゴリが示せるのは、崩れやすい場所の地図までだ。
扱いの外にあるものもはっきりしている。ブラウザの指紋のように自分では書き出せない識別子はブラウザフィンガープリントに、両端の観測で通信を結びつけるタイミング相関は通信のタイミング相関とTorの総合ガイドに委ねている。VPN事業者の選び方はVPNの総合ガイド、お金の出口の設計は暗号資産のプライバシー総合ガイド、サーバーやドメインの匿名化は匿名インフラの総合ガイドの担当だ。このカテゴリは、それらの道具を「どう運用すると崩れるか」を扱うところまでで、道具そのものの良し悪しは判定していない。
そして、区画を分けても行為の違法性は変わらない。事例の人物は、匿名性が崩れたこととは別に、行為そのものを罪に問われている。このカテゴリの記事は、匿名で発信する人、取材源を守る人、自分の生活を詮索から守りたい人が自分の運用を点検するために書いたもので、捜査を逃れる助言ではない。
まとめ#
匿名のSNSアカウントを持っているだけの人は、総論を読み、次にカンパートメント化の設計書の復旧経路の行を今日埋める。
取材源や相談者を守る人は、匿名メールとSNSの連結を読み、次にアカウント復旧経路で取材用アカウントの電話番号と再設定先を確かめる。
サーバーやサービスを運営する人は、Wall Street Market事例を読み、次に自分のVPNを手で切って何が起きるかを自己点検の手順で確かめる。
交際相手や同居人に端末や居場所を見られているおそれがある人は、設定を変える前に同居人・元交際相手から守る匿名性を読み、相手が触れていない端末から相談窓口に連絡する。
どの立場でも、表を閉じる前に次の見直し日を書いておく。EFFのSurveillance Self-Defenseは、状況が変われば計画も変わるので、計画を頻繁に見直すのがよい習慣だと書いている。サイト全体の地図に戻るならインターネット匿名化 総合まとめからどうぞ。
出典#
各記事の事実関係の出典は、リンク先の各記事の出典節にまとめてある。このハブで直接参照したのは次の3点。
- EFF Surveillance Self-Defense — Your Security Plan(状況の変化に応じて計画を頻繁に見直すのがよい習慣だとする記述。2026-11-08参照)
- van de Laarschot & van Wegberg, Risky Business?(USENIX Security 2021)(Hansa Market販売者1,733人の分析。安全でない慣行がすべての販売者タイプに広くみられたとする要旨。2026-11-08参照)
- netguardia — How Law Enforcement Actually Deanonymizes Tor Users (Hint: It's Rarely the Protocol)(総論の4経路の原典となった4分類。2026-04-26公開、2026-11-08参照)