MDE Attack Disruptionが作動しました

皆さんこんにちは。国井です。
いま書籍を2冊同時並行に書いていて
ブログ執筆になかなか手が回らず、間が空いてしまいました。

今日はMDEの新しい機能、Attack Disruptionについてです。
Microsoft Learnでは「自動攻撃の中断」っていう訳語が当たっているんだけど、なんかしっくりこないので、ここではAttack Disruptionという言葉で通します。
Attack DisruptionとはMDEが攻撃を検知したときに、検知した攻撃の種類に合わせて、その後に行われるであろう攻撃に先回りをして攻撃をブロックする機能です。
具体的にどのような攻撃に対して有効なのか？とか、どういうブロックをするのか？とかはブラックボックスなのでよくわからないのですが、私の環境ではPass the Hash (PtH) 攻撃をしたらAttack Disruptionが作動したので、こんな感じだったよというのを紹介します。

行った攻撃について

Windows 10クライアントとWindows Serverのドメインコントローラーがそれぞれ用意されている環境を用意しました。それでもってWindows 10クライアントはドメイン参加のコンピューターなんだけど、既にマルウェア感染によって危殆化している状態というシナリオにしてみました。
ここで行ったことは以下の通りです。

1．クライアントでnslookupコマンドを実行し、ドメインコントローラーの場所を特定
2．クライアントでnet groupコマンドを実行し、管理者のユーザー名を特定
3．クライアントでmimikatzを実行し、管理者ユーザーのNTLMハッシュを奪取
4．同じ仮想ネットワーク内にいるLinuxホストからPtH攻撃でドメインコントローラーに接続
5．ドメインコントローラーに接続成功したら、whoamiなどの探索系コマンドを実行

Microsoft Defender XDR管理センターで出力したインシデントとアラート

Microsoft Igniteで発表されたAttack Disruption機能ですが、その中ではいくつかのシナリオを持っていて、インシデントが発生した状況から自動的にシナリオを選択し、攻撃のブロックをしてくれるという話をしていました。
その話に基づくと、今回のシナリオではハンズオンキーボード攻撃と呼ばれるシナリオに該当したらしく、Hands-on keyboard attack was launched from a compromised account (attack disruption) というインシデント名でインシデントが出力しました。
ちなみにattack disruptionが作動する前にインシデント自体が出ていたのですが、attack disruptionのシナリオに一致したと判断した瞬間、もともとのインシデントの名前が変わってご覧のようなインシデント名に変わりました。

インシデント内のアラートを見てみると、こんな感じのものが出ていました。

ここまではいつものような表示内容でした。

自動調査について

MDEではインシデントが発生すると自動調査と呼ばれる機能が働いて、発生したインシデントからどのような対応が必要かを見極め、自動的に対処してくれます。例えばマルウェアが実行しているということであれば検疫するなどの処理です。
MDEの自動調査の結果として行った処置はサービスソースがMicrosoft Defender for Endpointとして出力されるのに対して、Attack Disruptionで実行した処置はサービスソースの記載がないことがわかります。

サービスソースの記載がないContaining a compromised user account suspected of conducting a hands-on-keyboard attack 項目をクリックすると調査画面としてはおなじみの画面が出てきてどういう処置を行ったのかが現れます。
一般的な調査と異なるのは[証拠]タブに「マルウェアが見つかったから検疫した」みたいな項目は出てこないことです。

じゃあ何をしたのか？というと、それは[ログ]タブに書かれていました。

説明欄に書いてある内容を抜粋すると次の通りです。

Contains the user account by enforcing a policy that prevents or terminates remote activity initiated by potentially compromised accounts through commonly used protocols associated with lateral movement. It might take a few minutes for this change to take effect. See Action Center for more information.
訳）横の動きに関連する一般的に使用されるプロトコルを介して、潜在的に侵害されたアカウントによって開始されたリモート活動を防止または終了するポリシーを強制することにより、ユーザーアカウントを含んでいます。この変更が有効になるまで数分かかる場合があります。詳細については、アクションセンターを参照してください。

説明がわかりずらいですが、つまりリモートデスクトップ接続を無効化したということが書かれています。

最後にこの処置をしたきっかけとなったアラートですが、こちらになります。

10.0.0.7 (クライアント) からドメインコントローラーに向かって遠隔からサービスを作成する操作が行われたと書かれているので、だからリモートデスクトップ接続を無効化して、そうした遠隔操作をこれ以上させないようにしたんだなということがわかります。

なお、処置の結果はMicrosoft Defender XDR管理センターのアクションと報告 > アクションセンターからも確認できます。アクションソースを[攻撃の妨害]としてフィルターすると、同じ結果を参照できます。

こんな感じでドメインコントローラーも含めてMDEにオンボードしておけば、ドメインコントローラーもMDEによるAttack Disruptionによる保護対象となるわけです。
(MDEにオンボードしているから、というよりはMDCによるカバレッジ対象になっているから？？)

一方その頃、Microsoft Defender for Identityは？

Microsoft Defender XDRでドメインコントローラーの保護と言えば、Microsoft Defender for Identity(MDI)を思い浮かべると思いますが、こちらはどのようなアラートを出してくれたのでしょうか？それがこちらです。

Suspicious service creationというアラートがMDIのアラートとなっていて、クリックするとこんな感じの内容を参照できます。PtH攻撃が行われ、PSExecによって勝手にサービスが作られたことを表すアラートが確認できます。

だけどMDIのアラートを見ていて、いつも思うことだけど「PtH攻撃が行われ、PSExecによって..」ってそういう攻撃があるってことを知っている前提になってますよね？このアラートを文面通りに解釈すると、わけのわからないサービスが作られたとしか確認できないので、それが攻撃なのか、それとも何かのトラブルで起きたことなのか、などがわからないのです。
(もちろん、DNSクエリやユーザー列挙系の攻撃はMDIにしかわからない情報を提供してくれるので、それはそれでありがたいのですが..)
そういう意味でドメインコントローラーの監視をMDIだけに任せるというのは自分としてはとても不安であり、その意味でドメインコントローラーをMDEにオンボードして立体的な調査を行えるようにしたり、Attack Disruptionで保護していくことには大きな意味があるように思うのです。