Cazadoraを使ってMicrosoft 365内の隠れた悪意あるOAuthアプリを見つける

Image

著者: Matt Kiely、Huntress Labs主任セキュリティリサーチャー

Tl;dr: たとえMicrosoft 365テナントを1つだけ管理している場合でも、OAuthアプリの監査を行う時期です。統計的に見て、あなたの環境に悪意あるアプリが潜んでいる可能性は高いです。

この作業を支援するオープンソーススクリプトを書きました: https://github.com/HuskyHacks/cazadora 

特に、エンタープライズアプリケーションとアプリケーション登録で以下を探してください:

  • ユーザーアカウント名が付けられたアプリ

  • 「Test」や「Test App」など、テストを示す名前のアプリ

  • インストールされているテナントのドメイン名が付けられたアプリ

  • 任意の文字列(例: 非英数字のみの名前「……..」など)を名前に使っているアプリ

  • 異常なリプライURL、特にポート7823のローカルループバックURL [“http://localhost:7823/access/”] を含むもの

本当に、今すぐアプリを監査してください!この記事は戻ってきたときにもここにあります。

脅威インテリジェンスに興味がある方は、ぜひ読み進めてください。

想像してみてください。今日は美しい日曜日の朝。長い一週間の後、やっと休息の日を迎えました。眠い目をこすりながらキッチンに向かい、お気に入りのカフェイン飲料を用意します。太陽が輝き、鳥たちがさえずっています。窓から顔を出し、夏の風を感じます。一瞬、心が安らぎ、生きていることに幸せを感じます。

そしてふと窓辺を見ると、そこに一匹だけ、ぽつんとシロアリが立っています。

最初は「まあ、一匹だけだし、大したことない」と思います。

しかし、もう一度考え直すと、血の気が引きます。なぜなら、見つけたのは一匹だけでも、シロアリは一匹だけでは済まないからです。

くつろぎの希望は消え去り、キッチンの床板を剥がす計画を立て始めます。

これは、私やHuntressの他のスタッフが、Azureアプリケーションのデータと、それらがどのようにパートナーテナントで悪用されているかを調べ始めたときの状況とほぼ同じです。さあ、私たちと一緒にキッチンの床板を剥がし、シロアリの巣がどれほど大きいかを明らかにしましょう!

OAuthアプリケーション攻撃

Unwanted Access機能をリリースして以来、Huntress SOCはアイデンティティ攻撃の阻止件数を着実に増やしてきました。この機能は、認証情報の窃取、トークンの窃取、Adversary in the Middle(AitM)攻撃、場所やVPN異常ログインなど、アイデンティティ領域の初期アクセスの主要部分をターゲットとしています。

データによると、この機能は脅威アクターの活動に大きな打撃を与え、現在では毎月3,000~6,000件の初期アクセス事例を阻止しています。

しかし、サイバー防御の本質として、現状に満足してはいけません。ハッカーは映画『アイ・アム・レジェンド』のゾンビのようなものです。

なぜか?どちらも直射日光にさらされると燃えます。しかしもっと重要なのは、どちらも時間が経てば進化し、現在の防御策が無意味になる点です。だからこそ、私たちは新たな攻撃チェーンの特定と分断の道を探し続けます。

特に注目すべき研究分野の一つが、ローグアプリ(Rogue App)の概念です。クラウドアプリケーションはユーザー体験の中核であり、開発者にとって強力なツールキットを提供します。しかし、最近分かったことは、クラウドアプリの魅力的な利点は、管理者やアプリ開発者だけでなく、サイバー犯罪者にとっても魅力的な選択肢となることです。

これは、初期アクセス対策システムをすり抜けた攻撃を探す次の最適な場所のように思えました。

そこでチームは、いくつかのリサーチクエスチョンを設定しました。AzureでOAuthアプリケーションはどのように機能するのか?攻撃時にどのように活用できるのか?なぜサイバー犯罪者にとって強力で便利なのか?これらのローグアプリを狩る最善の方法は?そして最後に、私が恐怖を感じた質問――一体どれだけ存在するのか?

Image
図1: テスト環境でのアプリケーション登録の現在のリスト。運が良ければ、あなたの環境には「not a backdoor」と名付けられたアプリが複数存在しないはずです。

これらの質問の答えを探す中で、予想以上のものを得ることになりました。

システムの仕組み: OAuthアプリの動作

しっかりつかまってください。ここからはAzureアプリケーションの仕組みについての短期集中講座です。最初に言っておきますが、このシステムは複雑で奇妙です。

私の理解を助けてくれたリソースの一つは、John Savill氏によるAzureアプリ登録、エンタープライズアプリ、サービスプリンシパルの技術トレーニング講義です。ちなみにJohn氏はAzure管理の認定マスターであり、この動画のサムネイルでもその概念を説明することに困惑している様子が見て取れます。

ですので、システムの細部まで完全に理解する必要はありません。このブログの目的に沿って、アプリが悪用される仕組みに直接関係する概念だけを説明します。

クラウド上のアプリは、スマホやPC上のアプリとよく似ています。何か便利なことをするために設計されたモジュール型プログラムです。AzureのアプリはEntra IDと連携し、たとえばM365アカウントでクラウドメールを整理するデスクトップクライアントを使えるようになります。

Azureはアプリケーションをエンタープライズアプリケーションアプリケーション登録の2つに分類しています。この命名規則は非常に紛らわしく、私もどちらがどちらか理解するのに時間がかかりましたが、主な違いは「あなたがそのアプリを作ったのか、それとも他人が作ったアプリを使っているのか」という点です。

エンタープライズアプリケーションは、他のテナントで誰かが作成・管理・公開したアプリを、あなたのテナントで利用しているものです。

アプリケーション登録は、あなた自身が自分のテナントで作成・管理・公開し、他の人が使えるようにするアプリです。つまり、アプリケーション登録はアプリのテンプレートのようなもので、エンタープライズアプリケーションは誰かが使っているアプリのインスタンスです。

開発者はアプリのコードを書き、自分のテナントでアプリケーション登録を作成し、公開します。

さて、ある管理者があなたのアプリを自分のテナントにインストールしたいとします。ウェブサイトを見てアプリが便利そうだと思ったのかもしれません。アプリは勝手にどこにでもインストールできるわけではありません。もしそうなら、カオスです。

したがって、認証(authN)と認可(authZ)の仕組みが必要です。通常は次のような流れになります:

  • ユーザーがアプリのインストールをリクエストします。この際、ユーザーはユーザー名・パスワード・MFAで認証し、信頼できる当事者によるインストールであることを確認します。

  • アプリには設計された目的を果たすための権限があります。たとえば、Graph API経由でユーザーのメールを取得する権限などです。アプリはユーザーに権限への同意を求めるプロンプトを表示します。

Image
図2: アプリケーションの認証・認可プロセス。サービスプリンシパルをユーザーテナントにインストールするための同意をアプリが要求しています。
Figure 3: The application authentication and authorization process. The user happily consenting to the required permissions.
図3: アプリケーションの認証・認可プロセス。ユーザーが必要な権限に喜んで同意しています。
  • ユーザーが権限に同意し、アプリにその権限に基づくリソースアクセスを許可します。認証認可が完了したことで、アプリは設計された機能を実行できるようになります。

  • サービスプリンシパルがユーザーテナントにインストールされ、このアプリのアカウントとして機能します。サービスプリンシパルは同意された権限や同意したIDを記録します。アプリがテナントにインストールされている間、サービスアカウントがアプリの代理として動作します。

Figure 4: the authentication and authorization process. With both sorted out, the app installs a service principal in the user’s tenant.
図4: 認証・認可プロセス。両方が完了すると、アプリはユーザーテナントにサービスプリンシパルをインストールします。

前のセクションが退屈で飛ばした方もいるかもしれませんが、要点は以下の通りです:

  • アプリは社内開発(アプリケーション登録)または他テナントからのインストール(エンタープライズアプリケーション)で構築できます。

  • アプリはテナント内の1人または複数のユーザーの代理としてリソースに委任アクセスできます。

  • Azureアプリは組み込みの認証・認可システムを利用して動作します。

  • アプリがどこかにインストールされるたびに、そのテナントにサービスプリンシパルがインストールされ、アプリの作業アカウントとして機能します。

  • そして最後に、Azureのデフォルト設定では、どのユーザーでもアプリをインストールし、自分のリソースアクセスに特化した権限に同意でき、アプリの審査は不要です!

ここには、悪用のための素晴らしいプリミティブが揃っています。

なぜか?大規模で複雑な認証・認可システムを運用したことがある人なら、攻撃者はシステムの修正不能な隙間を突いて悪用するのが大好きだと教えてくれるでしょう。

Kerberoasting攻撃を実行したことがあるレッドチーム担当者なら、最良の悪用プリミティブはバグではなく機能であり、したがって修正できないことを知っています。Azureのアプリもこの原則に従っています――良くも悪くもエコシステムの一部です。

そのカスタマイズ性により、攻撃者は自分の攻撃タイプに合わせてアプリを調整する多くの選択肢を持ちます。そして、このシステムがいかに分かりづらいかを考えると、ほとんど目立たずに活動できます。

Azureでアプリを使う場合、善悪問わず、アプリが機能する正当な枠組みの中に完全に収まっています。脅威アクターにとって、これは非常に強力な遊び場です。実際にどれほど有用なのか、これから見ていきましょう。

HuntressのIdentity Security Assessmentを活用する

「安全だろう」から「安全だと確信」へ。Identity Security Assessmentで実現しましょう。

Managed ITDRトライアルを開始して、Microsoft 365テナント内のローグアプリ、疑わしいログイン、隠れた受信トレイルール、リスクの高いアクセス活動を発見しましょう。カスタマイズされたIdentity Security Assessmentがあなたの受信箱に届きます。

最悪の場合?何かが見つかります。最良の場合?あなたは知ることができます。

Assessmentを活用する

Traitorware: 善良なアプリの裏切り

バールは非常に便利な道具です。木箱を開けたり、ドアが詰まったときにこじ開けたり、運が良ければニューメキシコの砂漠にある巨大な地下研究施設から脱出できるかもしれません。最後のネタが分かった方は、バイブチェック合格です。

バール自体は善でも悪でもありません。さまざまな文脈で役立ちます。そして、その文脈がバールをどう見るかを決めます。物資の箱を開ける場合も、誰かの家に侵入する場合も、バール自体は変わりません。もちろん、すべてのバールが常に悪いわけではありません。しかし、誰かが家に侵入しているのを見かけたら、たいていバールを持っています!

Azureアプリの世界で、私たちが最初に狩るアプリのカテゴリはバールに似ています。これをTraitorwareと呼びます。

この用語は、悪意を持って設計されたわけではないが、ハッカーやサイバー犯罪者、怪しい人物にとって非常に便利なアプリを指します。私たちは、攻撃で圧倒的に多く使われているアプリを狩ります。たとえそのアプリ自体が悪でなくても。

エンドポイントセキュリティで最も近いアナロジーは、「Living Off the Land」と「Bring Your Own tools」の中間でしょう。この攻撃タイプは、エンドポイント侵入時のリモート監視・管理(RMM)インストールに最も似ています――脅威アクターが正規ツールを持ち込み、それが怪しい目的に役立つというものです。

Figure 5: Traitorware, aka Good Apps Gone Rogue. Every app has a Jekyll and Hyde scenario. 
図5: Traitorware、すなわち善良なアプリの裏切り。すべてのアプリにはジキルとハイドの側面があります。

この記事執筆時点で、私たちが「決定的証拠」とみなすアプリは5つあります。統計的に見て、これら5つのアプリは攻撃者に好まれています。約1,500件の報告インスタンスと平均1.8%の偽陽性率というサンプルサイズから、これらのアプリを検出することで正規利用よりもはるかに多くのハッキング活動を発見できることがデータで裏付けられています。

これまでにまとめたTraitorwareアプリの完全リストと、それらがどのように悪用されることが多いかの詳細は、Rogue Appsのオープンソースリポジトリで公開しています。

同様の悪用事例を見たことがある方は、ぜひご連絡ください!PRを送ってナレッジベースに貢献していただければ、この新たな攻撃面をより明確に定義・追跡できます。

Stealthware: 農場直送の悪意あるアプリ

一方で、Azureアプリのエコシステムは、ハッカーがゼロから破壊を目的としたアプリを作るためのツールも提供しています。

ここで言うのは、農場直送、小ロット、自家製、倫理的調達、放し飼い、イルカに優しい、職人手作りの悪意あるアプリです。ハッカーの手で作られ、あなたのテナントに直接届けられます。

これらの攻撃の正式名称は「OAuth不正同意付与攻撃」ですが、犬をCanis Lupusと呼ぶようなものです。科学的命名法を使うのはオタクだけなので、私のようなクールなオタクになりたい方はStealthwareと呼びましょう。

Stealthwareアプリのハンティングで厄介なのは、2つとして同じものがないことです。特定のアプリ名で探すことはできません。各アプリはハッカーの目的に合わせてカスタムメイドされます。

教育目的での作り方は、Tradecraft Tuesdayのエピソードで解説していますので、興味があればご覧ください。

Figure 6: Stealthware, the imposter among Azure applications. Built to wreak havoc, built to blend in.
図6: Stealthware、Azureアプリケーションの中のインポスター。破壊のために作られ、紛れ込むために作られた。

ハントの実践

脅威モデルが固まったところで、データに飛び込み、「そのシロアリ1匹以外に、あと何匹いるのか?」という問いの答えを探す時が来ました。私とスタッフ脅威オペレーション開発者Christina Parryは、データ収集の旅に出ました。

複数の業界・業種にまたがる8,000以上のテナントを列挙し、すべてのエンタープライズアプリケーションとアプリ登録を収集し、膨大な分析を実施し、2024年10月のBSidesNYCで調査結果を発表しました。要点は以下の通りです:

  • 調査対象テナントでTraitorwareとStealthwareの両方の証拠を発見しました。

  • 調査対象テナントの約10%に、少なくとも1つのTraitorwareアプリがインストールされていました。

  • グローバルな希少性、アプリごとの割当ユーザー数、アプリに付与された権限の組み合わせでStealthwareを効果的に狩ることができます。

  • 調査対象テナント全体で1%未満の普及率かつ単一ユーザーに委任アクセスしているアプリは、Stealthwareである可能性が高いです。OAuth権限を侵入時にハッカーができることに基づいてグループ化し、希少かつ強力な権限を持つアプリを検出することで、ヒット率が大幅に向上しました。

発表後、私たちはデータを拡張し、すべてのHuntressパートナーテナントのデータを収集するシステムの構築に取り組みました。再分析と調整の結果、Traitorwareアプリに関する発見は約10%で一貫していました。

調査結果公開後、Huntress SOCも新しいテレメトリを活用してハンティング仮説を立て、パートナーテナント全体で500件以上のStealthwareアプリの事例を特定しました。

前述の通り、Stealthwareはアプリ名で探せないことを示しました。以下は、実際に発見された正真正銘の悪意あるアプリ名の一部です:

図7: 奇妙な悪意あるアプリ名のサンプル

いくつかの仮説が証明されたことで、ついに結論を出せる状況になりました。OAuthアプリ攻撃はHuntressパートナーテナンシーに存在するだけでなく、私たちの予想以上に蔓延していました。中には、発見時点ですでに数年存在していたアプリもありました。

この記事から何か一つでも持ち帰ってほしいのは、統計的に見て、あなたのテナントにもこれらのアプリが感染している可能性が高いということです。

紹介: Cazadora

ここまで読んで「やばい、アプリを監査した方がいいかも」と思った方、素晴らしい!それは、Azureアプリエコシステムにどれだけ攻撃の可能性があるかを十分に示せた証拠です。

コミュニティ教育の加速と、Azure管理者がシロアリの巣を一掃するための手助けとして、テナント内のアプリを列挙し、怪しい特徴を持つアプリを見つけ出すオープンソースツールを作成・公開しました。

Figure 8: The output of Cazadora, identifying a few apps that have suspicious characteristics.
図8: Cazadoraの出力例。いくつかの怪しい特徴を持つアプリを特定しています。

紹介します: Cazadora、超シンプルなAzureアプリハンティングスクリプトです。Huntressパートナーでなくても、誰でもこのスクリプトを実行し、テナント内のアプリをよく見られる攻撃手法の特徴に照らして監査できます。

自分のユーザー認証を使い、Graph APIを呼び出し、テナントのエンタープライズアプリケーションとアプリ登録に関するデータを取得し、ハンティングロジックを実行します。

動作は素早く、やや荒削りですが、Azure管理者がテナント内の「決定的証拠」アプリを即座に把握できるようにするのが狙いです。

もちろん、このスクリプトですべての悪意あるアプリを100%見つけられるわけではありません。何も見つからなくても、テナントが悪意あるアプリから安全だとは限りません。しかし、少なくともAzure管理者がアプリを監査し、明らかな問題を特定するための素晴らしい出発点となります。

使い方はリポジトリのREADMEをご覧ください!ぜひ試してみてください。何が見つかるか、それとも…

ITDR Assessmentを活用する

統計的に見て、何かが見つかる可能性は高いです。Huntress Identity Security Assessmentは、Microsoft 365のアイデンティティ脅威状況を明確に把握できます――ライセンスタイプ、ローグアプリ、疑わしいログイン、悪意ある受信トレイルールをハイライトします。

脅威が見つからなかった場合でも、私たちが監視・ハンティングしている主要領域や脅威についての貴重な知見が得られます。

最悪の場合?リスクを発見。最良の場合?安全が確認できます。どちらにしても、有益な情報と自信を得られます。ぜひご確認ください

状況認識を維持――Tradecraft Tuesdayに登録しよう

Tradecraft Tuesdayは、サイバーセキュリティ専門家向けに最新の脅威アクター、攻撃ベクター、対策戦略の詳細な分析を提供します。

毎週のセッションでは、最近のインシデントの技術的なウォークスルー、マルウェア動向の包括的な解説、最新の侵害指標(IOC)が紹介されます。

参加者は以下を得られます:

  • 新たな脅威キャンペーンやランサムウェア亜種に関する詳細なブリーフィング

  • 証拠に基づく防御手法や復旧技術

  • Huntressアナリストとの直接対話によるインシデント対応の洞察

  • 実践的な脅威インテリジェンスや検知ガイダンスへのアクセス

組織の環境を守る責任を持つ方のために設計された、リアルタイムのインテリジェンスと技術教育で防御態勢を強化しましょう。

Tradecraft Tuesdayに登録する →

スポンサーおよび執筆: Huntress Labs

翻訳元: https://www.bleepingcomputer.com/news/security/find-hidden-malicious-oauth-apps-in-microsoft-365-using-cazadora/

ソース: bleepingcomputer.com