サイバー脅威
Spring Boot Actuatorの設定ミスからSharePoint経由で情報流出：攻撃者が窃取した認証情報で多要素認証機能を回避する手口
すべてのクラウド侵害が、マルウェア攻撃やゼロデイ脆弱性悪用手口から始まるわけではありません。本事例で攻撃者は、外部公開されたSpring Boot Actuatorエンドポイントを発見し、露呈した構成ソースから認証情報を窃取後、OAuth2のROPCフローを悪用して多要素認証機能を回避し、不正アクセスを可能にしました。
- 外部公開されたSpring Boot Actuatorの「/env」データを通じてシークレットを露呈させた場合、すぐに不正アクセスに用いられる可能性があります。
- OAuth2のROPCフローは、パスワードのみでのログインや多要素認証機能の回避を可能にするため、窃取された認証情報が悪用される可能性が高まります。
- 被害範囲を最小限に抑えるためには、アプリのセキュリティ設定（Actuatorにおける制限、シークレットの削除）やアイデンティティ管理（ROPCフローの無効化、条件付きアクセスポリシー/最小権限の原則への準拠）の両方を強化する必要があります。
- TrendAI Vision One™で提供されている「Cyber Risk Exposure Management（CREM）」は、本事例に対して特に有効な防御策と言えます。CREMは、すべてのリスクを分析し、相互に関連付けて優先順位付けすることで、セキュリティチームに包括的な可視性を提供します。
- 外部公開されたSpring Boot Actuatorエンドポイント
- スプレッドシート内に平文で保存された認証情報
- セキュリティリスクの高い認証方法の採用（ROPC：リソース所有者パスワード資格情報）
これらの弱点を悪用することで攻撃者は、最終的に標的組織のSharePointサービスアカウントを乗っ取り、SharePoint Onlineからデータを外部送出させていました。
第一段階：外部公開されたSpring Boot Actuator
Spring Bootとは、本番環境で動作するWebアプリやマイクロサービスを迅速かつ簡単に構築するために設計されたJavaフレームワークのことです。一方、Spring Boot Actuatorとは、実行中のSpring Bootアプリに関する運用情報（例：/health、/heapdump、/env、/configprops）を表示するために用いられる組み込みモジュールのことです。
今回調査した事例では、Spring Boot Actuatorエンドポイントに認証機能がない状態で外部公開されていました。その結果、リクエストに対してHTTPステータスコード（200）を返し、機密情報を流出させていました（図1）。
平文の認証情報は明らかとなっていませんが、configpropsエンドポイントからは、SharePoint統合に関わる設定ブロックを含む有用な情報が露呈していました。
露呈した構成内容からは、以下の情報が明らかとなりました。
- SharePointサービスアカウントのユーザ名
- SharePointのホストURL
- サイト名：Dynamic365
- 構成ソース：application.yml
- パスワードフィールド：マスクが施されている（******）
- クライアントID
- クライアントシークレット
- シークレットID
これらの値は、[REDACTED]-2024を介してAzure ADからトークンを取得する際に用いられる認証情報に対応していました。アプリのシークレットは、パスワードと同様に機能します。つまり、アプリのクライアントIDとクライアントシークレットを知っている者であれば誰でも同アプリのアカウントユーザになりすまして認証を試み、Azure ADからトークンを取得できるということです。
これらのシークレットがスプレッドシート内に保存されていたため：
- 簡単にコピーされたり、流出したりする可能性がありました。
- 一元化されたシークレット管理を回避するために悪用された可能性がありました。
- ファイルへのアクセス権を持つ者なら誰でも、同アプリのアカウントユーザになりすますことが可能でした。
これは、利便性を優先するあまり、開発 / 検証時に用いる認証情報が適切に管理されずに保存されることで生じる典型的な運用上のセキュリティ課題と言えます。
第三段階：認証機能の悪用 – ROPCフローを用いたログイン
ROPCとは、アプリがユーザのパスワードを直接処理してログインを可能にする仕組みのことです。ログインページ（転送先）を表示する代わりにアプリは、認証情報を収集してIDプロバイダに送信します。
典型的なROPCフロー
- アプリが以下の情報を含むリクエストをIDプロバイダ（Azure AD/Entra ID）に送信する。
- クライアントID
- クライアントシークレット
- ユーザ名
- パスワード
- IDプロバイダが認証情報を検証する。
- 認証情報が有効な場合、IDプロバイダがアクセストークンを返す。
- アプリが取得したアクセストークンを用いて、以下のようなAPIにアクセスする。
- Microsoft Graph
- SharePoint Online
- OneDrive
攻撃者が実施したログイン試行は2回とも、client_assertionまたはクライアントシークレットが欠如していたためエラーとなっていました（図2、3）。攻撃者は、1回目のログイン試行をDynamics 365 Finance and Operations Service – Dev（開発環境）を介して、2回目をAzure AD上の内部アプリ（[REDACTED]-2024）を介して実施していました。
攻撃者は、どのアプリがトークンを取得できるかを確認するために、テナント内の複数のアプリを検証していたと考えられます。初期侵入時、攻撃者がログインを達成させる前にこうしたエラーに遭遇することは珍しくありません。攻撃者が正しい認証パラメータを特定するためにOAuthでのリクエストを試行し続けることはよくあることです。本事例では、2回のログイン試行がほぼ同時であったことから、攻撃者がトークンリクエストを自動化していたと考えられます（タイムスタンプに基づく）。
Azure AD上の内部アプリを以下に例示します。
その後、攻撃者がスプレッドシートから取得したclient_secretを用いて、ログインできたことが判明しました。
要約すると攻撃者は、窃取した2つの認証情報（後述）を用いて、Azure ADにROPCフロー経由で認証リクエストを送信しました。（1つ目：Azure AD上の内部アプリ（[REDACTED]-2024）に対する平文のクライアントシークレット（スプレッドシートから取得）および2つ目：SharePointサービスアカウントに対するパスワード（application.ymlから取得））
上記のリクエストは、検証用/開発用アプリ（[REDACTED]-2024）を介して送信されました。Azure ADが認証情報を承認した後、Microsoft Graph用アクセストークンが発行されます。攻撃者は、このトークンを用いてSharePointにアクセスし、不正操作を実施しました。
ROPCフローが安全な認証方法でないとされる理由は以下の通りです。
- ROPCフローを用いた場合、アプリがユーザのパスワードを収集して送信する必要があるため、シークレットが設定ファイル内に保存されたり、安全性の低いアプリにおいては傍受されたりするリスクがあります。
- ROPCは、最新のアクセス制御機能（多要素認証など）との互換性がありません。攻撃者が認証情報を取得した場合、追加の認証機能を起動させることなく、不正アクセスできることがしばしばあります。
- ROPCフローはすべてプログラムが実行するため、攻撃者が悪用するためのスクリプトをすぐに作成する可能性があります。
- ROPCフローを用いたログインは、APIリクエストを介してバックグラウンドで処理されるため、ユーザは自身のアカウントが用いられていることに気づかない可能性があります。
- 以下を用いて、Actuatorエンドポイントに対するパブリックアクセスを無効化しましょう。
- IP許可リスト
- リバースプロキシによる保護
- 有効なユーザ（認証情報）の要件
- 平文の認証情報を削除し、以下の場所に認証情報が保存されているかどうかなど、環境監査を実施しましょう。
- スプレッドシート
- 共有ドライブ
- ドキュメント
- 設定ファイル
- ROPCフローを用いた認証方法を無効化しましょう。
- ROPCフローが不要な場合は、無効化することが強く推奨されます。
- 企業組織は、より強力なセキュリティ制御に対応できる最新の認証方法を適用する必要があります。
まとめ
本調査により、攻撃者が有効な認証情報を用いてSharePointのデータを外部に送出させていたことがわかりました。一方で、マルウェアが展開 / ソフトウェアが侵害された痕跡は見つかりませんでした。攻撃者は、Azure AD（Entra ID）からROPCフロー経由で取得したアクセストークンを用いてSharePoint Onlineにアクセスし、データへの不正アクセスを達成させたと考えられます。
全体を考慮し、本事例は、次に示す3つのセキュリティ上の弱点によって生じたと推測されます。（1）外部公開されたSpring Boot Actuatorエンドポイントを通じて、内部アプリの構成ソースが露呈していた。（2）内部アプリのシークレットが平文でスプレッドシート内に保存されていた。（3）認証方法にROPCフローが用いられていた。
本調査では、現代のクラウド侵害が脆弱性を悪用する技術的な手法によるものでなく、有効な認証情報の悪用手口により、不正アクセスされることが多いという事実が浮き彫りとなりました。攻撃者が認証を突破した場合を想定し、アプリに対するセキュリティ設定やアイデンティティ管理（ROPCフローの無効化、条件付きアクセスポリシー/最小権限の原則への準拠）を強化するための対策が推奨されます。
戦略的な事前予防策として機能するTrendAI Vision One™ Cyber Risk Exposure Management（CREM）
本事例では、エクスポージャ管理（アイデンティティ保護、アプリのセキュリティ設定、クラウド上の認証フロー）における弱点など、ますます一般化しているセキュリティ上の課題が浮き彫りとなりました。本事例で攻撃者は、マルウェアやソフトウェアの脆弱性に依存することなく、標的環境内の設定ミスや安全性の低い古い認証方法を悪用していました。
TrendAI Vision One™ Cyber Risk Exposure Management（CREM）などの事前予防に重視した防御策は、セキュリティリスクが悪用される前に特定し、対処すべき優先順位を付ける際に役立ちます。サイバーリスク・エクスポージャ管理は、活発な脅威だけに焦点を当てるのではありません。
企業組織の攻撃対象領域（アタックサーフェス）を継続的に評価し、攻撃者が初期侵入して機密情報の窃取に至る可能性のあるセキュリティ上の弱点を特定し、対策案を提供します。
本事例においては、CREMが導入されていた場合に以下のようなリスク指標を特定できた可能性があります。
- 機密性の高い構成ソース（メタデータ）を露呈させた状態で外部公開されたアプリケーションサービスの存在
- OAuth 2.0における古い認証フロー（ROPCなど）が採用されたアプリやサービスアカウント
- 多要素認証機能が適用されていない / 条件付きアクセスポリシーで保護されていないアカウント
- 認証時、長く変更のないクライアントシークレットを用いるアプリの存在
- 潜在的な攻撃経路の存在（SharePoint Online上の外部公開されたサービス、アイデンティティ）
CREMでは、リスクを個別に評価せず、アイデンティティやクラウドサービス、露呈した攻撃対象領域を関連付けて相関分析することで、攻撃経路全体を特定します。単一のセキュリティ課題は、それ単体では、中程度のリスクとして評価される場合があります。ところが、別の課題と組み合わせることで、具体的には、初期侵入手口から機密情報の外部送出手口に至るまでの攻撃経路を可視化できるようになります。
CREMは、アイデンティティの保護状況、認証方法、外部公開されたクラウドアプリなどを継続的に関連付けることで、企業組織が従来のセキュリティ対策（事後対応型）から、事前にリスクを低減させるプロアクティブセキュリティ体制へと移行可能にします。本事例に似た攻撃シナリオへの対策として、古い認証方法を用いた運用体制を見直し、アイデンティティに対するセキュリティ制御を強化することで、認証情報の悪用手口やデータへの不正アクセスの発生率を大幅に低減できる可能性があります。
参考記事
From Misconfigured Spring Boot Actuator to SharePoint Exfiltration: How Stolen Credentials Bypass MFA
By: Ryan Soliven, Jovit Samaniego, Reine Roque
翻訳：益見 和宏（Platform Marketing, TrendAI™ Research）