調査によると、この攻撃は UTC 11:36〜17:48 の間に実行されており、完全に自動化された仕組みで大量のリポジトリを短時間で標的にしたとみられています。
このキャンペーンは、技術的な自動化と“開発作業に見える偽装”を組み合わせて実行されました。
攻撃者はランダムなユーザー名のGitHubアカウントを大量に作成し、次のような 自動化ボット風の名前 を使ってコミットを行いました。
これにより、変更が通常のCIメンテナンスのように見えるよう偽装されました。
コミットメッセージや作者情報も細かく加工され、CI設定の更新やワークフロー調整のように見える内容にしていました。これが疑いを持たれにくくする要因となりました。
攻撃は ブランチ保護ルールが弱い、または設定されていないリポジトリに集中していました。レビュー必須のPull Requestが無い場合、攻撃者はワークフロー変更を 直接デフォルトブランチへプッシュできてしまいます。
各コミットには Base64でエンコードされたBashスクリプトを含むGitHub Actionsワークフローが追加されていました。CIパイプラインが実行されると、Runner上でこのスクリプトが動作し、シークレット収集を開始します。
このため、多くの場合 CIが次に実行されるまで攻撃は表面化しませんでした。
ワークフローに埋め込まれたスクリプトは、CI環境からさまざまな機密情報を収集し、攻撃者のサーバーへ送信する設計でした。
主なターゲットは以下です。
CIパイプラインはデプロイ用の権限を持つことが多いため、侵害されると クラウド環境や本番デプロイ経路への侵入につながる可能性があります。
Megalodonが特に狙っていたのが GitHub ActionsのOIDCトークンです。
最近のCI/CD環境では、クラウド認証に OpenID Connect(OIDC)フェデレーションを利用するケースが増えています。これは長期的なAPIキーを保存する代わりに、ワークフローが短期間のIDトークンを取得してクラウドに認証する仕組みです。
この方式は静的な鍵を保存しないため安全性が高いとされています。しかし、もし攻撃者が パイプライン実行中にトークンを盗めば、そのジョブの権限を一時的に偽装できてしまいます。
盗まれたOIDCトークンはクラウドの認証システムから 一時的なアクセス権限に交換できるため、次のようなリスクが発生します。
トークンは短時間で失効しますが、その短い時間でも攻撃者にとっては十分価値があります。
Megalodonは、サプライチェーン攻撃の焦点が アプリケーションコードから「開発インフラ」へ移っていることを示しています。
CIワークフローを改ざんすることで、攻撃者は次のようなメリットを得ます。
CI/CD環境には強力な認証情報が集まりやすいため、ワークフロー1つの改ざんでも 多くの下流システムへ影響が広がる可能性があります。
ほぼ同じ時期、GitHubは 別のセキュリティインシデントも公表しました。
従業員の端末にインストールされた 悪意あるVisual Studio Code拡張機能により、攻撃者が 約3,800件のGitHub内部リポジトリへアクセスできたというものです。
この拡張機能はトークンや認証情報を盗み取るよう改ざんされており、開発者環境から侵入が始まりました。
攻撃のタイミングや手法の類似性から関連を指摘する報道もありますが、この内部侵害がMegalodon攻撃を直接引き起こしたという確証は現時点では公開されていません。
そのため、現状では 同時期に発生した別々のサプライチェーン事件として扱われています。
Megalodonは、攻撃の自動化により数千のリポジトリを短時間で侵害できることを示しました。今回の事例から、ソフトウェア開発チームには次のような防御策が重要とされています。
クラウド環境や本番デプロイをCIが直接制御する現代の開発環境では、CI/CDワークフロー自体がソフトウェアサプライチェーン防御の重要な要素になっています。