GitHubアカウント乗っ取り：wfx-lootの手口

GitHubのwfx-loot攻撃とは何か

wfx-lootは、攻撃者が盗んだGitHubの認証情報を使い、そのアカウントが書き込めるリポジトリに悪意のあるワークフローを送り込み、GitHub Actionsのシークレットとクラウドの認証情報を盗む攻撃です^[1]。最初に報告したAikido Securityは、攻撃者自身によるマルウェアの呼び名(「wfx」)と、盗んだシークレットに使われている言葉(「loot」)にちなんで名付けました^[1]。SafeDepも、最初の報告はAikidoによるものとしています^[5]。

StepSecurityは同じスティーラーを「wfx」と呼び、重要な点を強調しています。攻撃者はGitHub Actionsのバグを突いているわけではありません^[2]。実在する開発者やボットのアカウントの有効なトークンを使い、開発者のようにプルリクエストを開き、コミットをプッシュしています^[2][4]。

Aikidoは、主な目的はソフトウェアパッケージを通じた拡散ではなくCIのシークレットだとみています。ただし、自動公開のトリガーを通じて、少なくとも1つのPackagistパッケージと1つのGoパッケージにペイロードが入り込みました^[1]。BleepingComputerはAikidoの分析に基づき、乗っ取られたアカウントの一部は大規模な組織のものだったと伝えています^[3]。

wfx-loot攻撃の規模はどれほどか

Aikidoは、乗っ取られた4,837のアカウントが61,764のリポジトリで探りのプルリクエストを出し、スティーラーは少なくとも1,806のリポジトリで実行されたと数えています^[1]。調査者ごとに数字がわずかに異なるのは、攻撃が続いているあいだに、それぞれ別の時点でGitHubを検索したためです。

• Aikido:4,837のアカウント、61,764のリポジトリ。10,431件のプルリクエストが、そのアカウントが所有していないリポジトリに出されました。92%がまだオープンのままです。乗っ取られたユーザーのうち少なくとも50人が、npm、Go、Packagist、PyPI、cratesにパッケージを公開しています^[1]。
• Aikido(要約の数字):少なくとも1,835のリポジトリでペイロードが実行され、認証情報が奪われました。BleepingComputerはこの数字を使っています^[1][3]。
• StepSecurity:11月12日の07:40 UTC時点で、探りのプルリクエストは63,000件超、約90%がまだオープンです^[2]。
• SafeDep:11月10日から12日の間に、8,093のリポジトリが悪意のあるコミットを受けました。SecurityWeekが指摘するように、この数字はスティーラーが実行されたことを必ずしも意味しません^[5][4]。

Aikidoは、影響を受けたリポジトリでは実行ログが削除されていたため、実行の件数は被害を過小評価している可能性があると警告しています^[1]。

wfx-lootのスティーラーはどのように動くのか

盗まれたトークンで書き込めるリポジトリごとに、攻撃者は探りを入れ、ペイロードをプッシュし、約1分以内に後始末をします^[1]。

1. 探り:wfx-docsという名前のブランチから、「docs: dependency audit notes」というタイトルのプルリクエストが出され、ごく小さなメモファイルが追加されます。StepSecurityは「このプルリクエスト自体は何もしません」と述べており、トークンに書き込み権限があることを示すだけです^[2][4]。
2. ペイロード:約1,500行のシェルスクリプトが、次の3通りのいずれかで届きます。既存のワークフローへの注入(「ci: refresh build cache」)、スクリプトとnpmのpostinstallフックの組み合わせ(「chore: add ci helper」)、使い捨てのchore/ブランチ上の新しいワークフロー(「chore: add dependency audit workflow」)です^[1]。
3. 後始末:攻撃者は変更を元に戻し、ワークフローの実行とそのログを削除します^[1]。実行番号の欠落が唯一の痕跡であることも少なくありません^[1]。

スクリプトは、GitHub Actionsのシークレットとトークン、ランナーの環境全体、AWS、Azure、Google Cloud、Docker、Kubernetes、npm、PyPI、SSHなどの認証情報ファイル、シェルの履歴、AIプロバイダーや開発者ツールのキーを収集します^[1][3]。ランナー上で動作中のプロセスのメモリまで読み取ります^[1][4]。Aikidoは、分析したコピーが盗んだデータを攻撃者の管理するサーバーへのHTTP POSTだけで送っていたことを確認しました^[1]。StepSecurityはその後、変化を確認しています。11月12日の05:30 UTC頃から、新しいコピーはTelegramだけを通じてデータを送るようになり、公開されたサーバーアドレスをブロックするだけではもう止められません^[2]。

シークレットのローテーションだけでは不十分なのはなぜか

スティーラーは、認証情報をローテーションしても残るバックドアを仕込もうとするためです^[1][2]。Aikidoは3つの持続化の手口を説明しています^[1]。

• 偽造されたステータスチェック:Aikidoによると、リポジトリの必須チェックと同じ名前で偽の「成功」チェックを投稿し、ブランチ保護のマージ条件を通過させ得ます^[1]。StepSecurityは、調べた101のサンプルすべてでこの機能がオフになっていたことを確認しました^[2]。
• AWSの信頼ポリシーの書き換え:ロールの信頼ポリシーを、あらゆるAWSアカウントを許可するように設定できます^[1]。
• Azureのフェデレーションアイデンティティの注入:wfx-ci-…という名前のフェデレーション資格情報をAzure ADアプリケーションに追加でき、侵害されたリポジトリのワークフローが保存されたシークレットなしで認証できるようになります^[1]。

GitHubのOIDCトークンを発行してAWS、Google Cloud、Azureのセッションと交換し、他のIAMロールへ連鎖し、長期間有効なAWSアクセスキーを作成することもできます^[1][3]。だからStepSecurityは「ローテーションだけでは消えないので、持続化の仕組みを除去してください」と述べています^[2]。

自分のGitHubリポジトリが被害に遭ったか確認する方法は

11月10日以降の探りのプルリクエストと攻撃者のコミットメッセージを検索し、ワークフローの実行番号に欠落がないかを調べます^[2][1]。

1. プルリクエストで「docs: dependency audit notes」と、wfx-docs、またはchore/の後に8文字が続く名前のブランチを検索します^[1][2]。
2. 11月10日以降のコミットで、「ci: refresh build cache」、「ci: restore」、「ci: cleanup」、「chore: add ci helper」、「chore: add dependency audit workflow」を検索します^[2]。
3. ヒットしたものごとに、Actionsタブを開き、そのコミットの直後に実行番号の欠落がないかを確認します。StepSecurityは、これがスティーラーが動いたことを示す最も確実なサインだとしています^[2]。
4. コミットをプッシュしたアカウントを控えます。そのアカウントのトークンは盗まれています^[2]。探りのプルリクエストがある場合、ペイロードが実行されていなくても、そのアカウントは乗っ取られています^[1]。

痕跡がないことに頼らないでください。Aikidoは、wfx-lootのアーティファクト、wfx-のキャッシュエントリ、特別なステップサマリーがないことは、データが盗まれなかったことを意味しないと述べています。この攻撃ではそれらの経路がオフになっていたためです^[1]。Aikidoはまた、ペイロードが公開リポジトリだけでなく非公開リポジトリにも仕込まれている可能性を示唆しています^[1]。

スティーラーが実行された場合は何をすべきか

影響を受けたワークフローが使えたすべてのシークレットとクラウドのロールが侵害されたものと想定し、ローテーションしたうえで、持続化の仕組みを探してください^[1][2]。

• ローテーション:ジョブが到達できたすべてのリポジトリ、環境、組織のシークレット(ワークフローが名指ししているものだけではありません)、npm、PyPIなどの公開用トークン、シークレットとして保存されたクラウドのキーが対象です^[2]。
• パッケージの確認:悪意のあるコミットの後に公開されたパッケージのバージョンがないかを調べます^[2]。
• AWS:任意のAWSプリンシパルを許可する信頼ポリシー、11月10日以降に作成されたIAMアクセスキー、wfx-で始まるCloudTrailのセッションを探します^[2]。
• Azure:アプリの登録にあるwfx-ci-*という名前のフェデレーションアイデンティティ資格情報を削除します^[2]。
• Google Cloud、Vault、Kubernetes:トークンの生成と、GitHub Actionsのサインイントークンによるログインを見直します^[2]。
• GitHub:残ったブランチを削除し、探りのプルリクエストを閉じ、偽造されたチェックでマージされたものがないかを確認し、そのアカウントのトークン、OAuthの許可、SSHキーを取り消します^[2]。
• トークン(GitHubのドキュメントに従う):設定の開発者設定にある個人アクセストークンを見直し、見覚えのないものや不要なものを削除します。GitHubは、クラシックトークンではアクセスできるすべてのリポジトリにアクセスできてしまうため、きめ細かいトークン、必要最小限の権限、有効期限を勧めています^[6]。

npmのフックは開発者のマシンでも動作します。短い時間帯にnpm installを実行した人は、ローカルでスティーラーを実行したことになり、自分の認証情報もローテーションすべきです^[2]。SecurityWeekは、複数のセキュリティ企業の助言を、侵害されたトークンの取り消し、流出したシークレットのローテーション、許可されていないクラウドの変更の確認とまとめています^[4]。ボットアカウントについて、StepSecurityは、そもそもブランチ保護をバイパスする権限が必要かどうかを見直すことも勧めています^[2]。強力なサインイン保護はアカウントを盗む攻撃を難しくします。Two-Factor Authentication Explained: Which 2FA Method Is Safest?を参照してください。

影響を受けたパッケージは何か

Aikidoは、自動公開を通じてペイロードを取り込んだPackagistのパッケージとGoモジュールを挙げています^[1]。

• Packagist:digitalelvis/neuronai-studioのバージョン3.14.3。Aikidoは、これをインストールしたり開いたりしたマシンは侵害されたものとして扱うよう述べています^[1]。
• Go:github.com/onuragtas/docker-envのv1.0.278とv1.0.280。ペイロードはGitHub Actionsのワークフローファイルにだけあり、Goのソースとバイナリは変わっておらず、Goのビルドがワークフローファイルを実行することはありませんが、Aikidoはそれでもこれらのバージョンを削除するよう勧めています^[1]。

件数は一致していません。SafeDepは、PackagistとGoモジュールプロキシ上の3つのパッケージがペイロードを含むとし、SecurityWeekは2つのGoモジュールのバージョンに言及しています^[5][4]。SafeDepはさらに、これらのパッケージをcomposer requireやgo getでインストールする一般的な利用者の環境では、ペイロードは実行されなかったと付け加えています^[5]。どれか1つに頼る前に、各調査者の最新の一覧を確認してください。

wfx-lootの背後にいるのは誰で、トークンはどう入手されたのか

ここで取り上げた報告のいずれも攻撃者を特定しておらず、StepSecurityはトークンがどう入手されたかを突き止めていないと述べています^[2][4]。

StepSecurityは、Fly.ioのGitHub Appに発行されたトークンを通じて、19のアカウントから出された173件の探りのプルリクエストを確認しました。入手方法は判断できず、Fly.ioのインフラが侵害された証拠もないと述べています^[2][4]。

Aikidoは、10月のGhostActionの波で被害に遭ったアカウントとの重複を確認し、100を超えるリポジトリでGhostActionのワークフローファイルにwfx-lootが注入されているのを見ました。ただし、盗まれた認証情報は複数のグループの手に渡ることが多いため、両者は別々の攻撃で、おそらく別の攻撃者によるものだと評価しています^[1]。また、新しいバージョンのマルウェアの一部にインドネシア語のコメントがあることにも気付きました^[1]。トークンを慎重に保管することが重要です。基本はPassword Managers Explained: How They Work and Whether They Are Safeで解説しています。