はじめに
こんにちは。研究開発部の待井と申します。
最近Google Domainsで一般向けに取得可能となったTLD(.zip
など)についてフィッシング攻撃などに悪用されるリスクがあることで話題になっています。*1 *2
www.bleepingcomputer.com
積極的な対処例としては悪用の可能性があるドメインへのアクセスブロックや監査は有効な手法ですが、正規のサービスや問題のないサイトもあるため、一律でのブロックは難しい場合もあります。
またリモートワーカーが増えた環境下で、DNSやProxyによる一律での対処が難しい場合もあるかと思います。
そこで弊社ではMicrosoft 365 Defenderにて利用可能な「Advanced Hunting」を活用し、デバイス単位でのアクセス検知を試験的に実装しました。Microsoft環境(MDE)を利用している方々向けの参考として紹介します。
前提
Advanced Huntingを利用し、特定ドメインへのアクセス検知を行うには以下の前提を満たす必要があります。
Advanced Huntingとは
Microsoftが提供するセキュリティに関するサービスで蓄積されるログおよびデータをクエリベース(KQL: Kusto Query Language)で検索・抽出することで潜在的な脅威の発見や発生している事象の調査など様々なケースに利用できるツールであり、Webインターフェースで利用可能なものとなっています。 learn.microsoft.com
Advanced Huntingでは以下のサービスから得られるデータセットを利用可能です。
- Microsoft Defender for Endpoint
- Microsoft Defender for Office365
- Microsoft Defender for Cloud Apps
- Microsoft Defender for Identity
上記データセットから得られるデータはイベント情報や各種エンティティ情報としてテーブルに格納され、KQLによりテーブル指定、各種条件等を指定することで様々なデータの抽出や結合が可能です。
主なテーブルと格納されている情報は以下の通りとなります。*5
- AlertInfo
- 各種セキュリティに関わるサービスにおけるアラート情報
- DeviceInfo
- デバイスに関する各種情報
- DeviceNetworkEvents
- デバイスにおけるネットワーク接続に関する情報
- EmailEvents
- メールの配信やブロックなどのイベント情報
- IdentityLogonEvents
- ADやMicrosoftサービスに対する認証イベント情報
コミュニティクエリ
Advanced Huntingではあらかじめコミュニティで作成された様々な用途を持ったクエリが利用可能となっており、それを利用するだけでも簡単な調査や攻撃の痕跡などの発見に役立てることができます。
クエリ例: 複数アカウントを用いてログイン試行を複数回行い、最終的にログインに成功したIPアドレスを抽出するクエリ
上記のクエリ例のように「Advanced Hunting」はどのテーブルから情報をどのような条件で抽出し、どのような項目を表示したり、結合したりするかをクエリで自由に制御することができるため、それぞれの目的に合わせて脅威やイベントの発見、エンティティ情報の抽出に役立つツールとなっています。
検出ルール
「Advanced Hunting」では作成したクエリを基に検出ルールを作成することが出来ます。
検出ルールは作成したクエリを定期的に実行し、条件に合致するデータが検出された場合にアラートの発出やクエリにより発見されたエンティティ(デバイスやユーザ、ファイルなど)に対しどのような対処(デバイスの隔離、ファイルの検疫、ユーザを無効化等)を自動的に行うかについても設定が可能となっています。
実装内容
今回は「Advanced Hunting」で利用可能なクエリおよび検出ルールを用いて組織内のデバイスでTLDが.zip
であるサイトにアクセスした端末およびユーザ情報の検出およびアラートの発出を実装してみます。
クエリの作成
特定TLDに対するアクセス検知を行うため、デバイスにおけるネットワークイベントのログにおいて接続先ドメインのTLDが.zip
となっているログを抽出するクエリを作成する方法について記述します。
- Microsoft 365 Defenderポータルへアクセス
- ポータルサイトのメニューから「追及」 -> 「高度な追及」をクリック
- クエリの作成画面を開いたら画像のように「新規作成」 -> 「エディターでクエリを実行する」をクリック
- エディター画面にて以下のコードを記述
// 抽出対象のテーブルを指定 DeviceNetworkEvents // 抽出条件の指定 | where Timestamp > ago(1h) | where RemoteUrl matches regex "https?://[\\w!?+\\-_~=;.,*&@#$%()'[\\]]+\\.zip" // 表示するデータ項目の指定 | project Timestamp, DeviceId, DeviceName, ActionType, InitiatingProcessFileName, RemoteUrl, RemoteIP, ReportId
記述後、「クエリを実行」をクリックすることで画像のように現時点で該当するログが存在するかを確認することが出来ます。*6
クエリの詳細解説
上記コードの内容だけではどんな条件などが指定されているか分かりづらいため、少し掘り下げて説明します。
DeviceNetworkEvents
クエリの先頭でどのテーブルから情報を抽出するかを指定する必要があるため、今回はデバイスのネットワークイベントを保持しているDeviceNetworkEvents
を指定しています。
DeviceNetworkEvents
テーブルで保持されるデータ例は以下の通りとなります。
- Timestamp: イベントが記録された日付と時刻
- DeviceId: コンピューターの一意識別子
- DeviceName: コンピューターの完全修飾ドメイン名 (FQDN)
- ActionType: イベントをトリガーしたアクティビティの種類
- InitiatingProcessFileName: イベントを開始したプロセスの名前
- RemoteUrl: 接続したURL または完全修飾ドメイン名 (FQDN)
- RemoteIP: 接続したIP アドレス
- ReportId: イベントの一意識別子
上記以外にも利用できるデータは多数あるため、詳しく知りたい方はMicrosoft公式ドキュメントを参照ください。
| where Timestamp > ago(1h) | where RemoteUrl matches regex "https?://[\\w!?+\\-_~=;.,*&@#$%()'[\\]]+\\.zip"
テーブルを指定後、パイプ( | )およびwhere句を記述し、その後ろにDeviceNetworkEvents
テーブルで保持されるデータ項目と満たすべき条件を指定することでテーブルから抽出するデータを絞り込む。
今回の記述したクエリでは以下の条件を満たすログが抽出されます。
- ログのタイムスタンプが直近1時間以内
- 接続先のURLが上記の正規表現にマッチ(TLDが
.zip
となっているもの)
| project Timestamp, DeviceId, DeviceName, ActionType, InitiatingProcessFileName, RemoteUrl, RemoteIP, ReportId
project句を用いることで指定したデータカラムのみを結果として返すように指定することが可能となります。
今回はタイムスタンプや検知されたデバイスIDおよびデバイス名、接続を行ったプロセス、接続先URLおよびIPアドレスとレポートIDを結果として返すように指定しています。*7
検出ルールの作成
作成したクエリに基づいて該当するログが検出された際に実行する処理をまとめた「検出ルール」の作成する方法について記述します。
- クエリの作成後、画面右上にある「検出ルールを作成」をクリック
- 検出ルールの作成画面が表示されるため、アラートとして上げる内容を設定
- 検出名: 検出するルール名
- 頻度: 検出ルールによるクエリ実行をどの頻度で実行するかを指定
- 一定時間毎(1,3,12,24時間)にクエリを実行し、該当するログがある場合はアラートを発出するように設定可能(リアルタイム検出ではなく一定時間毎の検出となる)
- 連続(NRT)については一定の条件を満たす場合*8に利用可能であり、ほぼリアルタイムでクエリの実行およびアラートの発出が可能となる(今回はこちらを指定)
- アラートのタイトル: アラートを発出する際のタイトルを指定
- 重大度: アラートの重大度を指定(Microsoft 365 Defender環境で発出されるその他アラートと同一の尺度を用いる)
- カテゴリ: アラートの分類を指定(Microsoft 365 Defender環境で発出されるその他アラートと同一の尺度を用いる)
- 説明: このアラートの詳細説明を記述
- クエリにより検出されたエンティティ(今回の場合はデバイス)を特定するためのカラムを指定します。画像に記述されているようにMicrosoft 365 Defender環境でインシデントやその他アクションを実行する際に必要な情報として使用されます。
- クエリにより検出されたエンティティに対する操作を設定することが可能で、デバイスの分離やAVによるスキャンなどを自動実行するような設定が可能です。(今回はアクセス検知だけを目的としているため、操作については特に指定しません)
- 最後にこれまでに設定した内容に問題がないかを確認し、「送信」をクリックすることで作成完了となります。
作成した検出ルールについてはMicrosoft 365 Defenderポータルの「追及」 -> 「カスタム検出ルール」にアクセスすることで確認可能です。
テスト
今回はテストとして.zip
ドメインが利用可能となったことについて問題提起を行っているサイトに対して実際にアクセスを行い、設定した内容に従ってアラートが上がるかを確認してみます。
ブラウザでアクセス先URL: https[:]//financialstatement[.]zip/
にアクセスを行います。
アクセス後、「Advanced Hunting」にて作成したクエリの実行を行い、以下のログが発生および抽出できることを確認できました。
Micorosft 365 Defenderポータルに戻り、「インシデントとアラート」 -> 「アラート」にアクセスし、アラートが上がっていることについても同様に確認できました。
上記より意図した通りにクエリが動作し、検出ルールによりアラートが上がっていることを確認できたかと思います。
おわりに
今回はAdvanced Huntingを用いたデバイス単位での特定TLDへのアクセス検知を目的として実装を行いましたが、ほんの一部の機能を利用したにすぎないため、他にも様々な利用方法があるかと思います。
コミュニティクエリとして提供されている通り、攻撃痕跡の検出やラテラルムーブメントの検出など幅広くセキュリティに関わるイベントの検出が行えるため、特定のイベントをトリガーとして検出ルールを作成し、即時NW隔離の実行やデバイスの情報収集などを実行することで被害の拡大を防ぐなど幅広い活用方法が考えられます。そのため、今回紹介した一例が今後Advanced Huntingを活用する予定がある方に向けて少しでも参考になれば幸いです。
*1:通常のフィッシング手法に加え、.zipなどの拡張子を持つファイル名をURLに自動で変換するアプリケーションやサービスが存在するため、ファイルを共有しているように見えるリンクをクリックした際にTLDが.zipとなっているサイトへ誘導される懸念点があります
*2:実際に既に悪用が確認されているドメインも存在しています
*3:機能を有効化するためには特定のロールが必要になります
*4:デバイス単位で特定ドメインへのアクセス検知に必要なログを収集するため
*5:現時点では26種類のテーブルが存在する
*6:画像内ではコードの内容と少し異なり、過去7日間分のログを検索するように指定している
*7:後述する検出ルールでこのクエリを利用するためには「DeviceId」と「ReportId」をproject句で指定することが必須となる
*8:クエリが 1 つのテーブルのみを参照しており、特定のKQL演算子のみを利用している場合