認証情報を超えて：OAuthアプリの悪用で実現する永続的クラウド侵害

主なポイント  

• OAuthアプリケーションは、侵害された環境内で永続的なアクセスを得るために使用される可能性があります。 
• OAuthアプリケーションは、ユーザーの認証情報がリセットされたり、多要素認証（MFA）が適用されたりしても、その認可されたアクセスを維持します。 
• プルーフポイントのリサーチャーによって作成されたPoC（概念実証）および専用ツールによって示されているように、このような攻撃は完全に自動化することが可能です。 
• 脅威アクターは、すでにこれらの脆弱性を積極的に悪用しています。 
   

はじめに 

クラウドアカウント乗っ取り（ATO）は近年深刻化しています。サイバー犯罪者や国家支援型の攻撃者が、侵害された環境内で永続的なアクセスを得る手段として、悪意あるOAuthアプリケーションを採用するケースが増えています。これらの攻撃により、悪意ある攻撃者はユーザーアカウントを乗っ取り、偵察活動を行い、データを流出させ、さらなる悪意ある行為を実行することができます。 

セキュリティ上の影響は特に深刻です。攻撃者がクラウドアカウントへのアクセスを獲得すると、カスタム定義されたスコープや権限を持つ内部（セカンドパーティ）アプリケーションを作成・認可することができます。この機能により、メールボックスやファイルなどの重要なリソースへの永続的アクセスが可能となり、パスワード変更などの従来型のセキュリティ対策を事実上回避してしまいます。 

この攻撃手法を理解・実証するため、プルーフポイントのリサーチャーは、侵害されたクラウド環境内で悪意ある内部アプリケーションを自動的に生成するツールを開発しました。本ブログでは、そのツールの技術的な詳細と企業セキュリティへの影響について詳しく分析します。さらに、プルーフポイントのテレメトリで検出された実際のインシデントを検証し、脅威アクターがどのように現実世界でこれらの脆弱性を積極的に悪用しているのかを具体的な証拠とともに紹介します。 

OAuthアプリケーションの種類：セカンドパーティ対サードパーティ 

クラウド環境、特に Microsoft Entra ID の文脈では、セカンドパーティアプリケーションとサードパーティアプリケーションの区別を理解することが非常に重要です。 

セカンドパーティアプリケーション: これらは組織のテナント内に直接登録されたアプリケーションです。内部アプリケーションとも呼ばれ、通常は組織の管理者または適切な権限を持つユーザーによって作成・管理されます。セカンドパーティアプリケーションは、組織自身のディレクトリ内から発生するため、環境内である程度の暗黙の信頼を受け継ぎます。 

サードパーティアプリケーション: これらのアプリケーションは外部のテナントに登録され、他の組織のテナント内のリソースへのアクセスを要求します。一般的な例としては Zoom や DocuSign のような広く使われているサービスが挙げられます。サードパーティアプリケーションは、アクセスが付与される前に管理者の同意ワークフローや組織のセキュリティポリシーを通じて追加の精査を受けるのが通常です。 

この区別はセキュリティの観点から特に重要です。脅威アクターは、エクスプロイト後のフェーズでセカンドパーティアプリケーションを作成することを好む傾向があるためです。これらの内部アプリは検出がより難しく、外部アプリケーションの監視を主眼に置いたセキュリティコントロールを回避する可能性があります。 

 

攻撃のフロー 

初期侵入ベクター

サイバー犯罪者は、クラウドユーザーアカウントへの初期アクセスを得るために複数の手法を組み合わせることが多いです。一般的な戦術の一つは、リバースプロキシツールキットと個別に仕立てたフィッシング誘引を組み合わせて認証情報やセッションクッキーを盗む方法です（詳細は当社の最近のブログ FIDOダウングレード攻撃 をご参照ください）。 

攻撃者がユーザーのログイン認証情報を盗むと、対象アカウントへの不正アクセスを確立でき、攻撃の次のフェーズに向けた足がかりが整います。 
 

OAuthアプリケーションによる永続性の確立

初期侵入が成功した後、攻撃者は悪意あるOAuthアプリケーションの作成と展開にピボットすることが多くあります。このプロセスは通常、以下を含みます。 

• 侵害されたアカウントの権限を利用して新しい内部アプリケーションを登録 
• 最大の効果を得るために特定の権限やAPIスコープを設定
• これらのアプリケーションに組織の重要なリソースへのアクセスを許可

この手法の戦略的価値は、その永続性の仕組みにあります。侵害されたユーザーの認証情報がリセットされたり多要素認証が適用されたりしても、悪意あるOAuthアプリケーションは認可されたアクセスを維持します。これにより、特定して是正されない限り、環境内に検出されずに残り続ける強靭なバックドアが作られてしまいます。 
 

技術的実装：OAuthベースの永続化の自動化 

プルーフポイントのリサーチャーは、脅威アクターが悪意あるOAuthアプリケーションを通じて永続的アクセスを確立する方法を示す自動化ツールキットを開発しました。PoCは、現実の攻撃シナリオを反映するいくつかの主要な機能を実装しています。 

コア機能 

• OAuthアプリケーションの自動登録と構成 
• 権限スコープ選択のカスタマイズ可能性
• ユーザー認証情報に依存しない永続的アクセスのメカニズム
• アプリケーション命名規則の設定可能性

運用ワークフロー

最初に侵害されたアカウントから始めて、このツールは自動化されたアプリケーション作成を通じてポストエクスプロイテーション（侵害後のフェーズ）のプロセスを効率化します。デモンストレーションではランダム化されたアプリ名を使用していますが、現実の脅威アクターは検出を避けるために正規の業務アプリケーションを模倣するような欺瞞的な命名戦略を用いることが一般的です。 
 

Figure 1: Future Account Super-Secret Access tool, Version 1:  ウェルカム画面

自動展開プロセスの間、アプリケーションは攻撃者の目的に沿った事前構成済みの権限スコープで登録されます。この実装の重要な側面は所有権の帰属であり、侵害されたユーザーアカウントが新規作成されたアプリケーションの登録所有者となることで、そのアプリが組織環境内の正当な内部リソースとして実質的に確立されます。 

この所有権モデルは戦術的な利点をいくつか提供します：アプリケーションは内部で開発されたリソースのように見え、認証要求は組織のテナント内から発生します。アプリケーションは内部リソースに関連付けられた信頼関係を継承し、標準的なサードパーティアプリケーション向けのセキュリティコントロールではこの活動を検出またはフラグ付けできない場合があります。 

Figure 2: アプリケーション作成プロセス（この例ではアプリ名は「justSOMEniceAPP」）

Figure 3: 選択されたアプリケーションスコープ：Mail.Read と offline_access
 

アプリケーション登録が成功すると、ツールは自動的に2つの重要な認証コンポーネントを確立します。 
 

アプリケーションシークレットの生成 

ツールはまずアプリケーションの暗号化されたクライアントシークレットを作成します。これはアプリケーション自身の認証資格情報として機能し、機密クライアント認証フローで必要になります。サーバーサイドアプリケーションがトークンを要求するためには必須の要素です。 
 

トークンの収集  

自動化はその後、持続的なアクセスを維持するためにそれぞれ異なる目的を果たす複数のOAuthトークンタイプ（アクセストークン、リフレッシュトークン、IDトークン）を収集するプロセスに進みます。 

Figure 4: 収集されたトークン

この永続化メカニズムの有効性を検証するために、このツールにはアクセス保持の実演が含まれています。  

認証情報のリセットテスト - 標準的なインシデント対応を模擬するためにユーザーのパスワードを変更します。この操作は通常、盗まれた認証情報を通じて得られた不正アクセスを終了させるはずです。 

Figure 5: ユーザーパスワード変更の実演

アクセス検証 - パスワード変更後も、悪意あるアプリケーションは完全なアクセスを維持します。いくつかのOAuthトークンやアプリケーションシークレットは引き続き機能し、事前に承認された権限はすべて有効なままです。 

Figure 6: パスワード変更後に生成された新しいトークン
 

パスワードリセット後、このツールは悪意あるアプリケーションのアクセスが持続的に有効であることをいくつかの重要な活動を通じて実演します。 

メールアクセスの実演 - ユーザーのメールボックスの内容を正常に取得し、受信メールや過去のメールへの継続的なアクセスを維持します。アプリは現在、ユーザーの認証情報の変更から独立して動作します。 

不正アクセスの範囲はメールにとどまらず、アプリケーションの設定された権限に記載された任意のリソースにまで及ぶ可能性があり、例えば以下のようなものが含まれます。  

• SharePoint のドキュメントおよび共同作業コンテンツ
• OneDrive に保存されたファイル
• Teams のメッセージおよびチャネルデータ
• カレンダー情報
• 組織の連絡先
• その他の Microsoft 365 のリソース

Figure 7: パスワード変更後でもアクセスされたユーザーのメール

悪意あるアプリケーションの痕跡は、Microsoft Entra ID の管理インターフェース内で観察できます。具体的には以下の場所です： 

位置とナビゲーションパス：Entra ID ポータル → App Registrations  

• アプリケーションは標準的な内部登録として表示 

アプリケーションの管理インターフェース下にあるアプリケーション構成の詳細には、いくつかの主要なコンポーネントが表示されます： 

• アプリケーション構成：  
  • 基本的なアプリケーションメタデータ
  • 認証設定
  • API 権限と付与されたスコープ
• クライアント シークレット — 'Certificates & Secrets' セクションに配置： 
  • 有効なシークレット資格情報を表示（持続的なプログラムによるアクセスを可能にする重要な要素）
  • 有効期限日とシークレットの状態

標準的な管理インターフェースにおけるこの可視性は、定期的なアプリケーションの監査とモニタリングの重要性を強調しています。悪意あるアプリケーションは、特に精査されない限り正当な業務アプリケーションに紛れ込む可能性があります。 

Figure 8: Microsoft Azure におけるアプリケーションシークレットの場所

悪意あるアプリケーションが不正なアクセスを維持できる能力は、二つの重要な要因の欠如に直接結びついています。 
 

アクセス終了の条件  

• アプリケーション登録の手動削除および付与された権限の明示的な取り消し
• クライアントシークレット資格情報の有効期限切れ

本デモンストレーションでは、アプリケーションのクライアントシークレットは2年間の有効期間に設定されており、これにより攻撃者は次のような利点を得ます：  

• 認証情報の更新を必要としない長期的な持続的アクセス
• 保護されたリソースへ長期間アクセスする能力
• データ流出のための大きな機会窓口
• 環境内における長期的な居座り時間の延長

この長期的な持続性ウィンドウは、重大なリスクをもたらします。初期侵害の発見後も長期間にわたる未検出アクセスの可能性、継続的なデータ曝露、過去の不正アクセスの特定の難しさ、そして積極的なアプリケーションライフサイクル管理の必要性が含まれます。 

能動的な発見と是正作業が行われない限り、アプリケーションは管理者によるアクションが取られるか、クライアントシークレットが自然に期限切れになるまで、有効な攻撃ベクトルとして残り続けます。 
 

実際の攻撃分析 

プルーフポイントのテレメトリによって、実際に発生したアカウント乗っ取り（ATO）インシデントが4日間にわたり継続していたことが明らかになりました。最初の侵害は、ユーザーエージェント「Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Iron Safari/537.36」を使用したログイン試行によって検出されました。プルーフポイントの脅威インテリジェンスに基づくと、このユーザーエージェントのシグネチャは、Adversary-in-the-Middle（AiTM）型フィッシング攻撃、特に Tycoon フィッシングキットと関連している可能性が最も高いと考えられます。 

この脅威アクターは、米国を拠点とするVPNプロキシを経由して複数の悪意ある行動を実行しました。 

• 悪意あるメールボックスルールを作成
• 「test」という名前の内部アプリケーションを登録
• Mail.Read および offline_access 権限を持つアプリケーションシークレットを追加し、パスワード変更後も被害者のメールボックスへの永続的なアクセスを可能に

およそ4日後にユーザーのパスワードが変更されましたが、その後ナイジェリアの一般家庭向けIPアドレスからのログイン失敗が観測され、脅威アクターの出所である可能性が示唆されました。しかし、アプリケーション自体は依然として有効なままでした。この事例は、本ブログで説明している攻撃パターンを具体的に示すものであり、これらの脅威が理論的なものではなく、現在の脅威環境において実際に悪用されているリスクであることを証明しています。 
 

修復と推奨事項

環境内で悪意あるアプリケーションが疑われる場合、即時の修復措置を講じることが極めて重要です。 
 

優先対応事項 

クライアントシークレットを即時無効化 — すべてのクライアントシークレットを即座に無効化します。既存の証明書をすべて削除してください。これにより、アプリケーションが新しいトークンを要求する能力を即座に停止させます。 

• ユーザートークンの失効 — すべての既存ユーザートークンを即時に無効化します。 
• アプリケーションの削除 — アプリケーション登録全体を削除し、これまでに付与されたすべての権限を取り消します。関連するすべてのサービスプリンシパルも削除します。 
• 継続的なモニタリングの実装 — 業務アプリケーションを継続的に監視し、自動修復を適用することで、攻撃者が価値のあるリソースへの永続的なアクセスを確立するのを防ぐことができます。また、さらなる攻撃の発動を抑止することにもつながります。  
• ユーザーの意識向上 — ユーザーは防御の重要な一部です。以下のような内容について定期的なトレーニングを実施してください。  
• 信頼できるように見える悪意あるアプリやテナントを見分ける方法。 
• 予期しない同意リクエストを不審なものとして扱うこと。 
• 不審なアプリケーションの認可を迅速に報告すること。