Thunderstorm

4,000件の検出事項があるわけではない。王冠の宝石に至る6つの経路があるのだ。

CSPM は、重複排除され重大度でソートされた設定不備の平坦なリストを渡してくるだけで、 どれが重要なのかは自分で推測するしかない。Thunderstorm は到達可能性について推論する。 クラウドを読み取り専用で収集し、セキュリティケイパビリティのグラフとしてモデル化し、 GitHub Actions の OIDC トラストが4ホップで本番データレイクに至ることを教えてくれる。

上記のホップはどれも単体では検出事項ではない。公開バケット、state ファイル内のキー、 引き受け可能なロール、1つの過剰に広い IAM アクション。パスこそが検出事項であり、 パスを計算するものはほとんど他にない。

対象とするプラットフォームを深く掘り下げる。 AWS アカウント、Azure サブスクリプション、 または GCP プロジェクトに対して実行すると、その1つの環境をプロバイダー自身の用語で マッピングする。AWS では STS assume-role と IAM 権限昇格、Azure では RBAC と マネージド ID チェーン、GCP ではサービスアカウントのなりすまし。1つの環境、1つのグラフを、 そのクラウドが実際に動作する方法でモデル化する。

より多くを列挙するツールはたくさんある。ここでの主張は、Thunderstorm が 列挙したものに対して真の深さで推論するということだ。219 のリソースタイプ、 80 のエッジタイプ、2,400 以上の導出ルール、そして 1,049 のマッピングされた クレデンシャル漏洩サイト。すべて RAGE を出典とする。

RAGE はフォーマットであり、Thunderstorm がそれを生成し、Blaze がそれを探索する。

実際の攻撃チェーンを辿る様子を見る

これらは Thunderstorm が単一の scan から生成するものである。

AWS: 公開された Terraform state ファイルからアカウント全体の乗っ取りまで

1つの設定不備の S3 バケット。Thunderstorm はそれを6ホップで本番顧客データベースまで 追跡し、さらにデータベースのマスターシークレットへ直行する第2の経路も見つける。

Internet ──public s3:GetObject──▶ acme-terraform-state (public bucket)
         ──ExposesCredential────▶ AKIA…            (access key leaked in tfstate)
         ──CredentialsFor───────▶ ec2-app-role
         ──CanAssume────────────▶ terraform-exec    (sts:AssumeRole)
         ──CanEscalateTo────────▶ OrganizationAdmin (iam:AttachRolePolicy)
         ──CanReadData──────────▶ acme-prod-customers (PII)

各ホップは、それを可能にする権限、それを証明する証拠、そして平易な英語の ナラティブを伴う。漏洩した値も一緒に出力される:

Azure: 公開ストレージコンテナからサブスクリプション Owner まで

公開読み取り可能な BLOB がサービスプリンシパルのシークレットを漏洩する。1つの余分な 権限を持つ Contributor が自らをサブスクリプション Owner に昇格させる。アプリの エクスプロイトはない。ただのクラウド設定不備と IAM である。

Internet ──anonymous blob read──▶ acmedeploy (public Storage account)
         ──ExposesCredential────▶ automation-sp secret (in a deploy config blob)
         ──CredentialsFor───────▶ automation-sp (Contributor)
         ──CanEscalateTo────────▶ Owner  (Microsoft.Authorization/roleAssignments/write)
         ──CanReadData──────────▶ acmedatalake

GCP: コミットされたキーから2ホップのなりすましチェーンまで

サービスアカウントのなりすましはほとんどのツールにとって不可視である。Thunderstorm は iam.serviceAccounts.getAccessToken を、それが実際にそうであるラテラルムーブメントの エッジとして扱う。

Internet ──public allUsers───▶ acme-public-exports (GCS)
         ──ExposesCredential─▶ sa-deploy-key
         ──CredentialsFor────▶ sa-deploy
         ──CanImpersonate────▶ sa-data-pipeline
         ──CanImpersonate────▶ sa-org-admin
         ──CanReadData───────▶ acme_customers_pii (BigQuery)

得られるもの

• 攻撃パスグラフ、インタラクティブかつオフライン。 任意の足がかりを選び、到達可能 / 王冠の宝石 / すべてでフィルタリングし、任意のターゲットへの最短パスを見つける。
• 機密露出。 公開リソース、および Thunderstorm が実際に漏洩元から読み取ったクレデンシャルとシークレット。キャプチャされた値とその正確な場所を含む。
• 権限昇格とラテラルムーブメント。 assume-role、なりすまし、マネージド ID、自己付与、クロスアカウント/テナントのエッジ。それぞれがそれを可能にする権限に紐づく。
• 設計上説明可能。 すべてのエッジが証拠、権限、条件、信頼度、ナラティブを伴う。
• 印刷可能なレポート。 チェーンオブカストディ、ブラスト半径、注釈付きパス、確認された漏洩。
• Blaze Lite。 バイナリに埋め込まれた単一のオフライン HTML ビューア。view でブラウザで開く。何もアップロードされない。

要件

• Go 1.26+（2つのモジュール: collectors/、engine/）。
• スキャン対象の読み取り専用クレデンシャル（例: AWS プロファイル、GCP ADC、Azure ログイン）。
• RAGE: Thunderstorm が消費するカタログ。ベンダー化されたスナップショットがバイナリに埋め込まれているため、ビルドや実行に別途ダウンロードは不要（下記参照）。

RAGE が信頼できる唯一の情報源

Thunderstorm は独自の分類体系、マッピング、ルールを一切持たない。RAGE 標準を エンドツーエンドで消費する:

バージョンの紐付け: RAGE の spec_version が、Thunderstorm を RAGE リリースに 固定する唯一の番号である。コレクターはビルド対象の RAGE からそれをライブで読み取り （thunderstorm version は RAGE <v> を出力する）、出力するすべてのグラフにそれを 刻印する。Blaze Lite はその刻印を読み取り、サポートしていないバージョンに対して ビルドされたグラフには警告を出す。

RAGE の解決方法（最初に一致したものが優先）:

1. $RAGE_ROOT: 設定した場合、ライブの RAGE チェックアウト（開発用オーバーライド。編集は再ビルドなしで適用される）。
2. デフォルト: collectors/rage/ にあるベンダー化されたスナップショット。バイナリに埋め込まれる。

スナップショットを更新するには make RAGE_ROOT=/path/to/rage（または collectors/ で go generate ./...）。RAGE は github.com/trustedsec/rage にある。

認証

Thunderstorm は既存のクラウドクレデンシャルを使って読み取り専用でスキャンする。 シークレットを管理することはなく、ターゲットに書き込むこともない。プロバイダーの通常の ツールでログインし、scan をアカウント / プロジェクト / サブスクリプションに向ける。

AWS は標準の AWS SDK クレデンシャルチェーン（名前付きプロファイル、環境変数、SSO、またはインスタンスロール）を使用する:

aws configure --profile myprofile        # or: aws sso login --profile myprofile
./bin/thunderstorm scan --profile myprofile [--region us-east-1]

GCP は Application Default Credentials（ADC）を使用する。ログインしてからプロジェクトを渡す:

gcloud auth application-default login
./bin/thunderstorm scan --provider gcp --project my-project-id

サービスアカウントキーも GOOGLE_APPLICATION_CREDENTIALS=/path/key.json で動作する。

Azure は Azure CLI / DefaultAzureCredential チェーンを使用する。ログインしてから、必要に応じて1つのサブスクリプションにスコープする:

az login
./bin/thunderstorm scan --provider azure [--subscription <sub-id>]

サービスプリンシパルも AZURE_CLIENT_ID / AZURE_CLIENT_SECRET / AZURE_TENANT_ID で動作する。

多数のアカウントを一度にスキャンするには --aws-profiles、--gcp-projects、 --azure-subscriptions、または --scopes ファイル（1行につき provider:scope）を使用する。

使用方法

ビルド（./bin/thunderstorm を生成）:

make                              # build with the embedded RAGE snapshot
make RAGE_ROOT=/path/to/RAGE      # re-vendor from a live RAGE checkout, then build

スキャンしてから探索:

./bin/thunderstorm scan --profile <aws-profile>   # → a single .rage.ndjson attack graph
./bin/thunderstorm view --in engagement.zip       # open it offline in Blaze Lite
./bin/thunderstorm redact --in engagement.zip --out redacted.zip   # de-identify for sharing

--out を指定しない場合、エンゲージメントは ./output/（git で無視される）に置かれる。 ツールはこれだけである: scan、redact、view、version。

設計上の不変条件

• オントロジーは RAGE が所有する。 プロバイダー/サービスを追加するには RAGE を編集するのであり、Thunderstorm ローカルのスキーマを編集することは決してない。
• インベントリではなくケイパビリティ。 辿れるすべてのエッジはセキュリティケイパビリティである。インベントリは STRUCTURAL であり、パスから除外される。
• 説明可能。 すべてのエッジが証拠、権限、条件、信頼度、人間向けナラティブを伴う。
• 条件は第一級。 エッジの状態 = ACTIVE / CONDITIONAL / POTENTIAL / BLOCKED / UNKNOWN。BLOCKED エッジは、パスがなぜ失敗するかを説明するために保持される。

ライセンス

Thunderstorm は GNU General Public License v3 の下でライセンスされている（LICENSE 参照）。 これは許可されたセキュリティテスト、教育、研究のみを目的として提供される攻撃的 セキュリティツールである。自分が所有していない環境に対して実行する前に、明示的な 許可を取得すること。LICENSE の冒頭にある Authorized-Use 通知を参照。