UserLogonFailed2: CrowdStrike Failed Logon Event, SubStatus Decoded

What it records

UserLogonFailed2 is the Falcon sensor’s record of a failed sign-in on a Windows host; CrowdStrike’s published queries use it with event_platform=Win. It names the account in UserName, how the logon was attempted in LogonType, why it failed in SubStatus, and — for network and remote attempts — where it came from in RemoteAddressIP4. LocalAddressIP4 is the host’s own address, ContextTimeStamp when the attempt happened on the host, and ComputerName and aid which host refused it.

Both codes are numbers. LogonType uses Windows’s logon type values: 2 interactive, 3 network, 4 batch, 5 service, 7 unlock, 8 network cleartext, 10 remote interactive. SubStatus is the Windows NTSTATUS code written in decimal, which is why it looks like 3221225578. CrowdStrike’s own decoding table uses the values Microsoft documents for event 4625:

SubStatus (decimal)	Code	Meaning
3221225578	0xC000006A	The account exists, the password was wrong
3221225572	0xC0000064	No such account
3221226036	0xC0000234	The account is locked out
3221225586	0xC0000072	The account is disabled
3221225584	0xC0000070	Not allowed from this workstation
3221225582	0xC000006E	An account restriction applied

For any other value, paste the number into the error code lookup, which reads decimal NTSTATUS codes.

When it matters

• Brute force. Many 0xC000006A failures for one UserName from one RemoteAddressIP4 is password guessing (MITRE ATT&CK T1110.001). CrowdStrike’s own thresholding query starts at more than five failures per host, account, logon type and code.
• Password spraying. One source, many accounts, a few attempts each (T1110.003), usually with 0xC0000064 mixed in for names that do not exist.
• Lockouts. 0xC0000234 means the guessing already locked the account; the failures before it show where they came from.
• Remote desktop. Don’t rely on LogonType 10 alone: with Network Level Authentication, Windows checks the password before the remote-desktop session starts, and its own failed-logon events record such attempts as network logons (type 3).

How to investigate

1. Group failures by RemoteAddressIP4, UserName and SubStatus; check public sources against the IP blocklist checker.
2. Separate brute force (one account) from spraying (many accounts) and from a misconfigured service (one account, one internal address, steady rate around the clock).
3. Look for a UserLogon for the same account from the same address after the failures — that is the guess that worked.
4. On a domain controller, failures for many hosts’ users point at domain-wide spraying.

Failures per source, account and reason, with the reason converted to hex as CrowdStrike’s queries do:

#event_simpleName=UserLogonFailed2 event_platform=Win
| SubStatus_hex := format(field=SubStatus, "0x%x")
| groupBy([aid, ComputerName, RemoteAddressIP4, UserName, LogonType, SubStatus_hex], function=[count(as=Failures), min(ContextTimeStamp, as=FirstSeen), max(ContextTimeStamp, as=LastSeen)], limit=max)
| Failures > 5
| sort(Failures, order=desc)

Sources that tried more than ten accounts — spraying — leaving out private ranges:

#event_simpleName=UserLogonFailed2 RemoteAddressIP4=*
| !cidr(RemoteAddressIP4, subnet=["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8"])
| groupBy([RemoteAddressIP4], function=[count(as=Failures), count(UserName, distinct=true, as=Accounts), count(aid, distinct=true, as=Hosts)], limit=max)
| Accounts > 10
| sort(Accounts, order=desc)

The same over Falcon Data Replicator data in Splunk (add your index):

sourcetype="crowdstrike:events:sensor" event_simpleName=UserLogonFailed2
| eval SubStatusHex=tostring(tonumber(SubStatus), "hex")
| stats count AS Failures, dc(UserName) AS Accounts, values(SubStatusHex) AS SubStatuses by aid, RemoteAddressIP4, LogonType
| where Failures >= 10
| sort - Failures

The free log analyzer reads Falcon exports in the browser and flags bursts of failed logons per source address.