Windows Logon Types: A Triage Guide for Every 4624 Value
Every Windows logon type, what produces it in a healthy environment, what it means when it appears where it should not, and the queries to hunt it.
Windows logon types are the numeric codes in events 4624 and 4625 that record how an account authenticated: 2 at the console, 3 over the network, 5 as a service, 10 over RDP, and so on. The number does not tell you whether a logon is malicious. It tells you which questions are worth asking next.
Microsoft's table explains the credential-exposure risk of each type, which is the right lens for an architect deciding how admins should connect to servers. It is not the lens you need with a 4624 open in front of you at 02:00. This piece is the triage layer: what produces each type in a healthy environment, what it means when that type turns up where it has no business being, and the field combinations that decide the verdict.
Every Windows logon type in one table
The numbers come from the SECURITY_LOGON_TYPE enumeration and are stable across every supported Windows version. The two right-hand columns are the ones you will actually use.
| # | Name | What produces it normally | Read it as suspicious when |
|---|---|---|---|
| 0 | System | The SYSTEM account, at boot | Essentially never triage material |
| 2 | Interactive | Console logon, KVM or lights-out card, runas | A service account or admin account appears at a console it should never touch |
| 3 | Network | SMB, RPC, WinRM, remote registry, IIS integrated auth, SQL Windows auth | NTLM against a privileged account, or a source and destination pair that has never occurred before |
| 4 | Batch | Scheduled tasks | A task runs as a named human, or at an hour nobody scheduled |
| 5 | Service | The Service Control Manager starting a service | The account is a person rather than a service identity |
| 7 | Unlock | Someone unlocked the workstation, or reconnected to an existing RDP session | Unlocks on a server nobody sits at |
| 8 | NetworkCleartext | IIS basic authentication, WinRM with CredSSP | Almost anywhere else. A password crossed the wire recoverable |
| 9 | NewCredentials | runas /netonly | Nearly always worth a look. See below |
| 10 | RemoteInteractive | A new RDP session | RDP into a host with no RDP business, or sourced from a user workstation |
| 11 | CachedInteractive | Laptop logon with no domain controller reachable | A host that never leaves the corporate LAN |
| 12 | CachedRemoteInteractive | RDP with cached credentials | Same reasoning as 11, over RDP |
| 13 | CachedUnlock | Unlock validated against the credential cache | Same reasoning as 11, at unlock |
Types 1 and 6 never appear in practice. Type 1 is the undefined value and type 6 is Proxy, which the SECURITY_LOGON_TYPE enumeration documents as not supported. If you ever see either in a log, suspect the parser before the attacker.
Reading one 4624 field by field
Before the per-type detail, here is the record itself: a 4624 from a file server, flattened out of its XML into the field names Windows uses.
TimeCreated: 2026-08-19T02:41:08.113Z
Computer: FS-CORP-02.northwind.example
EventID: 4624
Subject\Security ID: NULL SID
Subject\Account Name: -
Subject\Logon ID: 0x0
New Logon\Security ID: NORTHWIND\a-mreyes
New Logon\Account Name: a-mreyes
New Logon\Account Domain: NORTHWIND
New Logon\Logon ID: 0x6F2A19
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Package Name (NTLM only): NTLM V2
Key Length: 128
Workstation Name: WKS-4471
Source Network Address: 10.14.22.60
Source Port: 51288
Elevated Token: YesSimulated example generated by SOCSimulator Research.
Work it from the bottom up. Logon type 3 says this was a network logon, so nobody sat down anywhere. NtLmSsp and NTLM say the authentication was NTLM rather than Kerberos, already unusual for a domain account reaching a domain-joined server by hostname. The account name carries an a- prefix, which in this environment marks an admin tier, and Elevated Token: Yes confirms the session received a full administrative token rather than a filtered one. The source is a user workstation subnet, at 02:41.
None of those facts is an alert on its own. Together they describe an administrative credential used over the network, with the weaker protocol, from a workstation, in the middle of the night. The next move is to pull every event sharing Logon ID 0x6F2A19, starting with 4672, which fires with the same logon ID whenever a session is granted sensitive privileges.
Two cautions. Subject on a network logon is normally NULL SID with logon ID 0x0, which just means no existing session initiated this one. And LSASS audits only what the authenticating service hands it, so Kerberos network logons frequently arrive with no workstation name and NTLM ones sometimes with no address at all. A blank Source Network Address is a hole in the record, not evidence of a local logon. If raw Windows records are new to you, our guide on how to read Windows event logs covers the XML view.
Baseline before you hunt
Every hunt below produces garbage until you know what your environment normally does. Start with the shape of logon activity per host. In Microsoft Sentinel, the SecurityEvent table carries the 4624 fields one for one (if KQL is unfamiliar, that guide walks the operators):
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4624
| where TargetUserName !endswith "$"
| summarize Logons = count(), Accounts = dcount(TargetUserName) by Computer, LogonType
| order by Computer asc, Logons descThe same question in Splunk, against the Windows TA:
index=windows sourcetype="WinEventLog:Security" EventCode=4624
| eval target=mvindex(Account_Name,-1)
| search NOT target="*$"
| stats count AS logons, dc(target) AS accounts BY host, Logon_Type
| sort host, -logonsThat mvindex(Account_Name,-1) is not decoration. Event 4624 carries two account names, the subject and the new logon, and the Splunk extraction returns both in one multivalue field. Filter on Account_Name without picking the last value and you silently match the wrong one, which is how a hunt returns nothing and looks clean.
In Defender XDR the equivalent table is DeviceLogonEvents, with one important difference: its LogonType column holds strings such as Network and RemoteInteractive, not integers. Numeric comparisons there return nothing, with no error.
DeviceLogonEvents
| where Timestamp > ago(7d)
| where ActionType == "LogonSuccess"
| summarize Logons = count(), Accounts = dcount(AccountName) by DeviceName, LogonType
| order by DeviceName asc, Logons descSave the output. A logon type that has never appeared on a host before is worth more than any threshold you could set on the ones that always do.
Logon type 2: Interactive
Somebody authenticated at the machine itself: the physical console, a KVM, an iLO or DRAC card, or runas without /netonly. Credentials stay resident in LSASS for the life of the session, which is why this type matters so much to anyone designing admin workflows.
On workstations, type 2 is background noise. On servers it is not. Most fleets are administered over RDP or WinRM, so a console logon on a production server is either an out-of-band session or something local that arranged one. Service accounts should never produce type 2 at all: if svc_sqlbackup logs on interactively, either an operator borrowed the credential to run something by hand or somebody with the password used it deliberately.
Logon type 3: Network
Type 3 covers every authentication where the account reached the machine over the network and no interactive session was built: SMB file access, RPC, WMI, WinRM and PowerShell Remoting, remote registry, remote MMC snap-ins, IIS integrated Windows authentication, SQL Server Windows authentication. One list, one type number, which is why it drowns everything else.
It is also where lateral movement lives. Nearly every technique under Remote Services (T1021) authenticates this way, and so does every legitimate file share access in the building, so volume by itself tells you nothing.
The combination does. Type 3 plus NTLM plus a privileged account is the one worth wiring into a saved query, because on a modern domain a privileged account reaching a domain-joined server by name should be getting a Kerberos ticket. NTLM instead means a hostname was bypassed, a credential was replayed, or something is authenticating by IP address. All three are worth a question.
let PrivAccounts = dynamic(["Administrator", "a-mreyes", "svc_backup", "da_helpdesk"]);
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4624 and LogonType == 3
| where AuthenticationPackageName == "NTLM"
| where TargetUserName in~ (PrivAccounts)
| summarize Logons = count(), Sources = make_set(IpAddress, 25), NtlmVersion = make_set(LmPackageName)
by Computer, TargetUserName
| order by Logons descReplace the hardcoded list with whatever identity lookup you already maintain. If you have none, a match against your tiering convention is a serviceable start, and building the lookup is a better use of an afternoon than tuning the query.
Failures on this type are their own conversation. A burst of 4625 events with logon type 3 from a single source against many accounts is password spraying (T1110). The same burst against one account, from one host, all day, is almost always a stale password in a mapped drive, a scheduled task or a service. Read the SubStatus code and the source before you page anyone.
Logon type 4: Batch
The Task Scheduler runs a task under stored credentials. The password lives on disk as an LSA secret, so anything that can extract LSA secrets on that host can recover it.
Two things make a type 4 interesting. First, the account: scheduled tasks running as a named human are an operational smell and a common persistence trick, because a task inherits whatever that person can reach. Second, the timing: a task that appears at an hour with no corresponding change record deserves a look at what created it.
Logon type 5: Service
The Service Control Manager started a service and logged it on. Like batch logons, the credential is stored as an LSA secret, and the resulting session holds reusable credentials.
Baselining this one is easy because the population is small and stable. LocalSystem, NetworkService, LocalService, managed service accounts and your handful of named service identities account for essentially all of it, and anything outside that set is the finding. A type 5 for a domain user account means a service was configured to run as a person. Sometimes that is a legacy application nobody has fixed. It is also how an attacker turns stolen credentials into a service that survives reboots, which lands under Valid Accounts (T1078) because the authentication itself is legitimate. The type 5 only tells you the service ran. Event 7045 in the System log tells you when it was installed and what binary it points at, which is the half the Security channel does not carry.
Logon type 7: Unlock
The workstation was unlocked. Usually that is exactly what it sounds like: the screen locked, somebody came back, they typed their password.
The nuance that catches people is RDP. A brand new Remote Desktop session records type 10. Reconnecting to a session still sitting on the host, disconnected, records type 7 instead, alongside event 4778 for the session reconnect. A host with far more type 7 than type 10 has people who never log out, which is untidy rather than malicious. But if you read type 7 as "someone is physically present," you will misread every reconnect on your server fleet.
Logon type 8: NetworkCleartext
The account authenticated over the network and the password reached the authentication package unhashed. Microsoft's phrasing is careful here: the built-in packages hash before transmission, so this does not automatically mean a plaintext password crossed the wire. It does mean the receiving process handled a recoverable password rather than a hash or a ticket.
The legitimate producers are a short list: IIS basic authentication, and PowerShell remoting with CredSSP. Both appear in Microsoft's administrative tools and logon types reference, which also marks both as leaving reusable credentials on the destination.
Everywhere else, treat a type 8 as a finding. It is rare enough to enumerate by hand:
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4624 and LogonType == 8
| summarize Logons = count(), FirstSeen = min(TimeGenerated), Sources = make_set(IpAddress, 15)
by Computer, TargetUserName, ProcessName
| order by Logons descindex=windows sourcetype="WinEventLog:Security" EventCode=4624 Logon_Type=8
| eval target=mvindex(Account_Name,-1)
| stats count AS logons, earliest(_time) AS first_seen, values(Source_Network_Address) AS sources
BY host, target, Process_Name
| convert ctime(first_seen)
| sort -logonsIf the answer comes back "one web server and one automation host," write it down as your baseline and alert on anything else. If it comes back with domain controllers in the list, that is the day's work.
Logon type 9: NewCredentials
Learn this one properly. The name is misleading.
Type 9 does not mean new credentials were created. It means a process cloned its existing token, kept the local identity it already had, and specified different credentials for outbound network connections. Locally you are still you. Over the network you are somebody else. That is what runas /netonly does, and Microsoft's reference lists RUNAS /NETWORK as the canonical producer.
Two things make it high signal. It is rare: outside admins working across a trust boundary, most environments generate a handful a week. And it is the primitive credential-theft tooling needs. The mimikatz sekurlsa::pth sequence creates a logon session this way before substituting the stolen hash, which is why a type 9 with logon process seclogo and authentication package Negotiate is a well-worn pass-the-hash indicator. ATT&CK files that family under Use Alternate Authentication Material (T1550).
The record tells you both halves of the identity. New Logon\Account Name is who the process remains locally; Network Account Name and Network Account Domain are the credentials it will present outbound, and those two fields are populated only for this logon type. A mismatch between them is the point of the event.
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4624 and LogonType == 9
| project TimeGenerated, Computer, SubjectUserName, TargetUserName,
TargetOutboundUserName, LogonProcessName, AuthenticationPackageName, ProcessName
| order by TimeGenerated descindex=windows sourcetype="WinEventLog:Security" EventCode=4624 Logon_Type=9
| eval target=mvindex(Account_Name,-1)
| stats count AS logons, values(Logon_Process) AS logon_process, values(Process_Name) AS process_name
BY host, target
| sort -logonsPair every hit with 4648, the explicit-credentials event, which fires on the same host and names the account whose credentials were supplied. Together they answer both questions: who ran it, and whose credentials they used.
Logon type 10: RemoteInteractive
A Remote Desktop session was created. Credentials are fully resident on the destination, which is why RDP into a compromised host is such an efficient way to lose an administrative credential.
Three details keep analysts honest. Network Level Authentication validates the credential before the session exists, so with NLA enabled you will often see a type 3 immediately preceding the type 10 for the same account. Cached RDP logons record type 12 instead. And Restricted Admin Mode is populated only for this type, which is a clean way to verify that admins reaching sensitive hosts use the mode that leaves no reusable credentials behind.
Direction matters more than volume here. Jump host to server is normal. Workstation to workstation, or server to server across tiers, usually is not.
Logon type 11: CachedInteractive
The user logged on with credentials cached on the machine because no domain controller could be reached. Windows keeps a limited number of verifiers locally so laptops still work on a plane.
The consequence is worth internalizing: no domain controller validated that logon, so no domain controller logged it. Your DC-side authentication timeline, the 4768, 4769 and 4776 events you lean on for account activity, has nothing for it. If your investigation depends on "the account was not used between these hours," a cached logon is where that assumption breaks.
Types 12 and 13 are the same story at a different door. 12 is a cached RDP logon, 13 a cached unlock, and both mean the local credential cache answered instead of a domain controller.
Type 11 on a laptop is unremarkable. On a desktop or server that never leaves the LAN it means that host could not reach a domain controller at that moment, and it is worth asking why. Sometimes the answer is a network outage. Sometimes somebody isolated the host on purpose.
Logon Process and Authentication Package
These two fields sit under the logon type in every 4624 and 4625. Together they tell you which component did the authenticating, and with which protocol.
Authentication Package is the protocol that validated the credential: Kerberos, NTLM, or Negotiate when the two systems negotiated between them. When the package is NTLM, Package Name (NTLM only) tells you the sub-protocol, and anything other than NTLM V2 on a modern network is a configuration problem in its own right.
Logon Process is which trusted component asked LSA to do the work. The common values:
User32is Winlogon, the interactive path. Console logons and unlocks.NtLmSspis the NTLM security support provider, the usual companion to network logons.KerberosandNegotiatare the Kerberos and Negotiate providers. The truncation in the second one is normal.seclogois the Secondary Logon service, which is whatrunasuses. Seeing it beside a type 9 is therunas /netonlyfingerprint.Advapimeans a process on the machine called theLogonUserAPI in advapi32.dll to validate a credential directly.
Microsoft's guidance for event 4624 is to keep a list of the logon processes you expect on a host and monitor for anything outside it. It is a cheap rule, and it catches the case where something registers itself with LSA that has no business being there.
That last one causes most of the confusion, and it turns up disproportionately on failures. When a 4625 shows Logon Process: Advapi with logon type 2 or 3 and no source address, something running on the host tried to authenticate an account and was refused: IIS, a database engine, a backup or monitoring agent, a scheduled task or a service holding a password that changed last Tuesday. Advapi is not an attacker signature. It tells you where to look: on the box, at the process name in the same event, not at a remote client that does not exist.
One practical note before you write a rule on these fields: Windows pads and truncates them. Advapi frequently arrives as Advapi with trailing spaces, and User32 as User32 . Exact-match comparisons quietly return nothing. Use startswith, or trim first.
The type 3 noise problem
A busy file server or domain controller produces tens of thousands of type 3 logons a day. You cannot alert on them and you cannot read them, so the only workable posture is baselining.
Drop machine accounts from the human-activity view. Names ending in $ are computer accounts, and on most networks they are the bulk of type 3 volume. Keep them in a separate view: they matter for other hunts, just not this one.
Count relationships, not events. Aggregate on the triple of source address, destination host and account, then compare today's set against the last 30 days. The first time a-mreyes authenticates to a server nobody in that role has ever touched is worth more than the ten thousandth time she reaches the file share she uses daily. New-pair detection scales; thresholds do not.
Separate ANONYMOUS LOGON and localhost. Type 3 with a source address of 127.0.0.1 or ::1 is a local process, not a remote client. Anonymous logons are ordinary null-session noise in most environments and something else entirely in a hardened one, so decide which yours is and filter accordingly.
With those three in place the residue is small enough to read, and the field combinations above become usable rules rather than aspirations.
Where this gets easier
The types take an afternoon to memorize. Recognizing that a type 9 on a jump host at 02:00 is worth escalating while a type 3 storm against a file server is a Tuesday is a different skill, and it comes from working a queue rather than reading tables. That is what SOCSimulator drills: realistic Windows authentication telemetry, in volume, with the noise left in. Our Windows event ID reference is the companion to this piece, one page per event, built around the same triage-first question.
Next time a 4624 lands in front of you, read the type, then the account, then the package, then the source. Four fields in that order, and most triage decisions make themselves.
Frequently Asked Questions
- What is logon type 3 in Windows?
- Logon type 3 is a network logon: an account authenticated to the machine from somewhere else on the network without an interactive session being created. SMB file access, RPC, WinRM and PowerShell Remoting, remote registry, remote MMC snap-ins and IIS integrated Windows authentication all produce it. It is by far the highest-volume logon type on a domain member, which is why it has to be baselined rather than alerted on.
- What does logon type 5 mean?
- Logon type 5 means the Service Control Manager started a service and logged the service on with the credentials configured for it. On a normal server almost every type 5 belongs to LocalSystem, NetworkService, LocalService, a managed service account or a dedicated service identity. A type 5 for a named human account means somebody configured a service to run as a person, which is either a bad operational habit or a persistence mechanism.
- What is the Advapi logon process?
- Advapi is the logon process name Windows records when a program on the machine calls the LogonUser API in advapi32.dll to validate a credential, rather than the credential arriving through Winlogon or a network security provider. IIS, database engines, backup and monitoring agents, scheduled tasks and services all authenticate this way. It tells you the attempt was made by a process running on that host, not by a remote client.
- Is RDP logon type 10 or 7?
- A new Remote Desktop session is type 10, RemoteInteractive. Reconnecting to a session that already exists on the host records type 7, Unlock, the same value a local unlock produces. With Network Level Authentication enabled, credentials are validated before the session is built, so a type 3 network logon often precedes the type 10. Cached RDP credentials record type 12 instead.
- What does logon type 9 mean in event 4624?
- Type 9 is NewCredentials. A process cloned its existing token, kept the local identity, and supplied different credentials for outbound network connections. That is what runas /netonly does, and it is also what several credential-theft tools do before reusing a stolen hash or ticket. It is rare in normal environments, which makes it one of the highest-signal values in the Security log.
- What does 4625 with logon type 3 mean?
- A failed network logon. Something tried to authenticate to the machine over the network with a credential the machine rejected. In bulk, from one source across many accounts, it is password spraying. In bulk against one account, it is usually a stale password in a mapped drive, service or scheduled task. Check the SubStatus code and the source address before deciding which.
Field notes
New walkthroughs and detections, in your inbox
A short email when we publish something worth your time. No spam, unsubscribe in one click.
Community
Continue the conversation
Discuss this with analysts who are actively training and working in the field.
Related Articles
How to Read Windows Event Logs: A SOC Analyst Guide
How to read Windows event logs in Event Viewer: pick the right channel, decode the XML view, and triage the Security events analysts see every shift.
Windows Event IDs Cheat Sheet: The 31 That Matter
Windows event IDs cheat sheet for SOC analysts: 31 essential security event IDs covering auth, process execution, log tampering, and lateral movement.
Cyber Threat Hunting Tools: 13 SOC Analysts Use (2026)
Cyber threat hunting tools every SOC analyst needs: Sigma, YARA, KQL, Velociraptor, Wireshark, Zeek, MISP and more — grouped by layer with code examples.