Event ID 4624: Windows Logon Types Explained

Windows Event ID 4624 means "An account was successfully logged on": Windows created a new logon session on the computer that was accessed. The Logon Type field tells you how it happened, for example 2 for someone at the keyboard, 3 for a network logon such as a file share, and 10 for Remote Desktop.

4624 is the most common event in most Security logs, so people learn to scroll past it. Once you can read the logon type, the source address and the Logon ID, a wall of 4624s turns into a timeline of who got in, from where, and what they did next. This post covers every logon type, the fields worth reading, Logon ID correlation and failed logons (4625). For the wider list of IDs, see our Windows Event Log IDs cheat sheet.

Where is Event ID 4624 logged?

4624 is written to the Security log (Microsoft-Windows-Security-Auditing provider) by the Audit Logon subcategory, under Security Settings > Advanced Audit Policy Configuration > Logon/Logoff. Microsoft recommends auditing both success and failure for it on domain controllers, member servers and workstations.

The key detail: the event is logged on the computer that was accessed, not the one the user sat at. Microsoft's own example: for a network logon such as opening a share, the event is generated on the computer that hosts the share. So if ws-fin-01 maps a drive on fs-01, you look for the 4624 on fs-01.

What are the Windows logon types?

This is the full table from Microsoft's 4624 documentation, with a note on what each one usually means in an investigation.

The examples in the last column come from Microsoft's "Administrative tools and logon types" reference. Two things worth knowing from it. First, PsExec with explicit credentials creates more than one session (Network plus Interactive), so one remote command can leave several 4624s. Second, types 2, 4, 5, 8, 9 and 10 leave reusable credentials in memory on the destination, while a plain type 3 logon does not. That is why admins RDP-ing into workstations is a credential-theft risk and an admin mapping a drive is not.

Which 4624 fields matter?

Microsoft added several fields in event version 2 (Windows 10). These are the ones you will read most:

A trap Microsoft calls out: address and workstation fields are only as good as what the protocol shares. Kerberos network logons often have no workstation name, and NTLM logons often have no IP details. A blank IpAddress is not suspicious by itself.

Another trap: the Subject is the account that reported the logon, usually SYSTEM. The person who logged on is under New Logon.

How do you correlate 4624 with 4634, 4647 and 4672?

The Logon ID is a hex number (for example 0x8dcdc) that names one session on one machine. Every event from that session carries it, so it is your join key. Microsoft notes that Logon IDs are only unique between reboots on the same computer, so always join on host and Logon ID together.

• 4672, Special privileges assigned to new logon. Logged when the new session receives sensitive privileges such as SeDebugPrivilege, SeBackupPrivilege or SeTcbPrivilege. Its Subject Logon ID matches the 4624's New Logon ID, so a 4624 followed by a 4672 with the same ID means an admin-capable session. Every SYSTEM logon also triggers it, so filter out SYSTEM, LOCAL SERVICE and NETWORK SERVICE before you hunt.
• 4647, User initiated logoff. The user chose to log off. Microsoft says it is most typical for Interactive and RemoteInteractive sessions.
• 4634, An account was logged off. The session was terminated and no longer exists. After a user-initiated logoff you will usually see both 4647 and 4634.

Put together, one RDP session looks like this on the target:

4624  LogonType=10  TargetUserName=jsmith  TargetLogonId=0x3A1F2C  IpAddress=10.20.4.17
4672  SubjectUserName=jsmith  SubjectLogonId=0x3A1F2C  PrivilegeList=SeDebugPrivilege ...
4647  TargetUserName=jsmith  TargetLogonId=0x3A1F2C
4634  TargetUserName=jsmith  TargetLogonId=0x3A1F2C  LogonType=10

Session length is the time between the 4624 and the 4634. And because 4688 process creation events carry the same Logon ID, you can list every process that ran inside the session. See Event ID 4688 for that half.

How do failed logons (4625) relate to 4624?

Event ID 4625 is "An account failed to log on". It is logged on the computer where the attempt was made, uses the same logon type values, and has the same network and authentication fields, plus a Failure Information section. It is generated by the Audit Logon and Audit Account Lockout subcategories.

The fields that turn a failure into a story are Status and Sub Status. Microsoft's monitoring list includes:

The pattern that matters is a 4625 burst followed by a 4624: many failures, then a success for the same account from the same source. That is a guess that worked.

What does attacker activity look like in 4624?

• Password spraying and guessing (T1110.003, T1110.001). Spraying is one source, many accounts, a few tries each, usually 0xC000006A and 0xC0000064. Guessing is one account hammered from one source. Either way, the 4624 that follows is the alert.
• Valid accounts (T1078). A successful logon with stolen credentials looks normal. You catch it on context: a type 10 from an IP that has never connected before, a service account logging on interactively, a disabled account suddenly active.
• RDP lateral movement (T1021.001). Type 10 logons between workstations, or from a workstation to a server it never talks to.
• SMB and admin shares (T1021.002). Type 3 logons from one internal host to many others in a short window, often followed by service installs (7045) on the targets.
• Pass the hash (T1550.002). MITRE's analytic looks for NTLM type 3 logons that lack the matching domain logon activity. On the 4624, that means AuthenticationPackageName=NTLM where you expect Kerberos.
• Wrong type for the account. Microsoft suggests alerting when a domain admin shows up on a type 4 (Batch) or type 5 (Service) logon.

How do you search for 4624 in Splunk and KQL?

The Splunk searches assume the Splunk Add-on for Microsoft Windows with classic (non-XML) event rendering, which gives you fields such as EventCode, Logon_Type, Account_Name and Source_Network_Address. In that format Account_Name holds both the Subject and the New Logon names, so check you are reading the second one.

Failures followed by a success (Splunk)

source="WinEventLog:Security" (EventCode=4625 OR EventCode=4624) Logon_Type IN (3, 10)
| eval outcome=if(EventCode=4624, "success", "failure")
| stats count(eval(outcome="failure")) AS failures count(eval(outcome="success")) AS successes dc(Account_Name) AS accounts BY Source_Network_Address
| where failures > 20 AND successes > 0
| sort - failures

Failures followed by a success (KQL, Sentinel)

SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID in (4624, 4625) and LogonType in (3, 10)
| summarize failures = countif(EventID == 4625), successes = countif(EventID == 4624),
            accounts = dcount(TargetUserName) by IpAddress
| where failures > 20 and successes > 0
| order by failures desc

Admin-capable sessions (KQL)

let logons = SecurityEvent
| where EventID == 4624 and LogonType in (3, 10)
| project TimeGenerated, Computer, TargetUserName, IpAddress, LogonId = TargetLogonId;
SecurityEvent
| where EventID == 4672
| where SubjectUserName !in ("SYSTEM", "LOCAL SERVICE", "NETWORK SERVICE")
| project Computer, LogonId = SubjectLogonId, PrivilegeList
| join kind=inner logons on Computer, LogonId
| project TimeGenerated, Computer, TargetUserName, IpAddress, PrivilegeList

Tune the thresholds to your environment. Twenty failures is a starting point, not a rule.

What are the common false positives?

• Service accounts and scanners. Backup agents, monitoring tools and vulnerability scanners create piles of type 3 and type 5 logons.
• Stale passwords. A user changes their password and an old mapped drive or phone keeps retrying. That is a steady drip of 0xC000006A from one device, not a spray.
• Machine accounts. Names ending in $ are computers. They log on to domain controllers constantly.
• Admins doing admin work. A help desk RDP session is normal. Ask whether this admin usually connects to this machine from this address.

The best filter is history: a type 10 from a source seen every weekday for a year is boring; the same logon from a new source at 03:00 is not.

FAQ

What is the Windows successful logon event ID?

1. The failed logon event ID is 4625. Logoff is 4634, and a user-initiated logoff is 4647.

What is logon type 3 vs logon type 10?

Type 3 is a network logon, such as accessing a file share, remote MMC or WinRM. Type 10 is RemoteInteractive, which is Remote Desktop. Type 10 leaves reusable credentials on the destination; a plain type 3 does not.

Why do I see two 4624 events for one logon?

Often because one action creates two sessions. Event version 2 records the pairing in the Linked Logon ID field. Tools such as PsExec with explicit credentials also create more than one session. Group them by time, account and Logon ID before you count anything.

Which audit policy enables Event ID 4624?

Audit Logon, under Advanced Audit Policy Configuration, Logon/Logoff. Enable Success for 4624 and Failure for 4625.

TL;DR

Event ID 4624 is a successful logon, logged on the machine that was accessed. Read the Logon Type first (2 keyboard, 3 network, 10 RDP), then who logged on under New Logon, then the source address and authentication package. Use the Logon ID to join it to 4672 (admin privileges), 4647 and 4634 (logoff), and to 4688 (what ran). A burst of 4625 failures followed by a 4624 from the same source is a guess that worked.

How EpicDetect Can Help

Reading the table is easy. Spotting which logon in a burst of failures matters takes practice. Our free cases are single investigations at a fictional finance firm. One of them, VPN Auth Spray Against Treasury Staff, asks you to show a multi-user failure burst from one external IP, pin the first successful session after it, and ship the attacker IP and compromised mailbox as IOCs with a supported verdict. Prefer a story? Adventures Season Zero is five free episodes as a new analyst in your first week.

If you want the background in order, the Atlas is a skill map of nine zones, from foundations through SOC, detection and threat intel. The first tier of every zone is free, and many lessons include typed-answer questions you cannot skip. Studying for Security+ too? The free daily drill and practice test sit in the same account, and Premium adds timed exam simulators.

Start free. No card needed.