36.イベントログ1: 4624(ログオン)から読み解く侵入の兆候
Windowsのセキュリティ監査において、最も記録件数が多く、かつ侵入検知の出発点となるのがイベントID 4624(アカウントが正常にログオンした)です。
一見すると「認証に成功した正常な記録」に過ぎないログですが、内部に含まれるパラメータを読み解くことで、Pass-the-Hash攻撃、不正なリモートデスクトップ接続、侵害されたサービスアカウントの横展開(Lateral Movement)といった重大なインシデントの兆候を炙り出すことができます。
この記事では、イベントID 4624の内部構造、侵入分析で最重要となる「ログオンタイプ」の判別、および不審なログを即座に抽出するためのクエリを解説します。
前提条件
- ログオン/ログオフカテゴリの監査(4624/4625を含む)は、Windowsの既定の監査ポリシーで有効になっています。ただし、厳格に要塞化されたゴールデンイメージやカスタムセキュリティベースラインでは無効化されている場合があるため、
auditpol /get /subcategory:"ログオン"で実際の設定状態を確認することを推奨します。 - 4624は環境によって非常に大量に記録されるログです。すべてを長期保存・SIEM転送する前に、保持期間とストレージ/取り込みコストを見積もってください。
Linuxエンジニア向けの例え
4624の分析は、Linuxで/var/log/auth.log(またはjournalctl経由のsshdログ)をlastコマンドやlastbと組み合わせて解析する作業に近いものです。
-
ログオンタイプの判別 ≒ コンソールからの直接ログイン、
ssh経由のリモートログイン、su/sudoによるユーザー切り替えを区別する作業に相当します。Type 2(対話型)はコンソールログイン、Type 3(ネットワーク)やType 10(RDP)はリモートアクセスに近い性質を持ちます。 - Pass-the-Hash攻撃の検知 ≒ 攻撃者が盗んだSSH秘密鍵を使って別サーバーに次々とログインしていく手口(横展開)をauth.logの接続元ホスト・鍵のフィンガープリントから追跡するイメージです。
-
Type 9(NewCredentials)の検知 ≒
sudo -uやsuで一時的に別ユーザーの権限を借りる操作に近く、通常の業務フローでは滅多に発生しないため、発生自体が調査対象になります。
1. イベントID 4624の重要フィールド
4624のログには多くの情報が含まれますが、脅威分析で確認すべき項目は以下の5点に集約されます。
- ログオン タイプ (LogonType): どのような手段(対面、ネットワーク経由、サービス等)でログオンしたかを示す数値。
- アカウント名 (TargetUserName) / ドメイン (TargetDomainName): 認証されたユーザーアカウント。
-
ソース ネットワーク アドレス (IpAddress): ログオン元のIPアドレス(ローカルの場合は
-または127.0.0.1)。 - ログオン プロセス (LogonProcessName): 認証を処理したサブシステム(User32, Kerberos, NtLmSsp など)。
- 認証パッケージ (AuthenticationPackageName): Kerberos なのか、レガシーな NTLM なのか。
注意:
IpAddressフィールドは万能ではありません。ローカルで開始されたログオンやWindows内部の一部の処理経路では、この値が127.0.0.1や空欄のまま記録されることがあります(Microsoft自身も「すべてのコードパスがIPアドレスの記録に対応しているわけではない」と説明しています)。RD Gateway経由や多段の踏み台構成でRDP接続元を正確に追いたい場合は、4624単体に頼らず、Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational(EID 1149)やMicrosoft-Windows-TerminalServices-LocalSessionManager/Operational(EID 21/25)と突き合わせて裏取りすることを推奨します。
2. ログオンタイプ(LogonType)の徹底解剖
4624ログを分析する上で最も重要な指標がログオンタイプです。この数値を把握していないと、正常なOSのバックグラウンド処理と外部からの不正侵入を区別できません。
| ログオンタイプ | 名称 | 概要 | 攻撃分析での着目点 |
|---|---|---|---|
| 2 | Interactive | PCのコンソール(キーボード・画面)から直接ログオン。 | 深夜や休日のログオン、一般ユーザー端末に管理者が直ログインしているケース。 |
| 3 | Network | ネットワーク経由で共有フォルダやIIS等にアクセス。 | 横展開の主戦場。NTLM認証でのType 3大量発生はPass-the-Hashの兆候。 |
| 4 | Batch | タスクスケジューラ等のバッチ処理による実行。 | 攻撃者がタスクを作成して永続化(Persistence)を図った可能性。 |
| 5 | Service | Windowsサービス起動時にサービスアカウントでログオン。 | 新規に不審なサービスが登録・起動されていないか。 |
| 7 | Unlock | 画面ロックの解除。 | 離席中の不正操作、物理アクセスインシデントの調査。 |
| 9 | NewCredentials |
runas /netonly による偽装資格情報の使用。 |
Mimikatz等で資格情報を切り替えて横展開する際の典型値。 |
| 10 | RemoteInteractive | RDP(リモートデスクトップ)経由の接続。 | 外部IPからの直接続、通常RDPを使用しない一般PCへのRDP接続。 |
3. 侵入・侵害を疑うべき「4つの危険パターン」
① 「Type 10 (RDP)」が不自然な送信元IPから発生
兆候: 社内ネットワーク外のIP、または普段リモート管理を行わない一般クライアントPC(例: 経理部PC)から、別のPCへType 10でログインしている。
想定される攻撃: 踏み台端末を経由した内部ネットワークの探索、または外部公開されたRDPポート経由の直接侵入。
② 「Type 3 (Network)」かつ「NTLM認証」による横展開
兆候: ドメイン環境で通常使われるKerberosではなく、AuthenticationPackageName = NTLM かつ LogonProcessName = NtLmSsp でType 3ログオンが連続して発生。
想定される攻撃: Pass-the-Hash攻撃。攻撃者がメモリから窃取したNTLMハッシュを使い、共有フォルダ(C$やADMIN$)経由でマルウェアを送り込んでいる可能性があります。
③ 「Type 9 (NewCredentials)」の検知
兆候: 一般的な業務では滅多に発生しないType 9が、一般ユーザーのセッション内で記録される。
想定される攻撃: 攻撃者がrunas /netonlyコマンドを使用し、ローカル端末上では現在のユーザーを保ちながら、ネットワーク通信時のみ窃取した別アカウント(ドメイン管理者など)に偽装して通信を試みている状態。
④ サービスアカウントの「Type 2」ログオン
兆候: SQL Serverやバックアップ処理用のサービスアカウント(通常はType 5のみ)が、Type 2(対話型)やType 10(RDP)でログインしている。
想定される攻撃: サービスアカウントのパスワードが漏洩し、人間(攻撃者)がそのアカウントを使ってコンソールやRDPから直接侵入した状態。
4. PowerShellによる不審な4624ログの抽出
イベントビューアーのGUIで膨大なログを手動確認するのは非現実的です。PowerShellのGet-WinEventを使用し、セキュリティログからターゲットを絞り込んで抽出します。
RDPログオン(Type 10)の履歴と接続元IPを抽出
# 過去24時間以内のType 10 (RDP) ログオンを抽出
$StartTime = (Get-Date).AddDays(-1)
$Filter = @{
LogName = 'Security'
Id = 4624
StartTime = $StartTime
}
Get-WinEvent -FilterHashtable $Filter | ForEach-Object {
$xml = [xml]$_.ToXml()
$data = $xml.Event.EventData.Data
$logonType = ($data | Where-Object { $_.Name -eq 'LogonType' }).'#text'
if ($logonType -eq '10') {
[PSCustomObject]@{
TimeCreated = $_.TimeCreated
TargetUser = ($data | Where-Object { $_.Name -eq 'TargetUserName' }).'#text'
IpAddress = ($data | Where-Object { $_.Name -eq 'IpAddress' }).'#text'
Workstation = ($data | Where-Object { $_.Name -eq 'WorkstationName' }).'#text'
ProcessName = ($data | Where-Object { $_.Name -eq 'ProcessName' }).'#text'
}
}
} | Format-Table -AutoSize
NTLM経由のネットワークログオン(Type 3)を抽出
# Pass-the-Hash等の兆候となるNTLM Type 3ログを抽出
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 500 | ForEach-Object {
$xml = [xml]$_.ToXml()
$data = $xml.Event.EventData.Data
$type = ($data | Where-Object { $_.Name -eq 'LogonType' }).'#text'
$auth = ($data | Where-Object { $_.Name -eq 'AuthenticationPackageName' }).'#text'
if ($type -eq '3' -and $auth -eq 'NTLM') {
[PSCustomObject]@{
TimeCreated = $_.TimeCreated
User = ($data | Where-Object { $_.Name -eq 'TargetUserName' }).'#text'
SourceIP = ($data | Where-Object { $_.Name -eq 'IpAddress' }).'#text'
Package = $auth
}
}
} | Format-Table -AutoSize
まとめ
ログオン成功を示す「4624」は、平常時のログノイズに埋もれがちですが、侵害された正規アカウントによる不審な活動を見つけ出すための最重要センサーです。
- ログオンタイプを常に意識する: Type 3(ネットワーク)、Type 9(偽装)、Type 10(RDP)を特に注視する。
- アカウントの属性とログオン方法の不一致を見逃さない: サービスアカウントの対話ログオンや、一般ユーザーによる不審なRDP接続を警戒する。
- 認証パッケージを確認する: ドメイン環境で突如発生するNTLM Type 3はPass-the-Hashを疑う。
- IpAddressフィールドを過信しない: RDPの多段接続などでは値が欠落・不正確になり得るため、必要に応じてTerminalServices系のログと突き合わせる。
日常的なベースライン(通常時のログ傾向)を把握した上で、これらの逸脱を検知・アラート化する仕組みを整えましょう。次回は、ログオン失敗(4625)やアカウントログオン(4768/4776)など、4624と対で見るべきイベントを扱う予定です。
今すぐ実行すべき確認コマンド
# 1. ログオン監査サブカテゴリが有効になっているか確認
auditpol /get /subcategory:"ログオン"
# 2. 直近24時間の4624ログを、ログオンタイプ別に集計
$Events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-1)}
$Events | ForEach-Object {
([xml]$_.ToXml()).Event.EventData.Data | Where-Object { $_.Name -eq 'LogonType' } | Select-Object -ExpandProperty '#text'
} | Group-Object | Sort-Object Count -Descending | Format-Table Name, Count -AutoSize
# 3. Type 10 (RDP) ログオンの裏取り用に、TerminalServices側の接続ログも確認
Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -MaxEvents 20 |
Where-Object { $_.Id -eq 1149 } | Select-Object TimeCreated, Message