【注意事項】

⚠ 本ブログに記載のコマンドや確認手順は、読者自身の環境における影響確認を支援する目的で提供している。組織の環境で実行する場合は、必ずシステム管理者またはセキュリティ管理者の許可を得ること。すべての操作は自己の責任において実施されたい。

【2026年3月31日 19:00 JST 更新】 以下の情報を追記・更新

- axios npm パッケージのサプライチェーン攻撃情報を追加（3/31発生、影響バージョン: 1.14.1 / 0.30.4）。チェックリスト、タイムライン、影響バージョン一覧（セクション2.7新設）、確認方法（セクション3.6新設）、C2/IoC情報を追加
- 同一マルウェアを配布する追加パッケージ（@shadanai/openclaw、@qqbrowser/openclaw-qbot）の情報を追加
- axios攻撃のC2（sfrclak[.]com:8000 / 142.11.206.73）をセクション4.1に追加
- セクション6にaxios攻撃のTeamPCP帰属に関する注記を追加

【2026年3月31日 07:00 JST 更新】 以下の情報を追記・更新

- 【注意事項】を追加
- Telnyx Python SDK（PyPI）の侵害情報を追加（3/27発生、影響バージョン: 4.87.1 / 4.87.2）。チェックリスト、タイムライン、影響バージョン一覧、確認方法（セクション3.5新設）を追加
- CVE-2026-33634 が CISA KEVカタログに登録（3/26登録、是正期限: 4/09）。セクション2.6のステータスを更新
- CVE-2026-28353（第1波・VSCode拡張機能の侵害）の情報をセクション2.6に追加
- Telnyx攻撃のC2（83.142.209.203:8080）をセクション4.1に追加
- Checkmarx GitHub Actionsの安全なバージョンを更新（kics: v2.1.20以上、ast: v2.3.33以上）
- セクション4.3にオーガニゼーションレベルでのSHAピンニング強制とpinactの使用方法を追加

本記事の情報は 2026年3月25日 06:00 JST（3月24日 21:00 UTC）時点のものである。
本インシデントは現在も進行中であり、今後新たな情報が判明する可能性がある。
最新の一次情報は Aqua Security公式ブログ および GitHub Discussion #10425 を参照されたい。本ブログの執筆にあたり参照したセキュリティ企業の分析レポート・ニュース記事へのリンクは、本記事末尾のセクション7（参考リンク）にまとめている。
3/22公開の第2レポートはこちらから確認できる。

まず確認すべきこと

2026年3月19日以降に、以下のいずれかを使用していないか？

• [ ] GitHub Actions で aquasecurity/trivy-action をタグ参照で使用した

• [ ] GitHub Actions で aquasecurity/setup-trivy をタグ参照で使用した

• [ ] Docker Hub から aquasec/trivy の v0.69.4, v0.69.5, v0.69.6, または latest タグを pull した

• [ ] Trivy バイナリ v0.69.4 を GitHub Releases からダウンロードした

• [ ] GitHub Actions で Checkmarx/kics-github-action をタグ参照で使用した

• [ ] GitHub Actions で Checkmarx/ast-github-action をタグ参照で使用した

• [ ] Open VSX から cx-dev-assist v1.7.0 または ast-results v2.53.0 をインストールした

• [ ] npm パッケージ @emilgroup/*, @opengov/*, @teale.io/eslint-config などの CanisterWorm 影響パッケージを使用した

• [ ] PyPI から litellm v1.82.7 または v1.82.8 をインストールした

• [ ] PyPI から telnyx v4.87.1 または v4.87.2 をインストールした

• [ ] npm パッケージ axios v1.14.1 または v0.30.4 をインストールした

1つでも該当する場合は、本記事のセクション3（確認方法）とセクション4（対応アクション）を直ちに参照してください。

1. 第2レポート以降の主要イベント

第2レポート（3月22日 14:00 UTC時点）以降も、攻撃者は活動を止めず、Trivy以外のエコシステムにも攻撃範囲を拡大した。以下の時系列は、各セキュリティ企業および公式ソースの公開情報に基づき構成したものである。二次情報の集約であるため、時刻や詳細に誤りが含まれる可能性がある。詳細な影響調査を行う場合は、必ず各行の「情報源」欄に記載された一次ソースを参照されたい。全て UTC で記載する。

影響を受けたバージョン・Exposure Windowの詳細はセクション2を参照。

2. 影響を受けた対象とバージョンの一覧

2.1 GitHub Actions

出典: trivy-action/setup-trivyについては GHSA-69fq-xp46-6x23 および Aqua Security公式ブログ。KICS/astについては Wiz、Sysdig、Checkmarx Security Update。

2.2 Trivyバイナリ/コンテナイメージ

注意: Docker Hub上のv0.69.4は3/19 22:20 UTCに一度削除されたが、latest タグは3/20 03:26 UTCに攻撃者が再び悪意あるコンテンツに紐付けた（Docker公式ブログ）。v0.69.5, v0.69.6は3/22に対応するGitHub Releaseなしで直接プッシュされたものである。

出典: Docker公式ブログ、GHSA-69fq-xp46-6x23。

2.3 npm パッケージ（CanisterWorm）

CanisterWormは、窃取したnpmトークンを使って被害者が管理する他のパッケージにも自動的にマルウェアを拡散する「自己増殖型ワーム」である。ICP（Internet Computer Protocol）ブロックチェーン上のCanisterをC2として利用する点が特徴的である。

出典: Socket（141アーティファクト）、JFrog（追加検出あり）、The Hacker News。パッケージリストは Socket追跡ページ で確認可能。

2.4 PyPI パッケージ

注意: LiteLLMは1日あたり約340万回ダウンロードされるパッケージであり、約3時間の曝露でも影響範囲は大きい（Snyk）

出典: Endor Labs、Snyk、FutureSearch（発見者）

注意: Telnyx Python SDKは月間70万以上ダウンロードのパッケージである。LiteLLM侵害（3/24）で窃取されたPyPIトークンを使用してアップロードされた疑いがある。技術詳細はセクション3を参照

出典: Telnyx Security Notice、Endor Labs、SafeDep

2.5 VS Code拡張（Open VSX）

出典: Wiz、Checkmarx Security Update。安全なバージョンはCheckmarx公式で確認。

2.6 CVE情報

※ CVSS v3.0: 9.8はTenableによる評価である。CNA（GitHub）はCVSS v4.0スコアのみを提供しており、NVDは3月25日06:00（JST）時点で「Awaiting Analysis」ステータスのままスコアを割り当てていない。

出典: Tenable、GHSA-69fq-xp46-6x23。CISA KEVカタログは3月25日06:00（JST）時点でCVE-2026-33634を含んでいない（CISA KEV）

CVE-2026-28353 は第1波攻撃（2/27~2/28）におけるTrivy VSCode拡張機能（Open VSX版 v1.8.12）の侵害に対して割り当てられたCVEである。

出典: GHSA-8mr6-gf9x-j8qg、CVETodo

2.7 npm パッケージ（axios）

注意: axiosはクラウド環境の約80%に存在するnpmの最も広く利用されるパッケージの一つである（Wiz, StepSecurity）。短時間の曝露にもかかわらず、影響を受けた環境の一部で実行が観測されている（Wiz）,（StepSecurity）。

悪意ある依存パッケージ: plain-crypto-js@4.2.1 — axiosソースコード内では一切import/requireされない「ファントム依存」であり、postinstall フックでRATドロッパー（setup.js）を実行することのみを目的とする。正規の crypto-js パッケージを偽装し、同一の説明文・著者名・リポジトリURLを使用している（StepSecurity, Socket）。

RATドロッパーはOS検出後にプラットフォーム固有のペイロードをC2（sfrclak[.]com:8000）からダウンロードし、実行後に setup.js を自己削除、package.json をクリーンなスタブに差し替えることで痕跡を消去する。事後の node_modules 検査では検知困難であるため、lockfileの確認が必須である。

同一マルウェアを配布する追加パッケージ: Socketは以下のパッケージがaxios攻撃と同一の plain-crypto-js マルウェアを配布していることを確認している（Socket）:

- @shadanai/openclaw（バージョン: 2026.3.28-2, 2026.3.28-3, 2026.3.31-1, 2026.3.31-2）（Socket, Wiz）
- @qqbrowser/openclaw-qbot@0.0.130 — 改ざんされた axios@1.14.1 を node_modules/ 内にバンドルし、plain-crypto-js を依存として注入

アドバイザリ: GHSA-fw8c-xr5c-95f9, MAL-2026-2306, SNYK-JS-AXIOS-15850650

出典: StepSecurity, Socket, Wiz, Aikido Security, The Hacker News, Snyk, Mend.io

axios攻撃のIoC（侵害指標）

以下のハッシュは Wiz が公開したIoCである。

出典: Wiz。追加パッケージ（@shadanai/openclaw, @qqbrowser/openclaw-qbot）の情報は Socket および Wiz による

3. 影響を受けたかどうかの確認方法

3.1 GitHub Actions（trivy-action / setup-trivy / kics-github-action / ast-github-action）

Step 1: ワークフローファイルの確認

リポジトリ内の .github/workflows/ ディレクトリで、以下のActionをタグ参照で使用していないか確認する。

    # リポジトリのルートで実行
grep -rn "aquasecurity/trivy-action@" .github/workflows/
grep -rn "aquasecurity/setup-trivy@" .github/workflows/
grep -rn "Checkmarx/kics-github-action@" .github/workflows/
grep -rn "Checkmarx/ast-github-action@" .github/workflows/

SHAピンニング（例: @abcdef1234567890...）ではなくタグ参照（例: @latest, @0.69.4, @v2.1.7）を使っている場合は影響の可能性がある。

Step 2: Exposure Window中の実行確認

ワークフローがExposure Window中に実行されたかどうかを確認する。

    # trivy-action: 3/19 17:43 – 3/20 05:40 UTC
gh run list --workflow=<ワークフロー名>.yml \
  --created "2026-03-19T17:43:00Z..2026-03-20T05:40:00Z" \
  --json createdAt,status,conclusion

# kics-github-action: 3/23 12:58 – 16:50 UTC
gh run list --workflow=<ワークフロー名>.yml \
  --created "2026-03-23T12:58:00Z..2026-03-23T16:50:00Z" \
  --json createdAt,status,conclusion

Step 3: 窃取データリポジトリの確認

攻撃のフォールバック窃取メカニズムが発動していた場合、GitHub組織内に tpcp-docs または docs-tpcp という名前のリポジトリが作成されている可能性がある。

    # GitHub CLIで確認
gh repo list <org名> --json name | grep -i "tpcp"

出典: CrowdStrike、Wiz。

3.2 Docker Hub（aquasec/trivy）

    # ローカルに存在するTrivyイメージのバージョン確認
docker images | grep -i trivy

# イメージのダイジェストを悪意あるダイジェストと照合
docker image inspect aquasec/trivy:<tag> --format ''

以下のダイジェストに一致する場合は侵害されている（GHSA-69fq-xp46-6x23）:

3.3 npm パッケージ（CanisterWorm）

    # node_modules 内の感染痕跡確認
find node_modules -name "deploy.js" -path "*/scripts/*" 2>/dev/null

# CanisterWormの永続化サービス確認（Linuxのみ）
ls -la ~/.local/share/pgmon/service.py 2>/dev/null
systemctl --user status pgmon.service 2>/dev/null

影響パッケージのリストは Socket追跡ページ で確認できる。

3.4 PyPI パッケージ（LiteLLM）

やってはいけない確認方法

⚠ 重要な注意: LiteLLM v1.82.8 には litellm_init.pth ファイルが含まれている。Pythonの .pth ファイルは Pythonインタープリターが起動するだけで自動実行 される（Snyk）。これは以下を意味する:

- pip show litellm を実行する → pip自体がPythonプロセスを起動 → .pthが発火する
- python -c "import litellm" → 同様に発火する
- IDEのPython言語サーバーが起動 → 同様に発火する

.pth ファイルによる任意コード実行の廃止は CPython Issue #78125 で 2018年から提案されているが、代替メカニズムの設計が未完了であり、任意コード実行機能は現在も有効のままである。なお、隠し .pth ファイルのスキップについては Issue #113659 で起票され、2024年2月にPython 3.12.2で修正済みであるが、これは本件の攻撃手法（非隠しファイルとしての .pth の悪用）とは無関係である。

安全な確認方法

Pythonを起動せず、ファイルシステムを直接確認する:

    # litellmパッケージの存在確認
find /path/to/venv/lib -type d -name "litellm" 2>/dev/null

# 悪意ある.pthファイルの存在確認
find /path/to/venv/lib -name "litellm_init.pth" 2>/dev/null

# バージョン確認（METADATAファイルをgrepで読む — Pythonを起動しない）
grep "^Version:" /path/to/venv/lib/python*/site-packages/litellm-*.dist-info/METADATA

# uvキャッシュの確認
find ~/.cache/uv -name "litellm_init.pth" 2>/dev/null

# 永続化痕跡の確認
ls -la ~/.config/sysmon/sysmon.py 2>/dev/null
ls -la ~/.config/systemd/user/sysmon.service 2>/dev/null
ls -la /tmp/pglog /tmp/.pg_state 2>/dev/null

v1.82.7 または v1.82.8 を動かしていた場合には、その環境を侵害済みとして扱うべきである。

出典: Endor Labs、Snyk

3.5 PyPI パッケージ（Telnyx）

やってはいけない確認方法

⚠ 重要な注意: Telnyx v4.87.1 / v4.87.2 は telnyx/_client.py に悪意あるコードが埋め込まれている。モジュールスコープで setup()（Windows攻撃パス）と FetchAudio()（Linux/macOS攻撃パス）が呼び出されるため、import telnyx の時点でペイロードが実行される。以下の操作は危険である:

- python -c "import telnyx" → ペイロードが発火する

v4.87.1 には攻撃者のタイポ（Setup() vs setup() の大文字/小文字不一致）が含まれている。SafeDepおよびEndor Labsのコードレベル分析によれば、この呼び出しはモジュールスコープで例外処理なしに実行されるため、NameError により FetchAudio() に到達する前にモジュール読み込みが中断され、いずれの攻撃パスも実行されない。一方、一部のブログではv4.87.1のLinux攻撃パスは機能したと報告している。v4.87.2 ではこのタイポが修正され、両攻撃パスが確実に発火する。

いずれのバージョンも悪意あるコードが含まれていることに変わりはなく、侵害済みとして扱うべきである。

LiteLLM（v1.82.8）の .pth ファイルとは異なり、Telnyxの攻撃コードはモジュール本体（_client.py）に直接埋め込まれているため、Pythonインタープリターの起動だけでは発火しないが、import telnyx を伴う操作で発火する。

安全な確認方法

Pythonを起動せず、ファイルシステムを直接確認する:

    # telnyxパッケージの存在確認
find /path/to/venv/lib -type d -name "telnyx" 2>/dev/null
# バージョン確認（METADATAファイルをgrepで読む — Pythonを起動しない）
grep "^Version:" /path/to/venv/lib/python*/site-packages/telnyx-*.dist-info/METADATA
# requirements/lockファイルでの確認
grep -r "telnyx==4.87.1\|telnyx==4.87.2" requirements*.txt Pipfile* pyproject.toml poetry.lock 2>/dev/null

感染痕跡の確認（Telnyx固有のIOC）

Telnyx攻撃はWAVオーディオステガノグラフィを使用してペイロードを配信する。C2サーバー 83.142.209.203:8080 から .wav ファイルをダウンロードし、オーディオフレームデータからXOR復号で実行ファイルを抽出する。

    # Windows: 永続化バイナリの確認（msbuild.exe に偽装）
dir "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe" 2>nul
# 再ドロップ防止用のロックファイル（attrib +h で隠しファイル化、12時間のクールダウン）
dir /ah "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe.lock" 2>nul
# ネットワークログでのC2通信痕跡確認（プロキシログ、ファイアウォールログを確認する）
# WAVファイルのダウンロード: hxxp://83.142.209.203:8080/ringtone.wav（Linux/macOS向け）
# WAVファイルのダウンロード: hxxp://83.142.209.203:8080/hangup.wav（Windows向け）
# 窃取データの送信: HTTP POST to hxxp://83.142.209.203:8080/（ヘッダー X-Filename: tpcp.tar.gz）
grep -r "83.142.209.203" /var/log/ 2>/dev/null

v4.87.1 または v4.87.2 をインストールしていた場合には、その環境を侵害済みとして扱うべきである。

出典: Telnyx Security Notice、SafeDep、Endor Labs、Socket.dev、Trend Micro

3.6 npm パッケージ（axios）

注意点

⚠ 重要な注意: axios v1.14.1 / v0.30.4 自体には悪意あるコードは含まれていないが、依存パッケージ plain-crypto-js@4.2.1 の postinstall フックが npm install 時に自動実行される。マルウェアは実行後に自己削除し、package.json をクリーンなスタブに差し替えるため、事後に node_modules/plain-crypto-js/ を検査しても、setup.js は既に削除されている可能性が高い。ただし、ディレクトリ自体の存在は侵害の証拠となる（正規のaxiosバージョンには plain-crypto-js は依存に含まれないため）

確認方法

Step 1: lockfileで悪意あるバージョンの確認

    # package-lock.json での確認
grep -A1 '"axios"' package-lock.json | grep -E "1\.14\.1|0\.30\.4"

# npm list での確認
npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"

# yarn.lock での確認
grep -A1 "axios@" yarn.lock | grep -E "1\.14\.1|0\.30\.4"

Step 2: plain-crypto-jsの存在確認

plain-crypto-js は正規のaxiosリリースには含まれない依存パッケージである。このディレクトリが存在すれば、悪意あるバージョンがインストールされた証拠となる。

    # node_modules 内の plain-crypto-js の存在確認
ls -la node_modules/plain-crypto-js/ 2>/dev/null

# プロジェクト全体での検索
find . -path "*/plain-crypto-js" -type d 2>/dev/null

Step 3: ファイルシステム上のペイロード痕跡確認

    # macOS: Apple正規プロセスに偽装したRATバイナリ
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null
# Linux: Python RAT
ls -la /tmp/ld.py 2>/dev/null
# Windows: PowerShellのコピーとスクリプト
dir "%PROGRAMDATA%\wt.exe" 2>nul
dir "%TEMP%\6202033.vbs" 2>nul
dir "%TEMP%\6202033.ps1" 2>nul

Step 4: ネットワークログでのC2通信痕跡確認

    # C2ドメイン/IPへの通信確認
grep -r "sfrclak\.com" /var/log/ 2>/dev/null
grep -r "142.11.206.73" /var/log/ 2>/dev/null

# User-Agent文字列による検知（ネットワークログ/プロキシログ）
# RATは以下の偽装User-Agentを使用する:
# mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)

Step 5: CI/CDパイプラインの確認

npm install を実行したCI/CDパイプラインも確認対象である。パイプラインが axios@1.14.1 または axios@0.30.4 をインストールした場合、注入された全シークレットのローテーションが必要である（StepSecurity）。

v1.14.1 または v0.30.4 をインストールしていた場合には、その環境を侵害済みとして扱うべきである。

出典: StepSecurity, Aikido Security, Wiz, Socket

4. 対応アクション

4.1 即時対応（Exposure Windowに該当する場合）

1. 影響を受けたアーティファクトの即時削除: 悪意あるバージョンのバイナリ、コンテナイメージ、パッケージを全て削除する
2. 全シークレットのローテーション: 該当するCIパイプライン・ランナーがアクセス可能だった全てのシークレットを侵害済みとして扱い、即時ローテーションする。対象には以下が含まれる:
   • クラウドプロバイダー認証情報（AWS, GCP, Azure）
   • GitHub PAT / GITHUB_TOKEN
   • SSH鍵
   • Kubernetes トークン / kubeconfig
   • Docker Hub / レジストリ認証情報
   • データベース認証情報
   • APIキー（Slack Webhook, Discord等を含む）
3. ワークフローの固定: GitHub Actionsのバージョン指定をタグからSHAピンニングに変更する
4. ネットワークログとインフラの確認: 以下のC2ドメイン/IPへの通信がないか確認する。加えて、kube-system namespace内に攻撃者のDaemonSetに対応するPodが作成されていないか確認する。LiteLLMバリアントでは node-setup-*、元のTrivy/KICSバリアントでは host-provisioner-std（標準版）および host-provisioner-iran（ワイパー版）の名前が使用される（ramimac）

C2ドメイン/IP一覧:

Kubernetes確認コマンド:

    kubectl get pods -n kube-system | grep -E "node-setup|host-provisioner"

4.2 安全なバージョンへの移行

出典: GHSA-69fq-xp46-6x23、Aqua Security公式ブログ、Checkmarx Security Update。

4.3 GitHub Actionsのピンニング

Gitタグはforce-push可能であり、今回の攻撃はまさにその仕組みを悪用したものである。タグ参照を廃止し、イミュータブルなコミットSHAで固定すべきである。

    # ❌ タグ参照（force-pushにより、悪意あるコミットを指すリスクがある）
- uses: aquasecurity/trivy-action@latest
- uses: aquasecurity/trivy-action@0.34.2

# ✅ SHA固定（イミュータブル、変更不可）
- uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1  # v0.35.0

上記のSHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 は、今回の攻撃で唯一改ざんされなかったv0.35.0の安全なコミットである（ramimac）。GitHubのImmutable Releases機能によって保護されていた。

加えて、CI/CDランナーからの想定外のアウトバウンド通信を検知する仕組み（Egress制御）を導入することも有効である。今回の攻撃では、ペイロードがC2ドメインへのHTTPS POSTで窃取データを送信していた。Egress Policyを設定し、許可リスト外のドメインへの通信をブロックしていれば、窃取を阻止できた可能性がある。

オーガニゼーションレベルでのSHAピンニング強制

GitHubはオーガニゼーション・エンタープライズ・リポジトリの各レベルで、全Actionsに対してフルコミットSHAでのピンニングを強制するポリシーを提供している。Settings → Actions → General の「Policies」セクションで「Require actions to be pinned to a full-length commit SHA」を有効にすると、SHAピンニングされていないActionを参照するワークフローは実行時にブロックされる。

• オーガニゼーションレベルの設定: GitHub Docs — Disabling or limiting GitHub Actions for your organization
• エンタープライズレベルの設定: GitHub Docs — Enforcing policies for GitHub Actions in your enterprise
• リポジトリレベルの設定: GitHub Docs — Managing GitHub Actions settings for a repository

ピンニング支援ツール: pinact

既存のワークフローを手作業で書き換えるのは現実的ではない。pinact を使用すると、ワークフロー内のタグ参照をフルコミットSHAに一括変換できる。

インストール:

⚠ 以下のコマンドを実行する前に、必ず組織のセキュリティ管理者またはインフラ管理者の許可を得ること。外部バイナリの導入はセキュリティポリシーに抵触する場合がある。

    # macOS (Homebrew)
brew install suzuki-shunsuke/pinact/pinact
# https://github.com/suzuki-shunsuke/pinact/releases で最新版を確認
Invoke-WebRequest -Uri "https://github.com/suzuki-shunsuke/pinact/releases/latest/download/pinact_windows_amd64.zip" -OutFile pinact.zip
Expand-Archive pinact.zip -DestinationPath C:\pinact
# C:\pinact を PATH に追加する
# https://github.com/suzuki-shunsuke/pinact/releases で最新版を確認
curl -sSfL "https://github.com/suzuki-shunsuke/pinact/releases/latest/download/pinact_linux_amd64.tar.gz" | tar xz -C /usr/local/bin pinact

その他のインストール方法や、GitHub Releasesからのバイナリ直接ダウンロードについては INSTALL.md を参照。

実行（リポジトリのルートで）:

    # ドライラン（差分確認のみ、ファイルは変更しない）
pinact run --diff

# 実際にファイルを書き換える
pinact run

Before（タグ参照 — force-pushで改ざん可能）:

    steps:
  - uses: actions/checkout@v4
  - uses: aquasecurity/trivy-action@0.34.2

After（pinact実行後 — SHAピンニング、元のバージョンはコメントで保持）:

    steps:
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
  - uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1 # v0.35.0

pinactはタグと同一SHAを持つsemverバージョンを自動解決する（例: v4 → v4.2.2）。semverではないブランチ参照（main 等）は安全のためスキップされる。

出典: pinact、GitHub Docs — Security hardening for GitHub Actions

5. クレデンシャルローテーションに関する警告

本インシデントは、クレデンシャルローテーションの手順に不備があれば、ローテーションの効果が大幅に減殺されることを示した。対応にあたるユーザは、自組織のローテーションにおいても同様の問題が生じないよう留意する必要がある。

5.1 対応するユーザへの警告

今回のインシデントでExposure Windowに該当し、シークレットのローテーションを実施する場合は、以下の4点を満たさなければローテーションの効果が失われるリスクがある。

1. 全クレデンシャルの棚卸し

まず「何が存在するか」を把握する。見落とされやすいものとして以下がある:

• GitHub PAT（複数アカウント、組織間ブリッジ用ボットを含む）
• Docker Hub / コンテナレジストリの認証情報
• npm / PyPI の公開トークン
• GPG署名鍵
• CI/CDプラットフォームのサービスアカウント
• Slack / Twitter / Discord のBot Token
• SSH鍵
• クラウドプロバイダーのIAMクレデンシャル

2. アトミックな無効化と再発行

逐次的なローテーション（1つずつ無効化→再発行）では、新旧のクレデンシャルが共存する時間帯が生まれる。CVE-2026-33634の公式説明が示すとおり、全てのクレデンシャルを同時に無効化し、その後に新しいクレデンシャルを発行すべきである。

3. ローテーション前の環境クリーン化

侵害されたサーバー、ランナー、開発端末の上で新しいクレデンシャルを発行すれば、攻撃者はそのクレデンシャルを窃取できる。本攻撃のペイロードは、プロセスメモリの読み取り（/proc/<pid>/mem）、ファイルシステムの走査、環境変数の収集を行っていた。ローテーション前に、まず環境をクリーンな状態に復元するか、新しい環境を構築してからローテーションを実施すべきである。

4. ローテーション後の検証

ローテーションが完了した後、旧クレデンシャルが確実に無効化されていることを検証する。具体的には:

• 旧トークンを使用したAPI呼び出しが 401 Unauthorized を返すことの確認
• 旧SSH鍵による接続が拒否されることの確認
• CI/CDパイプラインが新しいクレデンシャルで正常に動作することの確認
• 監査ログで旧クレデンシャルの使用が検出された場合のアラート設定

6. 攻撃者に関する情報

3月25日06:00（JST）時点で、本攻撃の実行者は調査継続中である。MandiantもCyberScoopの取材において攻撃者の正式な名称付けを行っていない（"The attackers, which the incident response firm has yet to name"）。

一方、攻撃ペイロードに自己署名文字列「TeamPCP Cloud stealer」が埋め込まれていることから、複数のセキュリティ企業（Wiz、Endor Labs、Sysdig、Cyble）はTeamPCPとして追跡している。ただし、Socketは「自己ラベルは偽旗の可能性もあるが、過去のTeamPCPツールとの技術的重複から、真正な帰属が妥当である」と指摘しており、帰属は確定的ではなく「高い確信度」での評価である点に留意する必要がある。

Mandiantによれば、本攻撃の背後にいるグループは主に米国、カナダ、英国に拠点を置く複数の脅威グループと連携しており、「非常に積極的な恐喝」で知られるとのことである。

【3/31 更新】 3/25以降、以下の動きが報告されている。

- TeamPCPがランサムウェアグループ「Vect」と提携し、窃取クレデンシャルを用いた恐喝活動を開始したとされる（Socket、SANS ISC）
- TeamPCPが独自のランサムウェア「CipherForce」を運用しているとの報告がある（SANS ISC Update 004）
- LAPSUS$がTeamPCP由来のクレデンシャルを用いたとされるAstraZenecaの侵害を主張している（SANS ISC Update 004、Hackread）

本ブログは影響確認を目的としているため、攻撃者の詳細な分析については上記の各ソースを参照されたい。

【3/31 19:00 更新】 axios npm パッケージのサプライチェーン攻撃（3/31発生）について、Socketは「この活動を最近報告されたTeamPCPキャンペーンに結びつける証拠は観測していない（we have not observed any evidence linking this activity to the recently reported TeamPCP campaigns）」と明記しており、Wizも「未知の脅威アクター（unknown threat actor）」と記載している。攻撃者のProtonMailの使用パターン（ifstap@proton.me, nrwise@proton.me）はTeamPCPの過去の手法と一致するが、帰属は現時点で確定していない。axios攻撃の詳細はセクション2.7および3.6を参照。

7. 参考リンク

一次情報

セキュリティ企業分析レポート

タイムライン・IOC・脅威アクタープロファイル

ニュースサイト

3/31更新で追加した参考リンク

3/31 19:00更新で追加した参考リンク

本記事は今後の情報に基づき更新される可能性がある。最新情報は本ブログおよび上記の公式ソースを参照されたい。

執筆者プロフィール

フューチャー株式会社

Cyber Security Innovation Group　エンジニア

棚井龍之介（たない りゅうのすけ）

役割

セキュリティ領域を専門とするエンジニア（クラウドインフラ領域、バックエンド開発 ）として業務に従事。同社が展開する脆弱性管理ツール「FutureVuls」に深く携わっており、OSSの脆弱性スキャナ（TrivyやVuls）のエンジン検証、SBOMの取り込み、サプライチェーン攻撃の調査・安全性の検証レポートなどを担当。

略歴

フューチャー株式会社の公式技術ブログ「Future Tech Blog」や「FutureVuls Blog」で継続的に技術発信を行っており、クラウドインフラからサイバーセキュリティまで幅広い技術領域で活躍。

• サイバーセキュリティ: 脆弱性管理（CPE名の検索最適化など）、サプライチェーンセキュリティの監視、セキュリティ製品の実装・運用

• クラウド・インフラストラクチャ: AWS（DynamoDB等のサーバレス技術）、Terraformを用いたInfrastructure as Code（IaC）の推進、LocalStackを利用したローカルテスト環境の構築。

• 業務自動化とプログラミング: 主な使用言語はGo言語やRuby。GAS（Google Apps Script）やSlack Botを利用した業務効率化、Seleniumを利用したUI操作の自動化。

棚井龍之介の他の記事を見る