4624 An account was successfully logged on

The record of a successful authentication, written when a logon session (the span from when a user starts using a machine until they finish) is created on the destination host. It is by far the most common event in the Windows Security log, so without a clear way to read it, the signal drowns in noise.

Overview

The subcategory is Audit Logon. The event is generated on the machine that was accessed, where the session was created, not on the device the person is sitting at. Who logged on, from where, and by what method is read from the combination of LogonType (the kind of logon), AuthenticationPackageName (the authentication method), and IpAddress (the source IP). Newer builds (Windows 10 and later) added fields such as ElevatedToken (whether the session runs with administrator rights), which help describe privilege elevation and remote administration.

How it is triggered

The “kind” of logon appears in the LogonType number, and that is the starting point of any investigation. The values seen most often in practice are:

• 2 Interactive: signing in directly at the machine’s console.
• 3 Network: access over the network, such as SMB (Windows file sharing), PsExec (a tool that runs commands on a remote host), or WinRM (Windows remote management).
• 10 RemoteInteractive: remote operation over RDP (Remote Desktop).
• 5 Service: a background OS program (a service) started.
• 9 NewCredentials: the current logon stays as is, but a different account is used only for outbound connections (equivalent to runas /netonly).

In steady state, most entries are automatic logons where SubjectUserSid (the SID of the reporting account) is S-1-5-18, the built-in SYSTEM account (an internal OS account, not a person). Human and remote logons are recorded amid this volume of automatic activity, so the noise filtering and correlation (cross-checking several logs) described below are prerequisites.

Security review points

Post-intrusion lateral movement (spreading the compromise from the first machine to others on the network) and the abuse of stolen credentials are the main things this event reveals.

• Spread of network logons: if a single account logs on to several hosts with LogonType 3 in a short window, suspect lateral movement over file sharing or remote management. A service account (an account for programs, not people) that usually runs a fixed task but suddenly logs on with LogonType 3 from an unfamiliar source also deserves attention.
• NTLM network logons: LogonType 3 together with AuthenticationPackageName of NTLM (the older Windows authentication protocol) is the classic landing point for pass-the-hash (an attack that authenticates using a stolen password hash, without ever knowing the plaintext password). Review it alongside 4776 on the same machine and 5140 for share access.
• LogonType 9 (NewCredentials): a 4624 with LogonProcessName of seclogo and AuthenticationPackageName of Negotiate matches the behavior of overpass-the-hash (an evolution of pass-the-hash) produced by Mimikatz (a well-known credential-theft tool). Correlate it with 4648, which marks the explicit use of another account’s credentials.
• Privilege and target: combine ElevatedToken set to Yes (an elevated administrator session) and 4672 (special privileges assigned) to track high-privilege accounts. Kerberos (the default Windows authentication protocol) ticket requests 4768 / 4769 can be tied to this event through LogonGuid (an identifier assigned to the logon).
• Contextual anomalies: logons outside business hours, unexpected source IPs, and success on accounts that should never be used (disabled or guest accounts) are worth investigating even on their own.

Notes for log review

Used as-is in a detection rule, this event produces a mountain of false positives (alerts that fire when nothing is actually wrong), so understand the sources of noise first.

• DWM-* (the internal process that draws the screen), UMFD-* (the internal font process), and SYSTEM automatic logons appear in huge numbers. The standard practice is to put them on an exclusion list and drop them up front.
• An IpAddress of ::1 or 127.0.0.1 means a logon from the machine itself (the loopback address); distinguish it from external remote access.
• A blank source field is not necessarily an anomaly; it is by design. Kerberos network logons often leave the workstation name empty, and NTLM does not carry the IP or port details. Only what LSASS (the core Windows process that handles authentication) received from the authenticating service is recorded.
• Domain controllers (the servers that handle authentication for the whole network) and file servers generate enormous volumes. Do not judge on a single 4624; accuracy comes only when you chain multiple events over time, for example “logon from an unfamiliar IP, then access to sensitive files within a few minutes.”
• Know the “normal combinations” of account, source, and logon type in advance (baselining) and watch for deviations from them. This is the practical approach.

Key fields

Glossary

• SID — a unique identification number assigned to each account or group. It pays to memorize common values such as S-1-5-18 for SYSTEM.
• Service account — an account created to run programs or services, rather than for a person to use.
• Correlation — cross-checking several logs to reconstruct a sequence of activity that a single event cannot show.
• Baseline — recording the normal state in advance and using it as the reference for anomaly detection.

References

• Microsoft Learn: 4624(S) An account was successfully logged on.
• Ultimate Windows Security: Event ID 4624
• SigmaHQ: Successful Overpass the Hash (logon type 9)
• CyberArk: Detecting Pass-the-Hash with Windows Event Viewer