breach-patterns

侵害パターン — 公開された侵害情報から先回りしてセキュリティを強化する

incident-triageの逆です。このスキルは「火事だ。今、何をすべきか」に対応します。こちらのスキルは「侵害に関する報告を読み、そこから導かれる監査上の質問を抽出して、自分たちのスタックを確認する」ためのものです。

ここに掲載している侵害事例は、公開され、十分に記録されており、パターンを見いだせるものです。それぞれのパターンから、OWASP のカテゴリーの枠から漏れがちな対策や確認事項が浮かび上がります。IMDS の悪用、サプライヤーの認証情報による被害範囲、CI 内のシークレット、シングルサインオンを介した横展開、侵害前のログ改ざんなどです。こうした対策は、初めてインシデントに遭った後に追加されることが少なくありません。他者の侵害事例を読むほうが、自分たちで侵害を起こすよりも低コストです。

相互参照先：このリポジトリ内のすべての監査スキルです。このスキルで「X について検討したか？」という質問を洗い出し、詳細な調査には関連する監査スキルを利用してください。侵害パターンから規制上の影響（医療データの漏えい、決済カードデータの漏えい、PII の漏えいなど）が明らかになった場合は、hipaa-audit、pci-audit、または privacy-engineering も参照し、その侵害の種類に伴う規制上の期限や通知義務を確認してください。パターンの発端が誰かのアカウント（フィッシングに遭った創業者、SIM スワップされた管理者、開発者のノート PC など）である場合は、鍵を保有する人々を対象に personal-opsec を実行してください。

認可

このスキルでは、公開されている侵害報告を読み、ユーザー自身のスタックがそれらに該当するかを確認します。ユーザーが所有しているか、レビューを許可されているシステムとコードのみを読み取り専用で確認してください。各パターンは、実際の攻撃がどのように行われたかを説明し、問題を解消できるようにするものです。誰かのシステムに対する実行可能な攻撃に転用しないでください。パターンが現在進行中であることが確認された場合は、作業を中止し、incident-triage に切り替えてください。

このスキルの使い方

以下の各侵害パターンについて、次の手順を実行します。

1. 読む：侵害の概要をまとめた段落を読みます
2. 質問する：自分たちの環境について、そこから導かれる監査上の質問をします
3. 対応付ける：既存の監査スキルにある具体的な確認事項に対応付けます
4. 判断する：対応方針を決めます。「この事象が起こらないことを確認済み」「問題があり、対応計画がある」「以下の理由によりリスクを受容する」のいずれかです

出力は「侵害パターンのカバレッジ」文書です。定型の報告書ではなく、進化するスタックに対して繰り返し実施する、随時更新可能なチェックリストです。

パターン 1 — IMDS の悪用（Capital One、2019 年）

何が起きたか： WAF の設定不備によって SSRF が可能になりました。攻撃者は SSRF を利用して EC2 インスタンスメタデータサービス（IMDSv1、トークン要件なし）にアクセスし、一時的な IAM 認証情報を取得しました。その認証情報を使って、1 億件を超えるレコードを含む S3 バケットを列挙し、データを窃取しました。

監査上の質問： ユーザー入力から URL を受け取るサービスのうち、IMDS 経由で IAM 認証情報にアクセスできるものはありますか？

確認事項：

• すべての EC2 起動テンプレートで IMDSv2 を強制します（MetadataOptions.HttpTokens: required）。cloud-audit を参照してください
• URL を受け付けるすべてのエンドポイントで SSRF 対策を講じます。owasp-audit の A01 SSRF バイパスマトリクスを参照してください（特にクラウドメタデータエンドポイントの行：169.254.169.254、metadata.google.internal、169.254.170.2）
• メタデータエンドポイントのパターンに一致するリクエストを WAF ルールでログに記録し、アラートを発報します

パターン 2 — サプライヤーの認証情報による被害範囲（SolarWinds、2020 年）

何が起きたか： 攻撃者は SolarWinds のビルドパイプラインを侵害し、Orion 製品にバックドア（Sunburst）を仕込みました。正規の Orion アップデートをインストールした顧客は、バックドアが仕込まれたバイナリを受け取りました。このバックドアにより、米国連邦政府を含む顧客ネットワーク内でのラテラルムーブメントが可能になりました。

監査の質問：

• サプライヤーが侵害された場合に同様の被害を受ける可能性がある認証情報を、環境内で保有しているサプライヤーはどこですか？
• CI / CD システムの認証情報を使って、本番環境へラテラルムーブメントできますか？
• ソフトウェアアップデートは署名で検証されていますか、それともソース URL を信頼していますか？

確認項目：

• CI/CD シークレットの権限範囲を最小限にする（完全な管理者権限ではなく、読み取り専用のデプロイトークンを使用）
• 重要な箇所で署名済みコミット／署名済みアーティファクトを必須にする
• サードパーティの JavaScript を特定のバージョンに固定するか、SRI を使って SHA で固定する
• ベンダー管理サービスの被害範囲を監査する — アカウント間の信頼パターンについては iam-audit を参照してください

パターン 3 — 開発者のエンドポイント経由のボールト情報流出（LastPass、2022 年）

何が起きたか： 攻撃者はまず、脆弱なサードパーティ製メディアプラグインを通じて、エンジニアの自宅のコンピューターを侵害しました。これにより、エンジニアの社内ボールトにアクセスできるようになりました。数か月後、そのアクセスを使って顧客のボールトデータを持ち出しました。これには、顧客をフィッシングの標的にするのに役立つ、暗号化されていない URL も含まれていました。

監査の質問：

• どのエンジニアリングアカウントが本番データにアクセスでき、そのためにどのようなデバイスのセキュリティ状態が求められますか？
• 社内システムへのアクセスに使用される個人所有デバイスに、デバイスセキュリティポリシーが適用されていますか？
• 暗号化されたユーザーデータの周辺に、どのようなメタデータが暗号化されずに保存されていますか？

確認項目：

• 価値の高いアクセスには、デバイスの信頼要件を設ける（ゼロトラストのセキュリティ状態 — iam-audit を参照）
• 特権アクセスには専用ワークステーション／踏み台ホストを使い、エンジニアの個人用ノート PC は使わない
• 「重要な」ペイロードだけでなく、メタデータも暗号化する — URL も PII です

パターン 4 — SSO のプッシュ通知疲れ（Okta / Lapsus$、2022 年）

何が起きたか： 攻撃者はサードパーティのサポートエンジニア（Sitel）の認証情報を入手しました。エンジニアが習慣や煩わしさから承認するまで、プッシュ通知による MFA プロンプトを大量に送りつけました。その後、サポートエンジニアのアクセス権を使って、一部の Okta 顧客テナントを閲覧しました（変更はできませんでした）。

監査の質問：

• 管理者アカウントの MFA は、フィッシング耐性のある方式（FIDO2／ハードウェアキー）ですか、それともプッシュ通知だけですか？
• サードパーティのサポート担当者／請負業者のアカウントにも、従業員と同じ制御が適用されていますか？
• サポート／カスタマーサクセスの役割が侵害された場合、被害範囲はどの程度ですか？

確認項目：

• 管理者と特権ユーザーには、フィッシング耐性のある MFA（FIDO2 / WebAuthn）を使用する — iam-audit を参照
• プッシュ通知による MFA で「番号照合」を有効にする（可能な場合）。ユーザーが無意識に承認できないようにする
• プッシュ通知疲れの検知 — 短時間にプッシュ通知のプロンプトが繰り返された場合は、アラートを発する
• 従業員のアクセスと同じ厳密さで、サードパーティのアクセスを四半期ごとに見直す

パターン 5 — 盗まれた認証情報 → SaaS 内のラテラルムーブメント（Snowflake の顧客、2024 年）

何が起きたか： 攻撃者は、個人所有デバイス上のインフォスティーラーマルウェアによって盗まれた認証情報を使い、MFA が必須になっていなかった Snowflake の顧客環境にログインしました。Ticketmaster、AT&T、Santander などからデータを持ち出しました。Snowflake 自体は侵害されておらず、侵害されたのは顧客でした。

監査の質問：

• スタック内に、ユーザーが MFA なしで認証できる SaaS サービスはありますか？
• SaaS へのアクセスには、MFA を必須にしたエンタープライズ SSO が必要ですか、それともローカルアカウントも許可されていますか？
• 個人所有デバイスから盗まれた認証情報によって、ビジネスに不可欠な SaaS のロックが解除される可能性はありますか？

確認項目：

• 環境内のすべての SaaS について、MFA の適用と SSO フェデレーションを監査する
• SSO が利用可能な場合、ローカルアカウントでのアクセスを無効にする
• 条件付きアクセスのポリシーで、準拠デバイスを必須にする — iam-audit を参照
• 従業員のメールアドレスを対象に、認証情報を監視する（HIBP、社内のダークウェブ監視）

パターン 6 — ファイル転送ソフトウェアの未修正ゼロデイ（MOVEit、2023年）

何が起きたか： Cl0p ランサムウェアグループは、Progress MOVEit Transfer の SQL インジェクションのゼロデイ脆弱性（CVE-2023-34362）を悪用しました。数百の顧客からデータを流出させました。その多くは、MOVEit 経由で機密性の高い人事／財務／医療データを転送していました。悪用キャンペーンがすでに進行してから、パッチが提供されました。

監査の質問：

• 環境内のインターネットに公開されたサードパーティ製ソフトウェアについて、ゼロデイが発覚した場合のパッチ適用 SLA はどのようになっていますか？
• コードを管理していない既成の／市販のソフトウェアには、どのような機密データが保存されていますか？
• サードパーティのシステムからの異常なデータ送信を検知する仕組みはありますか？

確認項目：

• インターネットに公開されたサードパーティ製ソフトウェア、その所有者、パッチ適用プロセスの一覧
• サードパーティのシステムにおけるネットワーク送信の監視（siem-detection を参照）
• CISA KEV の監視 — 登録された CVE が自社のスタックに該当した場合の自動アラート（vuln-research を参照）
• データ分類 — サードパーティのプラットフォームに保存する機密データを最小限に抑える

パターン 7 — CI ビルド成果物の侵害（Codecov、2021年）

何が起きたか： Codecov の Docker イメージ作成プロセスの欠陥により、攻撃者は認証情報を窃取できました。攻撃者は Codecov の Bash アップローダースクリプトを改ざんし、Codecov を使うすべての CI 実行から環境変数を流出させました。CI 環境からは、AWS キー、Stripe キー、npm トークン、GitHub トークンが漏えいする可能性があります。

監査の質問：

• 環境変数にアクセスできるサードパーティのツールのうち、CI 内で実行されるものは何ですか？
• CI の環境変数は各ジョブに必要なものだけにスコープ設定されていますか。それとも、すべてのジョブからすべての変数が見えますか？
• CI のステップが外部に通信し始めた場合、気づけますか？

確認項目：

• CI のシークレットはグローバルではなく、ジョブごと、ワークフローごとにスコープ設定する — secrets-audit と iam-audit を参照
• サードパーティの CI 統合をレビューする（環境変数にアクセスできるすべてのアップローダー、スキャナー、デプロイツール）
• 実行可能な範囲で CI のネットワーク送信を監視する
• ビルド成果物の出所証明 — SLSA フレームワーク、署名付きビルド、sigstore

パターン 8 — 内部関係者によるアクセスの悪用（Twitter / X の内部ツール悪用、2020年）

何が起きたか： 攻撃者は Twitter の従業員をソーシャルエンジニアリングでだまし、顧客アカウントに対する広範な権限を持つ内部管理ツールにアクセスしました。そのツールを使って著名人のアカウントを乗っ取り、ビットコイン詐欺を実行しました。

監査の質問：

• 強力な内部管理ツールにアクセスできる従業員は誰ですか？
• アクセスは記録され、レビューされていますか？
• 1 人の従業員が、別の人の承認なしに影響の大きい操作を実行できますか？

確認項目：

• 内部管理ツールを高信頼の対象として扱う — 強力な認証、JIT アクセス、監査ログ
• 機密性の高い操作（アカウント乗っ取り、大量データのエクスポート）には二者承認ルールを設ける
• 管理ツールへのアクセス権を持つ人を四半期ごとに確認する — iam-audit を参照
• アクセス時にアラートを発するハニーポットアカウント

パターン 9 — 長期間にわたる侵害を検知できなかった事例（Equifax、2017年）

何が起きたか： 攻撃者は、未修正の Apache Struts の CVE-2017-5638（2 か月前にパッチが提供されていた既知の脆弱性）を悪用しました。147M 件の信用情報を流出させながら、検知されるまで 76 日間、システム内に侵入していました。パッチは提供済みでしたが、スキャン対象のリストが古く、脆弱性スキャンで見つけられませんでした。

監査の質問：

• 有効な認証情報を持つ攻撃者が環境内に潜伏している場合、検知までにどれくらいかかりますか？
• パッチ適用 SLA は実際に守られていますか。それとも書面上だけですか？
• 脆弱性スキャン対象の一覧は、実際の資産一覧と一致していますか？

確認項目：

• 資産一覧と脆弱性スキャン対象を四半期ごとに照合する
• 重要度ごとのパッチ適用 SLA を明示するだけでなく、測定する（vuln-research）
• 悪用後の挙動（ラテラルムーブメント、データの集積、データ流出）に対する検知範囲 — siem-detection を参照
• 代表的なシナリオについて MTTD（平均検知時間）を測定する

パターン 10 — Cookie／トークン窃取 → MFA の回避（委託業者を経由した Uber の侵害、2022 年）

何が起きたか： 攻撃者は委託業者の認証情報を侵害し、MFA プロンプト疲労を利用して侵入した後、内部を調査しました。ネットワーク共有上に特権認証情報を含む PowerShell スクリプトを見つけ、そこから AWS、GCP、Google Workspace、Slack にアクセスしました。攻撃者が自らのアクセス権をさらに付与するために利用できる Privileged Access Management ツールも見つかりました。

監査の質問：

• ネットワーク共有にはどのような認証情報が置かれていますか？
• 攻撃者がネットワーク共有にアクセスした場合、何を見つけますか？
• 委託業者のアカウントによる被害範囲はどの程度ですか？

確認事項：

• すべての内部ファイル共有、Wiki、チケット管理システムで認証情報の検出スキャンを実施します — secrets-audit を参照してください
• 委託業者のアカウントにも、従業員と同じ MFA とレビューを適用します
• Privileged Access Management（PAM）システム自体を、最重要資産として監査します

追加すべきパターン（あなたの役割）

このスキルは、重大な侵害が公表されるたびに成長していく必要があります。手順：

1. 事後分析を読みます（ベンダー、ニュース記事、規制当局への提出書類）
2. 特定のベンダーにとどまらず一般化できる一文のパターンを抽出します
3. 自社のスタックで「いいえ」と答えられるべき監査の質問として表現します
4. 既存の監査スキルにある具体的な確認事項と対応付けます
5. このスキルに追加します

事後分析の優れた情報源：

• ベンダーのセキュリティブログ（侵害された企業自身による記事が、通常は最も正確です）
• 上場企業の SEC 8-K 提出書類（法的基準に準拠した詳細情報）
• 「BleepingComputer」、「Risky.Biz News」、「Krebs on Security」— 信頼性の高い侵害情報
• Verizon DBIR（年次）— 年間を通じたパターンを集約
• MITRE ATT&CK の実際の攻撃に関するレポート

出力形式

# Breach Pattern Coverage Assessment
## Environment: [name]
## Date: [date]

### Coverage status
| Pattern | Audit question | Status | Owner |
|---------|----------------|--------|-------|
| IMDS abuse (Capital One) | SSRF-to-metadata reachable? | Clean | sec |
| Supplier blast radius (SolarWinds) | CI/CD blast radius? | Gap — plan attached | platform |
| ... | | | |

### Gaps with plans
[For each Gap row above — what's the plan, by when]

### Patterns not yet evaluated
[Patterns where you don't yet have data to mark Clean / Gap]

これは四半期ごとに再実行する文書であり、一度きりのものではありません。業界のパターンは変化します。

境界

• このスキルは予防を目的としています（「これは自社で起きるか？」）。攻撃を目的とするものではありません（「Lapsus$ が行ったことを自分たちもできるか」）。
• 公開された侵害の詳細は公知情報です。活用してください。流出した認証情報のダンプや非公開情報を探してはいけません。
• 評価によって進行中の問題が明らかになった場合（「起こり得る」ではなく「実際に起きている」場合）は、incident-triage に切り替えてください。
• 防御範囲を評価するために必要な範囲を超えて、攻撃パターンや詳細な攻撃者向け手順書を作成してはいけません。

参考資料

• 「Cyber Incident Reporting and Analysis Methods」— DHS／CISA
• Verizon Data Breach Investigations Report（DBIR）— 年次の業界侵害分析
• MITRE ATT&CK の実際の攻撃に関するレポート
• CISA のサイバーセキュリティ勧告
• Krebs on Security（krebsonsecurity.com）
• 「Risky.Biz」のニュースポッドキャスト／ニュースレター
• Project Zero — Google の攻撃的セキュリティチームによる記事
• Mandiant／CrowdStrike の脅威レポート
• 「Tracing Stolen Bitcoin」— 攻撃者のワークフローに関する調査記事