はじめに
ネクストリードでは、Microsoft 365 をご利用のお客様のアラート監視やログ分析をサービスとして提供しており、セキュリティ侵害を早期発見し、より強固なセキュリティ構成を実現するためのお手伝いをしています。
先日弊社のお客様の環境で Microsoft Entra ID (Azure AD) の 「多要素認証がバイパスされた」 と思われる事象を確認しましたので、お客様の許可を得て注意喚起を兼ねてブログにしたいと思います。
経緯
下記のサインイン履歴を確認して分かる通り、今回被害にあったユーザーは普段は日本（青）からサインインをしていますが、7/10 にルーマニア（オレンジ）とウクライナ（紺）から立て続けにサインインが成功したことを検知しました。
お客様では「社外からのサインインは MFA を強制する」というアクセス制御ポリシーになっているため、上記のサインインに対しても MFA が強制されていましたが、なぜかサインインが成功している状況でした。
検知後すぐにお客様に連絡を取ったところ、該当ユーザーが上記のサインインに身に覚えがないとのことで、パスワード リセットと MFA の再登録を実施する対応を実施しました。
今回は MFA に成功していたため、当初は私たちもユーザー本人によるサインインである可能性が高いと考えていました。例えば、VPN などを使用するとこのようなログになる場合があります。Azure AD もリスクを検知していませんでした。
しかし、アクセス先のアプリケーションの傾向が普段と異なることや、ログのうちの 1 つのユーザーエージェントが不審であったことなどから念のため連絡したところ、意図していないサインインであり、攻撃であったことが判明しました。
サインイン ログの分析
最初にルーマニアから攻撃によるサインインが成功した際のログは下記のような状況でした。
ResultType が 50074 のログは「追加で多要素認証が必要」というサインインがまだ成功していない状況を示していますが、50140 や 0 はサインインが成功したことを示しています。
MfaDetail という列を確認すると "Text message" という文字列が確認できますが、これは該当ユーザーが SMS のワンタイムパスコードを使用して MFA を実施できる状態であることを示しています。
実は、上記のログは少し不思議な状況を示しています。
下記は同じようなログを後日弊社で再現させたログです。MFADetail を確認すると、最初に {} が記録され、その後に {"authMethod":"Text message"} が記録されていることが再現できます。ResultType が 50074 であるところも同じように再現できていますね。
しかし、私たちがテストしたところ MFA の応答に成功すると、次に {"authMethod":"Text message","authDetail":"+XX XXXXXXXX50"} のように authDetail という要素を含むログが記録されることが分かっています。今回の攻撃ではこのようなログは出力されていないにも関わらず、サインインが成功していました。
今回の攻撃がどのように行われているのか色々と調査を実施しましたが、結論としては現在も不明なままです・・。どなたかアイディアがあればお知らせください。
MFA (SMS) の流れ
調査の中で、MFA（少なくとも SMS）は下記のようなフローで行われることを確認しました。
① GET https://login.microsoftonline.com/common/oauth2/authorize?client_id=...
クライアントが認証要求を行います。パスワードを入力するフォームが提示されます。
② POST https://login.microsoftonline.com/common/login
パスワードを送信します。認証に成功したら MFA の選択肢が提示されます。
③ POST https://login.microsoftonline.com/common/SAS/BeginAuth
MFA の選択肢から SMS を選択します。OTP が SMS で送信され OTP 入力ページが表示されます。
④ POST https://login.microsoftonline.com/common/SAS/EndAuth
ブラウザに SMS に届いた OTP を入力して送信します。MFA に成功したことを示すセッション情報が返されます。
⑤ POST https://login.microsoftonline.com/common/SAS/ProcessAuth
MFA が成功したことを示すセッション情報を送信します。リソースへのアクセスができるトークンが返されます。
上記のフローの中でログの MfaDetail がどのように記録されるかを確認したところ、② で {}、③ で {"authMethod":"Text message"}、④ で {"authMethod":"Text message","authDetail":"+XX XXXXXXXX50"}、⑤ で {} が記録されると思われます。（ただし、サインインが滞りなく成功すると省略されたりマージされる場合もある気がします。）
このことを考慮すると、今回は何らかの方法を使って ④ の処理をバイパスする方法が存在する可能性が示唆されます。被害にあったユーザーも SMS による OTP 送信は特になかったとのことでした。
おわりに
本投稿では、私たちのお客様で発生した MFA バイパスと思われる事象について、注意喚起を兼ねて報告させていただきました。
ゼロトラストの原則の 1 つとして "Assume Breach (侵害前提)" があります。攻撃側は新しい攻撃を次々を生み出してくるため、防御側である私たちも常に知識や技術をアップデートし続ける必要があります。
多要素認証の必要性が叫ばれて久しく、まだ多要素認証の展開が終わっていない企業は早急に展開を進める必要があることはこれまでと変わりません。
そのうえで、より強度の高い MFA 要素（FIDO2 や Windows Hello for Business 等）をが必要な時代になってきています。多要素認証だけでは周回遅れかもしれません。
弊社では Microsoft 365 のセキュリティ強化を得意としていますので、ご相談があればぜひご連絡ください。