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
| Category | Details |
|---|---|
| Language & environment | PowerShell 5.1 in administrator mode (the Security log is readable only by administrators) |
| Today’s commands | Get-WinEvent -LogName ... -MaxEvents N, -FilterHashtable @{LogName='...'; Id=number}, | Format-List (one record in detail) |
| Concepts needed | Logs and logging, event IDs, auditing, what administrator privileges mean |
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:
| Log name | What it records |
|---|---|
| Security | Logins/logoffs, privilege use — the core of security (administrator required) |
| System | Status of Windows’ own components (drivers, updates, etc.) |
| Application | Records left by programs |
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:
| Event ID | Meaning |
|---|---|
| 4624 | Login succeeded |
| 4625 | Login failed |
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:
- The log’s contents are themselves sensitive information — knowing who logged in when is useful to an intruder, too
- 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:
- Right-click the Start button (or press
Win + X) - In the menu, click "Terminal (Admin)" or "Windows PowerShell (Admin)"
- 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:
- In an administrator PowerShell, query the 10 most recent 4624 (login success) events
- Write each record’s time on paper — does it match when you turned the computer on, when it woke from sleep?
- If there are 4625 (failure) events, write those times too, and check whether they were your own actions
- 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?
5. Model Answers & Completion Criteria
Mission Model Answer
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
In Notepad, compare the times against your own actions and add comments:
오전 8:53 로그인 성공 — 아침에 컴퓨터 켠 시간과 일치
오전 9:27 로그인 성공 — 절전 모드에서 깨어난 시간
오전 10:18 로그인 성공 — (절전 해제?)
...
How to verify: if the times in the log broadly match your actual actions, your query is accurate. If even one time is unexplainable, think about what the computer was doing then (waking from sleep, automatic updates, etc.) — the process of explaining an unexplainable record is itself investigation training. It’s exactly the same instinct as identifying startup programs in Step 11.
Advanced: pair the entries (4624) with the exits (4634, logoff) by time, and you can calculate "how long that account stayed." When breach analysts make precise statements like "the intruder entered at 23:04 and stayed for 47 minutes," it’s thanks to this pairing. If you have time, try it yourself with the data you queried today.
Exercise Answers
Answer 1. You get the error "Attempted to perform an unauthorized operation" (UnauthorizedAccessException) (verified on 2026-09-09). Log contents are sensitive information in themselves, and they’re the number-one target of an attacker’s trace-wiping, so access is protected by high privileges.
Answer 2. It tries to read every record in that log (tens to hundreds of thousands), and the command takes forever to finish. In the Section 3-3 verification, the System log alone held 43,607 records. The iron rule: when querying logs, always set a count limit (-MaxEvents) first.
Answer 3. Because the conditions were separated with a comma (,). Inside a FilterHashtable, conditions are separated by semicolons (;): @{LogName='Security'; Id=4624}.
Answer 4. No. Since logs are the first thing an attacker wants to erase, the very absence of records can itself be a trace that someone deleted them. Distinguishing "nothing happened" from "the records were wiped" is the investigator’s domain — which is why organizations copy logs to a separate system (see log centralization in the Summary).
Completion Criteria Checklist
- [ ] I can open an administrator PowerShell
- [ ] I can explain why administrator privileges are used "only when needed"
- [ ] I can query log lists and contents with
Get-WinEvent - [ ] I can filter by event ID with
-FilterHashtable - [ ] I know the meaning of 4624 and 4625, and can explain why the pattern "a burst of failures, then a success" is suspicious
- [ ] I can save query results with
Out-File - [ ] Mission: I completed timeline.txt
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
| Concept | One-line description |
|---|---|
| Event log | Windows’ black box — incidents recorded in chronological order |
| Security log | The access ledger of security events like logins (administrator required) |
| Event ID | An incident’s type number — 4624 success / 4625 failure |
| Audit | A system for recording so that review is possible later |
| Overwriting | Old logs being erased due to capacity limits — the reason evidence preservation is urgent |
Today’s Commands
| Command | What it does |
|---|---|
Get-WinEvent -LogName Security -MaxEvents N |
Views the most recent N records |
-FilterHashtable @{LogName='Security'; Id=4624} |
Filters by ID (separator is ;) |
| Format-List |
Views one record in detail |
| Select-Object ... | Out-File |
Selects needed columns and saves evidence |
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. Click the checkbox in the sidebar to save your progress.