【Elastic】Defender for Endpoint のログを取り込んでみた
はじめに
Microsoft 社の EDR 製品である Microsoft Defender for Endpoint [1] のデバイスログを活用して
セキュリティ運用業務を高度化するケースを想定し、Elasticsearch にログを取り込んでみました。
本投稿で説明する内容
本記事では Elastic Agent [2] で Defender for Endpoint のデバイスログを取り込み
Elasticsearch に取り込んだログを Kibana で検索や可視化できるようにします。
前提
・端末は Surface Laptop2 および Macbook Pro(2020)を利用しています。
・端末への Defender for Endpoint は事前導入済みです。
・Azure のサブスクリプションおよび AWS アカウントは事前作成済みです。
・Elasticsearch と Kibana は Standard Edtition で事前構築済みです。(Elastic Cloud でも可)
・Elastic Agent のインストールはスタンドアローン方式を利用しています。
利用環境
各ソフトウェアのバージョンは以下の通りです。
Product | version |
---|---|
Windows OS | Windows 11 Pro 22H2 |
macOS | Sonoma 14.4.1(23E224) |
Defender マルウェア対策クライアント | 101.24032.0006 |
Defender エンジン | 1.1.24030.4 |
Defender ウィルス対策 | 1.409.620.0 |
Defender スパイウェア対策 | 1.409.620.0 |
Amazon Linux | 2023.2.20231113.0 |
Elasticsearch | 8.11.2 |
Kibana | 8.11.2 |
Elastic Agent | 8.11.2 |
Microsoft M365 Defender Integration | 2.7.1 |
【構成図】
・Streaming API を介し、Event Hubs [3] 経由で Elastic Agent がログを取得します。
・対象とする 12 種類のログをすべて 1 つのイベントハブに転送する構成とします。
・Elastic Agent がどこまでログを取り込んだかを Azure Blob Storage に記録します。
全体構成図
【利用するライセンス】
・Microsoft ライセンスは、Microsoft Defender for Endpoint P2 を利用します。
・1 ライセンスで 5 端末/ユーザーまで利用可、月額払い 780 円/月(2024 年 5 月時点)です。
・機能一覧 を参照し、高度な追及の機能を利用できるプランを選定しています。
・Microsoft Defender for Endpoint P2 Trial(90日間)[4] で検証することも可能です。
利用するライセンス
取得するログ
取得対象とする Defender for Endpoint のスキーマは下記の通りです。
# | 種別 | スキーマ名 | 説明 |
---|---|---|---|
1 | アラートと動作 | AlertEvidence | 検知したアラートに関するログ |
2 | アラートと動作 | AlertInfo | 検知したアラートに関する重要度、脅威の分類などの情報 |
3 | デバイス | DeviceEvents | ウイルス対策やエクスプロイト保護などによって検知されるイベントを含む、複数のイベントのログ |
4 | デバイス | DeviceFileCertificateinfo | 端末上の証明書検証イベントから取得した署名済みファイルの証明書情報 |
5 | デバイス | DeviceFileEvents | ファイルの作成や変更、その他ファイルシステムに関するイベントログ |
6 | デバイス | DeviceImageLoadEvents | DLL ファイルの読み込みイベントに関するログ |
7 | デバイス | DeviceInfo | OS 情報を含む端末に関する情報 |
8 | デバイス | DeviceLogonEvents | 端末上のユーザーログオンやその他の認証イベントに関するログ |
9 | デバイス | DevicenetworkEvents | ネットワーク接続とそれに関連するイベントのログ |
10 | デバイス | DeviceNetworkInfo | 端末のネットワーク(NIC, IPアドレス, MACアドレスなど)に関する情報 |
11 | デバイス | DeviceProcessEvents | プロセスの作成とそれに関連するイベントのログ |
12 | デバイス | DeviceRegistryEvents | レジストリエントリの作成と変更に関するイベントのログ |
・Microsoft Defender Portal にアクセスし、[追及] > [高度な追及]で確認できます。
高度な追及(Advanced hunting)の画面
関連する Microsoft 社の API
Microsoft 社と Elastic 社の公式サイトを調べていると多くの似たような API が出てきます。
2024 年 5 月時点で抑えておくべきものは、以下の 2 つになります。
-
Microsoft 365 Streaming API [5]
・今回利用する API になります。
・アラートとデバイスに関するログをニアリアルタイムに転送します。
・転送先に Event Hubs と Azure Blob Storage が指定できます。
-
Microsoft Graph Security API [6]
・Defender シリーズや Purview DLP に関するアラートやインシデントのログを提供します。
・2018 年 9 月に GA して以降、アラート系はこの API に集約されています。
Elastic 社が用意しているツール
Defender for Endpoint のログ取得に関して、下記の 4 種類のツールがあります。
- Microsoft M365 Defender Integration [10]
- Microsoft Defender for Endpoint Integration [11]
- Filebeat azure eventhub input [12]
- Filebeat Microsoft module [13]
下記図は、各ツールで利用する API とその API で取得できるログをまとめた表になります。
各ツールの利用する API と取得可能なログ
Event に含まれるデバイスログを取得するために Streaming API を利用します。
Streaming API を利用して デバイスログを取得できるツールは以下の 2 つになります。
・Microsoft M365 Defender Integration
・Filebeat azure eventhub input
本記事では、Microsoft M365 Defender Integration を使った手順とその結果を解説します。
実施手順
ここからは、いよいよ実施手順について解説します。
- Event Hubs の設定
- Azure Blob Storage の設定
- Elastic Agent での取得設定
1. Event Hubs の設定
Defender for Endpoint の各スキーマのログを転送するため、イベントハブを作成します。
(Event Hubs の用語や機能の基礎知識については、参考 URL を参照ください)
【参考】
・Azure Event Hubs の機能と用語(公式ページ)
・Azure Event Hubs をいい感じにわかりやすくしたい
・Event Hubs を構成する(公式ページ)
1-1. リソースプロバイダーの登録
まず、Azure Portal にログインし、[サブスクリプション] を開きます。
利用するサブスクリプション名を指定し、[リソースプロバイダー] をクリックします。
一覧から microsoft.insights
を見つけ、[登録] します。(状態が Registered になれば OK です)
microsoft.insightsの登録
1-2. 名前空間の作成
Azure Portal のホームで [Event Hubs] を選択し、[+作成] ボタンをクリックします。
Event Hubs の作成
下記の設定項目を設定し、画面下部の [確認および作成] ボタンを押します。
名前空間の作成
【設定内容】
項目 | 設定値 | 備考 |
---|---|---|
サブスクリプション | Azure subscription 1 | 前手順で指定したものを利用 |
リソースグループ | Dev | 新規に作成 |
名前空間の名前 | defenderevents2 | グローバルに一意であること |
場所 | East US | 好きなリージョンを指定 |
価格レベル | Basic | 検証のため一番低いレベルを指定 |
スループットユニット | 1 | デフォルト値のまま |
数分ほどすると 「デプロイが完了しました」と表示されます。
Event Hubs の中に作成した名前空間が表示(状態: アクティブ)されていれば OK です。
[共有アクセスポリシー] を開き、RootManageShareAccessKey
をクリックします。
右側に開いた画面で [接続文字列 - 主キー] をクリップボードにコピーしておきます。
接続文字列 - 主キーのコピー
[プロパティ] を開き、名前空間のリソース ID をクリップボードにコピーしておきます。
リソース ID のコピー
名前空間のリソース ID の構造は以下の通りです。(Streaming API の設定手順で利用)
/subscriptions/<サブスクリプション ID>/resourceGroups/<リソースグループ名>/providers/Microsoft.EventHub/namespaces/<名前空間名>
【参考】
・Event Hubs の接続文字列の取得(公式ページ)
1-3. イベントハブの作成
作成した名前空間を開き、[概要] ページの [+イベントハブ] ボタンをクリックします。
イベントの作成1
下記の設定項目を設定し、画面下部の [確認および作成] ボタンを押します。
イベントの作成2
【設定内容】
項目 | 設定値 | 備考 |
---|---|---|
名前 | defenderhub | 好きな名前を入力 |
パーティション数 | 2 | オフセット値の動きを見るため 2 に変更 |
クリーンアップポリシー | 削除 | デフォルト値のまま |
保持時間(時間) | 1 | デフォルト値のまま |
[コンシューマーグループ] を開き、デフォルトで存在している名前($Default
)をメモします。
コンシューマーグループ名をメモ
1-4. Streaming API の設定
ここからは、Microsoft Defender Portal にログインして操作を行います。
ログイン後、[設定] > [Microsoft Defender XDR] をクリックします。
Streaming API の設定1
[ストリーミング API] > [+追加] ボタンをクリックします。
Streaming API の設定2
下記の設定項目を設定し、画面下部の [送信] ボタンを押します。
Streaming API の設定3
【設定内容】
項目 | 設定値 | 備考 |
---|---|---|
名前 | EventHubs Export | 好きな名前を入力 |
イベントハブにイベントを転送 | ☑︎ | Event Hubs に転送 |
イベントハブのリソース ID | <名前空間のリソース ID> | 手順 1-2 でコピーしたもの |
イベントハブ名 | defenderhub | 手順 1-3 で作成したもの |
イベントの種類 | アラートと動作(2), デバイス(10) | 12 個全部にチェック |
Defender for Endpoint でイベントが発生してから数分するとキューにデータ流れてきます。
イベントハブの性能グラフ
【参考】
・Configure Defender XDR to stream Advanced Hunting events to your Event Hub
2. Azure Blob Storage の設定
Elastic Agent が Event Hubs のログをどこまで読み取ったかを管理する
オフセットファイルの保存場所(ストレージコンテナー)を作成します。
【参考】
・Azure Storage の種類や追加オプションを紹介
・Azure Portal を介した Azure Blob Storage の使い方(初心者向け)
・ストレージアカウントアクセスキーを管理する(公式ページ)
2-1. ストレージアカウントの作成
再度、Azure Portal にアクセスします。
ホームで [ストレージアカウント] を選択し、[+作成] ボタンをクリックします。
ストレージアカウントの作成1
下記の設定項目を設定し、画面下部の [確認および作成] ボタンを押します。
ストレージアカウントの作成2
【設定内容】
項目 | 設定値 | 備考 |
---|---|---|
サブスクリプション | Azure subscription 1 | これまでの手順と同じものを利用 |
リソースグループ | Dev | これまでの手順と同じものを利用 |
ストレージアカウント名 | teststaccount99 | グローバルに一意であること |
地域 | East US | これまでの手順と同じものを利用 |
パフォーマンス | Standard | 汎用 v2 アカウントで良いため |
冗長性 | ローカル冗長ストレージ(LRS) | 検証のため一番低いレベルを指定 |
作成後、ストレージアカウントの [アクセスキー] を開き、[キー] を表示した上でコピーします。
ストレージアカウントキーのコピー
2-2. ストレージコンテナの作成
作成したストレージアカウントを選択します。
[コンテナー] を開き、[+コンテナー] ボタンをクリックします。
ストレージコンテナーの作成1
[名前] に好きな名前でストレージコンテナー名(testcontainer01
)を入力し、画面下部の [作成] ボタンを押します。
ストレージコンテナーの作成2
3. Elastic Agent での取得方法
Elastic Agent のインストール先は AWS EC2 の Amazon Linux 2023 になります。
今回は Fleet を利用せず、スタンドアローン方式で Elastic Agent をインストールします。
【参考】
・Elastic Agent インストール方法(公式ページ)
・スタンドアローンでの Elastic Agent インストール方法(公式ページ)
3-1. Integrations のポリシー設定
Elastic Agent で有効化する Integrations は elastic-agent.yml
で設定します。
Kibana の Integrations 画面で elastic-agent.yml
の設定を作成します。
Kibana にログインし、ホーム画面の [+ Add Integrations] をクリックします。
Kibana ホーム画面
「Microsoft M365 Defeder」をクリックします。
Integrations 画面
[+Add Microsoft M365 Defender] をクリックします。
Microsofot M365 Defender の追加
[Collect logs from M365 Defender API] のスライダーをオフにします。(今回は利用しません)
Collect logs from M365 Defender API の無効化
これまで設定してきた Azure 側の設定値を下記のように設定します。
Collect logs from Azure Event Hub の設定1
Collect logs from Azure Event Hub の設定2
【設定内容】
項目 | 設定値 | 備考 |
---|---|---|
Event Hub | defenderhub | 「イベントハブ名」を入力 |
Consumer Group | $Default | 「コンシューマーグループ名」を入力 |
Connection String | Endpoint=sb://••• | 「接続文字列 - 主キー」を入力 |
Storage Account | teststaccount99 | 「ストレージアカウント名」を入力 |
Storage Account Key | <ストレージアカウントキー> | ストレージアカウントの「アクセスキー」を入力 |
Storage Account Container | testcontainer01 | 「ストレージコンテナ名」を入力 |
画面下部の [Save and continue] ボタンを押します。
設定の保存
下記画面が表示されれば、Integrations の設定は完了です。
Integrations の設定完了
[Add Elastic Agent to your hosts] をクリックし、インストールの準備をします。
今回はスタンドアローン方式でインストールするため、[Run standalone] タブを開きます。
Elastic Agent の設定ファイルのダウンロード
先ほどの Integrations の設定が反映された elastic-agent.yml
が表示されています。
[Download Policy] をクリックして設定ファイルをダウンロードします。
3-2. Elastic Agent のインストール
以下のコマンド操作で Amazon Linux 2023 に Elastic Agent をインストールします。
まず、Amazon Linux のマシンにログインします。
ログイン後、curl コマンドを使って、インターネット経由でインストーラーをダウンロードします。
$ sudo curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-8.11.2-linux-x86_64.tar.gz
ダウンロードしたインストーラー(tar ファイル)を解凍します。
$ sudo tar xzvf elastic-agent-8.11.2-linux-x86_64.tar.gz
インストーラーの実行ファイルが置かれているディレクトリに移動します。
$ sudo cd elastic-agent-8.11.2-linux-x86_64
管理者権限で Elastic Agent のインストールを実行します。
$ sudo ./elastic-agent install
インストールするディレクトリが /opt/Elastic/Agent
になるが継続するかと聞かれますが、Y(Yes)
とします。
次に Fleet での管理を希望するか聞かれますが、今回は N(No)
とします。
Elastic Agent will be installed at /opt/Elastic/Agent and will run as a service. Do you want to continue? [Y/n]:Y
Do you want to enroll this Agent into Fleet? [Y/n]:n
Copying files............... DONE
Installing service....... DONE
Starting service... DONE
Elastic Agent has been successfully installed.
3-3. Elastic Agent の設定
/opt/Elastic/Agent
配下に置かれている elastic-agent.yml
を先ほど Kibana からダウンロードしたものに差し替えます。
$ sudo vi /opt/Elastic/Agent/elastic-agent.yml
差し替え後、outputs 句の username
と password
を自身の Elasticsearch の認証情報に書き換え、保存して閉じます。
outputs:
default:
type: elasticsearch
hosts:
- 'https://10.0.4.104:9200'
ssl.ca_trusted_fingerprint: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
username: 'elastic'
password: '<elastic ユーザーのパスワード>'
ファイル更新後、Elastic Agent のプロセスを起動します。
$ sudo systemctl start elastic-agent
プロセスが正常起動し、Elasticsearch に Index が作成されれば完了です。
$ sudo systemctl status elastic-agent
取り込みが開始されると Azure Blob Storage のストレージコンテナー内にオフセット値が記載されたファイルが生成されます。
オフセットファイル
ファイル名は Event Hubs のパーティション名になっています。(0番から順番)
ログの確認
最後に Kibana にログインし、取り込んだログについて確認してみます。
Index の確認
Kibana メニューの [Stack Management] > [index Management] を開きます。
logs-m365_defender.event-default
という Data Stream が生成されています。
Data Stream 名
上記の Data Stream に .ds-logs-m365_defender.event-default-yyyy.mm.dd-00000x
という Index が生成され、この中にログが格納されています。
Index 名
ログフィールド構造
EICAR テストファイルを使って、ウィルス検知させて DeviceEvent( ActionType
: AntivirusDetection
) のログを確認してみました。
下記表は、Defender Portal と Elastic Agent のフィールドをマッピングしたものになります。
(フィールド名が長いため、表全体を表示する場合は右側にスクロールしてください)
【EICAR 検知時の DeviceEvent のログ】
Defender Portal でのフィールド名 | Elastic Agent でのフィールド名 | サンプル値 |
---|---|---|
Timestamp | @timestamp | 2024年4月21日 17:27:42 |
DeviceId | host.id | 049958ba0defc576a9b1f7f1869ea0xxxxxxxxxx |
DeviceName | host.name | macbook-pro-2 |
ActionType | event.action | AntivirusDetection |
FileName | process.name | eicar.com |
FolderPath | process.executable | \Users\hibino\Downloads |
SHA1 | process.hash.sha1 | 9462312aa99c1a7876edd72699c776a955c24141 |
SHA256 | - | Null |
MD5 | process.hash.md5 | 98a12543aff7b2a99aa43c9856bcc10f |
FileSize | - | Null |
AccountDomain | - | Null |
AccountName | - | Null |
AccountSid | - | Null |
RemoteUrl | - | Null |
RemoteDeviceName | - | Null |
ProcessId | - | Null |
ProcessCommandLine | - | Null |
ProcessCreationTime | - | Null |
ProcessTokenElevation | - | Null |
LogonId | - | Null |
RegistryKey | - | Null |
RegistryValueName | - | Null |
RegistryValueData | - | Null |
RemoteIP | - | Null |
RemotePort | - | Null |
LocalIP | - | Null |
LocalPort | - | Null |
FileOriginUrl | - | Null |
FileOriginIP | - | Null |
InitiatingProcessSHA1 | process.parent.hash.sha1 | 9952aa17972afd3088999ca8fe3283ec6a92c899 |
InitiatingProcessSHA256 | process.parent.hash.sha256 | 12345555555555ccc982a5e49063cde0370f5554a25cc66aadccecea98f7b5aa |
InitiatingProcessMD5 | process.parent.hash.md5 | 98ea6d6123fecd2677666eb8678a7b99 |
InitiatingProcessFileName | process.parent.name | Google Chrome |
InitiatingProcessFileSize | process.parent.pe.sections.physical_size | 502704 |
InitiatingProcessFolderPath | process.parent.executable | /Applications/Google Chrome.app/Contents/MacOS/ |
InitiatingProcessId | process.parent.pid | 442 |
InitiatingProcessCommandLine | process.parent.command_line | "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" |
InitiatingProcessCreationTime | m365_defender.event.initiating_process.creation_time | 2024年4月17日 13:30:44 |
InitiatingProcessAccountDomain | m365_defender.event.initiating_process.account_domain | macbook-pro-2 |
InitiatingProcessAccountName | m365_defender.event.initiating_process.account_name | h_hibino |
InitiatingProcessAccountSid | m365_defender.event.initiating_process.account_sid | S-1-2-99-1234566789-1122334411-5511997705-1906 |
InitiatingProcessAccountUpn | - | Null |
InitiatingProcessAccountObjectId | - | Null |
InitiatingProcessVersionInfoCompanyName | - | Null |
InitiatingProcessVersionInfoProductName | - | Null |
InitiatingProcessVersionInfoProductVersion | - | Null |
InitiatingProcessVersionInfoInternalFileName | - | Null |
InitiatingProcessVersionInfoOriginalFileName | - | Null |
InitiatingProcessVersionInfoFileDescription | - | Null |
InitiatingProcessParentId | process.parent.group_leader.pid | 1 |
InitiatingProcessParentFileName | process.parent.group_leader.name | launchd |
InitiatingProcessParentCreationTime | process.parent.group_leader.start | 1970年1月1日 19:49:32 |
InitiatingProcessLogonId | m365_defender.event.initiating_process.logon_id | 0 |
ReportId | m365_defender.event.report_id | 39369 |
AppGuardContainerId | - | Null |
AdditionalFields | m365_defender.event.additional_fields | {"InitiatingProcess":{}, <以下省略> |
見るべきフィールドのポイント
Kibana の [Discover] 画面を開き、Data views で [logs-*]を指定します。
Discover 画面
デバイスログを検索する場合、event.kind
フィールドで event
を指定します。
(alert
は検知に関するアラートログになります)
event.kind の内訳
スキーマ名で検索する場合、m365_defender.event.category
フィールドで検索します。
m365_defender.event.category の内訳
ホスト名が記録されているフィールドはいくつかあります。
操作している端末のホスト名を検索する場合、host.name
フィールドで検索すれば大丈夫です。
操作しているユーザー名を検索する場合、イベントに応じてフィールド名が異なります。
・user.name
・m365_defender.event.initiating_process.account_name
・m365_defender.event.active_users
下記は event.category
フィールドの値 の内訳になります。
event.category の内訳
file
の場合、file.name
フィールドに操作したファイル名が記録されます。
network
の場合、destination.ip
と source.ip
のフィールドに IP アドレスが記録されます。
まとめ
さて、いかがでしたでしょうか?
1 本のブログにしてはかなりのボリュームになってしまいましたが
途中に良い切れ目がなかったため、結果的にボリュームたっぷりになってしまいました。
本当は Filebeat azure eventhub input についても記載する予定でした。
しかし、それだと流石にキツいと思い直し、次回の投稿ネタに回すことにしました。
現時点において、EDR 製品は下記の 2 強だと考えています。
(M365 を利用している場合の選択肢は、ほぼ Defender for Endpoint となると思います)
・Microsoft 社 Defender for Endpoint
・CrowdStrike 社 Falcon シリーズ
Elastic Stack を使って高度なダッシュボードを作成し、デバイスの不審な挙動をチェックする習慣をつけることは益々重要になるでしょう。この機会にぜひ、試してみましょう!
Discussion