M365インベーダーハンティング：ブルーチームのための初期アクセスベクトル対策ガイド

Microsoft 365 (旧称Office 365)は、Microsoft社が提供するクラウドベースの生産性向上ツールスイートで、メールクライアント、コラボレーションプラットフォーム、業務アプリケーションなどをひとつにまとめたソリューションです。これらのツールはすべて、IDおよびアクセス管理サービスのEntra ID (このブログではAzure ADと呼びます)と統合されています。M365は、組織のデータが集約される場所であり、どこからでもアクセス可能で広く利用されていることから、サイバー攻撃の主要な標的のひとつになっています。

初期アクセスは、攻撃者が組織の環境内に最初に侵入する攻撃の足場です。クラウドコンピューティング環境では、IDが新たな境界になっています。アカウントを乗っ取れば、攻撃を重ねることでデータの窃取が可能になります。逆にブルーチームにとっては、初期アクセスの段階で攻撃に対応できれば、実害を防ぐことができます。その点で、初期アクセス技法への警戒は重要です。

Splunk脅威調査チームによるこのブログ記事では、まず、M365の監視に利用できるデータソースについて概説します。その後、M365テナントに対する初期アクセスでよく使われる6つの一般的な技法を紹介し、これらの技法のシミュレート方法とSplunkによる検出方法について解説します。 

データソース

効果的な脅威検出は、分析の基盤となるデータソース選びから始まります。データソースの対象範囲と品質を理解することが、検出戦略を立てる鍵となります。このセクションでは、対象となるデータソースの概要、それらのデータソースの違い、Splunkへの取り込み方法について説明します。

統合監査ログ

M365の統合監査ログ(UAL)には、Exchange Online、SharePoint Online、OneDrive、Microsoft Teams、Azure ADなど、各種サービスのログが集約されます。このデータを統合することで、M365環境全体のユーザーアクティビティを一元的に把握できます。これらのログを検索するには、PowerShellコマンドレット「Search-UnifiedAuditLog」を使用します。また、Management Activity APIを使って、外部分析ツールからログにアクセスすることもできます。

M365のUALをSplunkに取り込むには、Splunk Add-On for Microsoft Office 365を使用するのがお勧めです。このアドオンを使えば、Management Activity APIを介してアクティビティ監査ログを簡単に取得できます。

Azure ADログ 

M365ではIDおよびアクセス管理の基盤としてAzure ADが使われるため、Azure ADのログはセキュリティ監視で重要な役割を果たします。Azure ADのサインインログと監査ログはスキーマが充実しているため、コンテキストを詳しく調査できます。これらログのアクセスと分析には、Microsoft Graph APIや、PowerShell SDKなどのRESTクライアントを使用します。また、Azure Event Hubsを使えば、データストリーミングパイプラインと簡単に統合できます。

Azure ADイベントをSplunkに取り込むには、Splunk Add-on for Microsoft Azureを使用するのがお勧めです。このアドオンでは、Graph API経由でデータを取得できます。また、Splunk Add-on for Microsoft Cloud Servicesを使えば、Azure Event Hubsと統合できます。Splunk Cloud Platformをご利用の場合は、内蔵のData Managerアプリケーションを使って簡単にデータを取り込めます。

2つのデータソースの違い

UALとAzure ADログのどちらもM365のセキュリティ監視において重要な役割を果たしますが、その目的は異なり、スキーマにも違いがあります。UALは、M365の各種サービスの監査ログが幅広く記録され、ユーザーアクティビティを包括的に理解するのに役立ちます。ただし、Azure ADログに記録されるような認証イベントやID管理イベントの一部の詳細は記録されません。 

たとえば、UALでは「UserLoggedIn」イベントでユーザー認証アクティビティの基本情報を確認できます。しかし、サービスプリンシパルサインイン、非対話型サインイン、マネージドIDサインインなど、一部の重要な認証イベントはログに記録されません。また、これらのイベントで提供される情報が限定され、詳細な分析には物足りないこともよくあります。

^{図1：UALの「UserLoggedIn」イベント}

これに対して、Azure ADログの「Sign-in activity」イベントは対象が広く、サービスプリンシパルサインイン、非対話型サインイン、マネージドIDサインインを含め、認証のサブカテゴリも個別に記録されます。ログの対象範囲が広いため、アクセストークンの窃取や、サービスプリンシパルやAzureリソースIDの悪用など、M365への攻撃を検出するために十分な情報を収集できます。 

Azure ADログの認証イベントでは、ユーザーとアプリケーションの情報、場所、デバイス、条件付きアクセス、使用された認証方法(単一要素認証と多要素認証(MFA)のどちらが使われたか)などの詳細を含む、包括的なデータセットが提供されます。さらに、Azure ADログには、Azure AD Identity Protectionによるサインインリスク情報も記録され、豊富なコンテキストを獲得できます。

^{_{図2：Azure ADの「Sign-in activity」イベント}}

こうした違いを理解しておくことは、精度の高い脅威分析を行うために非常に重要です。UALは、M365の各種サービスの悪用リスクを分析するために最適です。一方、Azure ADログは、認証とIDに関する脅威を分析するうえで主要なソースになります。両方のデータソースから得られたインサイトを統合すれば、状況をより包括的に把握できます。

Splunk脅威調査チームのアプローチ

Splunk脅威調査チームは、脅威の迅速な検出と無力化に必要なツールやインサイトを提供してセキュリティチームをサポートする専門チームです。その活動の一環として、M365を標的とする初期アクセス技法を検出するための、UALとAzure ADログの両方を活用した分析手法をこれまでに30種以上開発してきました。このアプローチを取り入れれば、どのようなデータソースを活用していても、Splunkを使ってM365に迫る脅威の検出やハンティングだけでなく、M365環境の保護も行えます。

これらの分析手法は、research.splunk.comの分析ストーリーセクションにあるOffice 365 Account TakeoverとAzure AD Account Takeoverのリンク先からダウンロードできます。

初期アクセス技法

このセクションでは、攻撃者がM365テナントに侵入するために使用する一般的な初期アクセス技法について説明します。各技法について、次の点を取り上げます。

• 実践的なシミュレーション戦略
• テレメトリから得られるインサイト
• Splunk脅威調査チームが公開している検出ルール

パスワードスプレー

パスワードスプレーは、よく使われる少数のパスワードとさまざまなユーザー名を組み合わせて有効な認証情報を探し出す攻撃技法です。Microsoft社による基本認証の廃止により、安全性の高い先進認証への移行が大幅に進みました。実際、MFAの導入率は、2017年の0.7%から2023年には37%に伸びています。 

こうした進歩はあったものの、パスワードスプレーの脅威は現在も続いており、攻撃ベクトルとして広く利用されています。さらに、後ほど詳しく説明するように、攻撃者は認証情報の取得後に、MFAによる制御を回避する方法を取り入れ始めています。

「Microsoftデジタル防衛レポート2023」では、Microsoftプラットフォームに対してパスワードの窃取を狙う攻撃が急増し、パスワードスプレーのインシデントが10倍以上に増加していることが報告されています。また、さまざまな国のIPアドレスで構成される分散ネットワークを使ってAzure AD Identity Protectionやスマートロックアウトなどのセキュリティ対策を回避する高度なパスワードスプレー攻撃についても警告しています。

^{図3：複数の送信元IPアドレスを使ったパスワードスプレー}

シミュレーション

従来型のパスワードスプレー攻撃のシミュレーションには、MSOLSpray、o365spray、Go365など、さまざまなオープンソースツールを利用できます。一方、複数の送信元IPアドレスを使った分散型のパスワードスプレーをシミュレートするときは、FireProxが効果的です。FireProxでAWS API Gatewayを使って透過型プロキシを構築し、リクエストごとに送信元IPアドレスをローテーションします。その際、URLパラメーターを活用してFireProxとMSOLSprayをネイティブに統合します。最後に、BadZureを使って、Azure ADラボ環境に模擬ユーザーを登録します。

^{図4：MSOLSpray}

テレメトリから得られるインサイト

認証要求の失敗はエラーコード50126として記録され、説明に「無効なユーザー名またはパスワードによる資格情報の検証中にエラーが発生しました」と表示されます。説明を見る限り、このエラーコードはユーザー名が無効な場合にも生成されるように思えますが、今回の実験でそうでないことがわかりました。 

実際、Microsoft社のドキュメントによると、入力されたユーザーアカウントが存在しない場合にはエラーコード50034が別に割り当てられ、その説明には、テナントディレクトリにユーザーアカウントが存在しないことが示されます。このエラーはクライアントリクエストに対して返されますが、Azure ADログには記録されません。一方、Windows Active Directoryの設定では、ユーザーが存在しない場合の認証失敗はKerberosエラー0x6で報告されます。

検出ルール

Azure AD Multiple Users Failing To Authenticate From IP

UALとAzure ADログのどちらでもエラーコード50126を監視することで、短時間の間に同じ送信元IPアドレスを使う多数のユーザーが認証に失敗する従来型のパスワードスプレー攻撃を検出できます。

`azuread` category=SignInLogs properties.status.errorCode=50126 
  properties.authenticationDetails{}.succeeded=false 
| rename properties.* as * 
| bucket span=5m _time 
| stats  dc(userPrincipalName) AS unique_accounts values(userPrincipalName) 
  as userPrincipalName by _time, ipAddress 
| where unique_accounts > 30

Azure AD Multi-Source Failed Authentications Spike

複数の送信元IPアドレスを使った分散型のパスワードスプレー攻撃を検出するには、独自の戦略が必要です。この分析手法では、同じ特徴を持つ認証要求が短時間で急増する状況を監視し、失敗したログイン試行の主要なメトリクスとして以下の値を算出します。 

• 一意のユーザー名/IPアドレスの組み合わせ数
• 一意のユーザー数
• 一意の送信元IPアドレス数と国数
• 一意のユーザーエージェント数

これらのメトリクスのしきい値をカスタマイズすることで、通常の動作から逸脱したパターンを見つけ出すことができます。

`azuread` category=SignInLogs properties.status.errorCode=50126
  properties.authenticationDetails{}.succeeded=false 
| rename properties.* as * 
| bucket span=5m _time 
| eval uniqueIPUserCombo = src_ip . "-" . user 
| stats dc(uniqueIPUserCombo) as uniqueIpUserCombinations, dc(user) as uniqueUsers, dc(src_ip) as uniqueIPs, 
  dc(location.countryOrRegion) as uniqueCountries values(user) as users, values(src_ip) as ips, 
  values(user_agent) as user_agents, values(location.countryOrRegion) as countries by _time 
| where uniqueIpUserCombinations > 20 AND uniqueUsers > 20 AND uniqueIPs > 20

これらの検出ルールをUALに適用するときは、O365 Multiple Users Failing To Authenticate From IpとO365 Multi-Source Failed Authentications Spikeを使用します。

不正な同意の付与

M365環境では、サードパーティアプリケーションが組織のデータにアクセスするのを許可するためにOAuth認証プロトコルが使われます。この仕組みを悪用する攻撃者は、悪質なAzureアプリケーションを登録し、ユーザーをだましてアクセス許可に同意させます。不正な同意を得た攻撃者は、アクセストークンを手に入れて、機密情報にアクセスしたり、メールを盗み見たり、ユーザーになりすまして操作を実行したりできるようになります。この手口を使えば、多要素認証(MFA)を回避することも可能です。

この問題に対応するため、Microsoft社は発行者の確認やリスクに基づくステップアップ同意などの対策を取り入れて、不正な同意の付与攻撃のリスクを大幅に緩和しました。それでも、攻撃者がこれらの対策を回避する可能性が残るため、この攻撃ベクトルへの警戒は引き続き必要です。たとえば、今年初めにProofpoint社が公開したブログによると、攻撃者がMicrosoft社の「発行者確認済み」のステータスを悪用して、一部のOAuthの配布要件を満たした事例が確認されました。また、Secureworks社は先日、「発行者確認済み」のステータスを偽装する手口を実証する調査報告を公開しました。

シミュレーション

不正な同意の付与攻撃のシミュレーションに利用できるオープンソースツールには、PwnAuth、o365-attack-toolkit、365-Stealerなど、いくつかあります。ここでは、365-Stealerを使用する方法をご紹介します。まず、このツールのGitHubページで説明されているように、マルチテナントアプリケーションを登録する必要があります。すべての要件を満たしたら、ツールを設定して実行し、模擬ユーザーに送信するフィッシングリンクを作成します。 

^{図5：365Stealer}

デフォルトでは、前述のセキュリティ対策により、新しく作成したマルチテナントアプリケーションの登録に対する同意要求が即座にブロックされます。何らかの方法でこれらの対策を回避する攻撃者をシミュレートするために、こちらのガイドに従って、PowerShellを使ってリスクに基づくステップアップ同意を無効にします。

^{図6：OAuth同意のブロック}

リスクに基づくステップアップ同意を無効にした状態でユーザーが悪質なリンクをクリックすると、次の画面が表示されます。この例では、ユーザーではなく悪質なアプリケーションが、メールの読み取りやメールの送信をするためのアクセス権を要求しています。具体的には、Mail.Read、Mail.ReadWrite、Mail.Sendの権限が要求されます。

^{図7：不正な同意の付与のリクエスト}

標的のユーザーがこれに同意すると、攻撃者がアクセストークンを取得することになります。

^{図8：トークンの窃取}

テレメトリから得られるインサイト

ユーザーが悪質なOAuth同意リンクをクリックして、同意を求める画面が表示されると、「Consent to application」イベントが生成されます。このイベントには、同意の成否、対象ユーザーのID、アプリケーション名、要求された権限など、重要な情報が含まれます。Azure ADログには、UALに含まれない情報として、IPアドレスフィールドが記録されます。ただし、このIPアドレスは、標的のユーザーのものでも攻撃者のものでもありません。実験では、このIPアドレスは通常、Microsoft社が所有するIPアドレス帯でした。

両方のデータソースにある「ModifiedProperties」の「ConsentAction.Permissions」フィールドには、アプリケーションが要求した権限が含まれます。このフィールドを抽出して分析することで、目的の脅威検出のための分析を作成できます。Microsoft Graph APIで取得できる権限はさまざまですが、M365のコンテキストに沿えば、特に重要なのは「Read.*」と「Files.*」の2つのカテゴリに絞られます。

^{図9：「Consent to application」ログイベント}

「Consent to application」イベントに含まれる詳細に基づいて、通知が必要な状況を検出するための分析を作成できます。さらに、ユーザーが不正なリクエストに同意したときは、「Add service principal」、「Add delegated permission grant」、「Add app role assignment grant to user」の3つのイベントが生成されます。 

^{図10：同意成功のイベント}

検出ルール

O365 User Consent Blocked for Risky Application

防止対策は、脅威のブロックだけでなく、標的となるユーザーのプロファイルに関するインサイトを獲得し、防御戦略を強化するためにも役立ちます。この検出ルールでは、M365でユーザーによるアプリケーションへの同意の付与が危険または悪質な可能性があると判断されてブロックされた挙動を検出できます。

`o365_management_activity` Workload=AzureActiveDirectory Operation="Consent to application." 
  ResultStatus=Failure 
| eval permissions =mvindex('ModifiedProperties{}.NewValue', 4) 
| eval reason =mvindex('ModifiedProperties{}.NewValue', 5) 
|  search reason = "Risky application detected" 
| rex field=permissions "Scope: (?[^,]+)" 
|  stats max(_time) as lastTime by Operation, user, reason, object, Scope 
| `security_content_ctime(lastTime)` 

O365 Block User Consent For Risky Apps Disabled

実験では、リスクに基づくステップアップ同意をわざと無効にしました。この操作を行うと、「Update authorization policy」カテゴリのイベントが生成されます。そのため、このカテゴリのイベントを監視すれば、攻撃を継続的に仕掛ける攻撃者がセキュリティ対策を弱体化させようとしたり、管理者が誤ってこの機能を無効にしたりした場合に、そのアクティビティを検出できます。 

`o365_management_activity` Workload=AzureActiveDirectory Operation="Update authorization policy." 
| eval index_number = if(mvfind('ModifiedProperties{}.Name', "AllowUserConsentForRiskyApps") >= 0, 
  mvfind('ModifiedProperties{}.Name', "AllowUserConsentForRiskyApps"), -1) 
| search index_number >= 0  
| eval AllowUserConsentForRiskyApps = mvindex('ModifiedProperties{}.NewValue',index_number) 
| where AllowUserConsentForRiskyApps like "%true%" 
| stats count min(_time) as firstTime max(_time) as lastTime by user, Operation,
  AllowUserConsentForRiskyApps, user_agent 
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)`

O365 File Permission Application Consent Granted by User

アプリケーションがGraph APIの特定の権限を取得して、ユーザーに代わってメールの読み取りや送信、OneDriveやSharePoint上のファイルへのアクセスを行えるようになったことを検出します。

`o365_management_activity` Workload=AzureActiveDirectory Operation="Consent to application." 
  ResultStatus=Success 
| eval admin_consent =mvindex('ModifiedProperties{}.NewValue', 0) 
| search admin_consent=False 
| eval permissions =mvindex('ModifiedProperties{}.NewValue', 4) 
| rex field=permissions "Scope: (?[^,]+)" 
| makemv delim=" " Scope 
| search Scope IN ("Files.Read", "Files.Read.All", "Files.ReadWrite", 
  "Files.ReadWrite.All", "Files.ReadWrite.AppFolder") 
| stats max(_time) as lastTime values(Scope) by Operation, user, object, ObjectId 
| `security_content_ctime(lastTime)`

O365 Mail Permission Application Consent Granted by User

`o365_management_activity` Workload=AzureActiveDirectory Operation="Consent to application." 
  ResultStatus=Success 
| eval admin_consent =mvindex('ModifiedProperties{}.NewValue', 0) 
| search admin_consent=False 
| eval permissions =mvindex('ModifiedProperties{}.NewValue', 4) 
| rex field=permissions "Scope: (?[^,]+)" 
| makemv delim=" " Scope 
| search Scope IN ("Mail.Read", "Mail.ReadBasic", "Mail.ReadWrite", "Mail.Read.Shared", 
  "Mail.ReadWrite.Shared", "Mail.Send", "Mail.Send.Shared") 
| stats max(_time) as lastTime values(Scope) by Operation, user, object, ObjectId 
| `security_content_ctime(lastTime)`

デバイスコードフィッシング 

M365とその認証プロセスではOAuthプロトコルが使われます。このプロトコルでは、さまざまなデバイス機能やユーザーエクスペリエンスに対応するための各種の認証フローがサポートされています。これらのフローは柔軟性と利便性を高めると同時に、新しい攻撃ベクトルとして悪用されることがあります。 

そのひとつが、RFC 8628で取り上げられている、「デバイス認可フロー」と呼ばれるOAuthプロトコル拡張です。このプロトコル拡張は、スマートテレビなど、入力機能に制限のあるデバイスに対応することを目的としています。このプロトコル拡張を使えば、ユーザーが認証情報を入力することなく、デバイスでOAuthの認証および認可プロセスを実行することができます。その際は、認証情報の代わりに一意のコードを生成し、ユーザーにPCなどの別のデバイスでこのコードを入力するように求めます。

^{図11：デバイスコードの入力要求}

この仕組みを悪用することで、攻撃者はMFAを回避してM365サービスに不正アクセスし、さまざまな攻撃につなげることができます。

シミュレーション

デバイス認可フローを悪用する攻撃者はまず、デバイスコードの認可フローを自身で開始して一意のユーザーコードを取得します。次に、信頼できるプロセスや必要な操作を装って標的のユーザーをだまし、このコードを正規のMicrosoft Webサイトで入力させます。ユーザーがだまされてコードを送信すると、攻撃者はその結果として送られるアクセストークンを手に入れることができます。すでに、この手口を自動化するTokenTacticsというオープンソースツールも出回っています。 

^{図12：TokenTactics}

標的のユーザーが正規のMicrosoft Webサイトにコードを送信すると、攻撃者はアクセストークンを取得してM365サービスにアクセスできるようになります。

^{図13：盗まれたBearerトークン}

テレメトリから得られるインサイト

UALのテレメトリでは、残念ながら、デバイスコード認証の試行を効果的に検出するための十分なコンテキストを得られません。しかし、Azure ADログの「Sign-in activity」イベントに、この試行の検出に役立つ詳細なデータセットが含まれています。中でも重要なのが「authenticationProtocol」フィールドです。 

^{図14：デバイスコード認証のログ}

検出ルール

Azure AD Device Code Authentication

デバイスコード認証の検出は簡単です。「authenticationProtocol」フィールドの値が「deviceCode」の認証イベントを見つけるだけです。

`azure_monitor_aad` category=SignInLogs "properties.authenticationProtocol"=deviceCode 
| rename properties.* as * 
| stats count min(_time) as firstTime max(_time) as lastTime by user src_ip, appDisplayName, userAgent 
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)`

MFA疲労攻撃 

プッシュ通知によるMFAを回避するためによく使われる手口のひとつが、あらかじめ盗んでおいた認証情報を悪用して認証要求を繰り返し発生させる方法です。狙いは、ひっきりなしに続く要求に標的のユーザーが疲れたり混乱したりして認証を許可してしまうことです。場合によっては、攻撃者がインスタントメッセージや電話などの代替手段を通じて標的のユーザーに直接連絡を取り、不正な認証要求を承認するように強く迫ることもあります。

テレメトリから得られるインサイト

MFA疲労攻撃は、MFA試行の失敗が頻発していないかを監視することで検出できます。MFA試行の失敗は、Azure ADのエラーコード500121「強力な認証の要求時に、認証に失敗しました」によって捕捉できます。このエラーコードを監視すれば、MFA要求のいわゆる「プロンプト爆撃」を受けているユーザーによる異常な回数の認証失敗を検知できます。さらにAzure ADログの「additionalDetails」フィールドを確認すれば、認証の失敗がユーザーによる拒否なのかタイムアウトなのかを区別できます。この情報を使えば、検出ルールの精度を向上させて、一部の誤検知を回避できます。UALにはこの詳細は記録されません。

検出ルール

Azure AD Multiple Denied MFA Requests For User

「異常な回数」とみなせるしきい値は組織によって異なるため、各組織の環境でのユーザーの正常な行動パターンに合わせてしきい値を調整してください。 

`azuread` category=SignInLogs operationName="Sign-in activity"
  | rename properties.* as * 
  | search status.errorCode=500121 
  status.additionalDetails="MFA denied; user declined the authentication"
  | bucket span=10m _time 
  | stats count min(_time) as firstTime max(_time) as lastTime by user, status.additionalDetails,
  appDisplayName, user_agent
  | where count > 9
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

Azure AD Multiple Failed MFA Requests For User

`azuread` category=SignInLogs operationName="Sign-in activity" properties.status.errorCode=500121 
  properties.status.additionalDetails!="MFA denied; user declined the authentication"
  | rename properties.* as * 
  | bucket span=10m _time 
  | stats count min(_time) as firstTime max(_time) as lastTime by user, status.additionalDetails, 
  appDisplayName, user_agent
  | where count > 9
  | `security_content_ctime(firstTime)` 
  | `security_content_ctime(lastTime)`

MFA対象サービスの列挙 

認証情報を盗み出した攻撃者が、標的テナントのMFA適用状況を調査することがあります。条件付きアクセスポリシーの複雑さを考えれば、管理者の見落としによって一部の認証ソースが単一要素認証のままになっていても不思議はないでしょう。攻撃者はそのことをよく認識しており、さまざまなデバイスタイプをシミュレートする自動化ツールを使って調査を行い、こうしたセキュリティの抜け道を探します。これらの不備が見つかると、盗んだ認証情報を使ってMFAによる保護対策を回避し、サービスに不正アクセスします。

シミュレーション

MFASweepやTeamFiltrationなどのツールを用いれば、有効な認証情報を使って異なるユーザーエージェントで各種のMicrosoftクラウドサービスに認証を行うプロセスを自動化できます。

^{図15：MFASweep}

テレメトリから得られるインサイト

この手口の痕跡には、同じユーザーがさまざまなユーザーエージェントと幅広いアプリケーションIDを使って認証に複数回成功するという特徴があります。通常であれば、ユーザー認証で使われるユーザーエージェントは、ブラウザやモバイルデバイスなどのクライアントに応じて、せいぜい2つか3つです。短時間で5種類以上のユーザーエージェントを使うのは異常であり、攻撃者が盗んだ認証情報を使ってMFA対象サービスの列挙を実行している可能性があります。

検出ルール

O365 Multiple AppIDs and UserAgents Authentication Spike

`o365_management_activity` Workload=AzureActiveDirectory (Operation=UserLoggedIn 
  OR Operation=UserLoginFailed) 
| bucket span=5m _time 
| stats  dc(_raw) as failed_attempts dc(ApplicationId) as unique_app_ids
  dc(UserAgent) as unique_user_agents values(ApplicationId) values(OS) by _time user src_ip 
| where failed_attempts > 5 and unique_user_agents > 5 and unique_app_ids > 2

中間者攻撃(AiTM) 

従来のフィッシング攻撃は、攻撃者がユーザーを偽のWebサイトに誘導して認証情報を入力させるものでした。このタイプの攻撃では認証情報が盗まれても、MFAを導入していればアカウントへの不正アクセスを防ぐことができます。しかし攻撃者はそれに適応し、MFA対策を回避する新しい方法を考え出しています。

中間者攻撃(AiTM)でも、攻撃者はまず、標的のユーザーを悪質なサイトに誘導します。これまでとの違いは、そのフィッシングサイトはプロキシサーバーのように機能し、ユーザーのリクエストを正規のWeb認証サイトにそのまま転送しながら、ユーザーと正規サイト間でやり取りされる機密情報を取得する点です。これにより、認証プロセスでやり取りされる認証情報やセッションCookieなどの重要データを盗み出すことができます。この方法を使えば、有効なセッションCookieを手に入れ、追加の検証なしで正規サイトと認証済みのセッションを確立することで、MFAを回避できます。

^{図16：AiTM攻撃の流れ(出典)}

シミュレーション

AiTM攻撃のシミュレーションには、Modlishka、Muraena、Evilginxなど、いくつかのオープンソースツールを利用できます。ここでは、強力で柔軟性の高いフィッシングフレームワークを提供するEvilginxを使用します。実験では、公開されているM365 phishletを使用し、攻撃のホストとしてsplunkphish.comドメインを用意しました。

^{図17：Evilginx}

次の図のように、Evilginxのリバースプロキシ機能によって、標的のユーザーは攻撃側のドメインでMFAセッションを確立することになります。

^{図18：標的のユーザーによるMFAの実行}

認証に成功すると、ユーザーは任意のページにリダイレクトされ、攻撃者はユーザーの認証情報とセッションCookieを手に入れます。この時点で攻撃は成功であり、以降は、手に入れたセッションCookieを使って、認証を行わずに、ユーザーになりすましてMicrosoftサービスを利用できます。

^{図19：Evilginxに表示された、盗まれたセッションCookie}

テレメトリから得られるインサイト

AiTM攻撃では、フィッシングサーバーがすべての通信を転送するプロキシとして機能します。そこでやり取りされる情報には、平文のパスワード、MFAコード、プロトコルヘッダー、ユーザーエージェントなどの機密情報が含まれます。この場合、認証ログのエントリは、ユーザーがブラウザから正規にサインインするときと同じになるため、問題ないように見えます。その中で唯一通常とは異なるのがIPアドレスです。このときログには、ユーザーが使うIPアドレスではなく、フィッシングサーバーのIPアドレスが記録されます。

実験では、UALの分析から、あるパターンを特定しました。標的のユーザーが悪質なドメインで認証に成功すると、「UserLoggedIn」イベントが生成されます。その後、攻撃者が盗んだセッションCookieを自身のブラウザにインポートしてM365テナントにアクセスすると、「UserLoggedIn」イベントが改めて生成されます。フィッシングサーバーと攻撃者のアクセスポイントでIPアドレスが異なる場合、この2つのイベントでは、SessionIdが同じでもIPアドレスが異なることになります。

^{図20：AiTM攻撃で生成された「UserLoggedIn」イベント}

Azure ADログには「SessionId」フィールドはありませんが、非対話型ユーザーサインインのログイベントから同様のインサイトを得られます。非対話型サインインは、ブラウザやデスクトップアプリケーションがユーザーに代わって実行するもので、ユーザー操作を必要としません。攻撃者が盗んだセッションCookieをインポートして標的のテナントにアクセスすると、非対話型サインインイベントが生成されます。

検出ルール

ハンティングの方法はいくつかありますが、成功するかどうかは攻撃の実行方法に大きく左右されます。こちらのサイトやこちらのサイトで紹介されている、条件付きアクセスを使ったAiTM攻撃防止策の導入も検討してください。

O365 Concurrent Sessions From Different IPs

`o365_management_activity` Workload=AzureActiveDirectory  Operation=UserLoggedIn
  | stats min(_time) as firstTime max(_time) as lastTime values(src_ip) as ips 
  values(user_agent) as user_agents by Operation, user, SessionId
  | where mvcount(ips) > 1
  | `security_content_ctime(firstTime)` 
  | `security_content_ctime(lastTime)`

Azure AD Concurrent Sessions From Different IPs

`azuread` properties.authenticationDetails{}.succeeded=true category=NonInteractiveUserSignInLogs
  | rename properties.* as *
  | bucket span=30m _time 
  | stats count min(_time) as firstTime max(_time) as lastTime dc(src_ip) AS unique_ips 
  values(src_ip) as src_ip values(appDisplayName) as appDisplayName by user
  | where unique_ips  > 1 
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

最後に

サイバーセキュリティの状況は、特にM365のようなクラウドベースの環境では、変化が激しく、先手を打つのが困難です。この記事で説明したように、攻撃技法の中には、MFAのような高度なセキュリティ対策を回避するものもあります。効果的な検出戦略を立てるには、IDベースの攻撃に対する理解を深め、初期アクセス技法を警戒することが重要です。この記事を参考に、セキュリティ運用を強化して、実害が出る前に攻撃を検出するための態勢を整備しましょう。

次回のブログ記事では、M365アカウントを乗っ取った攻撃者による偵察や情報窃取について解説する予定です。ぜひご覧ください。

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。