Forensics · Lesson 07
Windows Event Logs
Learn how Windows records authentication, account changes, services, scheduled tasks, PowerShell activity, applications, and Defender events so you can answer forensic questions from structured evidence instead of guesswork.
Event IDs are useful shortcuts, but the real evidence lives in the full event: provider, timestamp, record ID, account, logon type, service path, message fields, and surrounding context.
Lesson Snapshot
Learning objectives
Use Windows events as structured forensic evidence
Understand the purpose of the major Windows Event Viewer log channels used during defensive investigation.
Recognize useful Security, System, Application, PowerShell, Task Scheduler, and Defender evidence.
Use Event Viewer and PowerShell to filter records by time, event ID, provider, and keyword.
Interpret authentication and service events without treating one event ID as a complete story.
Correlate Windows event records with users, files, services, tasks, processes, and network activity.
Preserve the exact event source, timestamp, record ID, provider, account, and message needed for competition answers.
Core idea
Event ID is only the beginning
An event ID tells you what kind of record you are looking at, but the account, host, provider, logon type, path, service, timestamp, and neighboring events determine what that record actually means.
Competition caution
Preserve evidence before account or service cleanup
Deleting an account, removing a task, stopping a service, or clearing logs can make later forensic questions much harder. Save the relevant event details first.
Event channels
Know which Windows log is most likely to contain the answer
Security
Authentication, account activity, privilege use, logon events, account changes, and audited security actions.
Caution
Available detail depends on audit policy and system configuration.
System
Services, drivers, startup, shutdown, hardware, networking components, and operating-system events.
Caution
A system error can explain a failure without being security-related.
Application
Events generated by installed applications and application components.
Caution
Meaning varies heavily by vendor and software version.
PowerShell
PowerShell operational and script-related activity where logging features are enabled.
Caution
Do not assume every command is recorded on every Windows system.
Task Scheduler
Scheduled-task registration, triggering, execution, completion, and failures in relevant operational logs.
Caution
The task definition itself should also be inspected because logs may be incomplete.
Microsoft Defender
Antivirus scans, detections, remediation, protection events, and security-product status where logged.
Caution
A detection record is evidence of a security-product decision, not automatically proof of every surrounding assumption.
Event Viewer workflow
Move from question to the right Windows evidence
Start with the forensic question
Decide whether you need evidence about a login, account, service, task, application, script, or security-product event.
Pick the most likely log
Security for authentication and account questions, System for services and OS components, Application for software-specific issues, and operational logs for specialized features.
Set the time window
Use known timestamps from file metadata, browser history, scheduled activity, or scenario clues to narrow the search.
Filter carefully
Use event ID, provider, level, user, or keyword filters without hiding neighboring context.
Read details
Record the event time, record ID, provider, user or account fields, computer name, message, and any process or service references.
Correlate
Compare the event with account state, file paths, services, scheduled tasks, process evidence, or another log channel.
Document before changes
Preserve the event details before deleting accounts, disabling services, removing tasks, or clearing logs.
Security events
High-value authentication and account-change evidence
These are common events worth recognizing. Always read the full event fields and confirm the provider and channel.
An account successfully logged on.
Useful for establishing authentication activity, logon type, account, source information, and timing.
Caution
A successful logon does not prove the account owner was physically at the keyboard.
An account failed to log on.
Useful for failed authentication patterns, account names, source context, and reason fields.
Caution
One failed logon can be normal. Pattern and context matter.
An account was logged off.
Can help bound a session when correlated with related logon information.
Caution
Not every session ends with perfectly paired records in every situation.
A logon was attempted using explicit credentials.
Useful when credentials are supplied to start a process or access another resource.
Caution
The event describes credential use, not necessarily malicious behavior.
Special privileges were assigned to a new logon.
Useful for identifying privileged sessions.
Caution
Administrative or service accounts can generate legitimate privileged logons.
A user account was created.
Useful for account-creation questions and timeline correlation.
Caution
Verify whether the account is expected by the competition scenario before judging it.
A user account was enabled.
Useful when determining when a previously disabled account became active.
Caution
Account enablement may be authorized administration.
A user account was disabled.
Useful for tracking defensive or administrative changes.
Caution
If your team performs the action, document it so you do not confuse your own change with original evidence.
A user account was deleted.
Useful for reconstructing account lifecycle.
Caution
Deleting an account before forensic review can remove useful context.
A member was added to a security-enabled local group.
Useful for local privilege and group-membership changes such as Administrators.
Caution
Check the group, member, actor, and whether the change was authorized.
A member was removed from a security-enabled local group.
Useful for documenting privilege reduction or group cleanup.
Caution
Separate original state from your team's later defensive changes.
Logon types
A successful logon means different things depending on type
Interactive
A user logged on locally at the computer.
Network
A network logon, often associated with access to shared resources or remote service interactions.
Batch
A batch-style logon, commonly associated with scheduled activity.
Service
A service account logon.
Unlock
A workstation unlock.
RemoteInteractive
A remote interactive session such as Remote Desktop.
CachedInteractive
An interactive logon using cached credentials.
System events
Services, startup, shutdown, and operating-system evidence
A service was installed in the system.
Useful for identifying service name, executable path, service type, start type, and account details where present.
A service entered a running or stopped state.
Useful for confirming service state changes and timing.
A service terminated unexpectedly.
Useful when investigating outages or repeated service failures.
The Event Log service started.
Often used as one clue for system startup timing.
The Event Log service stopped.
Often used as one clue for clean shutdown timing.
The previous shutdown was unexpected.
Useful when investigating abrupt power loss, crashes, or restart behavior.
Event fields
Record the fields that make the event reproducible
TimeCreated
Places the record in the local timeline.
Id
Identifies the event type within that provider's schema.
RecordId
Provides a unique or sequential record reference within the log.
ProviderName
Tells you which Windows component or application generated the event.
LogName
Identifies the channel where the event was stored.
MachineName
Prevents mixing evidence from different systems.
UserId
Can identify a security principal associated with the event when available.
LevelDisplayName
Shows operational severity, which may differ from forensic importance.
Message
Contains human-readable event details and embedded fields.
Event Viewer
Useful actions in the graphical interface
Filter Current Log
Narrow by time, level, event source, event ID, keywords, or user.
Find
Search visible records for a keyword such as a username, service name, or executable path.
Event Properties
Review General and Details views for structured fields and full message content.
Save Selected Events
Export relevant events in authorized practice when preserving a subset is useful.
Create Custom View
Build a reusable filtered view for a recurring type of investigation.
Applications and Services Logs
Open specialized operational channels for PowerShell, Task Scheduler, Defender, and other Windows components.
PowerShell
Query Windows events efficiently
Recent Security events
Get-WinEvent -LogName Security -MaxEvents 50
Reads the most recent Security events.
Successful logons
Get-WinEvent -FilterHashtable @{
LogName = "Security"
Id = 4624
StartTime = (Get-Date).AddHours(-2)
}Filters recent successful logon events.
Failed logons
Get-WinEvent -FilterHashtable @{
LogName = "Security"
Id = 4625
StartTime = (Get-Date).AddHours(-2)
}Filters recent failed logon events.
Service installs
Get-WinEvent -FilterHashtable @{
LogName = "System"
Id = 7045
}Finds service-install events in the System log.
Compact useful fields
Get-WinEvent -LogName System -MaxEvents 30 | Select-Object TimeCreated, Id, RecordId, ProviderName, LevelDisplayName, Message
Formats commonly useful event fields for quick review.
Search by provider
Get-WinEvent -FilterHashtable @{
LogName = "System"
ProviderName = "Service Control Manager"
StartTime = (Get-Date).AddHours(-4)
}Narrows the System log to one provider and time window.
Authentication reasoning
Say only what the event actually supports
4624 logon type 2 for student1
Supported
student1 authenticated interactively on that computer at the recorded time.
Not supported
student1 personally performed every later action in the session.
4624 logon type 10 for adminlab
Supported
adminlab established a remote interactive session such as RDP.
Not supported
The remote session was unauthorized.
Three 4625 events followed by one 4624
Supported
Several failed logons were followed by a successful authentication.
Not supported
This pattern alone proves a password-guessing attack.
4672 occurs after 4624
Supported
The logged-on account received special privileges in that session.
Not supported
The account abused those privileges.
4732 adds trainee2 to Administrators
Supported
The local group membership changed.
Not supported
The change was malicious without scenario and actor context.
4720 account creation at 08:42
Supported
A new account was created at that time.
Not supported
The account was unauthorized until the scenario and role are checked.
Service evidence
Use System events to investigate service changes
7045 installs DemoUpdater
Next evidence
Record service name, binary path, start type, service account, timestamp, and related file metadata.
7036 shows DemoUpdater entered running state
Next evidence
Compare the start time with the installation event and process evidence.
7034 shows repeated unexpected termination
Next evidence
Check service configuration, application logs, executable path, and dependent services.
Service binary lives under a user profile
Next evidence
Treat the path as unusual context and correlate with download, task, process, and user activity.
Service runs under LocalSystem
Next evidence
Recognize the high privilege level, but verify whether that is expected for the software.
Your team disables the service
Next evidence
Record the pre-change evidence and log the defensive action separately.
Task Scheduler
Scheduled activity
Task registration
Operational logs may show when tasks are registered or updated, while the task definition itself provides command, trigger, user, and conditions.
Task trigger
A task can run at logon, startup, a specific time, a recurring interval, or an event trigger.
Task execution
Execution records can help connect a scheduled task to later process activity.
Task user
The configured account matters because it changes privilege and context.
Preserve before removal
Record task name, action, arguments, trigger, user, enabled state, and related events before deleting or disabling it.
PowerShell
Script evidence
Operational channel
PowerShell has operational logs that may contain host and execution information depending on configuration.
Script block logging
If enabled, script block logging can provide deeper visibility into script content and execution.
Module logging
If enabled, module logging can record pipeline execution details for configured modules.
Coverage varies
Do not assume every system has detailed PowerShell logging enabled.
Do not overinterpret
The presence of PowerShell activity is not itself suspicious. Administrative and defensive tasks commonly use PowerShell.
Defender
Security-product evidence
Detection event
Records that Microsoft Defender identified content or behavior according to its rules.
Remediation event
Can show quarantine, removal, or other protective action.
Scan activity
Can help explain why files were accessed or why timestamps and security-product events appeared.
Configuration state
Protection settings and service state can influence what events are generated.
Correlation
Combine Defender evidence with file path, hash, process, and user activity instead of relying on the product verdict alone.
Correlation
Combine multiple Windows events with independent artifacts
4624 interactive logon at 09:03 + browser download at 09:08 + file creation at 09:08
Supported conclusion
The account authenticated before the download-related activity, and the browser and filesystem evidence align in time.
7045 service install at 10:15 + new executable in ProgramData at 10:14 + 7036 running at 10:16
Supported conclusion
The executable and service events likely belong to one installation/start sequence.
4720 new account at 11:22 + 4732 addition to Administrators at 11:24
Supported conclusion
A newly created account gained local administrative membership shortly afterward.
Task Scheduler registration at 12:00 + process start at 12:05 + network connection at 12:05
Supported conclusion
The scheduled task may explain the recurring process and related network activity.
4625 failures at 13:10-13:12 + 4624 success at 13:13
Supported conclusion
Several failed authentications preceded a successful one for the relevant account.
Defender detection at 14:40 + file hash F-09 + process evidence P-03
Supported conclusion
The security-product event, file identity, and process activity refer to the same artifact when paths and hashes align.
Limitations
Understand why Windows event evidence may be incomplete
Audit policy controls coverage
Some Security events appear only when the relevant auditing category is enabled.
Logs have retention limits
Older records can be overwritten or archived.
Event IDs are provider-specific
An event ID has meaning only in the context of its provider and channel.
Versions can differ
Field names, messages, and operational channels can vary across Windows versions and components.
Time settings matter
Local display time, UTC storage, daylight saving changes, and clock drift can complicate timelines.
Events can reflect your own actions
Defensive changes made during the competition generate new events, so keep a change log.
Evidence note
Record a Windows event so another teammate can verify it
Forensic question
Computer name
Log name
Provider
Event ID
Record ID
Timestamp and zone
User or account
Relevant message fields
Related file or service
Corroborating event
Supported conclusion
Common mistakes
Windows event-log mistakes that weaken forensic answers
Memorizing IDs without reading fields
The same event type can contain different users, hosts, logon types, paths, or service details.
Ignoring logon type
A local interactive session, network access, service logon, and RDP session mean different things.
Treating 4625 as automatically malicious
Failed logons can result from mistakes, expired credentials, services, or legitimate automation.
Ignoring provider name
Event IDs only make sense in the context of the provider and channel.
Looking only at Security
Service, task, Defender, PowerShell, and application evidence may live in other channels.
Clearing logs before documentation
This destroys evidence and may remove the only record of account or service activity.
Confusing your own changes with original state
Defensive actions generate events too. Keep a separate change log.
Assuming one event proves motive
Event logs record activity, not human intention.
Fictional Windows event lab
Reconstruct an account and service sequence
student4 interactive logon succeeds on CP-WIN-09.
Account backup-helper is created.
backup-helper is added to the local Administrators group.
Service BackupHelper is installed with a binary under C:\ProgramData\BackupHelper\helper.exe.
BackupHelper enters the running state.
helper.exe opens a fictional outbound connection to 203.0.113.55.
Task 01
Which event establishes the user session?
The 08:31:10 Security 4624 event for student4.
Task 02
Which two events show account creation followed by privilege increase?
4720 at 08:35:44 and 4732 at 08:36:21.
Task 03
Which event most directly identifies the service executable path?
The System 7045 service-install event.
Task 04
What confirms the service started?
The 7036 event showing BackupHelper entered the running state.
Task 05
Does the network connection alone prove the service is malicious?
No. It shows outbound activity. Scenario requirements, executable identity, service purpose, and other evidence are still needed.
Task 06
What should be preserved before disabling the account or service?
The relevant Security and System events, account/group details, service configuration, binary path and hash, timestamps, and related network evidence.
Lesson checklist
Before moving on
I start with the forensic question before opening Event Viewer.
I choose the log channel most likely to contain the answer.
I filter by time before adding narrower criteria.
I record provider, event ID, record ID, timestamp, host, and user.
I understand common Security events for logons and account changes.
I check logon type before describing an authentication event.
I recognize common System service events.
I know where to look for Task Scheduler, PowerShell, and Defender operational evidence.
I read neighboring events before forming a conclusion.
I correlate important events with files, services, tasks, processes, or network evidence.
I preserve event details before changing the system.
I document my own defensive actions separately.
Reflection
Check your Windows event reasoning
Question 1
Why is event ID 4624 incomplete without logon type and account context?
Question 2
What additional evidence would you inspect after event ID 7045 shows a new service?
Question 3
Why can several 4625 failures followed by a 4624 success still have a legitimate explanation?
Question 4
Why should provider name be recorded with every important Windows event?
Question 5
How can your own defensive actions complicate the event timeline?
Question 6
Which Windows log or operational channel would you check first for a scheduled-task question?
Carry this forward
Use Event Viewer and PowerShell to find the right records, read the full event rather than only the ID, interpret logon type and provider context, correlate with independent artifacts, and preserve evidence before hardening changes.