Windows Logons

Windows logon events are evidence of authentication and session creation. They are not proof that a person was physically present, that the activity was interactive, or that the source address identifies the initiating endpoint. Services, scheduled tasks, remote administration, cached credentials, and authentication intermediaries all leave different shapes.

Core events

Event availability depends on audit policy, operating-system version, forwarding configuration, and parser quality.

Logon types

The name NetworkCleartext is easy to overread. Microsoft documents that the password is passed to the authentication package in an unhashed form; the event does not prove cleartext network transport.

References: Event 4624 and logon types , Event 4625 , Event 4776 , and administrative logon types and credential exposure

Fields worth preserving

A logon identifier is meaningful on the computer that issued it. Pair it with the device and use a tight time window; do not join unrelated hosts on LogonId alone.

Hunt patterns

Failed attempts followed by success

Group failures by target account, source, destination, and logon type. Then ask whether a success followed from the same source, or whether the source shifted. A password reset, unlocked account, mistyped password, service restart, or adversary can all produce this sequence.

A service identity used interactively

Look for service or application accounts using types 2 or 10, or appearing on user workstations. Validate how the account is designed, whether an operator used it for troubleshooting, and what executed inside the session.

Rare Remote Desktop paths

A new source-to-destination pair can be more useful than raw RDP volume. Add identity, asset role, working hours, connection broker behaviour, privileged-session tooling, and 4778/4779 session events.

Network-logon fan-out

One source producing type 3 logons to many systems may reflect administration, inventory, backup, vulnerability scanning, malware, or share enumeration. Compare destination count, rate, share access, remote service creation, process ancestry, and the source asset’s role.

NTLM where Kerberos is expected

NTLM can be caused by IP-based access, local accounts, workgroups, legacy software, name-resolution failures, or adversary activity. Treat it as an environmental question first, then narrow to new identities, systems, and paths.

Explicit credentials near remote activity

Correlate 4648 with process creation, outbound network activity, 4624 on the destination, service or task creation, and share access. The absence of 4648 does not prove credentials were not used.

A starting Kusto query

This example keeps enough dimensions to expose different behaviours instead of collapsing all failures into one account count.

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| summarize Failures=count(),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated),
            Statuses=make_set(strcat(Status, "/", SubStatus), 10)
    by TargetAccount, Computer, IpAddress, LogonType
| where Failures >= 10
| order by Failures desc

Before operational use:

• Inspect raw events for the highest groups.
• Confirm whether IpAddress is an endpoint, proxy, broker, or missing value.
• Split expected machine and service-account patterns from human accounts.
• Test whether collection gaps create apparent “failure without success” sequences.
• Decide whether the entity is the account, source, destination, or a relationship between them.

Investigation workflow

1. Establish the viewpoint and timestamp of the event.
2. Identify the target identity and logon type.
3. Resolve the source cautiously; include NAT, jump hosts, gateways, and brokers.
4. Correlate the local logon ID with privilege and process events.
5. Correlate Kerberos activity with 4768, 4769, and domain-related 4771 events from the domain controller’s perspective. Correlate NTLM credential validation with relevant 4776 events from the authoritative system.
6. Follow the session into execution, network, service, task, share, and file telemetry.
7. Compare the relationship with historical behaviour and asset purpose.
8. Document what the events prove, what they suggest, and what telemetry is absent.

Revision