これは Microsoft Security Advent Calendar 2024 カレンダーの19日目の記事です。昨日の投稿は@Eurekaberryさんでした。
はじめに
Sentinelを使った攻撃検知（分析ルール）クエリを作っていく内容です。といっても、WindowsEventLogだけを利用していきます。
Microsoft Defender for EndpointやMicrosoft Defender for Identityに任せればいいと思うのですが、今回は敢えて生のEventlogを扱っていく記事です（誰得）。いにしえの記事となると思います。
必要なEventlogの有効化
どんなEventlogを見ていくかですが、デフォルトで有効になっていないログがいくつかあります。
どのログを有効化していくかについては以下が参考になります。
SentinelにEventlogを取り込む
まずは、Eventlogを取り込むための設定についてです。
Eventlogの取り込みは、Azure Monitor Agentで取り込むことが出来るのでこいつを入れる必要があります。オンプレサーバのログを取り込みたい場合についてはAzure Arc経由でAzure Monitor Agentを入れることになります。
基本的にAzure Monitor Agentはデータ収集ルール (DCR)を設定した際に自動でインストールされるので、実質的にはオンプレサーバをArcに登録し、DCRを設定するだけで良いです。
Arcリソース登録は以下の「マシンの追加」から遷移して出来ます。
Arcにオンプレサーバを登録した後はDCRを設定します。設定の前にログを取り込むLogAnalyticsのワークスペース、Sentinelを作成しておきましょう。
また、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... | <DataItem Type="System.XmlData" time=""... | 4672 | Special privileges assigned ... | 12548 | N/A |
詳しくは以下をご覧下さい。
SecurityEvent
上記のEventData列がParseされて出てくるので、項目がとても多くここでは省略します。基本的にはEventlogのxmlの項目がそのままParseされて確認出来るので扱いやすいです。詳しくは以下をご覧下さい。
Sentinelで分析ルールのクエリを書く
これらのテーブルを利用して分析ルールのクエリを書いていきます。
攻撃については一部のみを扱っていきます。
Pass the Hash
攻撃者がユーザのパスワードのNTLMハッシュを利用して認証する攻撃です。メモリ内からパスワードのハッシュを抜き取ったりすることで、平文パスワードを知らなくても認証を突破することが出来ます。
Mimikatzとかが代表的な攻撃ツールです。
これに関してはEventlogのEventID 4624, LogonType 9などを見に行けば良いです。
詳しくは以下が参考になります。
SecurityEventが扱いやすいので、こちらを利用します。
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を見に行けば良いです。
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の監査ポリシーを有効化しておきましょう。
以下が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 |
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周りにある程度任せてしまうのがいいかとは思います。）