ハッカーがMicrosoftの正規機能であるデバイスコードフローを悪用し、多要素認証(MFA)を回避してMicrosoft 365アカウントを乗っ取る事例が増加しています。信頼された認証の仕組みが、密かなアカウント乗っ取りの手段に変貌しているのです。
本記事では、この攻撃がどのように機能し、なぜ確実にMFAを回避できるのか、そして防御側が検知・阻止するために何ができるのかを解説します。
OAuth 2.0デバイス認可グラント(デバイスコードフロー)は、スマートTV、会議室システム、一部のIoT端末など、ログイン画面を表示したりキーボード入力を受け付けたりすることが難しい「入力制限デバイス」向けに設計された仕組みです。
通常のシナリオでは、デバイスが短いコードをリクエストし、ユーザーは別の信頼できるデバイスでMicrosoftのサインインURLにアクセスしてそのコードを入力、MFAを完了させます。すると、Microsoftはアクセス権を要求した元のデバイスにトークンを発行します。
デバイスコードフィッシングでは、攻撃者はこの入力制限デバイスになりすまし、Microsoft Entra IDに対して正規のデバイスコードリクエストを発行することで、自分たちのインフラに紐づいた有効なワンタイムコードを取得します。
続いて攻撃者は、文書共有メールやQRコード、「アカウント確認」プロンプトといった巧妙な誘導手口を使い、被害者を本物のMicrosoftサインインページへ誘導して攻撃者のコードを入力させ、通常どおりMFAを完了させます。
この一連の流れはすべて本物のMicrosoftページ上で、正当なMFAを経て行われるため、結果として発行されるOAuthアクセストークンおよびリフレッシュトークンは、被害者ではなく攻撃者側のシステムに渡ってしまいます。つまり、被害者の信頼されたデバイスが、事実上「認証情報のロンダリングサービス」と化してしまうのです。
トークンを手に入れた攻撃者は、パスワードを盗んだり使い回したりすることなく、Outlook、OneDrive、SharePoint、TeamsといったMicrosoft 365サービスにログインできるようになります。
重要な点として、これらのトークンはパスワードをリセットした後もそのまま有効であり続けることが多く、IDに関する制御機能が明示的にトークンやセッションを無効化しない限り、長期間にわたって攻撃者の侵入が維持されてしまいます。
最近Microsoft 365テナントを標的とするキャンペーンでは、単発の稚拙なフィッシングメールではなく、複数段階のソーシャルエンジニアリングから始まります。これにより、デバイスコードのリクエストが通常の業務フローの一部であるかのように見せかけられています。
攻撃者はGoogle Sites、侵害された企業のリダイレクト、クラウドワーカーといった信頼済みのサービスを連鎖させて誘導ページや確認ページをホストし、その上で「確認コード」をMicrosoft公式のデバイスログインポータルに入力するよう指示を提示します。これにより、メールフィルターやURLレピュテーションシステムがこの一連の流れをブロックしにくくなっている、とtrendmicroは述べています。
注: IPアドレスおよびドメインは、誤って名前解決やハイパーリンク化されることを防ぐため、意図的に無害化表記(例: [.])としています。再度有効な形式に戻す作業は、MISP、VirusTotal、あるいは自社のSIEMなど、管理された脅威インテリジェンス基盤内でのみ行ってください。
SOC調査の死角を解消し、ANY.RUNで脅威をより早期に封じ込めることで、対応コストと業務への支障を軽減しましょう。
翻訳元: https://cyberpress.org/mfa-bypass-device-flow/
