Adversary in the middle(AiTM) 向けの Sentinel 検出ルールを考えてみる

Adversary in the middle(AiTM) とは？

Adversary in the middle 攻撃は昨今急速に増えている ID に対する高度な攻撃手法です。多要素認証(MFA)が普及してきたことで、MFA で保護されているユーザーは旧来のパスワードへの攻撃の侵害に成功するケースは減ってきておりますが、攻撃者は MFA で保護されているアカウントを侵害するために、より高度な攻撃を生み出してきております。そのうちの一つが Adversary in the middle (AiTM)攻撃です。
攻撃の動作の解説は日本マイクロソフトのサポートブログのこちらの記事をご参照ください。

Adversary in the middle への対策

具体的な対策方法は上述のサポートブログの記事にも書いてありますが、パスキー(FIDO2)を使うことです。パスキー(FIDO2)では、rpId で、リソース プロバイダー(認証を行うサービス)の ID を管理しており、これがリソース プロバイダーの URL と深く紐づいております。実際の認証の際には rpId の正当性のチェックを行う為、アクセス先の URL が正規のサービスかのチェックがされ、AiTM のような攻撃者の悪意あるサーバー、サービスが間にある場合に認証ができないようになっています。
とはいえ、MFA 自体もなかなか全社員に普及させることが難しい企業も一定数いる中、全員がパスキー(FIDO2)を使うという状況に行くにはより一層の時間が掛かると思います。
また、パスキーを展開できたとして、AiTM で侵害されてしまう電話番号や、TOTP のような要素での多要素認証を完全廃止することはより難しいでしょう。
その為、こういった攻撃には発生した際に可能な限り早期に検出ができるようにしておくというのは重要です。

攻撃が発生した際にどう検出するか？

基本的にはやはりサインインのログ情報を SIEM ソリューションで分析し、AiTM の兆候があった際にアラートを上げるという事が望ましいと思います。
今回は認証サービスが Microsoft Entra ID で、Microsoft Sentinel にサインイン ログ連携をしている構成でどういった検出ができるかを考えてみたいと思います。
コンテンツ ハブで公開されているテンプレートとして以下のものがあります。こういった既にあるテンプレートを展開して行くというのは手軽に先ず始めるという点で良いと思います。

• Possible AiTM Phishing Attempt Against Microsoft Entra ID

他の検出ロジックが無いか考えてみる

上記は AiTM の攻撃後の Web Session 情報などから AiTM の可能性を探るルールですが、私は少し違うアプローチでも検出ロジックを作れないか考えてみました。

1. AiTM は普段そのユーザーが利用していない IPアドレス等の環境からのアクセスになるため、サインイン リスクとして普段と違う属性からのアクセスが検出される可能性が高いです。さらにその上で、フィッシングに強くない MFA の要素を使ってサインインが成功しているはずです。
2. AiTM 攻撃が成立した後、正規のユーザーはどういった動作になるのでしょうか？よくあるのは正しいサービス(OfficeHome)等にリダイレクトされます。AiTM の攻撃の例でも一度認証したのに、もう一度 Microsoft Entra ID の認証画面が出るといった動きになるというのはよく説明されるケースです。つまり、AiTM 後には正規の通常のサインインがすぐに行われているというケースが多いと思われます。

上記から、普段と違うサインインで、フィッシングに強くない MFA でサインイン成功後に、普段と同様(サインイン リスクのない)のサインインが直後に成功している場合に、 AiTM を受けた可能性が有るというアラートを発生させるような分析ルール用の KQL を考えてみました。
以下サンプルでは通常のサインインは5分以内で、OfficeHome へのアクセスという条件を入れておりますが、この辺りは組織での誤検出の量と鑑みて調整していただければと思います。

let lookupWindow = 5min;
let NonPhishResistantMFA = dynamic(["Mobile app notification", "OATH verification code", "Text message", "Phone call approval (Authentication phone)", "Phone call approval (Alternate phone)", "Passwordless phone sign-in", "Phone call approval (Office phone)", "Passwordless Microsoft Authenticator", "Other"]);​
let possibleAiTM = SigninLogs​​
    | where RiskEventTypes has "unfamiliarFeatures"​
    | where RiskState == "remediated"​
    | mv-apply AuthenticationDetails = todynamic(AuthenticationDetails) to typeof(dynamic) on (​
        where AuthenticationDetails.authenticationMethod has_any (NonPhishResistantMFA)​
        | extend Method = AuthenticationDetails.authenticationMethod
        )
    | project-rename previousIPAddress=IPAddress, previousCreatedDateTime = CreatedDateTime;
possibleAiTM
| extend timekey = bin(previousCreatedDateTime, lookupWindow)
| join kind=inner (
    SigninLogs
    | where AppDisplayName == "OfficeHome"
    | where ResultType == 0
    | project-rename nextIPAddress=IPAddress, nextCreatedDateTime = CreatedDateTime
    | extend timekey = bin(nextCreatedDateTime, lookupWindow)
    )
    on timekey, UserPrincipalName
| where previousIPAddress != nextIPAddress
| where nextCreatedDateTime > previousCreatedDateTime
| summarize arg_max(TimeGenerated, *) by TimeGenerated, UserPrincipalName
| project
    TimeGenerated,
    Method,
    UserPrincipalName,
    UserId,
    UserDisplayName,
    AppDisplayName,
    ClientAppUsed,
    IPAddress=previousIPAddress,
    LocationDetails,
    MfaDetail,
    RiskEventTypes,
    RiskEventTypes_V2,
    RiskState,
    ResourceDisplayName,
    UserAgent

上記 KQL クエリのサンプル分析ルールの ARM テンプレートも公開してみたので宜しければご参考にしてください。

自動対応

AiTM の疑いがあった際に自動対応でその対象ユーザーのセッションを破棄するという事も対応として考えられます。ユーザーは再認証など求められてしまいますが、攻撃者が取得したトークンは利用できなくなり、侵害の拡大を防ぐことが期待できます。この辺りは検出時の誤検知の分量や、ユーザー再認証の影響等を含め、各組織で自動か対応をどこまでするかはご判断いただければと思います。

免責事項

本記事中の KQL クエリ、分析ルール ARM テンプレートは筆者の環境で動作させたサンプルとなります。利用、改変は自由ですが、利用者の責任で行っていただき、いかなる損害についても保証しかねます。