Microsoft 365 Defender 管理センターを利用したASRの管理
【2025年4月24日追記】Microsoft 365 Defender は、2023年11月からMicrosoft Defender XDRに名称変更されています。 機能に大きな変更はないため、「Microsoft Defender XDR」と読み替えていただければ、そのままご参考いただけます。
皆さんこんにちは。国井です。
最近わけあってMicrosoft Defender for Endpoint (MDE) を使う機会が多いのですが、
そんな中で攻撃表面の減少 (ASR) との関係性がわかりにくいところがあったのでまとめておこうかなと思いました。
攻撃表面の減少とは
攻撃表面の減少とはAttack Surface Reductionの略からASRと呼ばれている機能で、ものすごくざっくり説明するとWindows をターゲットとして行われる攻撃のうち、典型的な攻撃について検知・ブロックしてくれる機能です。
例えば、Microsoft Officeから子プロセスを実行させない(＝マクロ経由でのマルウェア感染防止)とか、難読化された可能性のあるスクリプトの実行をブロックする(＝マルウェアって自身の存在を簡単に知られないようにするためにスクリプトの内容を読めなくする) などの設定があります。この設定はPowerShellから設定したり、GPOやIntuneから設定したりすることができるのですが、
なかなか厳しいのは子プロセスを実行させない設定を行うと印刷ができなくなる？？などのトラブルが報告されており、厳しすぎるがゆえに起こる副作用が色々あるのが課題なんですよね..
ASRの副作用と闘う
副作用があることはMSさんもわかっているのか、ASRはブロックする設定だけでなく、監査だけを行う設定も用意しています。いきなりブロックして業務に影響が出ないようにするためです。だけど、監査するにしても結果がわからないとそのまま使ってて良いのかさえもわかりません。そこでMDEが登場します。
MDEのレポート > 攻撃表面の減少ルールからASRの設定状況や適用状況は確認できるようになっていて、Detectionタブでは適用状況、Configurationタブでは設定状況がそれぞれ確認できます。実際にDetectionタブを見てみるとCitrixReceiverUpdate.exeがASRでブロックされている様子が確認できます。
CitrixReceiverUpdate.exeって名前から想像するにCitrixのクライアントアプリのバージョンアップなどを自動で行ってくれるアプリですよね？
だからこれがブロックされ続けたら、いつまでもバージョンアップが起こらない → 脆弱性が放置される、というスパイラルに陥る可能性があります。
アプリのブロックは妥当なのか調べてみる
CitrixReceiverUpdate.exeが1月17日10:57にブロックしているんだけど、
不正な目的なのか？
また動いていなくてもよいものなのか？
この当たりを調べてみることにしました。
まずはAdvanced Huntingクエリで次のように実行してみました。
(DeviceEventsスキーマからActionType contains “ASR”と書くとASRでブロックしました系のログを拾えるのでお勧めです)
DeviceEvents | where ActionType contains "ASR" | project Timestamp, DeviceId, ActionType, FileName
でもって実行結果はこちら。
確かにCitrixReceiverUpdate.exeが1月17日10:57にブロックされたことが確認できました。
次にCitrixReceiverUpdate.exeプロセスそのものにフォーカスしてみていきます。
DeviceProcessEvents | where FileName contains "CitrixReceiverUpdater.exe" | project Timestamp, DeviceId, ActionType, FileName
すると、1月17日のログを含めて数回のCitrixReceiverUpdate.exeを実行した結果が確認できました。そしてそれぞれのログをクリックすると、ご覧のような結果を見ることができます。
これを見る限りでは不審な点は見当たらないし、他のログと比較しても同じような結果であることがわかりました。ということで今度はCitrixReceiverUpdate.exeから呼び出されたプロセスを調べてみることにしました。
| where InitiatingProcessFileName contains “CitrixReceiverUpdater.exe” と書くとCitrixReceiverUpdate.exeから呼び出されたプロセスが確認できます。
DeviceProcessEvents | where InitiatingProcessFileName contains "CitrixReceiverUpdater.exe" | project Timestamp, DeviceId, ActionType, FileName
実行結果はこちら。
ASRでブロックされた1月17日10:57ではCitrix Workspace Appの新しいバージョン？の22.12.0.48をインストールしようとしていることがわかりました。
これをブロックしているのだなということも時間からわかりますね。
悪影響もなさそうだし、むしろ新しいバージョンのインストールをブロックすることのほうが悪影響が大きいと判断し、ブロックしないよう、例外設定をすることにしました。
例外設定は先ほど登場したレポートの Detections タブから CitrixReceiverUpdate.exe を選択して、[除外の追加]をクリックするとブロックされなくなります。
除外の追加が完了すると、除外の追加 タブから追加したものが確認できます。
除外をしたら果たして新しいバージョンはインストールされたのだろうか？
もし気になるのであれば、Microsoft365管理センターの 脆弱性の管理 > 在庫 からオンボードされたデバイスにインストールされているアプリの一覧を確認できます。
Citrix Workspace アプリを選択すると、こんな感じでオンボードされたデバイスにインストールされているアプリのバージョンは22.12.0.48であることがわかりました。
CitrixReceiverUpdate.exeが動いて必要なアップデートを行ってくれたのね。
ASRは副作用が大きいがゆえに設定して終わり！ではなく、副作用がないか？適切に動作しているか？などのチェックが必要です。その時にMDEが使えますよとは言うものの、どうやって使えば良いんだという話も聞こえてきます。
そこで今回はその利用方法について私なりの調べ方というのを紹介させていただきました。
実際、この方法以外にもいろいろなやり方があるでしょうし、私のやり方のダメな部分とかもあると思うのです。
そのあたりはご意見などあれば、お聞かせ願えればうれしいです。
