Windows Event Logs and Where to Look for a Trace

When something suspicious happens on a Windows computer, the first question is always the same: what did the system record? Windows keeps a detailed diary of logins, service changes, policy updates and much more. Knowing where to look, and what a handful of key event numbers mean, lets you answer questions like "who logged in at 3 a.m.?" or "was a new account created?". It is also the last lesson of the chapter, so you will bring together registry, directory, PowerShell and logs in one small investigation.

In chapter 4 you read Linux logs with journalctl and /var/log. This lesson is its Windows counterpart.

The Windows event log system

Windows records events in structured logs. Each event is more than a line of text: it has an Event ID, a level (information, warning, error), a source, a timestamp, the computer, and a set of fields with details. The logs are viewed in the Event Viewer (eventvwr.msc) and are stored in files with the extension .evtx, under the system folder.

The main logs for a security-minded reader:

Log	What it contains
Security	Logins, logoffs, account changes, privilege use, audit results. Reading it needs administrator rights.
System	Operating system events: services, drivers, start-ups, shutdowns.
Application	Events written by applications.
Applications and Services Logs	Many specialised logs, including PowerShell and Windows Defender operational logs.

An important concept: what ends up in the Security log depends on the audit policy, which tells Windows which categories of events to record (for example "audit logon events" or "audit account management"). Auditing is configured by GPO in a company, and an untuned audit policy can leave you with an empty diary when you need it. Part of a security assessment is checking that the right events are enabled, and that logs are large enough not to be overwritten in a few hours.

Events worth knowing by heart

There are thousands of event IDs, but a short list covers a large share of investigations. Learn these:

Event ID	Log	Meaning
4624	Security	An account was successfully logged on
4625	Security	An account failed to log on
4634 / 4647	Security	Logoff
4672	Security	Special privileges assigned to a new logon (typically an administrator)
4688	Security	A new process was created (if process auditing is enabled)
4720	Security	A user account was created
4732	Security	A member was added to a security-enabled local group
4740	Security	A user account was locked out
1102	Security	The audit log was cleared
7045	System	A new service was installed

Why these? Each one answers a security question. Many 4625 events for the same account from the same source in a short time suggest password guessing. A 4624 event at an unusual hour for an administrative account deserves a question. 4720 followed by 4732 (a new account, then added to a privileged group) is exactly the pattern an intruder would produce to keep access. 1102 should alarm any defender: someone erased the evidence. 7045 is a standard place to find persistence through a new service.

The logon event also records a logon type, which says how the login happened. For instance, type 2 is an interactive login at the keyboard, type 3 is a network login (such as accessing a shared folder), and type 10 is a remote desktop session. The same account logging on with a type you do not expect, for example a remote logon at 3 a.m. on a machine that should only be used locally, is a lead.

Searching logs in the Event Viewer

In Event Viewer, select a log, then use Filter Current Log on the right panel to restrict by event ID, level and time. You can type the event ID (for example 4625) in the filter field. Click an event to see the details in the lower pane, including the account name, the source address and the reason for failure.

Searching with PowerShell

For anything repetitive, Get-WinEvent is the better tool. It queries logs quickly and returns objects you can filter:

# Last 10 failed logons (run PowerShell as administrator)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 10

# Successful logons in the last 24 hours
Get-WinEvent -FilterHashtable @{
    LogName='Security'; Id=4624
    StartTime=(Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Id -First 10

# New services installed
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} -MaxEvents 5 |
    Format-List TimeCreated, Message

Using -FilterHashtable is much faster than fetching all events and filtering afterwards. If the query returns an error saying that no events were found, it simply means that there is nothing matching. On a fresh VM with default settings, some events (such as process creation, 4688) may not exist because the audit policy is not enabled.

Beyond the basics: Sysmon and central collection

The native Windows logs are useful, but incomplete for detection. Many organisations add a free system monitor tool that records detailed events such as process creation with the full command line, network connections and file creation. And as we said for Linux, logs should be forwarded to a central place, where they can be correlated and stored even if the machine is compromised. This leads to the SIEM concept, covered later in the track.

A method for investigating

Whatever the platform, a simple procedure helps:

1. Define the question and the time window. "Did anyone log in to this machine between 1 a.m. and 5 a.m.?"
2. Pick the right log and event IDs. Logins are in Security (4624 and 4625).
3. Filter, then read the details. Account, source address, logon type, process.
4. Look for the chain. A suspicious login, then a new account, then a new service, in a short time.
5. Check that the logs themselves are intact. A gap in time, or event 1102, is a finding.
6. Write it down. Facts, times and sources, separately from your interpretations.

Your turn: generate and find your own events

On your Windows lab VM, create a local test user named testuser using the Settings application or net user testuser "ExamplePass123!" /add (use a throwaway password, in your isolated lab only). Then try to log in to the VM with a wrong password once on purpose. Open Event Viewer and find the event of the account creation and the failed logon, or use Get-WinEvent. If you cannot find them, check the audit policy (auditpol /get /category:*) and enable the relevant subcategories, then repeat. In your notebook, write the Event IDs, the time and the key fields you found. Finally, delete the test user.

See a solution

You should find event 4720 (user account created) with the name of the new account and the account that created it, and event 4625 (failed logon) with the target account name, the logon type and the reason of failure. If nothing shows up, enable auditing of "Account Management" and "Logon" categories (for example with the Local Security Policy, or auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable) and repeat the test: this is a typical discovery of a real assessment, auditing is often not on by default for everything you need. To clean up, run net user testuser /delete. You have also reproduced, in miniature, the investigation chain described above.