Step 12. Event Logs — Reading Windows’ Black Box

Level 0 — Understanding Computer Operation and Structure | Difficulty ★★★☆☆ | Estimated time 2–3 hours

Prerequisite: Step 11 complete. We will work in Windows PowerShell. Today you need an administrator-privilege PowerShell — you’ll learn how to open one inside this chapter.

• What you need: a Windows PC, PowerShell (administrator). Section 3-1 shows you how to open it.
• Caution: every exercise today is read-only. No commands that erase or modify logs appear. But since this is your first day using an administrator-privilege window, the hidden theme of today is learning "why this privilege must be handled with care."

When a plane crashes, the first thing investigators look for is the black box. Windows has a black box too — the event log. Logins, failed logins, program launches, system startups… every incident happening in Windows is recorded here in chronological order. The first page of nearly every breach investigation report features "login event analysis." Today, we write that first page ourselves.

1. Learning Objectives

By the end of this chapter, you will be able to:

• Open an administrator PowerShell and explain why this privilege is used "only when needed"
• Query Windows’ log list and contents with Get-WinEvent
• Filter by event ID using -FilterHashtable
• Query 4624 (login success) and 4625 (login failure) records and interpret their meaning
• Save query results to a file and experience the first form of "evidence preservation"

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

2-1. Logs — The Journal Windows Writes Automatically

A ship’s captain keeps a log: "09:00 departure, 12:00 rough seas, 15:00 arrival." When an accident happens, this journal reconstructs the timeline. Windows writes this journal automatically. Without being asked, it records a line whenever an important event occurs. This system is called logging, and each recorded line is an event.

Logs are divided by type; the main ones are:

Beyond these there are hundreds of specialized logs. What we’ll look at today is Security — the access ledger recording "who passed through this door, and when."

2-2. Event IDs — The Incident’s Type Number

Every event carries a type number: the event ID. No need to memorize them all — today, just remember two:

Picture the story these two numbers can draw: dozens of 4625s starting at 11 PM, then a single 4624 at 11:20 PM — someone kept getting the password wrong, and eventually got in. It’s the most classic pattern in breach investigation. Two numbers, and you can read a story like this.

2-3. Why Administrator Privileges — The Log’s Self-Defense

The Security log is locked so ordinary users can’t read it. Two reasons:

1. The log’s contents are themselves sensitive information — knowing who logged in when is useful to an intruder, too
2. The log is what an attacker most wants to erase — wiping traces is step one after a successful intrusion, so access itself is guarded by high privileges

"The more important the record, the higher the privilege protecting it" — a basic security design. Today we use the legitimate privilege (administrator of your own computer) that passes through that protection.

2-4. Logs Are Not Forever — Retention and Overwriting

Logs don’t pile up forever. There’s a capacity limit, and when it’s full, the oldest entries get overwritten. A personal computer usually retains a few weeks’ worth; companies store them separately according to policy (some industries have legal retention obligations).

That’s why breach investigations favor "the sooner you start, the better" — given time, evidence erases itself. One of the first instructions in real incident response manuals is "immediately copy the logs to a separate location and secure them." The Out-File saving you learn today is that action in miniature. And remember the cardinal rule of forensics: handle evidence as a copy, never touching the original.

2-5. The Perspective of Auditing

"Recording who did what, so it can be reviewed later" is called auditing. Like an accounting audit, records are what let you later establish what happened and who was responsible. The event log is Windows’ audit system, and the querying you learn today is the first step of that review.

3. Follow Along

3-1. Opening an Administrator PowerShell

Open a different window from the PowerShell you’ve used so far:

1. Right-click the Start button (or press Win + X)
2. In the menu, click "Terminal (Admin)" or "Windows PowerShell (Admin)"
3. When asked "Do you want to allow this app to make changes to your device?", click Yes

How to confirm: if the window title includes "Administrator," you’ve succeeded.

About this privilege: administrator rights are the power to "do anything." So the principle is to work under ordinary privileges normally and open this only when needed (as right now). The reason malware struggles so hard to gain administrator rights is exactly this power. Privileges only in the moment of need, with the purpose known — this habit itself is security.

3-2. Failing on Purpose First — The Security Log from a Normal Window

Before opening the admin window, type this in a regular PowerShell window:

Get-WinEvent -LogName Security -MaxEvents 2

Get-WinEvent : 권한이 없는 작업을 수행하려고 했습니다.

(Verified on 2026-09-09 in a non-elevated window. The error type is UnauthorizedAccessException — a no-permission exception.)

Why fail on purpose: to confirm Section 2-3’s "self-defense of the log" as a red error rather than a sentence. The same command works in an admin window and is blocked in a normal one — that contrast is the substance of privilege.

3-3. The Full Landscape of Logs — Which Logs Hold How Much

In the admin window:

Get-WinEvent -ListLog * | Where-Object { $_.RecordCount -gt 0 } |
  Sort-Object RecordCount -Descending | Select-Object -First 8 LogName, RecordCount

LogName                                            RecordCount
-------                                            -----------
Microsoft-Windows-Hyper-V-VmSwitch-Operational           49952
System                                                   43607
Microsoft-Windows-Store/Operational                      24591
Application                                              21405
Microsoft-Windows-StorageManagement/Operational          16793
Microsoft-Windows-StateRepository/Operational            12309
Microsoft-Windows-Storage-ClassPnP/Operational           11851
Intel-Gfx-Display-External/GfxDisplayExEventViewer       21788

(Verified on 2026-09-09. Rankings and counts differ from computer to computer.)

How to read the output: log names and accumulated record counts. On the verification computer, the System log alone holds 43,607 records — you can see in numbers how fast logs pile up. This is why -MaxEvents in the next section is essential. Ask for everything with no conditions, and the system spends ages scanning tens of thousands of records.

3-4. Peeking at the Security Log

Now the main event, in the admin window:

Get-WinEvent -LogName Security -MaxEvents 20

TimeCreated            Id   LevelDisplayName Message
-----------            --   ---------------- -------
2026-09-09 오전 9:...  4624 Information      계정이 성공적으로 로그온했습니다...
2026-09-09 오전 9:...  4672 Information      새 로그온에 특수 권한이 할당...
2026-09-09 오전 8:...  4634 Information      계정이 로그오프되었습니다...
...

(Screen example — run it yourself in the admin window and check your own computer’s records.)

How to read the output: from the left — time (TimeCreated), event ID (Id), severity (Level), summary (Message). The newest events sit on top. Most are normal activity by system accounts — for now, you’re at the stage of getting used to "so this is what logs look like."

3-5. Filtering — Login Successes Only (4624)

From tens of thousands of records, we pull out only the kind we want:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5

New syntax — -FilterHashtable @{...}: a bundle of conditions meaning "only those with log name Security and ID 4624." Write it in the shape @{condition1; condition2}, separating conditions with semicolons (;). If Step 4’s Select-String was "filtering by text," this is "filtering by property" — the log system filters in advance and sends only the results, so it’s much faster.

If you want to see one record in detail:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 1 | Format-List

Format-List spreads the result out as a vertical list. Read the full Message — it states which account logged in, and in what manner (logon type). It’s fine if the terminology is unfamiliar at first. Being able to find just the "account name" and "time" is enough.

3-6. The Thrill of Investigation — Finding Login Failures (4625)

Now, like a real investigator:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 10

If there are no results: nothing appears without an error, or a notice says "no events were found that match the specified selection criteria" — it means there are no failure records, and that’s normal, and a good sign. (On a computer with remote access exposed, unknown failures do occasionally get recorded.)

If there are results: look at each one. If it matches a time you remember mistyping your password, it’s normal. If there’s an unknown failure at an unknown time — that’s what a "suspicious signal" looks like. At this stage, don’t dig deep; the goal is to experience "so this is what I can see."

Today’s highlight experiment: lock your computer (Win + L), deliberately type your password wrong once, log in normally, then run the 4625 query above again. Your failure just now is recorded as the newest entry. The moment you see with your own eyes that "my action became a log," you understand what a log is, in your body.

3-7. Organizing into a Report — Evidence Preservation

Investigation is half organization. Let’s apply Step 5’s table-making:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5 |
  Select-Object TimeCreated, Id, Message |
  Out-File login-report.txt

Line-by-line explanation: take 5 events of ID 4624 → pick only the three needed columns (time, ID, summary) → save to a file. Open login-report.txt in Notepad and check.

Why do this: an investigation isn’t complete at the query — it includes leaving evidence as a file. Section 2-4’s "immediately copy and secure the logs" is exactly this action.

4. Missions & Exercises

Mission — Today’s Login Timeline

Let’s reconstruct your computer’s day:

1. In an administrator PowerShell, query the 10 most recent 4624 (login success) events
2. Write each record’s time on paper — does it match when you turned the computer on, when it woke from sleep?
3. If there are 4625 (failure) events, write those times too, and check whether they were your own actions
4. Organize this timeline into timeline.txt (free format — e.g., "09:12 login (turned the computer on)")

Exercises

Question 1. What happens if you read the Security log from a normal window, and why is it designed that way?

Question 2. What happens if you omit -MaxEvents from Get-WinEvent? State the iron rule of log querying in one line.

Question 3. You typed -FilterHashtable @{LogName='Security', Id=4624} and got a filter error. What was wrong?

Question 4. On some computer, an entire period of the Security log was found completely empty. Is "nothing happened during that period" the only interpretation? Why would an investigator find this suspicious?

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 10 |
  Select-Object TimeCreated, Id | Out-File timeline.txt
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 10 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id | Out-File timeline.txt -Append
notepad timeline.txt

오전 8:53  로그인 성공 — 아침에 컴퓨터 켠 시간과 일치
오전 9:27  로그인 성공 — 절전 모드에서 깨어난 시간
오전 10:18 로그인 성공 — (절전 해제?)
...

6. Common Pitfalls & Fixes

Wall 1. Permission error on the Security log

Symptom: a red error appears (verified on 2026-09-09):

Get-WinEvent : 권한이 없는 작업을 수행하려고 했습니다.

Cause: you ran it in a normal (non-administrator) PowerShell. The Security log is readable only by administrators.
Fix: check that the window title says "Administrator," and open an admin window as in Section 3-1. For reference, Application/System logs are often readable from a normal window, so you can remember it as "only Security needs the admin window."

Wall 2. The command won’t finish

Symptom: no result appears; the cursor just blinks.
Cause: without -MaxEvents, it reads all tens of thousands of records. The verification computer’s System log had 43,607 records, and large logs can hold hundreds of thousands.
Fix: interrupt with Ctrl + C, add -MaxEvents 20, and run again. Count limit first, always — that’s the iron rule of log querying.

Wall 3. Errors in FilterHashtable

Symptom: an error saying the filter condition is invalid.
Cause: mostly a syntax problem inside @{ }. Conditions must be separated by semicolons (;) — commas won’t work. Also check the spelling of the key names (LogName, Id).
Fix: copy the form @{LogName='Security'; Id=4624} exactly and change only the values.

Wall 4. Zero 4625s, so "is the command broken?"

Symptom: the query comes back completely empty, or a notice says "no events were found matching the specified selection criteria" (verified on 2026-09-09).
Cause: not broken — the failure count is 0. Good news.
Fix: interpret an empty result as "0 records." If you want to be certain, do the "fail on purpose" experiment from Section 3-6. If the failure record you just created appears, both the command and the log are working fine.

Wall 5. The Message is long and hard to read

Symptom: summaries are long and full of jargon.
Cause: log messages were written for developers and investigators from the start, so they’re not friendly.
Fix: at first, looking at just the two columns TimeCreated and Id is enough. "When, what kind" is the backbone of a timeline. Do detailed interpretation slowly with Format-List once you’re comfortable.

7. Summary

Today’s Concepts

Today’s Commands

A Sense That Matters More Than Commands

Today you personally performed the first move of forensic investigation — open the logs, filter by type, read the timeline. And at the same time you learned the attacker’s point of view: because this log is frightening, attackers try to erase it — which is why defenders guard it with privileges and collect copies. The battle over records — that picture is the essence of incident response.

Two more points before we close. First, beyond today’s 4624/4625, investigators have favorite numbers: 4634 (logoff), 4672 (administrator-level privileges assigned — sensitive!), 4688 (program execution), 4720 (new account created — gets recorded when an attacker creates an account). Breach investigation cheat sheets are entirely combinations of these numbers, so for now just remember "these things exist." Second, companies gather each computer’s logs into one place (a system called a SIEM) — to compare at a glance, and so that a copy survives even if an attacker wipes one computer’s logs. What you did today on one machine, organizations automate at a scale of tens of thousands — but the principle is the same as today’s: collect → filter → detect patterns.

Once every box is checked, Step 12 is complete.