はじめに
今回の記事は、Microsoft Defender for Identity (MDI)をActive DirectoryとMicrosoft Entra Connectにインストールをして、動作確認をしてみた記事です。
もともとMDIはADにセンサーをインストールすることで、オンプレミス環境におけるID保護を実現していました。さらに、Entra ConnectやADCSといったサーバもMDIで保護できるようになりましたので、今回テストをしてみます。
Microsoft Defender for Identity (MDI)とは
MDIとは、Active Directory(AD)のようなオンプレミスのIDを保護するID脅威検出（ITDR） のソリューションです。以前は、Azure Advanced Threat Protection (Azure ATP)と呼ばれていました。
なお、Entra IDのようなクラウドのIDを保護するソリューションとしては、Entra ID Protection (旧名：Azure AD Identity Protection) があります。
どちらもID保護を目的としていますが、保護対象がクラウドユーザ(Entra ID上のユーザ)か、オンプレミスユーザ（AD上のユーザ）かで異なるため、ITDRを考える場合は、両方を考慮するのがよいかもしれません。例えば、Microfoft Defender Portal上でも、ITDRダッシュボードという画面があり、クラウドユーザとオンプレミスユーザ、両方のIDを考慮したダッシュボードとなっています。
今回取り上げるMDIでは、ネットワーク上のMDIセンサーによって検出された疑わしいアクティビティに基づき、セキュリティアラートを発生させることが可能となります。具体的には、以下URLにセキュリティアラートのリストがあります。
補足：MITRE ATT&CK
MDIによって生成されたアラートは、MITRE ATT&CK マトリックスにマッピングすることも可能です。攻撃を防御することも重要ですが、攻撃を正しく認識することも重要視されますので、MITRE ATT&CKに照らし合わせた攻撃手法のカテゴリ化も大切となっています。
MITRE ATT＆CKとは、米国の連邦政府が資金を提供する非営利組織であり、以下マトリックスのような実際の攻撃をまとめたナレッジを公開しています。
具体的には、エンタープライズ向けのマトリックスに記載されている戦術には以下のようなものがあります。
| 戦術 | 英語 | 説明 |
|---|---|---|
| 偵察 | Reconnaissance | 攻撃者による情報収集行為のこと。例えば、標的のインフラストラクチャに対するスキャン行為やWEB上の情報調査などがある。 |
| 初期アクセス | Initial Access | 攻撃者がネットワークに侵入しようとすること。例えば、標的を絞ったスピアフィッシングや、公開されている Web サーバーの弱点を悪用することなどが挙げられる。 |
| 実行 | Execution | 攻撃者が悪意のあるコードを実行しようとすること。例えば、PowershellやWindowsのコマンドを利用することがある。 |
| 永続化 | Persistence | 攻撃者が不正アクセスする環境を確保しようとすること。例えば、スタートアップアイテム項目の追加やアカウントの作成などがある。 |
| 権限昇格 | Privilege Escalation | 攻撃者がより高いレベルの権限を取得しようとすること。システムの脆弱性等を利用して、ルートレベルや管理者レベルの権限を取得することが挙げられる。 |
| 認証情報アクセス | Credential Access | 攻撃者がアカウント名とパスワードを盗もうとすること。例えば、キーロギングや資格情報のダンプ、中間者攻撃、クレデンシャルスタッフィングなどがある。 |
| 探索 | Discovery | 攻撃者がアクセス先の環境を理解しようとすること。例えば、有効なアカウントやグループの検出、ドメイン、レジストリ、ソフトウェア等の情報の調査がある。 |
| 水平展開 | Lateral Movement | 攻撃者がアクセス先の環境を移動すること。SSHやRDPといったリモートサービスやSMBのようなプロトコルを利用して、ネットワーク内のシステムに移動したりすることが挙げられる。 |
| 持ち出し | Exfiltration | 攻撃者がデータを盗もうとすること。例えば、FTP、SMTP、HTTP/S、DNS、SMBといったプロトコルを利用することがある。 |
以下図は、Defender PortalのMDIアラートの詳細画面で、ADに対するクレデンシャルダンピングの可能性があるMDIのセキュリティアラートを表示しています。右下のアラートの詳細のところに、資格情報へのアクセスというカテゴリがあり、これがMITRE ATT&CKのカテゴリとなっています。
テスト構成
今回のテストでは、Hyper-V上に３台のWindows Serverを構築しており、別フォレストのADを２台、Entra Connect用のサーバを１台作っています。この３台にはすべてMDIセンサーをインストールすることで、MDIによるセキュリティ監視を実現しています。
Entra Connectの名前解決
特に、MDIのテストとは関係はないですが、今回Entra Connectは異なる２つのフォレストとなっているADと接続しています。そのため、Entra Connectをインストールする際には、２つの構成済みディレクトリの設定をしています。
Entra Connectは、AD1兼DNSサーバを通常は利用しているため、AD2兼DNSサーバでホスティングされているAD2のドメイン２は名前解決をすることできません。そのため、本テスト環境ではAD1のDNSに条件付きフォワーダーの設定をすることで、ドメイン2のDNSクエリの場合はAD2兼DNSにDNSクエリをフォワードしています。
この結果、Entra ConnectではAD1のドメイン１とAD2のドメイン2の双方の名前解決をすることができています。例えば、Entra Connectからドメイン２のDNSクエリを発行した場合は、まずAD１兼DNSサーバにDNSクエリが向かい、ドメイン２に該当するので、条件付きフォワーダの設定に従い、AD２兼DNSサーバに名前解決が向かいます。
よって、DNSの問題が解消され、Entra Connectとしても異なる二つのフォレスト上のドメインからID同期を実現することができました。
導入手順
MDIセンサーのインストール
Microsoft Defender Portalに移動し、[設定]から[ID]を選択します。
サイドメニューに[センサー]がありますので、[＋センサーの追加]を選択します。
「新しいセンサーを追加する」という表示が出てきますので、ここで[インストーラのダウンロード]を選択します。このインストーラをMDIセンサーをインストールしたいサーバ上に移動し、実行することでMDIセンサーをインストールすることが可能となります。なお、このページで、アクセスキーが表示されますが、この情報はインストーラをインストールする際に入力する必要がありますので、メモをとっておきます。
それでは、ダウンロードしたMDIセンサーのインストーラをAD１上に置き、実行します。
なお、Npcapというファイルもありますが、これはパケットスニファーのためのアプリです。MDIセンサーが不審なネットワークアクティビティを監視するにあたって、Npcapを利用している模様です。
Npcapのドライバー
MDIセンサーをインストールすると、自動でNpcapもインストールされます。試しに、イーサネットのプロパティを見てみると、Npcap Packet Driver (NPCAP) を確認することができます。
有名なWiresharkでもNpcapをパケットスニファのためのドライバーとして利用してたりします。
インストール自体は、ウィザードに従って進めるだけで簡単にできます。以下はインストール時のウィザード画面です。
Entra Connectの場合
Entra Connectに対して、MDIセンサーをインストールする際は、以下のようにインストーラ側で自動認識してくれます。手順自体は、ADにインストールした場合と同じですので、詳細は割愛します。
ここではインストールパスとアクセスキーを入力します。アクセスキーとは、先ほどDefender Portal上でメモをしたキー情報です。
[インストール]を押すと、数分でインストール完了します。
正常にインストール完了すると、以下の画面となります。
同様にして、AD2とEntra ConnectサーバにもMDIセンサーをインストールします。
Defender Portalに戻り、センサーの一覧を確認してみます。数10分時間がかかりましたが、３台ともＭＤＩセンサーが表示されます。ただ何も考えずにインストールしたため、「正常性の状態」に問題が発生しています。これは各サーバに対して適切な設定等が抜けているためとなります。
Entra Connectサーバのための設定
Entra Connectサーバにおいては、Defender Portal上で、ADのFQDN情報の入力が必要となります。
そのため、Entra Connect センサーのところから、[設定]を選択し、ADのFQDN情報を入力し、[保存]を選択します。
次に、[ディレクトリサービスアカウント]を選択します。ここではAD１用のアカウントとAD２用のアカウントの資格情報を入力しています。この情報を入力することで、Entra ConenctサーバからAD接続できるようになり、ネットワークトラフィック、監視対象イベントといったデータをADに照会することが可能となります。
MDIのディレクトリサービスアカウント
MDIのディレクトリサービスアカウント（DSA)としては、グループ管理サービスアカウント(gMSA) を利用することが推奨となっています。gMSAを利用することで、パスワードに関して、ドメインサービスにおけるキー配布サービス（KDS）で定期的な変更の元で管理され、管理者がパスワードの存在を意識する必要がなくなるため、よりセキュアと考えることができます。
https://learn.microsoft.com/ja-jp/defender-for-identity/deploy/directory-service-accounts
MDIセンサーによる監視のためのサーバ設定
それではMDIセンサーのエラーを解消するために、各種サーバの設定をしていきます。
少しめんどくさいですが、MDIセンサーのエラーが表示された状態も気になりますので、各サーバーに設定を施して、エラーを解消していきます。
以下リンク先に[NTLM監査を構成する]という内容のMS Learnの記事があります。この内容通りに監査設定を実施します。
設定した際のグループポリシーの管理の画面は以下の通りです。
以下リンク先に[UIから高度な監査ポリシー設定を構成する]という内容のMS Learnの記事があります。この内容通りに監査設定を実施します。
設定した際のグループポリシーの管理の画面は以下の通りです。
以下リンク先に[ドメインオブジェクト監査を構成する]という内容のMS Learnの記事があります。この内容通りに監査設定を実施します。
電源設定に関しても最初エラーが発生していましたので、こちらも[高パフォーマンス]に変更します。
一通り設定が完了しましたら、Defender PortalのMDIセンサーを見てみます。反映されるのに少し時間がかかりますが、「正常性の状態」が「正常」に変わりました。これでMDIセンサーのインストール作業と各種サーバ設定は完了です。
動作確認
ハニートークンアカウント
MDIには、おとりアカウントを作成し、このおとりアカウントが利用されたときに、セキュリティアラートを発生させる機能があります。例えば、攻撃者が真っ先に狙いたくなるようなアカウント名（例：admin , root)などでアカウントを用意しておき、実際にこのおとりアカウントが利用されたら、MDIのアラートにより気づくことができるようにします。
設定はエンティティタグのところに、[ハニートークン]というサイドメニューがあるので、[+ユーザーにタグをつける]をクリックし、対象となるユーザを選ぶだけとなります。選択可能なユーザはMDIセンサーが自動でAD上のユーザを表示してくれます。
もし、ハニートークンアカウントにしたいユーザがない場合は、AD上でユーザを作り、少し待つとDefender Portalで選択することが可能となります。
それでは、PCから意図的にドメイン参加するユーザとして、ハニートークンアカウントを利用してみます。実際にハニートークンアカウントの利用が成功しても、失敗してもアラートが発生しました。
以下画像のように、Honeytoken authentication activity on one endpointというインシデントが生成されています。
アラートの詳細画面を開いてみます。PC１からハニートークンアカウントを利用したログイン試行が観測されています。
さらに、このADユーザを選択することで、Defender Portalから[ADでユーザーを無効にする]ということもできます。
※ハイブリッドユーザの場合は、ADでユーザを無効化すれば、Entra Connectにより、Entra IDのユーザも自動で無効化されます。
実行後、AD上のユーザを確認してみると、ユーザが無効化されています。
無効化されていることが確認できましたので、再度有効化します。
Defender Portalで、[ADでユーザを有効にする]を選択します。
無事有効化も実現することができました。
テストモードの利用
今回はセキュリティアラートが発生しやすくするため、アラートのしきい値を調整する から 推奨テストモード を有効化しておきます。これによって、アラートが発生するしきい値が低となり、アラートが発生しやすくなります。
次に、Entra Connectサーバ上で、何度かドメインユーザやグループ(例：Domain Adminsなど)を確認するためのコマンド(net user /domain など)を実行してみますと、アラートが発生しました。
なお、MDIは学習期間があり、正当なアクティビティと不審なアクティビティを区別する機能がありますが、今回は、意図的に推奨テストモードにしているため、セキュリティアラートがトリガーされた模様です。
実際、画像の下部に「このアラートは、アラートのしきい値が低りレベルに設定されていたためにトリガーされました」と表示があります。
終わりに
今回は、Microsoft Defender for Identity (MDI)のインストールから簡易的な動作確認まで実施しました。実際のところ、MDIセンサーのインストールは簡単でしたが、セキュリティアラートを発生させるところに悪戦苦闘してしまいました。ADやEntra Connectは最重要なサーバである以上、MDIのようなセキュリティ製品は有用な気がしました。