Windows Logon Types and Authentication Events: Read 4624, 4625 and 4648 for Detection

Every Windows sign-in, share connection, scheduled task and service start is recorded as a logon with a type number, and most detection gaps come from analysts who cannot tell a normal type 3 from a dangerous one. The logon type, the authentication package and a handful of other fields in events 4624, 4625 and 4648 tell you how an account arrived, whether reusable credentials were left on the machine, and whether NTLM or Kerberos was used. This guide explains each logon type you will see (2, 3, 4, 5, 7, 8, 9, 10 and 11), how common administration methods such as mapped drives, RUNAS, PsExec, WinRM and Remote Desktop show up, how NTLM and Kerberos look in the events, and how the well-known groups such as Authenticated Users relate to logon sessions. It is written for SOC analysts, detection engineers and Active Directory administrators, and is based on Microsoft Learn documentation. For audit policy configuration and the wider event catalogue, see the Windows Event Log Guide.

Key takeaways

• The event is written where the account arrived. 4624 and 4625 are logged on the computer that was accessed: the workstation for a console sign-in, the file server for a mapped drive. Domain controllers see the authentication (4768, 4769, 4776), not every logon.
• The logon type tells you about credential exposure. Interactive (2), batch (4), service (5), cleartext (8), new credentials (9) and Remote Desktop (10) leave reusable credentials in memory on the destination; a plain network logon (3) normally does not.
• Read the authentication package, not just the type. Kerberos, NTLM and Negotiate appear in 4624; Package Name shows NTLM V1, NTLM V2 or LM, and Key Length is 0 for Kerberos.
• Mismatches are the high value signals. Microsoft's own monitoring advice flags domain administrators with batch or service logons, Remote Desktop without Restricted Admin where it is required, and NTLM where it should not appear.
• Correlate on Logon ID and Logon GUID. Logon ID ties 4624 to 4672 privileges and 4688 processes on the same host; Logon GUID ties a Kerberos logon to the 4769 service ticket on the domain controller.

Where authentication events are written

A single remote action produces events on more than one machine. Knowing which machine logs what is the first step to building a detection or an investigation timeline.

Microsoft recommends auditing both success and failure for Audit Logon on domain controllers, member servers and workstations, and describes the volume as low on clients and medium on domain controllers and servers. A practical consequence: if you only collect domain controller logs you see NTLM validation (4776) and Kerberos tickets (4768, 4769) but not the type 3 logons on file servers or the type 10 logons on jump hosts. Collect 4624 and 4625 from servers and administrative workstations too; the Windows Event Forwarding Guide covers how.

The logon types explained

The Logon Type field in 4624 and 4625 is a number from the Windows SECURITY_LOGON_TYPE enumeration. The table combines Microsoft's 4624 definitions with its administrative tools reference, which records which authenticators each type accepts and whether reusable credentials (NT hashes, Kerberos tickets or plaintext passwords) are held in the LSA session on the destination.

• Type 0 and types 12 and 13: type 0 (System) is used only by the System account, for example at startup. Microsoft describes 12 (CachedRemoteInteractive) as used for internal auditing and 13 (CachedUnlock) as a workstation logon; neither needs its own detection.
• NetworkCleartext is not plaintext on the wire: Microsoft's definition is that the password reached the authentication package unhashed. The concern is that a reusable password now sits on the server, so find and fix the application producing type 8.
• Type 9 looks local: a NewCredentials logon keeps the caller's local identity, so the New Logon account name is the original user, and the Network Account Name and Network Account Domain fields show the credentials used for outbound connections.

How administration methods appear in the logs

The same task can be done in ways that expose credentials very differently. Microsoft's administrative tools reference is the authoritative mapping; the most common rows are below. Credentials are always exposed on the source computer, which is why privileged access workstations matter.

Mapped drives and RPC context: mapping a drive or opening a share uses SMB on TCP 445, and older NetBIOS-based access uses UDP 137 (name resolution), UDP 138 (datagram) and TCP 139 (session service); Microsoft notes the NetBIOS ports are optional for the Server service on modern Windows. RPC-based tools such as the MMC snap-ins and Remote Registry start at the RPC endpoint mapper on TCP 135 and then use the dynamic range 49152 to 65535. All of these arrive as type 3. When you see a type 3 from an unexpected workstation, the Source Network Address, Workstation Name and Process Name fields, plus firewall logs for those ports, tell you which method was used. Remote Desktop uses TCP and UDP 3389 and WinRM TCP 5985 (HTTP) or 5986 (HTTPS).

Reading 4624 field by field

Since Windows 10, 4624 is version 2 of the event and carries a Logon Information block. Read these fields in roughly this order.

• Subject: the account that reported the logon, normally SYSTEM. Microsoft recommends reporting any 4624 where the Subject Security ID is not SYSTEM.
• Logon Type, Restricted Admin Mode, Virtual Account, Elevated Token: Restricted Admin Mode is populated only for type 10 and shows Yes when Remote Desktop used Restricted Admin; Virtual Account is Yes for managed and group managed service accounts; Elevated Token Yes means an administrator session.
• Impersonation Level: Identification, Impersonation (the most common) or Delegation. Delegation means the server can use the client's identity on remote systems, which matters for Kerberos delegation reviews. See the Kerberos Delegation Security Guide.
• New Logon: the account that logged on, its Logon ID (for correlation on this host), Linked Logon ID (the paired logon session, or 0x0 if none) and Logon GUID.
• Process Information: Process ID and Process Name of what requested the logon. Unexpected executables, or binaries outside System32 and Program Files, deserve review.
• Network Information: Workstation Name, Source Network Address and Source Port. Microsoft notes that Kerberos network logons usually lack the workstation name and NTLM logons lack TCP/IP details, so expect gaps and use both.
• Detailed Authentication Information: Logon Process, Authentication Package (Kerberos, NTLM or Negotiate; Negotiate picks Kerberos unless it cannot be used), Transited Services (populated for Kerberos S4U logons), Package Name (NTLM V1, NTLM V2 or LM) and Key Length (128 or 56 for NTLM, always 0 for Kerberos).

NTLM versus Kerberos in the events

Local accounts always use NTLM when signing in to the machine that stores them, so NTLM on a workstation is not by itself suspicious. To see NTLM use across the domain, collect 4776 from domain controllers and enable the security option Network security: Restrict NTLM: Audit NTLM authentication in this domain, which logs to the NTLM Operational log under Applications and Services Logs, Microsoft, Windows, NTLM without blocking anything. Audit there before applying any Restrict NTLM blocking setting. See the NTLM Deprecation and Elimination Guide for the removal programme and the NTLM Relay Guide for why NTLM on servers matters.

Failures and explicit credentials

4625 carries Failure Reason, Status and Sub Status. The codes worth alerting on, from Microsoft's 4625 and 4776 documentation:

4648 explicit credentials: logged when a process supplies an account's credentials explicitly, most often scheduled tasks and RUNAS. The event shows the Subject (who asked), Account Whose Credentials Were Used, Target Server Name (localhost when local) and the Process Name. Because 4648 is also routine operating system noise, alert on combinations: a user account supplying an administrator's credentials, a process outside standard folders, or a target server the account does not normally reach. The Logon GUID links it to the 4624 on the target and the 4769 on the domain controller.

Authenticated Users and the logon session groups

When a logon session is created, Windows adds well-known group SIDs to the token that describe how the user arrived. Permissions granted to these groups therefore depend on logon type, which is useful to know when reviewing share and file permissions.

A share permission of "Authenticated Users: Change" is reachable by any domain user over a type 3 logon from any workstation. When a type 3 logon to a file server looks odd, check what the token could reach through these groups before deciding the impact.

Detection rules that work

1. Privileged accounts on the wrong tier: alert on 4624 types 2, 10 and 11 for domain administrator accounts on any host that is not a domain controller or privileged access workstation.
2. Logon type mismatches: alert on type 4 or 5 for members of domain administrative groups, as Microsoft recommends; service and task accounts should be dedicated, low privilege identities.
3. Restricted Admin required: for accounts that must use it, alert on type 10 with Restricted Admin Mode No.
4. Elevated network logons from new sources: baseline type 3 logons with Elevated Token Yes per account and source address; new pairs often indicate lateral movement with admin shares, WinRM or PsExec.
5. Cleartext and CredSSP: alert on type 8 outside the known IIS Basic authentication servers.
6. NTLM hygiene: alert on Package Name NTLM V1 or LM, Key Length 56, and any NTLM for accounts in protected groups.
7. Kerberos ticket hygiene: on domain controllers, alert on 4769 with Ticket Encryption Type other than 0x11 or 0x12, and on bursts of service ticket requests for many SPNs from one account, a sign of Kerberoasting. See the Kerberoasting and AS-REP Roasting Defence Guide.
8. Special privileges: join 4672 to 4624 on Logon ID and alert when SeDebugPrivilege, SeTcbPrivilege or SeBackupPrivilege is granted to an account that is not SYSTEM, LOCAL SERVICE, NETWORK SERVICE or an expected administrator.
9. Failure patterns: thresholds of N failures in N minutes for 0xC000006A per account (guessing) and per source across accounts (spraying), and any 0xC0000064 run (enumeration).

Test each rule against known administration activity before enabling alerting: run a scheduled task, a mapped drive, an Enter-PSSession and a Remote Desktop session from a test admin account and confirm the logon type and fields you expect. That gives you a regression test whenever audit policy or forwarding changes.

Where identity fits

Logon types are the clearest view of non-human identities in Windows. Type 5 shows every service account sign-in, type 4 every scheduled task account, and Virtual Account Yes identifies managed and group managed service accounts. Batch and service logons store the password as an LSA secret on disk, which is why an over-privileged service account on many servers is a lateral movement path. Inventory the accounts that appear in type 4 and 5 events, move them to group managed service accounts where possible, and alert when one appears in a type 2, 3 from an unexpected source or 10 logon. See the Service Account Security Guide and the Pass-the-Hash and Pass-the-Ticket Guide.

Measuring coverage

• Collection coverage: percentage of domain controllers, servers and administrative workstations forwarding 4624, 4625, 4648, 4672 and (on DCs) 4768, 4769 and 4776.
• Tiering violations: weekly count of privileged account logons of types 2, 10 or 11 outside permitted hosts, trending to zero.
• NTLM share: NTLM logons as a percentage of all 4624 network logons, and the number of accounts and servers still using NTLM V1 or LM (target zero).
• RC4 tickets: 4769 events with encryption type 0x17 per day, trending to zero.
• Service identity hygiene: accounts seen in type 4 or 5 logons that are not group managed service accounts.

Common failure patterns

• Collecting only domain controller logs. Type 3 and type 10 logons on servers never reach the SIEM, so lateral movement through admin shares is invisible.
• Treating type 3 as noise. It is the most common type, but Elevated Token Yes from a new source is exactly how administrative lateral movement looks.
• Reading only the logon type. Without Authentication Package, Package Name and Key Length, NTLM V1 and LM use goes unnoticed.
• Running admin tools that leave credentials behind. CredSSP, PsExec with -u -p and scheduled tasks under domain admin accounts all leave reusable credentials on the target.
• Blocking NTLM without auditing first. Restrict NTLM settings applied without the audit setting break applications nobody had inventoried.
• Ignoring 4625 on service accounts. Repeated 0xC000006A or 0xC0000234 on a service account is either an attack or a stale password stored somewhere; both need an owner.

Framework mapping

Practitioner checklist

• Enable success and failure for Audit Logon, plus Audit Special Logon, Audit Credential Validation and the Kerberos subcategories on domain controllers.
• Forward 4624, 4625, 4648 and 4672 from servers and administrative workstations, not only domain controllers.
• Parse Logon Type, Elevated Token, Restricted Admin Mode, Virtual Account, Authentication Package, Package Name, Key Length, Source Network Address and Process Name as fields.
• Write tiering rules for privileged accounts on types 2, 10 and 11.
• Alert on type 4 and 5 logons by domain administrators and on type 8 outside known servers.
• Audit NTLM in the domain, then drive NTLM V1, LM and 56 bit keys to zero.
• Alert on non-AES Kerberos service tickets.
• Inventory accounts seen in batch and service logons and move them to group managed service accounts.
• Replace CredSSP and PsExec with explicit credentials with methods that use type 3 logons.
• Run a test admin through each method quarterly and confirm the expected events arrive.

Standards and references

• Microsoft Learn: 4624(S) An account was successfully logged on
• Microsoft Learn: 4625(F) An account failed to log on
• Microsoft Learn: 4648(S) A logon was attempted using explicit credentials
• Microsoft Learn: Administrative tools and logon types reference
• Microsoft Learn: 4776(S, F) The computer attempted to validate the credentials for an account
• Microsoft Learn: 4769(S, F) A Kerberos service ticket was requested
• Microsoft Learn: Special identity groups
• Microsoft Learn: Service overview and network port requirements for Windows

Related NHI Mgmt Group resources: Windows Event Log Guide · Lateral Movement Guide · Kerberos Security Guide · NTLM Deprecation and Elimination Guide · Service Account Security Guide