Event ID 4624: An Account Was Successfully Logged On — Reading Logon Type

What it records

Event 4624 is Windows recording that a logon session was created. Microsoft’s description is precise about where to look for it: “This event generates when a logon session is created (on destination machine). It generates on the computer that was accessed, where the session was created.” A successful RDP connection to a jump box is logged on the jump box; a file-share access is logged on the file server, not on the client and not on the domain controller.

The field that decides how you read everything else is Logon Type. Microsoft’s table gives 2 Interactive (“A user logged on to this computer”), 3 Network (“A user or computer logged on to this computer from the network”), 4 Batch, 5 Service (“The Service Control Manager started a service”), 7 Unlock, 8 NetworkCleartext, 9 NewCredentials (“A caller cloned its current token and specified new credentials for outbound connections”), 10 RemoteInteractive (“A user logged on to this computer remotely using Terminal Services or Remote Desktop”), 11 CachedInteractive, 12 CachedRemoteInteractive and 13 CachedUnlock.

Around it, the Subject section names the account that reported or invoked the logon, and the New Logon section names the account the session belongs to, with its Security ID, Account Name, Account Domain and Logon ID. Linked Logon ID gives the paired session, or 0x0 when there is none. Elevated Token is a Yes/No flag; if “Yes”, “the session this event represents is elevated and has administrator privileges”. Restricted Admin Mode is only populated for RemoteInteractive logons.

Network and authentication detail fills in the rest: Workstation Name, Source Network Address, Source Port (0 for interactive logons), Logon Process, Authentication Package, Package Name (NTLM only), which Microsoft populates only when the package is NTLM, and Transited Services, which is Kerberos-only and populated “if the logon was a result of a S4U (Service For User) logon process”.

When it matters

4624 is high-volume and mostly benign, so severity comes from which account, from where, and by what route.

Pattern	Reading
4624 from a source that just produced a run of 4625 failures	Successful guess — see 0xC000006A on the preceding failures
Logon Type 10 for an admin account from an unfamiliar address	Interactive remote access by someone who should not have it
Logon Type 3 for one account across many servers in minutes	Lateral movement using valid credentials
Logon for a disabled, guest or dormant account	Microsoft’s recommendation covers accounts “that should never be used”
Logon outside working hours for a high-value account	Microsoft’s anomaly recommendation: monitoring “for use of an account outside of working hours”
Elevated Token “Yes” plus a matching 4672	The session holds administrator privileges on that host

Microsoft’s monitoring guidance for this event is built around the New Logon Security ID: watch it for high-value accounts such as domain administrators, service accounts and domain controller accounts; watch it against an allowlist of accounts permitted to perform an action; and check that account types match the logon — a domain administrator arriving as a batch or service logon is the example given.

How to investigate

Start with the remote logon types and ask which identities reached which hosts from which address:

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4624
| where LogonType in (3, 10)
| where TargetUserName !endswith "$"
| summarize Logons = count(), Hosts = dcount(Computer), HostList = make_set(Computer, 20),
            Types = make_set(LogonType, 5), Packages = make_set(AuthenticationPackageName, 5)
    by TargetUserName, IpAddress
| order by Hosts desc, Logons desc

One account touching many servers from one address inside a short window is the lateral-movement shape; one server touched by many accounts from one address is more often a scripted sweep.

Next, surface only the sessions that came with privileges, by joining the session’s Logon ID to 4672:

let privileged = SecurityEvent
    | where TimeGenerated > ago(24h) and EventID == 4672
    | project SubjectLogonId, PrivTime = TimeGenerated;
SecurityEvent
| where TimeGenerated > ago(24h) and EventID == 4624
| join kind=inner privileged on $left.TargetLogonId == $right.SubjectLogonId
| project TimeGenerated, Computer, TargetUserName, TargetDomainName, LogonType, IpAddress,
          WorkstationName, LogonProcessName, AuthenticationPackageName, ElevatedToken, TargetLogonId
| order by TimeGenerated desc

Then test novelty — an account logging on from a source it has never used before is the cheapest anomaly you can compute:

let seen = SecurityEvent
    | where TimeGenerated between (ago(30d) .. ago(1d))
    | where EventID == 4624
    | distinct TargetUserName, IpAddress;
SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4624 and LogonType in (3, 10)
| join kind=leftanti seen on TargetUserName, IpAddress
| project TimeGenerated, Computer, TargetUserName, IpAddress, LogonType,
          AuthenticationPackageName, LogonProcessName, WorkstationName
| order by TimeGenerated asc

When one of these looks wrong, pivot on the Logon ID: 4672 for privileges, 4648 for onward use of explicit credentials from that session, 4688 for processes it started, and 4634 or 4647 for when it ended. On the domain controller side, the same authentication appears as 4768 and 4769 for Kerberos or 4776 for NTLM validation, which tells you which DC issued the credential. If the 4624 followed a burst of failures, work the failures too — the Windows 4625 password-spray rule covers that grouping. Without a SIEM, export the Security log as XML from Event Viewer and load it into the free browser log analyzer.