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 unit.

• 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 unit, 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

This section’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:

A sequence of failures followed by a success is a reason to investigate. Correlate the account, source, logon type, and time before concluding that the same person finally obtained access.

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

Security-log access depends on the token, channel permissions, and policy. Elevated administration commonly permits this exercise; explicitly delegated readers may also have access.

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

Retention depends on configured size, overwrite or archive policy, and event volume. Record those settings; there is no universal number of days retained.

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

Before you begin. Security events depend on audit policy, retention, permissions, and the selected time range. A missing event is not proof that an action never occurred.

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

Confirm elevation by checking the session token rather than relying only on a customizable window title. Use only your own authorized administrator session.

Elevation grants additional authority and should be limited to the required query. It does not override every Windows security boundary.

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 : Attempted to perform an unauthorized operation.

Illustrative output. Values, wording, account names, and available fields vary by environment.

Compare the query in an ordinary and an authorized elevated session. If both can read the channel, record the delegated access rather than trying to force a failure.

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
Intel-Gfx-Display-External/GfxDisplayExEventViewer       21788
Application                                              21405
Microsoft-Windows-StorageManagement/Operational          16793
Microsoft-Windows-StateRepository/Operational            12309
Microsoft-Windows-Storage-ClassPnP/Operational           11851

Illustrative output. Values, wording, account names, and available fields vary by environment.

Read the log name and returned record count. The displayed counts are illustrative and change over time. Apply a bounded query rather than retrieving an entire log unnecessarily.

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:... AM    4624 Information      An account was successfully logged on...
2026-09-09 9:... AM    4672 Information      Special privileges assigned to new logon...
2026-09-09 8:... AM    4634 Information      An account was logged off...
...

(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

No matching records means none were returned by this query. Check audit policy, retention, permissions, and time range before interpreting that absence; it is not proof that no failed logon occurred.

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.”

Optional controlled observation: only on a disposable local account whose lockout policy you understand, compare one failed and one successful sign-in with the event log. Do not repeatedly guess passwords. Authentication methods and audit settings affect which events appear; record the actual result.

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.

The text export is a readable learning report. It omits event structure and is not a complete forensic acquisition or chain-of-custody procedure. Preserve original event data separately when conducting an actual investigation.

4. Missions & Exercises

Mission — This section’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 red syntax 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 AM  login success — matches when I turned the computer on this morning
9:27 AM  login success — when it woke from sleep
10:18 AM login success — (wake from sleep?)
...

6. Common Pitfalls & Fixes

Wall 1. Permission error on the Security log

Symptom: a red error appears (Illustrative source example):

Get-WinEvent : Attempted to perform an unauthorized operation.

Cause: the current token may lack permission to read this channel. Channel permissions and delegated access vary.

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 example 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: a red syntax error such as Missing expression after ',' (Illustrative source example).
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?”

Cause: no matching events were returned. Audit configuration, retention, selection, or actual absence can explain this.

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

This section’s Concepts

This section’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 this section’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 this section’s: collect → filter → detect patterns.

Once every box is checked, Step 12 is complete.