SentinelでWindowsEventLogを追う

:::note info
これは [Microsoft Security Advent Calendar 2024](https://qiita.com/advent-calendar/2024/microsoft-security) カレンダーの19日目の記事です。昨日の投稿は@Eurekaberryさんでした。
:::

# はじめに
Sentinelを使った攻撃検知（分析ルール）クエリを作っていく内容です。といっても、WindowsEventLogだけを利用していきます。
[Microsoft Defender for Endpoint](https://learn.microsoft.com/ja-jp/defender-endpoint/microsoft-defender-endpoint)や[Microsoft Defender for Identity](https://learn.microsoft.com/ja-jp/defender-for-identity/what-is)に任せればいいと思うのですが、今回は敢えて生のEventlogを扱っていく記事です（誰得）。いにしえの記事となると思います。

# 必要なEventlogの有効化

どんなEventlogを見ていくかですが、デフォルトで有効になっていないログがいくつかあります。
どのログを有効化していくかについては以下が参考になります。

https://github.com/Yamato-Security/EnableWindowsLogSettings

# SentinelにEventlogを取り込む
まずは、Eventlogを取り込むための設定についてです。
Eventlogの取り込みは、Azure Monitor Agentで取り込むことが出来るのでこいつを入れる必要があります。オンプレサーバのログを取り込みたい場合についてはAzure Arc経由でAzure Monitor Agentを入れることになります。
基本的にAzure Monitor Agentはデータ収集ルール (DCR)を設定した際に自動でインストールされるので、実質的にはオンプレサーバをArcに登録し、DCRを設定するだけで良いです。

https://learn.microsoft.com/ja-jp/azure/azure-arc/servers/concept-log-analytics-extension-deployment

Arcリソース登録は以下の「マシンの追加」から遷移して出来ます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2036848/6b4fb6b5-a38f-7222-2561-307eb5a256a3.png)

Arcにオンプレサーバを登録した後はDCRを設定します。設定の前にログを取り込むLogAnalyticsのワークスペース、Sentinelを作成しておきましょう。

https://learn.microsoft.com/ja-jp/azure/azure-monitor/agents/data-collection-windows-events

また、Sentinelのコネクタに`Windows Security Events via AMA`があるので、これ経由でEventlogを取り込むことも出来ます。
自身でDCRを設定した際はSentinelのテーブルで`Event`という名前で取り込まれますが、`Windows Security Events via AMA`を使った場合は`SecurityEvent`という名前でEventlogのセキュリティイベントだけ取り込まれます。

ここらの設定に関しては色々と他の記事が出てくると思うのでこの辺にしておきます。

# Eventlogのテーブル
上記のテーブルがどんな感じかを書いていきます。

## Event
一例です。（めっちゃ見にくい）
|TimeGenerated|Source|EventLog|Computer|EventLevel|EventLevelName|ParameterXml|EventData|EventID|RenderedDescription|EventCategory|UserName|
|---|---|---|---|---|---|---|---|---|---|---|---|
|2024-12-19T00:00:00Z|Microsoft-Windows-Security-Auditing|Security|DESKTOP-XXXX|0|Information|\<Param>S-1-5-18</Param>...|\<DataItem Type="System.XmlData" time=""...|4672|Special privileges assigned ...|12548|N/A|

詳しくは以下をご覧下さい。

https://learn.microsoft.com/ja-jp/azure/azure-monitor/reference/tables/event

## SecurityEvent
上記の`EventData`列がParseされて出てくるので、項目がとても多くここでは省略します。基本的にはEventlogのxmlの項目がそのままParseされて確認出来るので扱いやすいです。詳しくは以下をご覧下さい。

https://learn.microsoft.com/ja-jp/azure/azure-monitor/reference/tables/securityevent

# Sentinelで分析ルールのクエリを書く
これらのテーブルを利用して分析ルールのクエリを書いていきます。
攻撃については一部のみを扱っていきます。

## Pass the Hash
攻撃者がユーザのパスワードのNTLMハッシュを利用して認証する攻撃です。メモリ内からパスワードのハッシュを抜き取ったりすることで、平文パスワードを知らなくても認証を突破することが出来ます。
Mimikatzとかが代表的な攻撃ツールです。

これに関してはEventlogの`EventID 4624`, `LogonType 9`などを見に行けば良いです。
詳しくは以下が参考になります。

https://blog.netwrix.com/2021/11/30/how-to-detect-pass-the-hash-attacks/

SecurityEventが扱いやすいので、こちらを利用します。
```:kql
SecurityEvent
| where EventID == 4624 and LogonType == 9 and LogonProcessName == "seclogo"
| project TimeGenerated, Computer, EventSourceName, EventID, Activity, LogonType, LogonProcessName, SubjectUserName, TargetUserName, TargetDomainName, ProcessName, IpAddress
```
認証先のマシンのEventlogではなく、認証元のマシンのEventlogを見ることで検知出来ます。
また、Sysmonをインストールしておけば`lsass.exe`への不審なアクセスから判断できることもあります。EDRぇ...

## AS-REP Roasting
AD環境への攻撃です。
攻撃者が何らかの方法でUser名のリストを手に入れた際などに試したりします。そのUserがKerberos事前認証を必要としない場合は、認証なしにTGTを取得できるので、そのUserのパスワードをオフラインで解読し、取得する攻撃です。
Rubeusとかが代表的な攻撃ツールです。

これらを検知するためには、`EventID 4768`を見に行けば良いです。

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768

```:kql
SecurityEvent
| where EventID == 4768
| parse EventData with * 'PreAuthType">' PreAuthType '</Data>' * 
| where PreAuthType == "0"
| project TimeGenerated, Computer, EventID, Activity, PreAuthType, TargetUserName, TargetDomainName, IpAddress
```
`PreAuthType`は事前認証なしでAS-REQを送信する場合に`0`となります。ただ`SecurityEvent`にはデフォルトでParseされないので、`parse`を使って取り出しています。

といっても攻撃者目線だとADとの疎通が通ればLDAP経由で情報収集をし、AS-REP Roastingが通りそうなUserを割り出してから攻撃するとも思うので、LDAP列挙の検知ルールを整備するのもいいと思います。
（ここまでしなくてもDefender for Identity使えばぇ...）

## DCSync
攻撃者がADからパスワードハッシュを取得する攻撃です。ドメインに対して`DS Replication Get Changes`、`Replicating Directory Changes All`、`Replicating Directory Changes In Filtered Set`などの権限があると実行出来ます。Mimikatzとかで実行できます。
これによってADの管理者権限を取られると一気にAD掌握に繋がり危険な兆候です。

これらを検知するには`EventID 4662`と`Replicating`系の`Properties`をKQLで引っかけます。
※`EventID 4662`を見るために`Directory Service Access`の監査ポリシーを有効化しておきましょう。

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4662

以下が`Properties`とアクセス権のCNの対応表です。
|CN|Properties|
|---|---|
|DS-Replication-Get-Changes|1131f6aa-9c07-11d1-f79f-00c04fc2dcd2|
|DS-Replication-Get-Changes-All|1131f6ad-9c07-11d1-f79f-00c04fc2dcd2|
|DS-Replication-Get-Changes-In-Filtered-Set|89e95b76-444d-4c62-991a-0facbeda640c|

```:kql
SecurityEvent
| where EventID == 4662 and AccountType != "Machine" and ObjectServer == "DS"
| where Properties has "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" or Properties has "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" or Properties has "89e95b76-444d-4c62-991a-0facbeda640c"
| project TimeGenerated, Computer, EventID, Activity, Properties, SubjectUserName, SubjectDomainName
```
このアラートを起点に`SubjectUserName`を深ぼって行く形かなと思います。

# おわりに
Eventlogを使った攻撃検知のクエリを書いてみました。拡張してカスタムしていただければと思います。
振る舞い検知が流行ってる中でゴリゴリEventlogをに対してSentinelを使って見ていくのも面白いかもしれませんね？
（Azure Monitor Agentさんは軽いのでこういうのもありかもしれませんが、リソース制約がないならDefender周りにある程度任せてしまうのがいいかとは思います。）