Cloud Security

ゴーストログインがMFAを迂回し、SIEMとSOCを欺く

「ログは嘘をつかない」なんて過去の話だ。Entra IDの「成功」イベントが、実際のデータアクセスがないにも関わらず、正規のものに見せかけられる新たな攻撃手法が登場した。攻撃者がセンサーを弄んでいる間に、君のSIEMは「すべてクリア」と叫んでいるかもしれない。

{# Always render the hero — falls back to the theme OG image when article.image_url is empty (e.g. after the audit's repair_hero_images cleared a blocked Unsplash hot-link). Without this fallback, evergreens with cleared image_url render no hero at all → the JSON-LD ImageObject loses its visual counterpart and LCP attrs go missing. #}
抽象的なネットワークノードとデータフローの表現に、疑問符とエラーシンボルが追加され、欺瞞的なセキュリティイベントを示唆している。

Key Takeaways

  • 攻撃者はEntra IDでMFAと条件付きアクセスを迂回する「成功」したログインイベントを作成できるが、実際のデータにはアクセスしない。
  • クロステナントROPCを利用したこの手法は、SIEMを偽陽性で氾濫させ、ML/UEBAモデルを汚染し、SOCチームを無駄な調査に駆り立てる。
  • 真の危険は直接的なデータ窃盗ではなく、SOCチームへの運用上の負担、監査のためのログ整合性の侵害、そして実際の攻撃を隠蔽する可能性にある。

サイバーセキュリティのログについて、これまで知っていたことを一旦忘れよう。我々は20年近く、「ログは嘘をつかない」という、しばしば盲目的ながらも安心できる信仰のもとに生きてきた。SIEM、ユーザー行動分析、自動化されたプレイブックといった、我々のセキュリティ体制のすべては、ログイン失敗と成功を区別するという礎の上に築かれている。では、攻撃者が君のEntra ID(旧Azure AD)環境で、あたかも正規のサインインのように見せかけることができたとしたらどうなるだろう? MFAや条件付きアクセスポリシーをやすやすと突破したように見える認証成功イベント、しかも君の実際のデータには一切触れることなく、だ。これはVaronis Threat Labsが明らかにした、実に不穏な現実であり、正直、このベテラン記者の夜も眠れなくさせる類の代物だ。直接的なデータ盗難が差し迫った脅威ではないかもしれないが、君のセキュリティ運用、予算、そしてデータ記録の整合性そのものに対する下流への影響? それらははるかに陰湿だ。

クロステナントROPC:ログインのないログ

そのトリックは、リソースオーナーパスワード認証(ROPC)プロトコルの特定のニュアンスと、「クロステナント」アーキテクチャに隠されている。要点はこうだ:攻撃者は君の組織(テナントAとしよう)の有効なユーザー名とパスワードを入手する。通常なら、強力なMFAやレガシープロトコルブロックがドアを閉ざすだろう。しかし、この攻撃ベクトルは巧妙だ。攻撃者はテナントAに直接ログインしようとするのではなく、同じ認証情報を使って、全く異なる、はるかに緩いテナント(テナントB)で認証を行うのだ。

ここで事態が厄介になる。

君のテナント(ターゲットであるテナントA)はパスワードを検証する。ドカン。これで「サインイン:成功」イベントが生成される。一方、攻撃者が実際に接続している 別の テナント(テナントB)は、それ自身の 条件付きアクセスポリシーをチェックする。テナントBは、このユーザーや認証情報に対して何の問題もないため、認証はスムーズに通過する。結果はどうなる? 君のSIEMはクリスマスツリーのように点灯し、あたかも君が苦労して築いたすべての防御を迂回したかのように、成功したログインを誇らしげに宣言する。多くの監視ツールにとっては、これで一件落着だ。ユーザーはログインし、問題なし。もちろん、実際には巨大な問題が山積しているのだが。

井戸に毒を盛る:真の危険

攻撃者はテナントBに閉じ込められているため、直接君のファイルにアクセスできないとしても、君のセキュリティ体制への影響は、控えめに言っても、極めて懸念される。この現代のセキュリティサーカスでは、混乱は攻撃者の親友だ。

では、これがどのように井戸に毒を盛るのか?

まず、ユーザーおよびエンティティ行動分析(UEBA)と機械学習モデルを考えてみよう。これらのシステムは、「通常」がどのようなものかを学習するように設計されている。君のログを、怪しげな地理的場所や、見たこともないIPアドレスから、ありえない速さで大量の偽の「成功」ログインで氾濫させることで、攻撃者は実質的に、君のモデルに実際の脅威を無視するように訓練するのだ。1時間に50カ国からログインしたユーザーを、単なる異常ではなく、侵害の重大な兆候としてシステムがフラグを立てるのを想像してみろ。これは、影で起こっている本当の攻撃を完全に隠蔽するほどのノイズを生み出す。さらに悪いことに、セキュリティ制御はこれらの偽のアラートに反応し始め、現実に基づかないデータに基づいて、重要な本番システムを混乱させる可能性がある。

SOCへの税金:幽霊のために流す血と汗と涙

これらの偽陽性の一つ一つに値札がついており、それはアナリストの時間と予算で支払われる。セキュリティアナリストが、悪名高い悪いIPからの「成功」ログインを発見したとする。何が起こるか? 彼らは行動を起こす。CISOは必死の電話を受ける。ユーザーアカウントは無効化される。文字通り発生しなかった侵害の調査に、何時間もの時間が費やされる。攻撃者はこれを自動化できる。スクリプト化できる。毎日、これらの「ゴーストログイン」を何千も君のシステムに氾濫させることができる。これは単に迷惑なだけではない。それは君の最も価値があり、最も高価なリソース、すなわち人間のアナリストを標的とした、高度なサービス拒否攻撃だ。君は幽霊を追いかけるために予算と人員を燃やさなければならない。

コンプライアンスの悪夢?ああ、もちろんだ。

監査担当者に、ユーザーXからのMFAなしで500件の「成功」ログインがログに記録されているとどう説明するか? MFAは すべてのアカウント に強制されるはずなのにだ。君のログの整合性? ぶっ壊れだ。君はもはやイベントの真の記録を見ているのではなく、歪められ、操作された現実のバージョンを見ているのだ。そしてそれは、諸君、コンプライアンス担当者にとって最悪のシナリオだ。

Varonisは正しいことをした、これをMicrosoftに報告した。そして、神の御加護を、Microsoftはこれを「低度」と評価した。彼らの論理は? データアクセスなし、直接的な侵害なし。純粋に技術的、リソースアクセスという観点からは、理解できる。しかし、最前線から見れば? SOCを管理しようとするCISOにとって、君のセキュリティを検証しようとする監査担当者にとって、その深刻度は低いどころではない。

SOCおよび監査の観点からは、懸念は依然として大きい。防御側はこれらのイベントを依然として意味のあるアクセスがあった証拠と解釈し、リソース侵害を必ずしも反映しないテレメトリに基づいて調査、アラート、インシデント対応ワークフローをトリガーする可能性がある。

率直な真実はこうだ:静的なログだけではもはや十分ではない。 多くのベンダー、そしてMicrosoftでさえ、ROPCを見て「低度」と見なすのは、直接データが流出していないからだ。しかし、真の危険は コンテキスト、いや、むしろその完全な欠如にある。「彼らはログインしたか?」と尋ねるのをやめ、「彼らはデータにアクセスしたか?」「我々のテナント 内部 のリソースにアクセスしたか?」という難しい質問を始める必要がある。君のセキュリティツールが玄関ドアしか見ていないなら、偽のドアベルの音に簡単に騙される可能性がある。家 の中 で何が起こっているかを知る必要があるのだ。

だから、次にSIEMルールを構築するとき、あるいはアラートを確認するとき、その認証ログに知的な塩を少し振りかけろ。それらは常に、見かけほど正直ではない。

なぜこれは私のSOCにとって重要なのか?

このクロステナントROPC攻撃は、君のセキュリティオペレーションセンター(SOC)の運用効率と精度に対する直接的な攻撃だ。それは、君のSOCが脅威を検出し対応するために依存しているデータそのものを武器化する。MFAや条件付きアクセスといった主要な認証制御を迂回するが、実際のデータへのアクセスを許可しない「成功」したログインを数千件生成することで、攻撃者は偽陽性の洪水を生み出す。これにより、SOCアナリストは存在しないインシデントの調査に貴重な時間を費やさざるを得なくなり、リソースと予算を枯渇させる。さらに、欺瞞的なデータを与えることで、UEBAやMLモデルを汚染し、通常の活動のように見せることで実際の脅威を隠蔽する可能性がある。最終的に、この手法は直接的なデータ窃盗ではなく、データが本当に危険にさらされている 検出能力 を crippled することなのだ。

これは私の仕事を置き換えるのか?

いいえ、この特定の手法が直接君の仕事を置き換えるわけではないが、君の仕事を間違いなくより困難にし、適切に対処されなければ、君の既存のツールを効果を低下させる可能性がある。「ゴーストログイン」の目的は、君のセキュリティチームとシステムを過負荷にし、混乱させることであり、それらを排除することではない。セキュリティアナリストのコアワーク — 調査、脅威ハンティング、インシデント対応 — は依然として極めて重要だ。しかし、この攻撃は、単純な「ログイン成功/失敗」の指標を超えた、より洗練された検出方法の必要性を浮き彫りにする。君は、認証イベントそのものではなく、君のテナント内での 実際の リソースおよびデータアクセスを検証することに焦点を当てる必要がある。これは、より深い可視性とコンテキストを提供するツールの導入と設定、そして直接的な不正アクセスだけでなく、欺瞞のパターンを探すために君の脅威ハンティング戦略を適応させることを意味する。


🧬 関連インサイト

よくある質問

リソースオーナーパスワード認証(ROPC)プロトコルとは何をするのか? ROPCは、アプリケーションがユーザーのユーザー名とパスワードを直接処理するレガシー認証フローだ。アプリケーションに認証情報がより直接的に露呈する可能性があり、ネイティブに多要素認証(MFA)をサポートしないため、OAuthやOpenID Connectのような最新のプロトコルよりも一般的に安全ではないと見なされている。

Entra IDでこのクロステナント攻撃はどのように機能するのか? 攻撃者は、自身のホームテナント(テナントA)とは 異なる テナント(テナントB)で認証するために、有効なユーザー認証情報を使用する。テナントBのポリシーが最終的に(制限された)認証フローを許可するとしても、パスワードが有効であるため、テナントAはこのログインを「成功」として記録する。これにより、テナントAのデータやリソースへのアクセスを許可することなく、テナントAに欺瞞的な「成功したログイン」ログが作成される。

なぜMicrosoftはこの攻撃を低度と呼ぶのか? Microsoftの評価は、直接的な影響、すなわちユーザーデータやテナントリソースが侵害されていないことに焦点を当てている可能性が高い。彼らの見解では、セキュリティの主な目的は、データとサービスへの不正アクセスを防ぐことだ。それが起こっていないため、直接的なリスクは低く評価されている。しかし、この記事は、SOC運用、監査可能性、そして実際の攻撃を隠蔽する可能性への影響が、防御側にとっては重大な懸念事項であると主張している。

Written by
Threat Digest Editorial Team

Curated insights, explainers, and analysis from the editorial team.

Worth sharing?

Get the best Cybersecurity stories of the week in your inbox — no noise, no spam.

Originally reported by Varonis Blog