面接で数件のログを渡され、「何が起きましたか」と聞かれたら、まず根拠を示せる短い流れを説明しましょう。どのPCが記録したのか、どのアカウントが対象なのか、結果は何か、何がまだ分からないのか。この順番で読む力が役に立ちます。
第3回ではユーザー、権限、プロセス、サービスを観察しました。今回は操作の記録を読み、ログのタイムラインと1枚のトリアージメモを作ります。SOCやジュニアセキュリティアナリストの仕事で使う基礎です。
用意するもの： ブラウザー、テキストエディター、練習ログ。中心の演習はどのOSでもできます。任意のWindows演習は、自分のPCのSecurityログを読む権限がある場合に、イベントビューアーとWindows PowerShellを使います。目安は約3時間。SIEMのアカウントは不要です。
第4回のワークブックをダウンロードしてください。6枚の図は注釈付きの教材用イメージです。値は架空で、実事件の画面を撮影したものではありません。選択すると元のサイズで開けます。
1. 集計の前に1件を読む
ログは記録の集まりです。イベントは観測された内容の記録で、アラートはルールや検知による通知です。複数のイベントから1つのアラートが作られることもあります。どちらも単独で事件全体を説明するものではありません。
今回読むのは、プロバイダーMicrosoft-Windows-Security-AuditingのWindows Securityイベント2種類です。
| イベントID | 記録していること | それだけでは分からないこと |
|---|---|---|
| 4624 | アカウントのログオン成功。アクセス先のコンピューターにログオンセッションが作られた。 | 許可された操作か、安全な操作か。 |
| 4625 | アカウントのログオン失敗。試行が行われたコンピューターに記録される。 | 誰が試したのか、攻撃だったのか。 |
イベントIDはプロバイダーとチャネルと一緒に扱います。すべての製品で同じ番号が同じ意味になるわけではありません。イベントビューアーの「情報」はイベントのレベルであり、安全性の判定ではありません。監査の結果と各フィールドを読みます。
図1：イベントIDは種類、レコードIDは元のログ内の個別の記録を探す手がかりです。
ダウンロードはJSON Lines形式で、1行に1つのJSONオブジェクトを入れています。教材としてフィールド名を短く正規化しています。Windowsの生のXML、.evtx、SIEMのテーブルではありません。例えば次のような内容です。
{
"time_utc": "2026-10-20T09:01:20Z",
"provider": "Microsoft-Windows-Security-Auditing",
"channel": "Security",
"computer": "LAB-PC1",
"record_id": 12002,
"event_id": 4625,
"user": "LAB\\mira",
"logon_type": 3,
"source_ip": "192.0.2.44",
"status": "0xC000006D",
"sub_status": "0xC000006A"
}
JSONではバックスラッシュをエスケープするため2つ書きます。実際のアカウント表記は、バックスラッシュ1つのLAB\miraです。この教材のuserは対象アカウントのドメインと名前を結合し、source_ipはIpAddress、time_utcはTimeCreated/SystemTimeに対応させています。他の項目はComputer、EventRecordID、EventID、LogonType、Status、SubStatusに対応します。このファイルの変換規則であり、他のログにそのまま当てはめるものではありません。
実際の4624では新しいログオン（New Logon）、4625では**ログオンに失敗したアカウント（Account For Which Logon Failed）**を読みます。**サブジェクト（Subject）**はログオンを報告・要求した側のアカウントで、対象とは異なることがあります。最初に見つけたアカウント名を、そのまま対象として写さないようにします。
確認ポイント： イベントID 4625とレコードID 12002の違いを説明してください。どちらもプロセスIDではありません。
2. 任意のWindows演習：元の記録を探す
自分のWindows PCでコマンドプロンプトを開き、実行します。
eventvwr.msc
イベントビューアーでWindowsログ → セキュリティを開きます。現在のログをフィルターの記録日時でユーザー設定の範囲を選び、過去15分を含む開始・終了を設定します。イベントIDに4624,4625を指定します。1件選び、全般と詳細 → XML表示を比べてください。プロバイダー、コンピューター、イベントID、レコードID、時刻、対象アカウント、ログオンタイプを探します。Windowsやイベントのバージョンによって、表示名や利用できるフィールドは異なります。
図2：全般で内容を読み、XMLでフィールド名と元の時刻を確認します。
アクセス拒否なら、その制約を記録して練習ファイルを使います。管理された端末では組織のアクセス手順に従ってください。監査ポリシーの変更、ログの消去、意図的なログオン失敗は必要ありません。記録が少ない理由には、監査設定、保存期間、選んだ時間帯、アクセス制限などがあります。
Securityログへの既存のアクセス権がある場合、次のWindows PowerShellはローカルPCだけを対象に、過去15分の範囲を固定し、最大20件を取得します。
$end = Get-Date
$start = $end.AddMinutes(-15)
$events = @(Get-WinEvent -FilterHashtable @{
LogName = 'Security'
ProviderName = 'Microsoft-Windows-Security-Auditing'
Id = 4624, 4625
StartTime = $start
EndTime = $end
} -MaxEvents 20 -ErrorAction Stop)
$events | Select-Object TimeCreated, Id, RecordId, MachineName |
Format-Table -AutoSize
Get-WinEventは標準では新しい順に返します。上限が20件なので、活動の多い時間帯の総件数とは限りません。該当なしとアクセス拒否は別の結果です。実際のメッセージを記録してください。取得できた場合は、選んだ中で最新の1件のXMLを見ます。
$events[0].ToXml()
実際のアカウント名、ホスト名、エクスポートしたログは公開しないでください。公開用のポートフォリオには架空の教材を使えます。練習ファイルだけを使った場合、Windows演習は「未実行」と記録します。
3. 時刻の基準をそろえる
教材の時刻の末尾にあるZはUTCを示します。2026-10-20T09:01:20Zと2026-10-20T18:01:20+09:00は同じ瞬間です。タイムゾーンやUTCからの差がない時刻は、その文脈が分かるまで不完全な情報として扱います。
図3：元のタイムスタンプを残し、タイムラインの基準を明記します。表示時刻と収集時刻は別の問いに答える情報です。
WindowsのXMLではTimeCreatedのSystemTime属性を確認できます。Microsoftのイベント例はUTC表記です。イベントビューアーなどがローカル時刻に変換して表示する場合もあるので、元の文字列と同じ基準だと決めつけず、表示のタイムゾーンを確認します。
今回の演習はUTCで統一します。ファイルの行順ではなく、日時として読んだイベント時刻で並べてください。実環境では受信の遅れや順序の逆転、端末時計のずれがあります。近い時刻に並ぶことは流れを考える手がかりですが、因果関係の証明ではありません。教材には収集時刻や時計の状態の情報はありません。
確認ポイント： ファイルの1行目が最初に起きたイベントとは限らない理由を説明してください。
4. 結果とログオンタイプを読む
このWindowsイベントのタイプ2は対話型、タイプ3はネットワークログオンです。タイプ10はリモート対話型で、リモートデスクトップなどで使われますが、教材にはありません。タイプ3だけでRDPや特定のアプリを使ったとは言えません。
図4：イベントIDで結果を読み、タイプと失敗情報で状況を補います。
| 教材の値 | 文書上の意味 | 読み取れる範囲 |
|---|---|---|
0xC000006D |
ユーザー名や認証情報に問題がある、一般的なログオン失敗。 | SubStatusがあれば、詳細も確認する。 |
0xC000006A |
パスワードが正しくない。 | 入力ミス、保存された古い資格情報、不正な推測などが候補になる。 |
0xC0000064 |
指定されたユーザーが存在しない。 | その試行のアカウント検索に関する結果で、すべての環境やアカウントの話ではない。 |
このファイルのnullは値がないことを示します。成功イベントの失敗専用フィールドや、対話型イベントで送信元IPがない場合に使っています。0.0.0.0というアドレスではありません。実際のWindows記録では、フィールドや状況により-、空の値、ループバックなど別の表現があります。
192.0.2.44と192.0.2.80は文書用の予約アドレスです。遮断したり、脅威情報で照合したりする指標ではありません。実際のIPでも、それだけで人物は特定できません。プロキシ、NAT、共有端末などの状況も必要です。
5. 演習：7件のタイムラインを作る
練習ログをダウンロードし、テキストとして開きます。時刻順ではない8行が入っています。うち1行は、架空のエクスポート処理で同じ記録が再度含まれたものです。下の答えを見る前に試してください。
- ファイル名、プロバイダー、チャネル、コンピューター、最も早い時刻と遅い時刻を書く。
- 重複を探す。コンピューター、チャネル、レコードIDを比べ、その上でレコード全体が一致するか確認する。
- コンピューターが異なる12001は両方残す。12002も同様。レコードIDはPCやログをまたいで共通の一意な番号ではない。
- 作業用タイムラインから、完全一致した重複1行だけを除く。元のファイルは保存する。
- 異なる7件をUTCのイベント時刻で並べ、失敗と成功を別々に数える。
LAB-PC1、LAB\mira、192.0.2.44、タイプ3に絞る。流れを記述し、考えられる説明を2つと、それを区別するために必要な根拠を書く。
小さなファイルなので手作業で比べられます。この組み合わせは固定した教材内での確認用です。実環境でログがリセットされた場合や、出典の変更、値が食い違う記録がある場合は、さらに状況を確かめてから重複を除きます。
PowerShellで一覧にする場合、ダウンロードのあるフォルダーでPowerShellを開き、実行します。
$rows = @(Get-Content -LiteralPath .\security-from-zero-topic-04-auth.jsonl |
ForEach-Object { $_ | ConvertFrom-Json })
$rows | Sort-Object { [DateTimeOffset]::Parse($_.time_utc) } |
Select-Object time_utc, computer, record_id, event_id, user |
Format-Table -AutoSize
これは入力8行を並べるだけで、重複の除去や安全性の判定はしません。他のフィールドは元のファイルで確認します。並べ替えは読むための補助であり、各記録の確認の代わりにはなりません。
図5：絞り込んだ流れは異なる4件です。関連のない操作を同じ話にまとめず、全体の記録も残します。
答え合わせ： 以下はすべて2026年10月20日、UTCで、同じプロバイダーとSecurityチャネルです。重複はLAB-PC1 / Security / 12002です。
| 時刻（UTC） | コンピューター / レコードID | イベントID | 対象アカウント | タイプ | 送信元IP |
|---|---|---|---|---|---|
| 09:01:00 | LAB-PC1 / 12001 | 4625 | LAB\mira | 3 | 192.0.2.44 |
| 09:01:10 | LAB-PC2 / 12001 | 4625 | LAB\backup | 3 | 192.0.2.80 |
| 09:01:20 | LAB-PC1 / 12002 | 4625 | LAB\mira | 3 | 192.0.2.44 |
| 09:01:40 | LAB-PC1 / 12003 | 4625 | LAB\mira | 3 | 192.0.2.44 |
| 09:02:10 | LAB-PC1 / 12004 | 4624 | LAB\mira | 3 | 192.0.2.44 |
| 09:02:20 | LAB-PC2 / 12002 | 4624 | LAB\svc-backup | 3 | 192.0.2.80 |
| 09:02:30 | LAB-PC1 / 12005 | 4624 | LAB\mira | 2 | 値なし |
ファイル全体では異なる7件、失敗4件、成功3件です。絞り込んだ流れは70秒間の失敗3件と成功1件です。後のタイプ2は別の情報であり、ネットワークログオンの流れに成功を1件追加するものではありません。LAB-PC2の2つのアカウントも同一視しません。
6. 次の担当者が動けるメモを書く
観測した事実は、例えばこう書けます。「LAB-PC1では、対象LAB\mira、送信元192.0.2.44、タイプ3の異なる失敗ログオン3件がUTC 09:01:00〜09:01:40に記録された。同じ項目を持つタイプ3の成功が09:02:10に続いた。エクスポート内の重複1行は集計から除いた。」
この書き方なら、攻撃者を想像で作らずに根拠を伝えられます。利用者が入力を直した、アプリが古い資格情報で再試行した、不正に推測した、などは仮説です。どれに該当するか、同じ人物の操作かは、このファイルだけでは確定できません。
図6：次の担当者に、問い、根拠の参照先、具体的な確認手順を渡します。
| 次に確認すること | 解決したい問い |
|---|---|
| 許可された資産台帳、DHCP、VPNなどの記録で、その時刻の送信元端末を特定する。 | 想定された端末か。IPだけでは人物は分からない。 |
| 組織のサポート・調査手順で、アカウントの想定された操作を確認する。 | 既知のサインイン、保存された資格情報の問題、定期処理などがあったか。 |
| 成功時刻の前後5分を最初の範囲にして、アクセス先、ID、端末の関連ログを確認する。 | どのセッションや活動が続いたか。ホストと時刻に加え、利用できるログオン・セッションIDも使う。 |
| 監査設定、収集の状態、保存期間、時刻同期を確認する。 | 欠落や時計のずれが読み方に影響していないか。 |
教材にはSID、ログオンID、認証パッケージ、プロセス詳細、ログオン後の活動がありません。名前とIPは記録を選ぶ手がかりですが、単一のセッションだった証明にはなりません。実際の調査では元の情報をより多く保存し、チームのエスカレーション基準に従います。
ワークブックを使って1枚にまとめます。問いと範囲、出典、タイムライン、事実、考えられる説明、不明点、次の確認、現時点の扱いを含めてください。今回なら**「追加の状況確認が必要。侵害は未確認」**という扱いが妥当です。失敗3件だけで共通の重大度を決めたり、この架空の教材だけを根拠に送信元の遮断を勧めたりしません。
終えた後の応募書類には、例えば「架空のWindowsログオンデータを分析し、重複を照合してUTCタイムラインを作成。根拠、不明点、追加の確認事項を記録した」と正確に書けます。イベントビューアーの経験は、その演習も実施した場合に別途記載してください。
7. 面接で説明する練習
| 質問 | 答えに含めたいこと |
|---|---|
| 4624と4625の違いは？ | このプロバイダーのSecurityイベントでは成功と失敗。単独では意図は決まらない。 |
| 8行が7件になった理由は？ | 出典も含めて確認した、完全一致のエクスポート重複1行。レコードIDだけでは不十分。 |
| タイプ3はリモートデスクトップ？ | ネットワークログオン。リモート対話型はタイプ10で、サービスやプロトコルの特定には別の根拠が必要。 |
| 失敗の後の成功は侵害の証明？ | 違う。流れ、他の説明、次に必要な根拠を述べる。 |
| 検索結果がない理由は？ | 時間帯、アクセス権、監査設定、保存期間、収集の問題、または本当に該当する操作がない。 |
| 次の担当者に何を渡す？ | 範囲と基準時刻が明確なタイムライン、出典の参照、事実、不明点、具体的な確認事項。 |
他の人が同じ7件のタイムラインを再現でき、数字の意味を聞き直さなくても判断を理解できれば、次へ進めます。第5回のアカウント、認証、アクセスは、まだロードマップ上の予定です。
出典と実行に関する注記
フィールドの意味は2026年10月21日にMicrosoftの4624、4625、Audit Logon、NTSTATUS値、TimeCreated、EventRecordIDの文書で確認しました。Get-WinEventとFilterHashtableも参照してください。
JSON Lines教材は公開作業環境でPythonのJSONライブラリーを使って解析し、件数、重複、時刻順を確認しました。ホスト、アカウント、イベントはすべて架空です。アドレスはRFC 5737の文書用範囲です。Windows画面とPowerShellの手順は文書で確認したもので、Windows上では実行していません。教材の検査は、実環境での収集や検知の検証ではありません。
2026年10月22日（日本時間）： 日英で初公開。ロードマップに戻る。