How to Analyze Windows Event Logs for Suspicious Activity

When something suspicious happens on a Windows computer, the operating system may leave clues in its event logs. These records can help investigators understand login attempts, account changes, process execution, system errors, and other activity.

For example, repeated failed logins followed by a successful login from an unfamiliar source may warrant investigation. A newly created account or an unexpected change to a privileged group may also deserve attention.

Windows Event Logs do not automatically tell you whether a system has been compromised. The important skill is knowing which events to examine, how to filter them, and how to correlate the evidence.

In this guide, you will learn how to use Windows Event Viewer and PowerShell to investigate suspicious activity, understand important Event IDs, and document your findings.

What Are Windows Event Logs?

Windows Event Logs are records generated by the operating system and applications. They capture events such as successful logins, failed authentication attempts, service failures, and changes to system configuration.

Administrators use these records to troubleshoot problems. Security analysts and digital forensic investigators use them to reconstruct activity and identify behavior that may indicate a security incident.

Windows organizes events into different logs.

Additional logs are available under Applications and Services Logs, including logs associated with Windows Defender, Task Scheduler, Remote Desktop, and other components.

The events available on a computer depend on its configuration, enabled audit policies, installed components, and log-retention settings.

Step 1: Open Windows Event Viewer

Event Viewer is the built-in Windows interface for browsing and filtering event logs.

To open it:

1. Press Win + R.
2. Type eventvwr.msc.
3. Press Enter.
4. Expand Windows Logs in the left panel.
5. Select Security, System, or another relevant log.

You can now browse the recorded events.

Each event typically includes a timestamp, source, Event ID, severity level, and description. Selecting an event displays more information in the lower panel.

For security investigations, start with the Security log. If you are investigating a broader incident, examine related logs as well.

How to filter events

The Security log can contain thousands of records, so examining every entry manually is inefficient.

To filter it:

1. Select Windows Logs → Security.
2. Click Filter Current Log in the Actions panel.
3. Enter one or more Event IDs in the event ID field, separated by commas.
4. Set a relevant time range if needed.
5. Click OK.

For example, entering 4624,4625 filters for successful and failed logon events.

Important: If you cannot access the Security log or the events you expect are missing, check your permissions, audit policy, log retention, and collection configuration.

Step 2: Understand the Most Important Security Event IDs

An Event ID identifies a particular type of event. It is a starting point for investigation, not a verdict that an attack occurred.

The following events are useful when examining common Windows security scenarios.

Microsoft's security-event reference documents these and other event types. Their availability and detail depend on the relevant Windows auditing configuration. Microsoft's Windows security event reference.

Do not interpret Event IDs in isolation

A successful logon (4624) is normal on most systems. A failed logon (4625) may simply reflect a mistyped password. Event 4672 can appear during legitimate administrative activity.

The investigative question is not simply whether an event exists. It is whether the event fits the expected activity for that user, device, time, and environment.

Step 3: Investigate Failed Login Attempts

Repeated failed logins can indicate password guessing, a misconfigured service, an expired password, or ordinary user error.

Start with Event ID 4625.

In Event Viewer:

1. Open Windows Logs → Security.
2. Select Filter Current Log.
3. Enter 4625.
4. Review the timestamps and event details.

Pay attention to:

• Account name: Which account was targeted?
• Logon type: What kind of logon was attempted?
• Source network address: Is a source address recorded?
• Workstation name: Is a computer name recorded?
• Failure information: Why did the logon fail?

Not every event contains every field. The available details depend on the authentication method and event context.

Search for failed logons using PowerShell

Open PowerShell and run:

$StartTime = (Get-Date).AddHours(-24)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = $StartTime
} | Select-Object TimeCreated, Id, ProviderName, Message |
    Format-List

This command retrieves failed-logon events from the last 24 hours and displays their details.

You may need elevated permissions to read the Security log.

What should you consider suspicious?

Examples include:

• A large number of failed attempts against one account.
• Attempts against multiple usernames within a short period.
• Repeated failures from an unfamiliar source address.
• Failures followed by a successful logon that does not fit the user's normal activity.

These patterns justify further examination, but they do not independently establish malicious activity.

Also, the absence of failed-logon events does not prove that nobody attempted unauthorized access. Logging may be incomplete, and some authentication activity may be recorded on a different computer, such as a domain controller.

Step 4: Examine Successful Logins

A failed login shows that an authentication attempt did not succeed. Event ID 4624 records a successful logon.

The next question is whether the successful session was expected.

In Event Viewer, filter the Security log for 4624.

Examine the following fields where available:

• Account name and domain.
• Timestamp.
• Logon type.
• Source network address.
• Workstation name.
• Authentication-related information.

Understand logon types

The logon type helps explain the kind of session Windows recorded.

Interpret these values in context. A network logon, for example, is not inherently suspicious; ordinary file sharing and other network services can generate such events.

Retrieve successful logons with PowerShell

$StartTime = (Get-Date).AddHours(-24)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624
    StartTime = $StartTime
} | Select-Object TimeCreated, Id, Message |
    Format-List

Look for sessions that are unusual for the account or computer.

For example, a successful remote interactive logon to a workstation that is not normally accessed remotely may warrant investigation. Correlate it with the account's expected behavior, source information, other logon events, and any available endpoint or network telemetry.

Do not assume that an unfamiliar IP address automatically identifies an attacker. VPNs, NAT, remote administration tools, and shared infrastructure can complicate attribution.

Step 5: Look for Unexpected Account and Privilege Changes

Attackers who gain access to a Windows system may attempt to create accounts or change group membership. Administrators also perform these actions legitimately, so context matters.

Focus on events such as:

• 4720: A user account was created.
• 4728: A member was added to a security-enabled global group.
• 4732: A member was added to a security-enabled local group.
• 4672: Special privileges were assigned to a new logon.

Find account-creation events

Use this PowerShell command to search the last seven days:

$StartTime = (Get-Date).AddDays(-7)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4720
    StartTime = $StartTime
} | Select-Object TimeCreated, Id, Message |
    Format-List

Review the account that was created and the account responsible for the action, where those fields are available.

Investigate group-membership changes

To find additions to local or global security groups:

$StartTime = (Get-Date).AddDays(-7)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4728, 4732
    StartTime = $StartTime
} | Select-Object TimeCreated, Id, Message |
    Format-List

Check which account was added, which group was changed, who performed the action, and whether the change was authorized.

The significance of a group change depends on the group's permissions and role. A membership change involving a privileged group generally deserves closer scrutiny than one involving a routine group.

Remember that a missing event does not necessarily mean no change occurred. Relevant auditing must be enabled, and the event must still be available in the collected logs.

Step 6: Investigate Suspicious Process Execution

Event ID 4688 records process creation when the relevant auditing is enabled. It can help investigators identify programs launched during a suspicious session.

Useful fields may include:

• New process name.
• Creator process information.
• Account or security context.
• Process-related identifiers.
• Command-line information, if configured to be recorded.

For example, an unexpected script interpreter launched by an office application might deserve investigation. However, legitimate software also launches other processes, so the parent process and surrounding activity matter.

Search for process-creation events

$StartTime = (Get-Date).AddHours(-24)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4688
    StartTime = $StartTime
} | Select-Object TimeCreated, Id, Message |
    Format-List

Process-creation logging can generate substantial volume. For a large environment, use narrower time windows and more specific filters.

Command-line visibility matters: Event 4688 does not necessarily include the full command line by default. Additional audit policy configuration may be required. If command-line recording was not enabled when the event occurred, enabling it later will not retroactively populate older events.

If process evidence is incomplete, investigate related sources such as PowerShell logs, endpoint detection telemetry, application logs, and available process-monitoring records.

Step 7: Check Whether Security Logs Were Cleared

Event ID 1102 indicates that the Security audit log was cleared.

This event deserves attention because clearing logs can remove useful investigative history. However, legitimate administrative activity can also clear logs.

Search for it using:

$StartTime = (Get-Date).AddDays(-7)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 1102
    StartTime = $StartTime
} | Select-Object TimeCreated, Id, Message |
    Format-List

If an event appears, examine the timestamp and available subject information. Determine whether the action was expected and compare it with other logs.

Also consider whether other event logs were cleared. Event ID 104 from the System log can indicate that an event log was cleared.

If the local logs have been cleared, check whether copies exist in a central logging system, a SIEM, a Windows Event Forwarding collector, or an appropriately preserved .evtx export.

A cleared log is an important finding, but it does not by itself prove that an attacker was responsible.

Step 8: Build a Timeline by Correlating Events

Individual events provide limited context. Correlating multiple events can help reconstruct what happened.

Consider this hypothetical investigation scenario:

This sequence would justify further investigation, but it is not proof of a compromise. The events might be unrelated, generated by legitimate administration, or incomplete.

To evaluate the scenario:

1. Confirm that the events came from the relevant computer or log source.
2. Compare timestamps and account identifiers.
3. Examine source addresses and logon types where available.
4. Review process details and any available command-line information.
5. Determine whether the account and actions were authorized.
6. Correlate the findings with other logs and evidence.
7. Document what the evidence supports and what remains uncertain.

Use a consistent time zone when comparing records from different systems. Windows event timestamps, exported logs, and SIEM displays may use different time representations.

Step 9: Export Events for Further Examination

For forensic analysis or incident documentation, preserve relevant logs before they are overwritten or lost.

Export logs using Event Viewer

1. Open the relevant log in Event Viewer.
2. Right-click the log.
3. Select Save All Events As.
4. Choose the .evtx format when preserving the native event-log records.
5. Save the file to an appropriate evidence or case directory.

You can also export filtered events when you need a smaller subset for review. Keep the filtering criteria and retain broader relevant evidence where appropriate.

Read an exported EVTX file using PowerShell

Get-WinEvent -Path "C:\Evidence\Security.evtx" -MaxEvents 100 |
    Select-Object TimeCreated, Id, ProviderName, Message |
    Format-List

Replace the example path with the actual location of the exported file.

For a forensic examination, record the source computer, collection time, relevant time range, collection method, and any filters used. Calculate and document hashes according to your evidence-handling procedure.

Exporting a log preserves the records available at the time of export; it does not guarantee that the source system recorded every relevant event.

Common Problems and Limitations

Why Windows Event Logs are not the complete picture

Event logs are valuable evidence, but they have limitations:

• Logging may not have been enabled for the activity under investigation.
• Logs may have been overwritten, cleared, or modified.
• Some events may be stored on another computer, such as a domain controller.
• The recorded information may not include every detail needed to reconstruct an action.
• A single event may have several legitimate explanations.

For serious incidents, combine event-log analysis with other relevant evidence, such as endpoint telemetry, network records, file-system artifacts, windows artificats, and memory or disk examination where appropriate.

Frequently Asked Questions