Investigate Windows Sign-In and Account Activity

Windows Security events help answer who authenticated, where, and how. This guide reviews event IDs 4624 (successful logon), 4625 (failed logon), 4740 (account locked out), and 4672 (special privileges assigned to a new logon).

Start with a bounded time range and the right computer. Events 4624 and 4625 are normally reviewed on the computer where the logon was attempted. For a domain account lockout, event 4740 is commonly investigated on a domain controller. Event availability depends on audit policy, log retention, and successful event collection.

Security log: Review the selected failed logon alongside nearby successful events and its source details.

---

Step 1: Set Scope and Confirm You Can Read the Security Log

01

Choose the Host, Account, and Time Window

Preparation

Record the alert or case ID, target account, affected host, and time range in UTC. Query the endpoint that received the logon; include the relevant domain controllers when investigating a domain lockout or authentication path. Run an approved elevated PowerShell session if access to the Security log requires it. Do not change audit policy during an investigation without change approval.

$startUtc = [DateTime]::UtcNow.AddHours(-4)
$endUtc = [DateTime]::UtcNow
# Convert the UTC case boundaries to local DateTime values for the event-log filter.
$start = $startUtc.ToLocalTime()
$end = $endUtc.ToLocalTime()
$eventIds = @(4624, 4625, 4672, 4740)

Get-WinEvent -ListLog Security |
  Select-Object LogName, IsEnabled, RecordCount, MaximumSizeInBytes

❯ View Expected Console Output

LogName  IsEnabled RecordCount MaximumSizeInBytes
-------  --------- ----------- ------------------
Security      True       18342          209715200

---

Step 2: Query Only the Relevant Events

02

Filter the Security Log by ID and Time

Event Collection

Use FilterHashtable so Windows filters the Security log before PowerShell formats the results. A limited time window and event-ID list are faster and easier to review than exporting the entire log. Keep the limit visible; if the result reaches it, narrow the time range or repeat the query in smaller windows.

$events = Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = $eventIds
  StartTime = $start
  EndTime   = $end
} -MaxEvents 2000 -ErrorAction Stop

$events |
  Select-Object @{Name='TimeCreatedUtc'; Expression={
      $_.TimeCreated.ToUniversalTime().ToString('o')
    }}, Id, MachineName, RecordId, ProviderName, Message |
  Format-List

❯ View Expected Console Output

TimeCreatedUtc : 2026-10-05T09:22:18.0000000Z
Id             : 4625
MachineName    : WS-042
RecordId       : 18341
ProviderName   : Microsoft-Windows-Security-Auditing
Message        : An account failed to log on. ...

---

Step 3: Read the Fields That Explain the Event

03

Inspect the Event Details, Not Just Its ID

Field Review

In Event Viewer, open Windows Logs → Security, select the event, and review its General and Details views. In PowerShell, the Message field shows the rendered event. Preserve the original event and record ID when exporting so another analyst can return to the source record.

$events |
  Sort-Object TimeCreated |
  Select-Object @{Name='TimeCreatedUtc'; Expression={
      $_.TimeCreated.ToUniversalTime().ToString('o')
    }}, Id, RecordId, Message |
  Export-Csv -NoTypeInformation -Path '.\signin-review.csv'

❯ View Expected Console Output

signin-review.csv

Includes the timestamp, event ID, original record ID, and rendered
message for each result in the selected time range.

---

Step 4: Interpret the Events in Context

04

Use the Event Fields to Form a Working Timeline

Analysis

Compare the account, logon type, source address or workstation, status, and related logon ID. A successful logon is not automatically interactive or suspicious. A privileged-logon event may be normal for built-in service accounts. Validate unusual activity against the host role, account owner, approved access path, and expected working pattern.

4624  Successful logon. Review New Logon, Logon Type, source details,
      and Logon ID.
4625  Failed logon. Review target account, source, Logon Type, Status,
      and Sub Status.
4740  Account lockout. Review the locked account and Caller Computer
      Name; investigate on the relevant domain controller.
4672  Special privileges assigned to a new logon. Review the account,
      privilege list, and matching logon ID.

Common 4624 Logon Types:
2 = Interactive at the computer
3 = Network access to the computer
5 = Service
7 = Workstation unlock
10 = RemoteInteractive, commonly Remote Desktop

❯ View Expected Console Output

Example: A type 3 logon to a file server is a network logon; it does
not by itself prove that a user sat at that server.

---

Step 5: Correlate, Scope, and Record the Result

05

Check Neighboring Hosts and Related Events

Correlation

For a domain account, compare the target endpoint’s logon events with domain-controller records in the same UTC window. Correlate 4672 with a nearby 4624 on the same computer using the logon ID when available. For 4740, check the caller computer and nearby failures across the account’s normal devices. Missing source address or workstation fields can be normal for some authentication paths.

Document:
- Computer and log source queried
- Exact start and end time, expressed in UTC
- Event ID and record ID for each important event
- Account, logon type, source, status, and related logon ID
- What expected activity or change record was checked
- What remains unknown and who owns the next action

❯ View Expected Console Output

Finding: Three failed network logons preceded a successful type 3
logon from an approved management host. Source records and the
maintenance ticket are linked. No containment action was taken.

Do not treat a single event as a verdict

Repeated failures may come from a stale service password, scheduled task, or a user device. A 4672 event is not proof of abuse, and 4740 may identify a caller computer rather than a network address. Correlate with identity, endpoint, and change records before assigning intent.

When the query returns no events

Check the selected computer, time range, permissions, audit policy, log retention, and event forwarding health. An empty result means the query returned no retained matching events; it does not establish that no sign-in activity occurred.

References

Microsoft: Event 4624 · Event 4625 · Event 4740 · Event 4672 · PowerShell Get-WinEvent filtering