Terraformプロバイダーを踏み台にするGraphalgo──IaCサプライチェーンを狙ったRAT配布の新潮流です

今日の深掘りポイント

• Terraformプロバイダー（サードパーティ製）を悪用してRATを配布する初観測の事例と報じられ、IaCワークフロー自体が侵入口になる現実を突きつけています。
• 依存解決の自動化（terraform init）と開発者・CIのアウトバウンドを前提にした「開発基盤のゼロトラスト未満」が、本件の成否を左右しています。
• 供給網防御は「ピン留め・検証・私設レジストリ・監査」の四点セットに尽きます。Terraformのロックファイル監査と、Goモジュール/プロバイダーの内部プロキシ化は今からでも有効です。

はじめに

IaCはクラウド運用の自動化を推進した一方で、依存解決の自動取得という利便性が攻撃者にとっても魅力的な経路になりつつあります。Graphalgoと呼ばれるマルウェアは、悪意のあるTerraformプロバイダーとGoモジュールを足がかりに、ターゲット選別型のRATを展開する手法を採用したと報じられています。これは、従来のパッケージレジストリ（npm、PyPIなど）を超え、IaCの供給網を直接狙う段階に攻撃がシフトしたサインです。CISOやSOC、Threat Intelの読者にとっては、開発基盤のゼロトラスト化と供給網ガバナンスを、クラウド権限管理と同列の「最優先」で位置づけ直すタイミングと言えます。

深掘り詳細

事実整理（報道ベース）

• Graphalgoは、悪意あるTerraformプロバイダーおよびGoモジュールを利用して、特定の被害者に向けてRATを展開する手法を用いていると報じられています。トロイの木馬化されたTerraformプロバイダーとして、gocommunity-io/dockerd、kreuzwenker/dockerが挙げられています。公開日が示されたGoモジュールとして、gocommunity.io/orderedbtree（2026年8月11日）、gogets.dev/btreex（2026年9月8日）が紹介されています。
• この経路（Terraformプロバイダー）を使ったマルウェア拡散は「初観測」とされ、IaCワークフローが攻撃対象面に組み込まれたことを示唆します。
• マルウェアはSHA-256ハッシュなどの条件で実行をガードし、自動解析を回避しつつ、選別した環境でのみアクティブ化する振る舞いが報じられています。
• C2にはSlack APIやブロックチェーンを用いた手法が確認されたとされ、従来型インフラに依存しないレジリエントな通信路を確保しているとの見立てです。

以上は公開記事の報道に基づく整理であり、一次調査機関の技術詳細や追加IOCは今後の公開に依存します。

参考情報:

• Graphalgo Malware Abuses Terraform Provider and Go Modules to Deliver RAT (GBHackers)

インサイト（なぜ効くのか／どこが痛点か）

• IaCの「自動取得」が逆手に取られる構造です
  Terraformはrequired_providersの宣言に基づき、terraform initでリモートからプロバイダーを取得します。組織が「信頼可能なソースの強制」「バージョンとチェックサムの固定」「私設レジストリ／ミラーの強制」を徹底していない場合、開発者やCIが見慣れない名前空間のプロバイダーを無批判に取得する余地が生まれます。これがそのまま実行フェーズに接続するため、検出のタイミングは遅れがちになります。
• 選別実行（Execution Guardrails）で検知をすり抜けます
  実行ガード（環境ハッシュなど）により、サンドボックスや大規模スキャンでは活動を見せず、狙った組織・ビルド環境でのみRATが有効化されます。これによりVT等の汎用検出で「静か」に振る舞い、SOCのトリアージ閾値を越えにくくします。
• C2の弾力性（Slack/ブロックチェーンの活用）です
  一般的なアウトバウンド制御では、SaaSやWebプロトコルの完全遮断は業務影響が大きく、出口での選別が難題です。Slack APIや分散台帳をC2に用いれば、ブロックリスト中心の制御や単純なDNS/ASN封鎖の効果が薄れます。監視は「誰が、どこから、どの頻度・ペイロードで使っているか」という振る舞い解析の比重が高まります。
• 「IaC SBOM」の未整備が可視化を妨げます
  アプリSBOMは普及しつつありますが、IaC（プロバイダー／モジュール）のSBOMやロックファイル監査を標準運用に落とし込めていない組織が多いです。結果、供給網の逸脱（未知の名前空間・突然の依存の出現）に対する継続的検知が遅れます。

総じて、これは「開発・運用の利便性が上げた天井」を突かれたケースです。防御側は、パイプラインと開発端末を含む「開発基盤」のゼロトラスト化を、メールやVPNと同じ一次防衛レイヤに格上げする必要があります。

脅威シナリオと影響

以下は公開報道を踏まえた仮説シナリオです。個別環境へ適用する際は、貴組織のIaC運用・プロキシ設計・端末管理に照らして調整してください。

• 侵入経路（仮説）
  • 攻撃者は悪意のあるTerraformプロバイダーを公開し、見慣れないが「もっともらしい」名前空間・説明・バージョニングで擬装します。
  • 開発者／CIがterraform initを実行し、外部レジストリから該当プロバイダーを取得・検証します（検証が不十分な場合、混入に気づきません）。
  • プロバイダー実行時に環境チェック（SHA-256等のキーイング）を通過した対象のみで、RATが展開されます。
  • C2はSlack APIやブロックチェーンを介し、HTTPS経由の通常トラフィックに溶け込みます。
• 到達可能な影響（仮説）
  • 開発端末・ビルドワーカーに常駐し、クラウドクレデンシャルやGit/CIシークレット、Terraformの状態ファイル（state）にアクセスする可能性があります。
  • 組織のVCSやアーティファクトリ、内部レジストリへの横展開を試み、供給網のさらなる汚染（依存のトロイ化）に発展し得ます。
  • 検出回避により滞在時間が延び、クラウド権限の昇格（IAMミスコンフィグの悪用）やリソース改ざんのリスクが高まります。

MITRE ATT&CKの仮説マッピング（代表例）です。環境や検体により差異があり得ます。

• 初期侵入: Supply Chain Compromise（ソフトウェア依存・開発ツールの妥協）[T1195.001]に相当し得ます。
• 実行: ユーザー実行／開発ツール実行の濫用（Terraformプラグインが実行トリガ）で、Command and Scripting Interpreter [T1059]相当の併用があり得ます。
• 防御回避: Execution Guardrails（環境キーイング）[T1480.001]、不正名称による偽装 [T1036] が想定されます。
• C2: Application Layer Protocol（Web/HTTPS）[T1071.001]、SaaSを用いたC2（Slack等）に該当し得ます。
• 資格情報アクセス/発見: Credentials in Files [T1552]、Cloud Credential Discovery [T1087/T1526に隣接]の可能性があります。
• 永続化: OS依存でRun Keys/Startup Folder [T1547]などの汎用手口が取り得ます。

この手口は「すぐ燃え広がるワーム」よりも、「選んで刺す」運用型の脅威像に近いです。新規性が高く、実施の障壁は低くない一方で、開発基盤のアウトバウンドと依存検証が緩い組織では実害に直結しやすい、というバランス感にあります。CISO視点では「全社横断のパイプライン標準化」と「開発端末のネットワーク最小権限」を同時に前進させる好機です。

セキュリティ担当者のアクション

まずは「見える化→封じ込め→既定化」の順で進めると、現場の摩擦を抑えつつ実効性が上がります。

• いま直ちにやること（スカウト的サーチ）

  • すべてのリポジトリとCIテンプレートで、.terraform.lock.hcl と main.tf を横断検索し、未知の名前空間や以下の文字列混入を確認します（IOCサーチの一環です）:
    • プロバイダー: gocommunity-io/dockerd、kreuzwenker/docker
    • Goモジュール: gocommunity.io/orderedbtree、gogets.dev/btreex
  • 開発端末・ビルドワーカーのアウトバウンドログを遡及分析し、見慣れないモジュールホストや上記ドメインへのアクセスの有無を確認します。Slack APIへの定常外アクセス（特にビルド環境から）も洗い出します。
  • 影響が懸念される場合は、当該端末・ワーカーのメモリスキャン、クラウドクレデンシャルの即時ローテーション、Terraform stateの改ざん有無チェックを実施します。

• 早期封じ込め（パイプラインの最小権限化）

  • Terraform
    • required_providersでソースアドレスとバージョンを厳格にピン留めします（範囲指定を避け固定化します）。
    • .terraform.lock.hcl（依存ロック）の強制コミットとPRレビュー時の差分監査を標準化します。
    • provider_installationで私設レジストリ／ネットワークミラー（社内プロキシ）を必須化し、外部レジストリへの直接取得を禁止します。
    • プロバイダーの許可リスト（allowlist）を作成し、未知の名前空間はCIでビルド拒否します。
  • Goツールチェーン
    • GOPROXYを社内プロキシに固定し、GOSUMDB/GONOSUMDB/GOPRIVATEを組織方針に合わせて厳格設定します。
    • go mod verifyの実行とモジュールキャッシュの定期監査をCIに組み込みます。
  • ネットワーク
    • 開発端末・CI/CDランナーのアウトバウンドを、社内レジストリ・監査済SaaSへの最小許可に絞ります。監査済み以外のモジュールホスト／新規ドメインはデフォルト拒否とし、例外は期限付き承認にします。

• 監視と検知（ふるまい中心へ）

  • Terraformやgoコマンドを親プロセスに持つ不審な子プロセス生成、未知の実行ファイルドロップ、自己削除の痕跡をEDRで監視します。
  • Slack APIや類似SaaSへのアクセスについて、端末役割別のベースラインを作成し、ビルド環境からのAPI多用・深夜帯の連続アクセスなどをアラート化します。
  • IaCのSBOM/依存台帳を整備し、リポジトリ単位の「初見依存」や「名前空間逸脱」を継続検知します。

• ガバナンスと教育（長期安定化）

  • IaCの供給網ポリシー（プロバイダー/モジュールの取得元・検証方法・承認手続）を、アプリSBOMと同格の社内標準に昇格します。
  • IaC・SaaS・Dev端末を横断するゼロトラスト設計（ID境界、ネットワーク境界、アーティファクト境界）を、段階的にロードマップ化します。
  • 開発者向けに「.terraform.lock.hclの意味」「required_providersの厳格化」「モジュールの由来確認」を短時間で学べるハンズオンを提供し、日常運用に落とし込みます。

最後に一言。今回の事例は、攻撃者が「開発者の当たり前」を静かに乗っ取る設計に長けていることを示しています。華やかなゼロデイではなく、日常の自動化の裏側に潜るアプローチです。だからこそ、私たち防御側の「当たり前」を、少しだけ厳しく、少しだけ仕組み化していくことが効きます。今日の点検が、来月のインシデントを未然に消します。小さな改善を、いまから積み上げていきます。