ExaFiles：エクサフォース最前線の知見: GitHub OAuthトークン侵害の検出

エグゼクティブサマリー

数週間前、エクサフォースの検出エンジンは、台湾のみを拠点とするエンジニアリング組織のアカウントで、GitHubユーザーがヨーロッパの24以上の都市から、ほぼ同時にZIPアーカイブ形式でリポジトリをダウンロードしていることを検出しました。調査の結果、このアクティビティは、約3か月前にGitHub Desktopのインストール時に発行され、侵害されるまで一度も使用されていなかったGitHub OAuthトークンに起因していることが判明しました。

調査の終了時点で、このトークンは、アカウントからアクセス可能な638件のリポジトリのうち472件に保存されていたデータを不正に持ち出すために悪用されていたことが判明しました。攻撃では、分散型の住宅用プロキシおよびVPNネットワークを利用し、自動化されたスクリプトによるアクセスが、異なる利用者による通常のブラウザーアクセスに見えるよう設計されていました。

本ブログでは、GitHubの一部のデフォルト設定に潜むリスクを取り上げるとともに、エクサフォースの検出プラットフォームの優れた検出能力を紹介し、お客様の環境で同様の侵害を未然に防ぐための方法について解説します。

重要なポイント：

• GitHubには、この種のOAuthトークンの悪用を標準機能で検出する仕組みがありません。そのため、追加の検出手段がなければ、この不正利用は見過ごされていた可能性があります。一方、エクサフォースは、5つの独立した異常シグナルを相関分析することで、数分以内に信頼度の高い単一の検出結果として標準機能で検出しました。
• GitHub OAuthトークン（従来のOAuth AppトークンおよびGitHub Appリフレッシュトークン）は、設計上、有効期間が長く設定されており、その有効期間を短縮するための標準機能は提供されていません。唯一の対策は、組織で定めた運用スケジュールに従ってトークンを失効させ、再認証を実施することですが、この運用はエクサフォースによって自動化できます。
• GitHub Desktopなどで利用するトークンの有効期限を設定すること、休眠トークンをリスクとして検出すること、リポジトリへのデフォルトアクセス権限をより厳格に設定することといった予防策を講じることで、このような攻撃が成功する可能性を大幅に低減できます。

攻撃の全体像

1. トークンの発行　エンジニアが公式配布サイトからGitHub Desktopをインストールし、初回セットアップを完了しました。標準的なブラウザーベースのOAuthフローは1分以内に完了し、repo、user、workflowの各スコープを持つトークンが発行され、macOSキーチェーンに保存されました。その直後にGitHub Desktopはもう一度起動されましたが、その後は使用されませんでした。トークンは有効な状態のまま一度も使用されず、これは多くの開発組織で見られる一般的な開発ツールの導入時の利用パターンと一致しています。
2. 休眠期間　その後の3か月間、アカウントのアクティビティは、台湾を拠点とするインフラ、macOS環境でのツール利用、異常の検出なしというベースラインと一貫していました。この期間中、当該トークンが使用されることはありませんでした。
3. 不正持ち出しの開始　2026年6月19日、まず15秒間に76件のリポジトリがダウンロードされる形で、不正持ち出しが始まりました。攻撃者は休眠状態のOAuthトークンを使用し、自動化されたクライアントがrepo.download_zipリクエストを発行し始めました。1回のセッション内で、リクエストはベルギー、英国、ノルウェー、フィンランド、スペイン、ドイツ、その他多数のヨーロッパの拠点からほぼ同時に発信されました。これらはすべて同一のGitHubセッションIDと、同一の短縮されたWindowsユーザーエージェント文字列によるもので、単一の人間の操作者では説明のつかないパターンでした。
4. 検出　エクサフォースは、5つの異なる異常シグナルを組み合わせ、単一の信頼度の高いアラート（詳細は後述）として相関付けた検出結果を生成しました。このアラートは、台湾を拠点とするインフラおよびmacOS環境のツール（git、Chrome、GitHub CLI）からのみ発生し、ヨーロッパからのアクティビティが一度もなかった、一貫した単一地域による397件の過去イベントというベースラインに基づいて生成されました。
5. 不正持ち出しの継続　アクティビティは継続し、最終的にアカウントからアクセス可能な638件のうち472件の個別リポジトリに及びました。
6. 対応　封じ込めは、エクサフォースMDRチームと、プラットフォームのSOAR機能を組み合わせて実施しました。お客様はその後、手動での修復対応を実施しました。具体的には、Google Workspaceアカウントの無効化、GitHub OAuth認可の失効、漏えいしたシークレットのローテーション、影響を受けたデバイスの封じ込めを行いました。当該ホストにはインシデント発生前のエンドポイントテレメトリが存在しなかったため、フォレンジック分析を支援する目的で、その直後にEDRを導入しました。フォレンジックレビューの結果、デバイス上にマルウェアや永続化メカニズムは検出されず、調査時点で継続中の侵害は存在しないことが確認されました。
   

GitHub OAuthトークンについて知っておくべきこと

本事例の鍵となったのは、広くは理解されていない、ある詳細です。この点については、後日公開する別のブログでさらに詳しく取り上げます。従来型のGitHub OAuth Appトークン（GitHub Desktopが生成するタイプ）は、設計上、固定的な有効期限を持ちません。GitHubは2つの異なる統合モデルをサポートしており、それぞれの認証情報のライフサイクルは大きく異なります。

• 従来型OAuth App（gho_で始まるトークン）は、より古くシンプルなモデルであり、GitHub Desktop、多くのCLI、初期のサードパーティ統合で使用されています。一度認可されると、トークンは無期限に有効なままで、30日、90日、1年といった有効期限のサイクルはありません。GitHubの唯一の保護機能は休眠チェックです。丸1年間まったく使用されなかったトークンは自動的に失効します。使用されたトークン、または休眠期間が1年未満のトークンは、有効な状態が維持されます。
• GitHub App（ghu_で始まるトークン）は、より新しく、きめ細かい制御が可能なモデルです。このモデルでは、アプリケーション開発者がトークンの有効期限をオプトインで設定できます。有効化した場合、デフォルトの有効期間は8時間で、6か月間有効なリフレッシュトークンによって支えられます。このリフレッシュトークン自体は有効期間が長いため、盗まれた場合、再認証なしに新しい8時間有効なアクセストークンを数か月にわたって発行し続けることができます。したがって、このモデルは侵害の影響を受ける期間を狭めるものの、有効期間の長い認証情報を排除するわけではなく、その問題を1階層下に移すにすぎません。

GitHub Desktopは従来型のOAuth Appモデルを基盤に構築されているため、有効期間の短いGitHub Appのライフサイクルは利用できませんでした。これが、3月に発行されたトークンが6月時点でも完全に使用可能だった理由です。休眠期間は95日であり、GitHubの1年間の自動失効しきい値には十分収まっていました。有効期間の短いクラウド認証情報（例えば、SSOセッションを通じて発行され、定期的な再認証を必要とするAWS STSトークンなど）とは異なり、この種のGitHub認証情報は、それが属する特定のアプリケーションが有効期限を組み込んで構築されていない限り、実質的なライフサイクルを持ちません。GitHub Appモデルであっても、有効期間の長い認証情報を排除するわけではなく、その時々で侵害にさらされる対象を、アクセストークンからリフレッシュトークンへと移すにすぎません。

これらのトークンの有効期間を短縮するための標準機能は提供されていません。GitHubは、データベース認証情報をローテーションするように、この種のトークンを固定スケジュールで失効させる標準設定を提供していません。その間隔の管理は、完全に組織側に委ねられています。そのため、チームは休眠トークンや古いトークンを検出する独自の仕組みを構築し、個々の認可を失効させる必要があります。これには、リフレッシュトークンのデフォルトである6か月よりも短い間隔で再認証を強制することも含まれます。これらの検出および管理機能は、現在ではエクサフォースプラットフォームの標準機能として提供されています。

修復のための代替オプションの1つは、有効期限を標準でサポートする認証情報タイプに移行することですが、これは聞こえるほど自由度の高い選択肢ではありません。GitHub Desktopは、ブラウザーベースのOAuthフローのみをサポートしています。GitHubのドキュメントには、ユーザー名／パスワードまたはトークンベースのサインインはGitHub Desktopではサポートされていないと明記されており、その認証情報タイプを変更できる設定は存在しません。有効期限付きの認証情報を取得するには、ワークフローをコマンドラインに移行し、代わりにFine-grained Personal Access Tokenで認証する必要があります。このトークンには必須の有効期限（最長366日、組織ポリシーによってはより短い期間）が設定され、アカウントの全アクセス範囲ではなく、特定のリポジトリ単位にスコープを制限できます。

もう1つ、検討から除外すべき代替案があります。SSHキーが代替手段として提案されることがありますが、これは根本的な問題に対処するものではありません。従来型のOAuth Appトークンと同様に、SSHキーもデフォルトでは有効期限を持たず、盗まれたキーは、そのアカウントがアクセス可能なすべてのリポジトリを引き続きクローンするために使用できます。SSHはアクセスの手段を変えるだけであり、根本的なリスクそのものを変えるものではありません。

GitHubもGitHub Desktopも、これらの認証情報の有効期間を単独で短縮できない以上、ほとんどのチームにとって最も現実的な方法は、これを自ら管理することです。すなわち、休眠トークンを追跡し、より短いサイクルで再認証を強制し、アクセスが不要になった認可を失効させることであり、これらはまさにエクサフォースが対応できるよう設計された、継続的な検出と管理です。

OAuthトークン侵害の検出

エクサフォースは、このアクティビティを、すべて同一セッションに相関する5つの独立した異常シグナルから構成される、単一の信頼度の高い検出結果として、追加設定なしで特定しました。

• ASN異常 － このアカウントでこれまで一度も観測されたことのない25以上の自律システムからのトラフィック
• 不可能な移動（Impossible Travel） － 地理的に整合性のないリクエストのシーケンスで、時速数百万キロメートルという移動速度を示唆
• ロケーション異常 － 3か月間にわたり台湾のみを拠点としていたアクティビティからの逸脱
• アクセス頻度の異常 － 15秒間に76件のリポジトリのダウンロード
• ユーザーエージェント／ロケーション異常 － 一貫していたmacOS／Chromeのベースラインに代わって出現した、Windows系の短縮されたユーザーエージェント文字列

これらのシグナルは、いずれも単独では十分ではありませんでした。単独で見た場合、ロケーション異常や見慣れないASNは誤検知を招きやすく、正規の移動やVPNの利用でも同様のパターンが日常的に発生するためです。これを通常の異常から信頼度の高い検出結果へと引き上げたのは、単一のセッション上に複数のシグナルが同時に存在していたことです。

さらに、追加の相関分析を適用しました。プラットフォームは、GitHubのセッションアクティビティとIdPイベントを同一タイムライン上で相関付け、大量ダウンロードの開始が対応するIdP認証イベントより前であったことを確認しました。これは、正規ユーザーによる認証済みセッションではなく、自動化された認証情報リプレイの可能性を強く示す兆候です。この複数シグナル・複数データソースにまたがる相関モデルにより、検出結果を即座に高信頼度として判定でき、手動トリアージを待つことなく迅速な対応につなげることができました。

一方、従来型のSIEMで同じレベルの検出を再現するには、一見した以上に大きなエンジニアリング工数が必要になります。例えば、ロケーション異常ルールを1つ作成するだけでも、ベースラインをユーザー単位、アカウント単位、または特定の認証情報単位のどこに設定するかという課題があります。GitHub OAuthトークンは、そのいずれにも単純には分類できません。ユーザーに紐付いた派生的な認証主体であり、同一アカウント上で複数のトークンが同時に有効になる可能性があるためです。また、ベースラインの維持管理は非常に複雑です。条件を狭く設定しすぎると、通常のVPN利用と実際の異常を区別できず、逆に範囲を広く設定しすぎると誤検知が過剰に発生します。従来型SIEMでこのようなベースラインを構築し、同様のシグナルを相関分析するには、通常、数週間から数か月にわたるルール開発とチューニングが必要です。さらに、各種トークン、認証方式、ユーザーモデルに関する深い専門知識も求められます。このレベルの運用を継続できるのは、高度な専門性と十分なリソースを備えた一部のセキュリティチームに限られます。

まさにこのギャップを解消するために、エクサフォースの検出プラットフォームは構築されています。UEBAによるベースライン分析とプロファイリングを標準搭載し、それらを多層型の検出エンジンの下で活用することで、単独では判断が難しい低精度の異常シグナルを、高精度な検出結果へと集約します。これにより、セキュリティチームは未知の攻撃への対応や、より深い脅威ハンティングに集中できます。また、この攻撃を受けて、エクサフォースは「Dormant Token Reactivation」を標準搭載の検出機能として追加し、この種の攻撃パターンをさらに包括的に検出できるようになりました。

対応アクション

この事例は、高信頼度の検出が発生した時点でOAuth Appトークンを自動的に失効させることの有効性を示しています。このシナリオに対応するインシデント対応ランブックには、以下の対応手順を含める必要があります。

1. 影響を受けたアイデンティティに関連するOAuth認可（grant）および有効なセッションを直ちに失効させます。対象には、GitHubセッション、Google Workspaceセッション、ならびにそれらから派生したSSOトークンが含まれます。GitHubには、この処理専用のエンドポイントがあります：POST https://api.github.com/credentials/revoke。このエンドポイントはトークン値を受け取り、対象トークンを即座に失効させます。特筆すべき点として、このエンドポイントは設計上認証を必要としません。ログインや所有権の証明も不要です。これは、漏えいした認証情報が発見された瞬間に、発見者が即座に無効化できるようにするためです。エクサフォースでは、この機能を標準搭載の対応アクションとして提供しています。高信頼度の検出が発生すると、プラットフォームが自動的にこのエンドポイントを呼び出します。そのため、インシデント発生中にチームがAPI呼び出し用のスクリプトを作成し、手動で連携する必要はありません。
2. トークンがアクセスしたすべてのリポジトリに対してシークレットスキャンを実行します。特に、侵害時の影響範囲（blast radius）が大きい認証情報が配置されていることが多い、インフラストラクチャコード、デプロイメントコード、プラットフォームコードを優先的に確認します。特定された認証情報はローテーションします。これらの対応は、エクサフォースSOARプラットフォームによって自動化することも可能です。

予防的コントロール

以下の予防的コントロールを導入していれば、このアクティビティをより早期に検出できた可能性があり、場合によっては発生自体を防止できた可能性があります。ただし、単一の制御だけで根本的な問題を完全に解消することはできません。これは、有効期間が長く、広範な権限範囲を持ち、ネットワーク制限を受けないOAuthトークンが、一時的な設定ミスではなく、GitHubの認証情報モデルに内在する構造的な特徴であるためです。それでも、これらの制御を組み合わせることで、このようなシナリオが発生する頻度を低減し、発生した場合でも攻撃の進行範囲を限定できます。

1. プライベートリポジトリに対するIPアドレス許可リストを設定し、VPNまたはZTNA経由でのアクセスを必須化します。盗まれたトークンが承認済みのネットワーク範囲からのみ利用可能であれば、分散型住宅用プロキシプールは有効な攻撃経路として機能しなくなります。ただし、この対策には大きなトレードオフがあります。すべてのエンジニアがVPNまたはZTNAソリューションを経由してアクセスする必要があり、多くの組織や個々のエンジニアにとって運用上の制約や負担が発生します。また、現時点ですべての顧客がこのようなインフラを導入しているわけではありません。
2. CLIベースのGitアクセスでは、Fine-grained Personal Access Tokenの利用を標準化し、機密性の高いリポジトリへアクセスするユーザーにはGitHub Desktopの利用を非推奨とします。これは見た目以上に実務へ適用しやすい対策です。GitHub Desktopは独自のブラウザベースOAuthフローのみをサポートしているため、有効期限付き認証情報を利用するよう構成することはできません。一方、Fine-grained PATには必須の有効期限が設定され、特定リポジトリ単位でアクセス範囲を制限できます。また、組織オーナーはカスタム自動化を導入することなく、現在利用可能な機能としてトークン最大有効期間ポリシーを適用できます。この制御によって、すべてのエンジニアがGitHub Desktopをインストールすることを防止できるわけではありません。しかし、まったく利用期間を制限できないトークンタイプに依存する代わりに、セキュリティチームは具体的で強制適用可能な標準を確立できます。
3. 休眠トークンのリスクフラグ付け　作成後に一度も使用されていないOAuthトークン、または60日以上使用されていないOAuthトークンを継続的なリスク項目として可視化することで、チームはこの種の認証情報が攻撃に利用される前に、事前に失効できます。この制御が存在していれば、本事例で悪用されたトークンも、攻撃発生の数か月前にリスクとして検出されていました。なお、休眠トークンはエクサフォースで利用可能なリスクルールの1つであり、休眠トークンの再アクティブ化についても、現在では標準機能の検出として提供されています。
4. アクセス権限レベルに応じた開発者エンドポイントへのEDR導入　この対策はトークン窃取そのものを直接防止するものではありません。しかし、本事例の調査で確定的な根本原因を特定できなかった最大の要因に対処できます。
5. 組織全体の読み取り権限を付与しない、デフォルトのリポジトリ権限設定　恒常的なアクセス権を必要な範囲のみに制限することで、認証情報がどのような経路で侵害された場合でも、単一の侵害された認証情報による影響範囲を最小化できます。

まとめ

この攻撃が成功した背景には、GitHub Desktopの認証情報モデルに存在する構造的なギャップがあります。GitHub Desktopが発行するOAuth Appトークンには定期的な有効期限がなく、1年間完全に未使用の場合のみ失効する仕組みです。また、GitHub Desktop内部の設定変更によってこのギャップを解消することはできません。この問題は本事例固有のものではなく、GitHub Desktop、CLI、またはその他のClassic OAuth統合を利用するあらゆる組織に影響します。このギャップを根本側で解消できない以上、検出によって補完する必要があります。従来型SIEMでも実現は可能ですが、ASN、不可能な移動（Impossible Travel）、ロケーション、アクセス頻度、ユーザーエージェント、IdPイベントの時系列など複数のシグナルを相関させるには、高度なベースライン構築と複数データソースを横断した分析が必要になります。

検出だけでは十分ではありません。このような事象の発生頻度そのものを低減するには、予防的コントロールと組み合わせる必要があります。エクサフォースは、このサイクルをエンドツーエンドで実現します。Risk Rulesによって予防すべきアクションを可視化し、複数のシグナルを相関分析して、追加設定なしで信頼度の高い検出結果を生成します。さらに、SOARによる自動封じ込めまで実行することで、各機能を個別に構築・調整・運用する負担を軽減します。