Compact
true
担当領域:セキュリティ技術センター リスクハンティング・アナリシスグループ
大規模国際イベントのサイバーセキュリティ対応業務を経て、現在はインシデント対応、ペネトレーションテスト、NEC CSIRTなどの業務に従事。2×SANSメダル、2×Splunk Boss of the SOCトロフィーを保持CISSP、GCFAを保持

NECサイバーセキュリティ戦略統括部 セキュリティ技術センターの桐下です。
今回のブログでは、Pass-The-Cookieという攻撃手法について紹介します。Pass-The-Cookieは、多要素認証をバイパスすることが可能な強力な攻撃です。Office365(Microsoft365)を対象にデモを交えながら攻撃手法を紹介します。

注意事項

本ブログで紹介する内容を悪用しないでください。
攻撃に対する脅威を知ることでセキュリティ対策の強化に繋げていただくことが目的です。

Pass-The-Cookieとは

Pass-The-Cookieとは、WebアプリケーションのセッションCookieを攻撃者が何らかの手段で入手し、セッションCookieを悪用して認証をバイパスする攻撃手法です。有効なセッションCookieをブラウザに投入するだけでWebアプリケーションにログインすることが可能です。セッションCookieは、ログイン成功状態を保持しています。そのため、セッションCookieを入手し、ブラウザに投入することでID/Password認証及び多要素認証要求をバイパスし、一気にログイン成功状態に遷移することができます。Pass-The-Cookieは、Mitre ATT&CK [1]においてUse Alternate Authentication Material: Web Session Cookie(T1550.004) [2]というサブテクニックに分類されます。

ここではPass-The-Cookieの悪用例として、Office365に対して攻撃者がPass-The-Cookieにより侵入するケースを考えてみます。
前提として攻撃者は、Office365にログイン中の被害者のセッションCookieを何らかの方法で盗んだとします。攻撃者は、被害者アカウントのID/Passwordを知らず、かつ被害者アカウントがOffice365の多要素認証を設定済みであっても、有効なセッションCookieを保有していれば攻撃者が被害者アカウントになりすましてOffice365にログインすることができます。
Office365にログインできれば、SharePoint Onlineから組織内の秘密情報の入手、Exchange Onlineを悪用したビジネスメール詐欺(BEC)、被害会社や被害会社と取引がある会社を狙ったマルウェアの配布等悪用される可能性があります。攻撃者にとっては、金銭の入手、機密情報の入手等の観点で有用であろう攻撃手法です。

上述した通り、Pass-The-Cookieを成功させるためには、攻撃者はあらかじめセッションCookieを入手する必要があります。
セッションCookieの入手は 、Mitre ATT&CKにおいてSteal Web Session Cookie(T1539) [3]というテクニックに分類されます。またForge Web Credential: Web Cookie(T1606.001) [4]というサブテクニックを使用し、偽造することも可能です。本ブログでは、セッションCookieの入手(Steal Web Session Cookie)について説明します。

Pass-The-Cookieの手順のイメージ
Pass-The-Cookieの手順のイメージ
50

今回は、セッションCookieの入手方法の例として、AiTM(Adversary in The Middle)フィッシングに焦点を当てます。以降では、セッションCookieの入手からPass-The-Cookie成功までの流れをデモを交えながら紹介します。

Office365の認証の流れ

Pass-The-Cookieのデモを実施する前の参考情報として、Office365の正規の認証の流れを記載します。今回は、オンプレミスのActive Directoryと連携はせず、Azure Active Directory にて認証をするシンプルな構成で検証をしています。

まず、Office365のログインサイト(login.microsoftonline.com)に遷移します。

Office365のログイン画面1
Office365のログイン画面1
50

Office365の多要素認証の設定が完了したアカウントにID/Passwordを入力してログインします。

Office365のログイン画面2
Office365のログイン画面2
50

ユーザが正しいID/Passwordを入力した後に多要素認証が要求されます。今回は、対象アカウントにMicrosoft Authenticatorアプリを使用した多要素認証を設定しています。

Office365の多要素認証の要求画面
Office365の多要素認証の要求画面
50

Microsoft Authenticatorアプリを使って、ユーザが応答することで多要素認証が成功し、Office365に対するログインが成功しました。

多要素認証設定済みユーザのログイン画面
多要素認証設定済みユーザのログイン画面
50

通常、多要素認証を設定しているユーザは、上記の流れでOffice365にログインすることができます。
多要素認証は、通常のフィッシングや不正な認証試行に対して強力な防御手段となります。
仮に多要素認証が設定されているアカウントのID/Passwordが流出したとします。攻撃者は当該ID/Passwordを使ってログインを試行するものの、被害者ユーザが多要素認証に応答しなければ、攻撃者はログインすることができません。(多要素認証が適用できない基本認証が有効になっている場合を除きます。 [5])しかし、Pass-The-Cookieは、強力なこの防御手段である多要素認証をバイパスすることができます。

Pass-The-Cookieのデモに移ります。AiTM(Adversary in The Middle)フィッシングを利用したPass-The-Cookieの流れを紹介します。
AiTM(Adversary in The Middle)フィッシングは、その名の通り中間者攻撃を活用したフィッシングです。攻撃者はリバースプロキシとして動作するフィッシングサイトを用意し、被害者をフィッシングサイトに誘導します。そして、そのフィッシングサイトが正規のWebアプリケーションとの通信を肩代わりします。

AiTM(Adversary in The Middle)フィッシングのイメージ
AiTM(Adversary in The Middle)フィッシングのイメージ
50

フィッシングサイトは、被害者から正規サイトに登録されている被害者アカウントのID/Passwordを受け取り、それをそのまま正規サイトにリクエストします。正規のID/Passwordを使ったリクエストなので、正規サイトはフィッシングサイトからのリクエストであっても、被害者からのリクエストと同様に処理します。通常、多要素認証(電話、SMS、認証アプリ等)は正規サイトと被害者の間で別経路(別の通信手段)にてやり取りされます。被害者が正規サイトからの多要素認証に応答すると、攻撃者は正しいID/Passwordに加え、認証成功の状態を保持したセッションCookieを入手することができます。

今回は、ローカル環境にAiTMフィッシングサイト(リバースプロキシ)を構築しました。AiTMフィッシングにより、多要素認証をバイパスしてOffice365の被害者アカウントのセッションCookieを入手し、Pass-The-Cookieを実施します。

攻撃者の画面-設定したAiTMの画面
攻撃者の画面-設定したAiTMの画面
50

攻撃者は、AiTMフィッシングサイトへのリンクが記載されたフィッシングメールを作成し、被害者に送付します。

被害者の画面-攻撃者が送付したフィッシングメールの例
被害者の画面-攻撃者が送付したフィッシングメールの例
50

被害者は、フィッシングメールを受け取ると、Office365のログインサイト (login.microsoftonline.com)と類似したリンクの記載を確認できます。被害者がフィッシングメールの文面やリンクに不審感を持たずにクリックしてしまうと、攻撃者が用意したAiTMフィッシングサイトに遷移します。URL部分を除き、AiTMフィッシングサイトの画面は、被害者から正規のOffice365のログインサイトと同じに見えます。

被害者の画面- AiTMフィッシングサイト
被害者の画面- AiTMフィッシングサイト
50

被害者がAiTMフィッシングサイトに対して、Office365に登録してあるID/Passwordを入力し、サインインボタンを押します。

被害者の画面- AiTMフィッシングサイトに対するパスワード入力
被害者の画面- AiTMフィッシングサイトに対するパスワード入力
50

被害者がOffice365に登録してあるID/PasswordをAiTMフィッシングサイト上に入力すると、AiTMフィッシングサイト経由でOffice365のログインサイトにID/Passwordが送付されます。ID/Passwordが正しいことがOffice365のログインサイトで確認されると攻撃者には下記の画面が表示されます。

攻撃者の画面-被害者が入力したID/Passwordの確認
攻撃者の画面-被害者が入力したID/Passwordの確認
50

攻撃者は、被害者アカウントのOffice365のID/Passwordを入手できました。

Office365では多要素認証が設定されているため、被害者はOffice365から多要素認証を要求されます。多要素認証の成功有無に関わらず、この段階で攻撃者が被害者アカウントのID/Passwordを入手できている点にご注意ください。

被害者の画面-AiTMフィッシングサイトの多要素認証の要求画面
被害者の画面-AiTMフィッシングサイトの多要素認証の要求画面
50

被害者がOffice365のログインサイトからの多要素認証に成功すると、サインイン状態の維持の有無を選択する画面が表示されます。

被害者の画面-AiTMフィッシングサイトの多要素認証成功後の画面
被害者の画面-AiTMフィッシングサイトの多要素認証成功後の画面
50

上記の画面において、どちらかを選択するとAiTMフィッシングサイト上の処理が終了し、被害者はAiTMフィッシングサイトから正規のOffice365に遷移します。被害者の遷移先は、攻撃者が自由に設定することが可能です。

被害者の画面-AiTMフィッシングサイトからリダイレクト後のOffice365の画面
被害者の画面-AiTMフィッシングサイトからリダイレクト後のOffice365の画面
50

一方、被害者がAiTM側での認証処理を完了させ、Office365に遷移すると攻撃者の画面上に認証情報の取得が完了した旨が表示されます。

攻撃者の画面-被害者のログイン成功後の画面
攻撃者の画面-被害者のログイン成功後の画面
50

攻撃者は、取得したOffice365のセッションCookieを確認します。

攻撃者の画面-入手したセッションCookieの確認
攻撃者の画面-入手したセッションCookieの確認
50

被害者アカウントのセッションCookieが記録されています。攻撃者は、被害者の端末を侵害することなく、被害者アカウントのセッションCookieを入手することができました。

攻撃者はセッションCookieを入手したので、この後Pass-The-Cookieの試行に移ります。攻撃者の端末からOffice365のログインサイトに遷移します。

攻撃者の画面-Office365のログイン画面
攻撃者の画面-Office365のログイン画面
50

攻撃者はブラウザにセッションCookieを投入し、Pass-The-Cookieを試行します。投入したセッションCookieが有効である場合、攻撃者はCookieを投入するだけで、一気に被害者アカウントとしてOffice365にログインすることができます。

攻撃者の画面-正規のOffice365のログイン後の画面
攻撃者の画面-正規のOffice365のログイン後の画面
50

Pass-The-Cookieにより、攻撃者はID/Password入力無し、および多要素認証無しにOffice365にログインすることができました。
ここまで説明した通り、AiTMフィッシングは、攻撃者が被害者の端末への侵入無しに多要素認証をバイパスできる点が非常に強力です。

Microsoft社は、2021年9月以降に1万を超える組織を標的とするAiTMフィッシングを確認しています。 [6] またZscaler社は、2022年6月から特定の業界や地域を標的としたAiTMフィッシングが急激に増加していることを確認しています。 [7] このようにAiTMフィッシングは増加傾向にあり、かつ非常に強力な攻撃であるため注意が必要です。

一般的なPass-The-Cookieへの対策

Pass-The-Cookie及びセッションCookieの入手/偽造に関する一般的な対策例としては、Mitre ATT&CKのUse Alternate Authentication Material: Web Session Cookie(T1550.004) [2]、Steal Web Session Cookie(T1539) [3]及び Forge Web Credential: Web Cookie(T1606.001) [4] のMitigations、Detectionをご確認ください。

Office365におけるPass-The-Cookieへの対策

ユーザがAiTMフィッシングに引っかかった場合や端末がマルウェア感染した場合には、Office365の認証をおこなうAzure Active Directoryにおいて、被害を受けたユーザのセッションの取り消しを実施することを推奨します。環境の構成次第ですが、Active Directory、Azure Active Directory のどちらかで被害を受けたユーザのパスワード変更の実施も推奨します。また攻撃者が侵入した際にユーザに対して新たにFIDO2セキュリティキー等の認証方法(バックドア)を追加することがあります。攻撃者により認証方法が追加された場合、パスワードを変更しても攻撃者が再度侵入できる可能性があります。攻撃者により追加された認証方法がないか確認し、もしあれば削除しましょう。

侵害発覚後のAzure Active Directoryでのセッションの取り消し
侵害発覚後のAzure Active Directoryでのセッションの取り消し
50

Azure Active Directoryでのセッションの取り消しは、上図のように実施できます。これにより、多要素認証のバイパスに繋がるセッションCookieの認証成功の状態を取り消すことができます。

セッションの取り消し後のPass-The-Cookieの失敗
セッションの取り消し後のPass-The-Cookieの失敗
50

また、AiTMフィッシングへの対策としてメールの文面、送信元、URL等を確認することで不審なメールを判別できるようにするためのユーザ教育も重要です。

Jeffrey Appel氏のブログでは、Office365におけるAiTMフィッシングへの対策がまとめられていますのでそちらをご確認ください。 [8] Jeffrey Appel氏のブログでは、下記の認証方法がAiTMフィッシングに対して有効であると紹介しています。

Jeffrey Appel氏のブログには、条件付きアクセスの設定による防御、監視すべきMicrosoft製品のアラート一覧のようにPass-The-Cookie(Use Alternate Authentication Material: Web Session Cookie)への対策と共通する部分も多く含まれています。

最後に

今回はPass-The-Cookieについて紹介しました。Pass-The-Cookieは多要素認証をバイパス可能な強力な攻撃手法です。このブログを通じて攻撃に対する脅威をご確認いただき、少しでもセキュリティ対策の強化に繋げていただくことができれば幸いです。
多要素認証は、現在も通常のフィッシングや認証試行に対して有効な防御手段であることに変わりはありません。有効化することでPass-The-Cookieや多要素認証疲労攻撃 [12]等を除いた多くの攻撃を防ぐことができることは忘れないでいただけると幸いです。

付録. 攻撃者が端末に侵入した場合のOffice365の認証方法の有効性検証

Jeffrey Appel氏が紹介する下記の3つの認証方法は、AiTMフィッシングに対して有効です。

ただし、Pass-The-CookieへとつながるセッションCookieの入手方法は、AiTMフィッシングだけではありません。そこで攻撃者がOffice365を利用する端末に侵入した際に,これらの認証方法が攻撃者によるOffice365への侵入を防ぐことが可能かを検証します。(AiTMフィッシングと比較し、端末への侵入は攻撃者視点では成功の難易度が上がります。)具体的には、端末に侵入した攻撃者がセッションCookie(もしくはそれと同等のもの)を窃取することでOffice365 に侵入可能か検証します。

先に検証結果を述べると、3つの認証方法は、AiTMフィッシングに対して有効ですが、攻撃者が端末に侵入したケースに対しては、有効ではありません。BYODを含むOffice365を利用する端末が侵害された場合には、攻撃者が多要素認証をバイパスしてOffice365に侵入する可能性がある点にご注意ください。


以降、個別の検証結果を確認します。


はじめにFIDO2セキュリティキーを使用した認証です。

FIDO2セキュリティキーを使用したOffice365のログイン画面
FIDO2セキュリティキーを使用したOffice365のログイン画面
50

FIDO2セキュリティキーにより認証済みのOffice365のセッションCookieを窃取します。窃取したセッションCookieをブラウザに投入するだけでFIDO2セキュリティキー無しに攻撃者の端末からOffice365にログインすることができました。被害者がFIDO2セキュリティキーを使用している場合でも端末を侵害することで攻撃者はFIDO2セキュリティキー無しにOffice365にログインできるようになります。

攻撃者の画面-FIDO2セキュリティキーによるログイン時のPass-The-Cookie成功画面
攻撃者の画面-FIDO2セキュリティキーによるログイン時のPass-The-Cookie成功画面
50

次は証明書ベースの認証です。

証明書ベースの認証を使用したOffice365のログイン画面
証明書ベースの認証を使用したOffice365のログイン画面
50

証明書ベースの認証により認証済みのOffice365のセッションCookieを窃取します。ブラウザにセッションCookieを投入することでPass-The-Cookieを試行しますが、攻撃者はログインに失敗します。証明書に関するエラーが発生しているようです。

攻撃者の画面-証明書によるログイン時のPass-The-Cookie失敗画面
攻撃者の画面-証明書によるログイン時のPass-The-Cookie失敗画面
50

ただし、セッションCookieのブラウザへの投入に加え、追加の操作をすることで証明書がなくとも攻撃者の端末からOffice365 にログインすることができました。端末に侵入し、Cookieを窃取することで証明書ベースの認証に対してもPass-The-Cookieが成功することを確認しました。
また端末が侵害された場合には、認証に使用する証明書を攻撃者が端末から窃取し、悪用する可能性がある点にも注意が必要です。

攻撃者の画面-証明書によるログイン時のPass-The-Cookie成功画面
攻撃者の画面-証明書によるログイン時のPass-The-Cookie成功画面
50

最後は、Windows Hello for Businessを使用した認証です。

Windows Hello for Businessを使用した端末へのログイン画面
Windows Hello for Businessを使用した端末へのログイン画面
50
Windows Hello for Businessを使用したOffice365へのログイン画面
Windows Hello for Businessを使用したOffice365へのログイン画面
50

Windows Hello for Businessを使用し、Azure Active Directoryのアカウントを使用してログインした端末(Azure AD参加済みデバイス [13])から Windows Hello for Business により認証済みのOffice365のセッションCookieを窃取します。窃取したセッションCookieをブラウザに投入するだけで攻撃者の端末からOffice365にログインすることができました。被害者がWindows Hello for Businessによる認証をしている場合でも、攻撃者によって端末が侵害されてしまうと、Office365にログインできるようになります。

攻撃者の画面- Windows Hello for Business によるログイン時のPass-The-Cookie成功画面
攻撃者の画面- Windows Hello for Business によるログイン時のPass-The-Cookie成功画面
50

また攻撃者がAzure Active Directoryのアカウントに対してログインした端末に侵入し、Office365への認証に使用される有効なPRT(Primary Refresh Token) [14]を入手することで、Pass-The-Cookieと同様に多要素認証無しにOffice365にログインすることができます。これは、Pass-The-PRTと呼ばれる攻撃手法となります。

攻撃者の画面-Windows Hello for Businessによるログイン 時のPass-The-PRT成功画面
攻撃者の画面-Windows Hello for Businessによるログイン 時のPass-The-PRT成功画面
50

参考文献

[1] https://attack.mitre.org/

[2] https://attack.mitre.org/techniques/T1550/004/

[3] https://attack.mitre.org/techniques/T1539/

[4] https://attack.mitre.org/techniques/T1606/001/

[5] https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/block-legacy-authentication

[6] https://www.microsoft.com/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/

[7] https://www.zscaler.com/blogs/security-research/large-scale-aitm-attack-targeting-enterprise-users-microsoft-email-services

[8] https://jeffreyappel.nl/protect-against-aitm-mfa-phishing-attacks-using-microsoft-technology/

[9] https://learn.microsoft.com/ja-jp/azure/active-directory/authentication/howto-authentication-passwordless-security-key

[10] https://learn.microsoft.com/ja-jp/azure/active-directory/authentication/concept-certificate-based-authentication

[11] https://learn.microsoft.com/ja-jp/windows/security/identity-protection/hello-for-business/hello-overview

[12] https://www.itworldcanada.com/post/hackers-use-mfa-fatigue-to-bypass-multi-factor-authentication

[13] https://learn.microsoft.com/ja-jp/azure/active-directory/devices/concept-azure-ad-join

[14] https://learn.microsoft.com/ja-jp/azure/active-directory/devices/concept-primary-refresh-token

執筆者プロフィール

執筆者
original
50

桐下 拓也(きりした たくや)
セキュリティ技術センター リスクハンティング・アナリシスグループ

大規模国際イベントのサイバーセキュリティ対応業務を経て、現在はインシデント対応、ペネトレーションテスト、NEC CSIRTなどの業務に従事。
2×SANSメダル、2×Splunk Boss of the SOCトロフィーを保持
CISSP、GCFAを保持