Event 4624 sits in the Audit Logon subcategory of the Windows Security audit policy, under Advanced Audit Policy Configuration > Logon/Logoff. It writes to the Security channel on the machine that was accessed, the destination side of the logon, not the source. Every time Local Security Authority Subsystem Service (LSASS) finishes building a logon session and issues an access token, this event fires.
That covers a wide range of triggers: a user typing a password at a physical console, a domain controller validating a Kerberos ticket for a network share request, Task Scheduler running a job under a service account, the Service Control Manager starting a Windows service, an RDP client completing its handshake, or a workstation unlocking after being locked. All of these produce the same event ID with the same base schema; the field that separates them is Logon Type, a small integer carried in the Logon Information section.
The subject fields (Subject Security ID, Subject Account Name, Subject Account Domain, Subject Logon ID) describe who or what reported the logon, which for most interactive and network logons is the SYSTEM account itself, since LSASS is the process actually creating the session. The Microsoft documentation calls this out directly: if Subject Security ID is not SYSTEM, that is worth a second look, because it usually means a non-standard logon path is in play.
The New Logon block (Security ID, Account Name, Account Domain, Logon ID, Linked Logon ID) is where the actual identity that received access lives, and Logon ID here is the value every other Security event for that session will carry, letting an analyst pivot from the logon straight into everything that account did before its matching 4634 logoff.
Network Information (Workstation Name, Source Network Address, Source Port) tells you where the logon came from, but this section is inconsistently populated: Kerberos-authenticated network logons frequently leave Workstation Name blank because Kerberos doesn't carry that data the way NTLM does, and purely local interactive logons show 127.0.0.1 or a blank source address rather than a real network origin.
Detailed Authentication Information carries Logon Process (the trusted component that handled the logon, commonly User32 for interactive sessions, Kerberos or NtLmSsp for network ones) and Authentication Package Name, which resolves to NTLM, Kerberos, or Negotiate. Negotiate is not a protocol itself, it's the Windows SSPI layer that picks Kerberos when it's available and falls back to NTLM otherwise, so a Negotiate entry with an actual NTLM sub-package populated in Package Name (NTLM only) tells you Kerberos wasn't used for that session even on a domain-joined host, which matters in a Kerberoasting or NTLM-relay investigation.
Since Windows 10 the event also carries Restricted Admin Mode (only meaningful on Logon Type 10, flags whether the RDP session avoided placing cleartext-derivable credentials on the target), Virtual Account (Yes/No, flags Managed Service Accounts and similar), and Elevated Token (Yes/No, flags whether the resulting session carries administrative rights, distinct from the account merely being an administrator).
A SOC sees 4624 constantly: it is one of the highest-volume events in any Security log, often outnumbering nearly every other audit category combined on a busy domain controller, because every file share access, every scheduled task tick, and every service restart produces one. That volume is exactly why the event is filed under noise-management concerns as much as detection concerns; most SIEM onboarding work for Windows starts with figuring out how to keep 4624 without drowning the pipeline in it.
The event pairs tightly with 4625 (failed logon, same schema minus the New Logon success fields, plus a Status/Sub Status failure code) and with 4634/4647 (logoff, closes out the Logon ID lifecycle a 4624 opens). It's also frequently read alongside 4648, which logs a logon attempted with explicit credentials, a pattern that shows up when a user runs an application as a different account and that separate logon subsequently produces its own 4624 with a distinct Logon ID.
Attacker activity lights this event up in a few recognizable shapes. Lateral movement with stolen or harvested credentials produces a 4624 with Logon Type 3 (Network) from the pivot host, usually paired with NTLM authentication when Kerberos delegation isn't available to the attacker. Pass-the-hash tooling authenticates against a target using only the NTLM hash, without ever needing the plaintext password, and the resulting 4624 typically shows Logon Type 3, Authentication Package NTLM, and a Logon Process of NtLmSsp or the tool's own registered process name rather than a standard Windows component.
Remote access via compromised RDP credentials produces Logon Type 10 from a Source Network Address that, on a well-scoped internal network, has no business reaching that host directly, or from a public IP entirely if RDP is directly exposed. Credential-pivoting after a local compromise, where an attacker who only has local rights on a box wants to reach domain resources with credentials obtained elsewhere, produces Logon Type 9 (NewCredentials), the same signature runas /netonly generates for legitimate administrative use, which is precisely what makes it worth separating carefully rather than ignoring.
