Agent Foskett Academy • Lesson 37 • Investigating IdentityLogonEvents

Investigating IdentityLogonEvents in Microsoft Defender XDR

IdentityLogonEvents records authentication activity associated with accounts and devices protected by Microsoft Defender XDR and Microsoft Defender for Identity.

This table helps defenders investigate successful logons, failed logons, account access patterns, source IP addresses, protocols, destination devices and suspicious authentication behaviour.

In this lesson, you will learn how to use IdentityLogonEvents to follow identity evidence, review logon activity and support Microsoft Defender XDR investigations.

Start Lesson 37 Back to Academy

Agent Foskett Academy lesson explaining IdentityLogonEvents in Microsoft Defender XDR

Lesson overview

Learn how IdentityLogonEvents helps defenders investigate authentication activity, suspicious account access and identity-based attack patterns.

Review successful and failed logons

Investigate source IP and device context

Correlate identity evidence with endpoint activity

Why IdentityLogonEvents matters

Many investigations start with a simple question: who logged in, from where, and did the activity make sense?

Identity activity leaves evidenceSuccessful and failed logons can reveal account misuse, password spraying, suspicious access and unusual authentication behaviour.

Context changes the meaningA logon may look normal until you review the source IP address, protocol, destination device, timestamp and account involved.

Authentication is part of the timelineIdentityLogonEvents helps connect account access to endpoint, process, file, registry and network activity.

Investigation scenario

A user reports they were locked out. The helpdesk resets the password. But the failed logons continue, and one successful logon appears from a device the user does not recognise.

The account was noisyRepeated failures appeared before the successful logon. That pattern changed the investigation from helpdesk issue to security review.

The timestamp matteredThe successful logon happened outside normal user activity hours, from a source that did not fit the user’s normal pattern.

The next step was correlationThe logon became the starting point for checking device activity, process execution and network connections after access was granted.

Step 1 — Review recent identity logons

Start broad. Review recent logon activity and keep the core investigation fields visible.

IdentityLogonEvents
| where Timestamp > ago(7d)
| project Timestamp, ActionType, AccountName,
          AccountDomain, DeviceName, LogonType,
          Protocol, IPAddress, FailureReason
| order by Timestamp desc

Step 2 — Focus on one account

Once an account becomes interesting, narrow the investigation to that user and review the surrounding authentication activity.

IdentityLogonEvents
| where Timestamp > ago(14d)
| where AccountName =~ "rebecca"
| project Timestamp, ActionType, AccountName,
          DeviceName, IPAddress, LogonType,
          Protocol, FailureReason
| order by Timestamp asc

Step 3 — Identify repeated failures

Repeated failed logons can indicate password spraying, brute force attempts, stale credentials, service account issues or active attacker activity.

IdentityLogonEvents
| where Timestamp > ago(24h)
| where ActionType has "LogonFailed"
| summarize FailedAttempts = count()
          by AccountName, IPAddress, DeviceName, FailureReason
| order by FailedAttempts desc

Step 4 — Review successful logons after failures

A successful logon after many failures can be more important than the failures themselves.

IdentityLogonEvents
| where Timestamp > ago(7d)
| where ActionType has_any ("LogonSuccess", "LogonFailed")
| project Timestamp, ActionType, AccountName,
          DeviceName, IPAddress, LogonType, Protocol
| order by AccountName asc, Timestamp asc

Step 5 — Summarise by account and source IP

Summarising identity activity helps reveal high-volume sources, noisy accounts and suspicious access patterns.

IdentityLogonEvents
| where Timestamp > ago(7d)
| summarize LogonEvents = count(),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
          by AccountName, IPAddress, LogonType
| order by LogonEvents desc

Step 6 — Correlate with endpoint activity

After a suspicious identity event, look at what the device did next.

let SuspiciousDevice = "WORKSTATION-07";
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ SuspiciousDevice
| project Timestamp, DeviceName, FileName,
          ProcessCommandLine, InitiatingProcessFileName,
          AccountName
| order by Timestamp asc

Common investigation uses

IdentityLogonEvents becomes powerful when it is treated as a timeline source, not just a list of logons.

Password sprayingLook for repeated failures across many accounts from a small number of sources.

Suspicious successful accessReview successful logons from unfamiliar IP addresses, unexpected devices or unusual protocols.

Post-authentication behaviourUse the logon event as a pivot into process, file, network and registry telemetry.

Common mistakes

Identity investigations can go wrong when successful authentication is treated as proof of safe activity.

Only reviewing failuresFailed logons matter, but the successful logon after the failures may be the real compromise event.

Ignoring protocol and device contextThe account name alone is not enough. Review how the logon happened and where it landed.

Stopping at the loginThe login is often the beginning of the incident. Always ask what happened after access was granted.

What you learned

IdentityLogonEvents records authentication evidenceYou can use it to investigate successful logons, failed logons, source IP addresses, protocols and device context.

Context mattersA successful logon may still be suspicious depending on the account, location, device, protocol and timing.

Identity evidence should be correlatedFollow suspicious logons into DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents and other Microsoft Defender XDR telemetry.

Related Agent Foskett Academy lessons

Building Investigation Timelines Connect authentication activity, endpoint events and cloud evidence into a single investigation timeline.

Investigating DeviceProcessEvents Follow suspicious process execution after a successful sign-in.

Investigating DeviceNetworkEvents Review outbound connections and network activity following authentication events.

Investigating DeviceRegistryEvents Examine registry modifications and persistence mechanisms associated with compromised accounts.

Connecting Tables with join Combine authentication evidence with endpoint and email telemetry.

Using let Statements to Reuse Evidence Store users, devices and indicators for reuse across investigations.

Final thought

A login event is not just a technical record. It is a statement that access was attempted or granted. The investigator’s job is to decide whether that access made sense.

Agent Foskett mindsetDo not stop at “the login succeeded.” Ask whether the account, device, source, protocol and timing belonged together.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD