2026年4月28日、Check Point ResearchはVECT2.0の暗号化に関する技術分析（CPR-2026-0428）を公開しました。その調査結果は明快です。VECTの暗号化は特定の方法で破られているということです。 128 KBを超えるファイルの場合、各ファイルチャンクに対して一意の暗号化キーを生成すべきプロセスが、代わりに単一の値を再利用しており、その最終的な値のみが保存される。その結果、大容量ファイルの最初の4分の3は永久に乱され、被害者による復元は不可能となる。VECT側でも復元は不可能である。
身代金を支払っても、大容量のファイルは復元されません。復号鍵は本物です。データの損失は、その鍵が関係してくる前にすでに発生しています。
その発見は、それ自体として重要な意味を持ちます。また、それは、これまでかなり注目されてこなかった、より構造的な問題の帰結でもあります。
ターゲットの選定方法
ほとんどのランサムウェア攻撃は、同じ標的選定の手順を踏んでいます。攻撃グループは組織を特定し、アクセス権を構築または購入した後、攻撃を実行します。標的の選定は、アクセス権が確立される前に行われます。特定のランサムウェアグループによる攻撃のリスクは、そのグループが貴社のような組織を標的にすることを決定したかどうかに左右されます。
VECTはこのような仕組みではありません。そのサプライチェーンパートナーであるTeamPCPも同様です。
2026年7月2日に公開されたFBIのIC3 FLASH-20260702-01は、特定の標的を絞るのではなく、規模の拡大を重視した攻撃キャンペーンについて記録している。2026年2月から3月にかけて、TeamPCPは、組織が開発やセキュリティスキャンに依存している、広く利用されている4つのオープンソースソフトウェアパッケージを改ざんした：
- コンテナのセキュリティ脆弱性をスキャンするためのツール「Trivy」について：TeamPCPは、コードリポジトリへの書き込み権限を持つ開発者の認証情報を盗み出し、その脆弱性（CVE-2026-33634）を悪用して、Trivyの自動ワークフローの77バージョンのうち76バージョンに悪意のあるコピーを上書きした。
- Checkmarx KICS、 インフラストラクチャのコードをスキャンして設定ミスを検出するツール：TeamPCPも同様に35のバージョンを上書きした。また、各被害組織独自の自動化用認証情報を利用して、
docs-tpcp被害者のGitHubアカウント内。 - LiteLLM v1.82.8、月間ダウンロード数が約9,500万回に上るソフトウェアライブラリ：TeamPCPは、
litellm_init.pthインストール先へ。以下の拡張子を持つファイルは.pthこの拡張機能は、実際にどのソフトウェアを実行しているかに関係なく、Pythonが起動するたびに自動的に読み込まれ、実行されます。これにより、TeamPCPは そのパッケージがインストールされていた任意のマシン上で、コードが継続的に実行される. - Telnyx Python SDK バージョン 4.87.1 および 4.87.2：3段階のリモートアクセストロイの木馬。これは、攻撃者が感染したマシンを密かに制御できるようにするソフトウェアを指す。
TeamPCPは、Shai-Huludworm背後にいるグループと同じであり、このワームは侵害されたパッケージを利用して、開発環境やCI/CDパイプラインを通じて自動的に拡散する。 2026年2月から3月にかけてTrivyおよびLiteLLMを標的としたキャンペーンでも、信頼されたパッケージ、自動実行、認証情報の収集という同じ基本メカニズムが使用されました。『Shai-Hulud Part 2』では、2026年5月のTanStackキャンペーンについて取り上げており、このキャンペーンworm さらにworm 、パッケージの検証チェックを通過するために有効な暗号署名証明書を生成していました。
その結果、ソフトウェアの構築、テスト、デプロイを行う自動化システムである1万以上のCI/CD（継続的インテグレーションおよびデプロイ）パイプラインから、50万件以上の認証情報が盗み出されました。AWS、Azure、GCPのトークン。Kubernetesのシークレット。コンテナレジストリの認証情報。GitHubおよびGitLabのアクセストークン。
TeamPCPは標的を選定したのではなく、パッケージを選定した。2026年3月までに、認証情報アーカイブが作成されていた。VECTはそのアーカイブを精査し、リストの中からランサムウェアの被害者を選定した。
ターゲットの選択は、アクセス後に行われ、その前ではなかった。
「我々は力を合わせ、これらの攻撃の被害を受けたすべての企業に対してランサムウェアを展開する準備ができており、それだけに留まるつもりはない。」
「我々は、こうした妥協を連鎖させ、壊滅的な影響をもたらす一連のランサムウェア攻撃を展開していく。」
ランサムウェアへの曝露に関して、この変更がもたらす影響
従来のランサムウェア対策の計画策定では、「攻撃者が当社の環境に侵入するには、どのような行動を取る必要があるか」という問いが投げかけられます。この問いは、攻撃者がまだ具体的な手段を決めていないことを前提としています。TeamPCPモデルによれば、その問いに対する答えは、数ヶ月前に、チームがすでに忘れてしまった開発パイプラインにおける日常的なパッケージのインストールによって、すでに導き出されていた可能性があるのです。
ソフォスのカウンター・スレット・ユニット（CTU）は、TeamPCPから流出した認証情報を使用したVECTの展開が少なくとも1件確認されたと発表しました。FBIは、盗まれた認証情報が「最初の侵害からかなり経った後も悪用されることになる」と警告しています。VECTによる攻撃のリスクは、同グループが貴社の業界を標的としているかどうかによって決まるわけではありません。そのアーカイブに貴社のクラウドトークンが含まれているかどうかによって決まるのです。
ログに表示されない理由
これがギャップ3です：動きが見えない。
について litellm_init.pth パーシステンスファイルは、対象となる環境においてPythonが起動するたびに自動的に実行されます。ソフトウェアパッケージマネージャーはインストールを記録します。CI/CDパイプラインは、既知のサービスアカウントに帰属するワークフローの実行を記録します。クラウドプロバイダーは、認識されたIDからの認証済みAPI呼び出しを記録します。 3件の監査ログ、3件のセキュリティオペレーションセンター（SOC）チケット、1件の情報漏洩。
侵害されたパッケージから本番クラウド環境に至る経路を示す単一のログは存在しません。その経緯を突き止めるには、インストール日時、ワークフローの実行、およびアウトバウンドAPI呼び出しを、影響を受けたパッケージバージョンのリストと照合する必要があります。しかし、ほとんどの組織はこのようなリストを管理しておらず、ほとんどのセキュリティ監視システムも自動的に照合を行っていません。2026年4月に発生したAnodot/Snowflakeのサプライチェーンインシデントでも、同様のログの断片化という問題が見られました。この事件では、SaaS統合プロバイダーから盗まれたトークンが複数の顧客環境で再利用され、各システムは自身の担当範囲内のアクティビティのみを検証していたものの、それらを結びつけるものは何もありませんでした。VECT/TeamPCPの事例では、SaaS統合層ではなくCI/CD層を通じて、同様のパターンが繰り返されています。
Checkmarx KICSベクターは、さらに別の層を追加します。TeamPCPは、被害者自身の自動化用認証情報を使用して、 docs-tpcp 被害者のGitHub組織内。リポジトリ作成イベントは、被害者のサービスアカウントに帰属するものとして、GitHubの監査ログに記録される。 一見、何もおかしいところはないように見えた。これがギャップ1だ。
業務内部における能力のギャップ
チェック・ポイントがVECT 2.0のコードを分析したところ、素人による開発の明らかな兆候が見られた。具体的には、記述されているものの実際には実行されないセキュリティ回避コード、自らを無効にしてしまう難読化レイヤー、柔軟に見えるが実際にはハードコードされている設定フラグ、そしてプログラム内に含まれる不完全な装飾テキストなどである。VECTが被害者のファイルを永久に破壊してしまう原因となる暗号化の欠陥も、同様のパターンに当てはまる。malware 素人のmalware 。
しかし、それを支えるインフラはそうではありません。VECTのアフィリエイトプログラムには、モネロ（プライバシー重視の暗号資産）のエスクロー口座、BreachForumsとの連携、段階的な手数料体系、そして身代金交渉を担当する専任の交渉担当者が含まれています。 2026年4月16日に正式に導入されたBreachForumsの「大規模アフィリエイト」モデルにより、オペレーターは独自のインフラを構築することなく、このインフラを利用できるようになります。TeamPCPの認証情報アーカイブは、技術的な攻撃スキルの代わりとなります。つまり、標的の防御システムに脆弱性がなくても、そのクラウドトークンをすでに保有していれば攻撃が可能になるのです。
これは防衛計画において重要な点です。正常に動作しているエンドポイントセキュリティソフトウェアであれば、malware検知します。ソフトウェアのサプライチェーンや自動化されたパイプラインを経由して配信されても、検知機能は作動しません。検知機能が機能していないわけではありません。不完全なだけなのです。
今確認すべきこと
2026年4月以前に、お使いの環境でこれらのパッケージのいずれかが実行されていた場合は、その事実が確認できるまで、パイプラインのクラウド認証情報を漏洩したとみなしてください：
- LiteLLM、具体的にはv1.82.8。また、以下も検索してください。
litellm_init.pth2026年2月および3月にLiteLLMを実行したすべてのマシンのPythonインストールディレクトリ内。 - Trivy GitHub Action。その期間中に 0.76.x または 0.77.x のタグに固定されたすべてのバージョン。
- Checkmarx KICS GitHub Action、影響を受ける 35 のタグのいずれか。
- Telnyx Python SDK 4.87.1 または 4.87.2。
GitHub 組織のリポジトリ一覧から、以下を検索してください docs-tpcp. これが存在するということは、TeamPCPがユーザーの自動化用認証情報を使用してこれを作成したことを意味します。影響を受ける環境において、2026年4月以前に発行されたクラウド認証情報（AWS、Azure、GCPのサービスアカウント、コンテナレジストリトークン、GitHubおよびGitLabのアクセストークン）を更新してください。2026年2月から4月にかけて、パイプラインのサービスアカウントから本番環境へのAPI呼び出しについて、AWS CloudTrail、Azure Monitor、およびGCP Cloud Audit Logsを確認してください。特に、既知のデプロイより前の日付の呼び出しに注意してください。
『Mind Your Attack Gaps』の「ギャップ3」の章 『Mind Your Attack Gaps』 の「ギャップ3」の章では、ハイブリッドクラウドにおける侵害事例が取り上げられており、そこでは別の攻撃チェーンにおいても同様のログの断片化という問題が横断的に発生しています。Vectra AIでは、3つの別々の監査システム間の相関関係に依存することなく、ID、クラウド、SaaSを横断する環境間の移動をモデル化しています。TeamPCP/VECTキャンペーンは、単一環境の可視化だけではこの種の攻撃をカバーできない理由を如実に示す好例です。
認証情報のアーカイブは存在します。2026年4月以前にパイプラインで影響を受けるパッケージを実行していた場合、今問うべきは「標的になる可能性があるか」ではなく、「トークンがすでにそこに記録されているか」ということです。