Windows Logon Events Cheat Sheet: Event IDs, Types and Failure Codes

Almost every Windows investigation comes back to the same question: who logged on, from where and how? This cheat sheet puts the event IDs, logon types and failure codes you need in one place, so that newer analysts can read an authentication alert with confidence and experienced ones have a quick reference on shift.

Which event IDs should you know?

All of these appear in the Windows Security log, provided the relevant audit policies are enabled. Keep in mind where each one is written, because a query against the wrong host type returns nothing and proves nothing.

What does each logon type mean?

The logon type tells you how the session was created, and it is usually the fastest way to judge whether a logon makes sense. The last column shows whether Microsoft lists the type as leaving reusable credentials in the LSA session. That matters when you assess what an attacker could steal from a host after an administrator has logged on to it.

What do the failure codes tell you?

In a 4625, Status gives the reason and SubStatus often gives the more precise one. Read the sub status first. If it is 0x0, fall back on the status. Most of these codes also appear as the Error Code in event 4776.

Kerberos result codes

Kerberos failures on domain controllers use different codes. You will see these in 4771, and 0x6 in 4768.

Which fields answer who, where and how?

Each question maps to a few fields. The names below are the Windows event names and, in brackets, the Microsoft Sentinel SecurityEvent columns.

Which patterns should you escalate?

These combinations come up regularly. None of them is proof on its own, so confirm each against what the account and host normally do.

Keep these queries to hand

Adjust the thresholds and time ranges to suit your environment. Splunk field names depend on how your Windows data is ingested, so check them first.

Microsoft Sentinel

SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4625
| where IpAddress !in ("-", "")
| summarize Attempts = count(),
            Users = dcount(TargetUserName),
            Hosts = dcount(Computer),
            Reasons = make_set(SubStatus, 5)
    by IpAddress
| where Users >= 10
| sort by Users desc

let lookback = 1h;
let failures = SecurityEvent
    | where TimeGenerated > ago(lookback)
    | where EventID == 4625
    | summarize Failures = count(), LastFailure = max(TimeGenerated)
        by TargetUserName, IpAddress
    | where Failures >= 5;
SecurityEvent
| where TimeGenerated > ago(lookback)
| where EventID == 4624
| where LogonType in (3, 10)
| project SuccessTime = TimeGenerated, TargetUserName, IpAddress, Computer,
          LogonType, AuthenticationPackageName
| join kind=inner failures on TargetUserName, IpAddress
| where SuccessTime > LastFailure
| project SuccessTime, TargetUserName, IpAddress, Computer, LogonType,
          AuthenticationPackageName, Failures

Microsoft Defender XDR

The DeviceLogonEvents table stores the logon type as text instead of a number, so check the values in your tenant if a filter returns nothing.

DeviceLogonEvents
| where Timestamp > ago(24h)
| where ActionType == "LogonSuccess"
| where LogonType == "RemoteInteractive"
| where RemoteIPType == "Public"
| project Timestamp, DeviceName, AccountDomain, AccountName, RemoteIP, Protocol
| sort by Timestamp desc

Splunk

index=wineventlog EventCode=4625 earliest=-1h
| stats count AS attempts dc(user) AS users values(Sub_Status) AS sub_status BY src
| where users>=10
| sort - users

PowerShell on a single host

Use this when the host is not sending logs to your SIEM. Reading the Security log needs elevated rights.

$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddHours(-24)
} -MaxEvents 200 -ErrorAction SilentlyContinue

foreach ($e in $events) {
    $xml = [xml]$e.ToXml()
    $d = @{}
    foreach ($n in $xml.Event.EventData.Data) { $d[$n.Name] = $n.'#text' }
    [pscustomobject]@{
        Time      = $e.TimeCreated
        User      = $d['TargetUserName']
        LogonType = $d['LogonType']
        Status    = $d['Status']
        SubStatus = $d['SubStatus']
        Source    = $d['IpAddress']
    }
}

Key takeaways

Bookmark this page, and test the queries against your own data while things are quiet. Knowing how normal logons look in your estate, including which accounts use which logon types, is what makes the odd one stand out when an alert arrives.