皆さんこんにちは。国井です。
Microsoft Defender for Endpoint (MDE) ってセキュリティ対策を行う上で何が便利なの？という話を聞きます。
EDRとしての適切なインシデント対応だったり、インシデント対応自体が簡単にできますよ、という話だったりはあちこちで聞く話だと思いますので、今日はそこから視点をずらして、タイムラインという機能を利用することによる便利さを紹介します。
タイムラインというのはMDEの管理対象となるデバイスで、どのようなファイルアクセスやネットワークアクセスなどがあったかを追跡できる機能で、これを利用することによって、不正アクセスの履歴を追跡できたり、またはトラブルシューティングの目的で使ったりできるのです。
トラブルシューティング？って思うかもしれないですが、案外便利なんですよ。
私たちが普段ネットワークがらみのトラブルシューティングをしましょうと言ったらWireSharkを使う方法やFiddlerを使う方法などを思い浮かべると思います。しかし、どちらのツールもローカルにインストールしなければならないという欠点があります。そこでもしMDEが皆さんの会社で使われているのであれば、これを使って履歴を追跡していけば、なぜアプリが動かないのか？とかなぜネットワークアクセスに失敗するのか？とか、そうした情報をクライアント上での操作を行うことなくトラブルシューティングできるというメリットがあるのです。
本当にトラブルシューティングで使うかどうかは別として、
今回はPowerShellからMicrosoft Graphを使ってMDEのログを収集するというスクリプトを実行した場合、
どのようなファイルアクセスがあるか？
どのようなネットワークアクセスがあるか？
を追跡しながら、MDEのタイムラインの見かたをチェックしてみたいと思います。
前提条件
ここではPowerShellからMicrosoft Graphを利用してMDEのアラートログを参照するスクリプトを実行し、その実行の様子をMDEから参照してみます。
前提条件～MDEの契約とオンボーディング
MDEはMicrosoft 365 E5または単体ライセンスで購入できます。無料試用版もありますので、お持ちでない方は無料試用版でスタートしましょう。
無料試用版をゲットしたらオンボーディングスクリプトをダウンロードし、管理対象となるデバイスにインストールしましょう。登録が完了すると、Microsoft 365 セキュリティ管理センター画面にデバイスが表示されます。
前提条件～アプリの登録
また、APIアクセスにはAzure ADで[アプリの登録]を利用してアプリを登録しておく必要がありますので、Azure AD管理センター画面で [Azure Active Directory]-[アプリの登録]から次のパラメーターでアプリを作成しました。
■作成時の設定
・名前：MDATP
・アカウントの種類：この組織ディレクトリのみに含まれるアカウント
・リダイレクトURI：なし
■作成後のアプリの登録の設定
・クライアントシークレットを作成し、値を保存
・APIのアクセス許可：APIの種類として[所属する組織で使用しているAPI]を選択し、アプリケーションの許可としてAlert.Read.Allを追加
APIのアクセス許可は設定が完了したら、管理者の同意を設定することもお忘れなく。
前提条件～スクリプトの準備
MS GraphでAPIアクセスする場合、アクセストークンを取得するまでのプロセスとアクセストークンを提示してAPI経由でデータを取得するプロセスに大きく分かれるので、この2つがわかりやすいようにスクリプトを分けてみました。
(‘テナントID’、’クライアントID(アプリケーションID)’、’クライアントシークレット’に記載されている情報は前の手順で作成したアプリの登録の中に情報があるので、それをコピーして使ってください)
■アクセストークンを取得するスクリプト (Get-Token.ps1)
$tenantId = ‘テナントID’
$appId = ‘クライアントID(アプリケーションID)’
$appSecret = ‘クライアントシークレット’
$resourceAppIdUri = ‘https://api.securitycenter.windows.com’
$oAuthUri = “https://login.windows.net/$TenantId/oauth2/token”
$authBody = [Ordered] @{
resource = “$resourceAppIdUri”
client_id = “$appId”
client_secret = “$appSecret”
grant_type = ‘client_credentials’
}
$authResponse = Invoke-RestMethod -Method Post -Uri $oAuthUri -Body $authBody `
-ErrorAction Stop
$token = $authResponse.access_token
Out-File -FilePath “./Latest-token.txt” -InputObject $token
return $token
■アクセストークンをもとにAPIアクセスするスクリプト (Get-Alerts.ps1)
$dateTime = (Get-Date).ToUniversalTime().AddHours(-24).ToString(“o”)
$url = “https://api.securitycenter.windows.com/api/alerts?`
$filter=alertCreationTime ge $dateTime”
$headers = @{
‘Content-Type’ = ‘application/json’
Accept = ‘application/json’
Authorization = “Bearer $token”
}
$response = Invoke-WebRequest -Method Get -Uri $url -Headers $headers ‘
-ErrorAction Stop
($response | ConvertFrom-Json).value | ConvertTo-Json
なお、この2つのスクリプトは必ず同じWindows PowerShellコンソール画面の中で実行してください。なぜなら最初のスクリプトを実行した結果、$token変数にアクセストークンが入っており、それを使って2つめのスクリプトを実行するからです。
準備ができたら、それぞれのスクリプトを実行してみましょう。
MDEで結果を確認～概要編
MDEのタイムラインを参照するときはMicrosoft 365 Defender画面またはMicrosoft Defender Security Center 画面を使います。
ただ、Microsoft 365 Defenderは画面が見にくいので、ここではMicrosoft Defender Security Center 画面(https://securitycenter.windows.com)を使います。
Microsoft Defender Security Center 画面から[Device inventory] をクリックして該当のデバイスを開くとTimelineタブをクリックして履歴を参照できます。
この中からPowerShellの実行結果を追跡するのであれば、まず検索窓にpowershell_ise.exeと入れてみましょう。
するとPowerShellに関連する実行結果だけが表示されます。
MDEで結果を確認～ファイルイベント編
タイムラインの検索結果から[Filters]をクリックして、さらにフィルターを設定しましょう。いろいろありますけど、まずはFile Eventsを選択してみます。
こちらでは変更したpowershell_ise.exeによって作成したファイルや変更したファイルなど、ファイル単位でのイベントが表示されます。
今回はスクリプトを実行して作成するファイルはありませんので、テンポラリのファイルだけが作られていることがわかります。
MDEで結果を確認～プロセスイベント編
続いてフィルターでProcess eventsを選択してみましょう。
こちらはWindows上で実行したプログラム(プロセス)が一覧で出ていることがわかります。
PowerShellでアクセストークンを取得した様子やpowershell_ise.exeが実行された様子などがわかります。
powershell_ise.exeをクリックすると、その詳細が確認でき、
Get-Token.ps1が実行されたことがわかります。
MDEで結果を確認～ネットワークイベント編
今度は[Filters]をクリックして、Network eventsだけを選択して、powershell_ise.exeによるネットワークイベントだけを表示します。
同じログが2回ずつ出ているけど、PowerShellからAPIアクセスすると次の2つのアクセスがあることがわかります。
https://login.windows.net
https://api.securitycenter.windows.com
それぞれのタイムラインをクリックしてみます。
まずhttps://login.windows.netにアクセスしたログ。
こちらはGet-Token.ps1ファイルからアクセスしたと表示されていることがわかります。
続いてhttps://api.securitycenter.windows.comにアクセスしたログ。
こちらもGet-Token.ps1ファイルからアクセスしたと表示されていることがわかります。
えっ？？https://api.securitycenter.windows.com ってMDEのAPIアクセス時のエンドポイントなんじゃないの？
なんでGet-Token.ps1のアクセス時にこのエンドポイントにアクセスしているの？と思った方、そうですよね！
そこで今度はGet-Alerts.ps1というキーワードで検索してログを出してみました。
この中からpowershell_ise.exe created file Get-Alerts.ps1ファイルを開いてみます。
すると、ご覧のようにGet-Alerts.ps1ファイルはGet-Token.ps1ファイルを実行したpowershell_ise.exeの配下に表示されていることがわかります。
つまり、Get-Alerts.ps1によるネットワークアクセスはGet-Token.ps1を実行したpowershell_ise.exeの配下からのアクセスなので、
画面上はGet-Token.ps1からネットワークアクセスがあったと見えてしまうのです。
どうしてこういうことが起きるかというと、こういう風にひとつの画面の中で2つのタブを開いてスクリプトを実行しているからです。
つまりMDEでネットワークアクセスの追跡を行うときは先に実行したプロセスの子プロセスとしてどんなプロセスが動いていたか？を確認したうえで追跡を行わないと間違った判断を下す可能性があるので注意してください。
MDEで結果を確認～そのほかのイベント編
最後にフィルターでOther eventsを選択してみます。
すると実行したPowerShellコマンドレットのひとつひとつが表示されていることがわかります。これを使えば、単純にPowerShellスクリプトを実行した！というだけでなく、どんなコマンドレットが実行されたかまでが確認できます。
まとめ
今回はPowerShellスクリプトでMicrosoft Graph経由でMDEのログを取得する、という操作を例に出力されたタイムラインを参照してみました。タイムラインはただ単純に眺めているだけではログの羅列にしか見えませんが、Filterを駆使することによって様々な情報をあぶりだすことができます。
そのほかのケースでもタイムラインを使った調査をやってみたいという方、いらしたらMicrosoft 365インシデント対応コースというトレーニングコースを開催していますので、そちらも参加してみていただければと思います。
