知らない従業員がハッカーのデバイスを自分のアカウントに登録してしまい、その後、犯人は生成されたOAuthトークンを使用して永続的なアクセスを維持します。
OAuthデバイス登録を悪用して多要素認証ログイン保護をバイパスする別のデバイスコードフィッシングキャンペーンが発見されました。
KnowBe4の研究者によると、このキャンペーンは主に北米企業やプロフェッショナルを対象に、脅威アクターからのメール内のリンクをクリックするよう知らない従業員をだまして実施されています。
メッセージは、企業の電子資金送付、給与ボーナスに関する文書、ボイスメール、または他の誘い文句について述べたものであるかのように装っています。また、「セキュアな認可」のコードが含まれており、ユーザーがリンクをクリックするとそのコードの入力を求められ、実際のMicrosoft Office 365ログインページに移動します。
被害者はログインページが正当であるため、メッセージが正当だと考え、コードを入力します。しかし、被害者が知らないのは、実はそれは脅威アクターが制御するデバイスのコードであるということです。被害者がしたことは、OAuthトークンを発行してハッカーのデバイスに自分のMicrosoftアカウントへのアクセス権を付与することです。そこから、ハッカーはそのアカウントが従業員に使用を許可するすべてのものにアクセスすることができます。
これは認証情報の盗難についてのものではないことに注意してください。ただし、攻撃者が認証情報を望む場合は、盗難される可能性があります。これは被害者のOAuthアクセストークンとリフレッシュトークンを盗み、Outlook、Teams、OneDriveなどのアプリケーションを含む、Microsoftアカウントへの永続的なアクセスを得ることについてです。
Microsoft 365を含む特定のサイトがOAuth 2.0デバイス認可付与プロセスを使用してアカウントへのデバイスの追加を許可しているため、これは機能します。これは、住宅所有者がスマートテレビをNetflixに追加する方法に似ています。
KnowBe4はそれを新しい攻撃と呼んでいますが、Johannes Ullrich（SANS研究所の研究部長）はそれを「古く新しい」と呼んでいます。
トレンドマイクロによると、Pawn Stormという脅威アクターは2015年にさかのぼるほど前からフィッシングキャンペーンでOAuthを活用しています。2020年にマイクロソフトはユーザーに「同意フィッシング」について警告しました。これは脅威アクターがOAuth 2.0プロバイダをインストールすることで、攻撃者が制御するアプリケーションがデータにアクセスするための許可を求めるものです。Ullrichはある従業員がこれらのフィッシングメールの1つに引っかかったことを認めました。
この攻撃の最新版に対する主な防御は、ユーザーが自分のアカウントに接続することを許可されているアプリケーションを制限することです、と彼は述べています。Microsoftはエンタープライズ管理者に、ユーザーがOAuthを通じて認可する可能性のある特定のアプリケーションをホワイトリストに登録する機能を提供しています。
Roger Grimes（KnowBe4のCISO顧問）は2020年にデバイスコードフィッシングについて書きました。木曜日のインタビューで、彼は最新の戦術の特徴は被害者が有効なドメインにログインし、目標はユーザーのデバイストークンを取得することだと述べました。
「ユーザーは正当なポータルにログインしている意味で、何も悪いことをしていません」と彼は述べました。「ログインしているURLを見ると、それはmicrosoft.comです。しかし、攻撃者は[被害者]が確認するためのコードを取得するため、事前にデバイスを登録しています。」
David Shipley（カナダのセキュリティ意識向上トレーニングプロバイダであるBeauceron Securityの責任者）は、OAuthデバイスコード攻撃は2024年以降増加していると述べました。「これはアカウントセキュリティ、特にMFAの改善に対する自然な進化的反応です」と彼は述べました。
最も簡単な防御は、必要でない限り、Office 365に追加のログインデバイスを追加する機能をオフにすることです、と彼は述べました。
さらに、従業員は、なじみのあるシステムからのものであっても、異常なログインリクエストのリスクについて継続的に教育を受けるべきです。
「このような新しいソーシャルエンジニアリング技術について人々に教え、このような種類の攻撃に基づいてフィッシングシミュレーションを実施することの価値は、人々がそれらの報告に慣れるようになり、実際の攻撃が発生しているときに役に立つことです」と彼は付け加えました。
Cory Michal（AppOmniのCSO）は、攻撃は多くの場合、OAuthトークンとサービス/統合アイデンティティを活用していると述べました。これは、アイデンティティ強化と多要素認証に多額の投資をしてきた多くの組織の盲点です。
「OAuthトークンはしばしばベアラー認証情報として機能します」と彼は述べています。「攻撃者がそれらを取得した場合、対話型のログインやMFAチャレンジをトリガーすることなく、統合として機能するために単一要素アクセス方法として使用され、アクティビティは通常のAPI/統合パターンに溶け込む可能性があります。言い換えると、非人間のアイデンティティとOAuthトークンの衛生が同じ厳密さで管理・監視されていない場合、強力なMFA強制は永続的な曝露と共存することができます。」
彼は、IT指導者がクラシックな第三者ベンダーレビューを超えて、実際にSaaS環境で実行されている統合をインベントリーおよび監査し、どのアプリが接続されているか、OAuthスコープ/権限が何か、またそれらがまだ必要かどうかを決定する必要があると述べました。
「ほとんどのチームは気付いている以上に多くの統合を持っており、多くは元の事業需要の後ずっと広範な権限を保持しています」と彼は指摘しました。
「同時に、私たちが依存するあらゆるSaaSベンダーのセキュリティ基準を引き上げるべきです。トークンセキュリティ、ロギング、インシデント対応、セキュアな統合パターンに関する明確な要件を持ち、自分たちのテナント構成と監視がハードン化されていることを確認し、統合アクティビティは最小権限で、監視可能で、上流で何かが侵害された場合に迅速に対応可能です」とMichalは付け加えました。
Grimesは、ユーザーは自分のMicrosoft、Google、および他のログインアカウントにアクセスするために認可されているデバイスがいくつあるかを確認するよう教育できると述べました。また、ログインページに移動するメールリンクを継続的に疑うよう警告する必要があります。
デバイスコードフィッシングに関するブログでは、彼は条件付きアクセスポリシーでMicrosoft Entra管理者が「デバイスコードフロー」を無効にできることを指摘しました。これはEntraのすべてのデバイスコードユーザーを無効にします（悪意のあるユーザーだけではなく）。これは、ユーザーがデバイスコード以上の情報を提供してログインする必要があることを意味しますが、このタイプのフィッシング攻撃からIT環境をより適切に保護します。
