Windows Security Subsystem Architecture

The authentication chain from keyboard to Kerberos ticket

When a domain user logs into a Windows endpoint, the authentication flows through a specific chain of security subsystem components. Each component processes the credential one step further from raw input to authenticated session.

The user enters credentials at the logon screen hosted by winlogon.exe, which runs in Session 0 and manages the Credential Provider UI. Winlogon passes the credentials to LSASS through a secure channel. LSASS loads the appropriate Security Support Provider — Kerberos for domain authentication, MSV1_0 (NTLM) for legacy or fallback scenarios — through the SSPI (Security Support Provider Interface). The Kerberos SSP constructs an AS-REQ (Authentication Service Request) containing the user's encrypted credentials and sends it to the domain controller's Key Distribution Center. The KDC validates the credentials against Active Directory's ntds.dit database, generates a Ticket-Granting Ticket, and returns it to the endpoint. LSASS stores the TGT in memory — this is the Kerberos ticket that Mimikatz extracts. LSASS then creates an access token containing the user's SID, group memberships, and privileges. Windows uses this token for every resource access decision for the duration of the session.

Each step in this chain has endpoint security implications. Credential Provider injection — an attacker installs a malicious Credential Provider DLL that captures passwords as they are entered at the Winlogon screen. SSP injection (T1547.005) — an attacker registers a malicious SSP with LSASS that receives credentials during every authentication event, capturing plaintext passwords for every user who authenticates. SAM database dumping — an attacker extracts local account hashes from the SAM registry hive (HKLM\SAM), bypassing LSASS entirely. Each technique targets a different component in the chain, and each requires a different defensive control.

The defensive controls map to specific chain components. Windows Hello for Business replaces password-based authentication with asymmetric key pairs, eliminating the NTLM hash from LSASS entirely — the private key never leaves the TPM, so there is nothing in LSASS to dump. Credential Guard isolates the Kerberos tickets and NTLM hashes in LSAIso. The LSASS ASR rule blocks unauthorized handle access to the LSASS process. Advanced audit policies generate Security event log entries through the Security Reference Monitor when authentication events occur — Event ID 4624 for successful logon, 4625 for failed logon, 4768 for Kerberos TGT request, 4769 for Kerberos service ticket request.

What the authentication evidence looks like

The Security event log records every step of the authentication chain. Event ID 4624 is the most information-dense security event on Windows — a single successful logon record contains the authentication protocol, the logon type, the source network address, the account name, the authentication package, and the elevated token information.

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Event ID:      4624
Task Category: Logon
Level:         Information
Computer:      DESKTOP-NGE042.northgate.local
Description:
  An account was successfully logged on.
  Subject:
    Security ID:     SYSTEM
    Account Name:    DESKTOP-NGE042$
  Logon Information:
    Logon Type:      10
    Restricted Admin Mode: No
    Elevated Token:  Yes
  New Logon:
    Security ID:     NORTHGATE\m.chen
    Account Name:    m.chen
    Account Domain:  NORTHGATE
    Logon GUID:      {a7c9e102-...}
  Process Information:
    Process Name:    C:\Windows\System32\svchost.exe
  Network Information:
    Source Network Address: 10.50.12.87
    Source Port:     52419
  Authentication Information:
    Authentication Package: NTLM
    Key Length:      128

Five fields in this record tell the complete security story. Logon Type 10 is RemoteInteractive — this is an RDP session, which means the user's credentials are cached in LSASS on the remote host (as explained in Section 1.2). The full credential set — NTLM hash, Kerberos TGT — will remain in LSASS until the machine reboots, potentially for days or weeks on modern endpoints with fast startup enabled. Restricted Admin Mode: No means the full credentials are cached, not just a restricted token. If Restricted Admin Mode were enabled, the admin's credentials would not be cached on the remote host — the session would use a restricted token that cannot be used for pass-the-hash. This single field is the difference between "credentials exposed" and "credentials protected" for every RDP session in the organization. Authentication Package: NTLM means Kerberos was not used, which exposes the NTLM hash for pass-the-hash attacks. NTLM fallback may indicate a misconfigured SPN, an IP-based connection instead of hostname, or a cross-forest authentication. Each cause has a different remediation. Elevated Token: Yes means this is a privileged logon — the account has administrative rights on the target system. Source Network Address: 10.50.12.87 — at NE, this IP is a standard user workstation, not the admin jump server at 10.50.100.5. A domain admin account logging in via RDP from a user workstation using NTLM at 02:47 AM on a Saturday with full credential caching is either a legitimate emergency response or an attacker using stolen credentials from the jump server to the endpoint. The investigation starts with confirming whether m.chen was on call that Saturday night — a question that one Event ID 4624 record makes possible to ask.

NTLM versus Kerberos: the protocol choice that shapes your attack surface

The authentication protocol — NTLM or Kerberos — fundamentally changes the credential exposure on each endpoint. Kerberos is the default for domain authentication in Active Directory environments. NTLM is the fallback when Kerberos cannot complete — when the client cannot reach a domain controller, when the target is identified by IP address instead of hostname, or when a legacy application does not support Kerberos. The protocol choice determines what credential material ends up in LSASS and how that material can be abused.

Kerberos authentication stores TGTs and service tickets in LSASS. The TGT enables pass-the-ticket attacks but has a default lifetime of 10 hours — after expiry, the ticket is no longer valid for obtaining new service tickets. The TGT can be renewed, extending its effective lifetime, but renewal requires the user's session to be active. Once the session ends and the TGT expires, the pass-the-ticket opportunity closes. NTLM authentication stores the NT hash in LSASS indefinitely until the machine reboots. The NT hash enables pass-the-hash attacks with no expiration — the hash is valid until the user changes their password, which may be months or years on accounts without password rotation policies. This asymmetry means NTLM usage creates a fundamentally larger credential exposure window than Kerberos.

Kerberos also has its own attack techniques that do not depend on LSASS dumps. Kerberoasting requests service tickets for accounts with Service Principal Names and cracks them offline — the attack targets the KDC, not LSASS, and generates Kerberos Event ID 4769 with encryption type 0x17 as the detection indicator. AS-REP roasting targets accounts with "Do not require Kerberos preauthentication" enabled, requesting encrypted data that can be cracked offline to reveal the account password. Golden Ticket attacks use a compromised KRBTGT hash to forge TGTs — granting unlimited access to every resource in the domain for the lifetime of the KRBTGT key. Silver Ticket attacks forge service tickets for specific services without touching the KDC at all. Each Kerberos attack technique targets a different component of the authentication chain and generates different telemetry — understanding which component is targeted determines which detection approach works. The endpoint security controls from this course address the LSASS-resident credential material (ASR, PPL, Credential Guard), while the detection rules in Module ES8 address the Kerberos-specific techniques (Kerberoasting detection via Event ID 4769, AS-REP roasting via Event ID 4768 with specific encryption types). Both layers are necessary because the credential storage and the protocol-level attacks require different defenses. Protecting LSASS stops the attacker from extracting cached credentials. Detecting Kerberoasting stops the attacker from cracking service account passwords offline. Neither defense covers the other's attack surface — both must be deployed.

// Audit NTLM vs Kerberos authentication across the fleet
DeviceLogonEvents
| where Timestamp > ago(7d)
| where LogonType in ("Interactive", "RemoteInteractive", "Network")
| summarize
    KerberosCount = countif(Protocol == "Kerberos"),
    NTLMCount = countif(Protocol == "NTLM")
    by DeviceName
| where NTLMCount > 0
| extend NTLMPercent = round(NTLMCount * 100.0 / (KerberosCount + NTLMCount), 1)
| sort by NTLMPercent desc

Devices with high NTLMPercent are using legacy authentication and have NTLM hashes in their LSASS process. These devices are higher-priority targets for LSASS protection controls because the cached NTLM hashes are valid indefinitely — unlike Kerberos tickets that expire. If a device shows 80% NTLM authentication, investigate why Kerberos is failing: misconfigured SPN, IP-based access instead of hostname, or a legacy application that forces NTLM. Each reason has a different remediation, and reducing NTLM usage directly reduces the credential theft attack surface on those endpoints.

PPL, the Security Reference Monitor, and the trust chain

The Security Reference Monitor (SRM) runs in kernel mode and enforces access control for every resource request on the system. When a process opens a file, reads a registry key, or connects to a network share, the SRM checks the process's access token against the resource's security descriptor. The SRM generates the Security event log entries (through the Security-Auditing ETW provider from Section 1.4) that record authentication, access, and privilege events. Because the SRM runs in the kernel, it cannot be tampered with from user mode — an attacker who controls a user-mode process cannot modify the SRM's access control decisions.

Protected Process Light (PPL) is a kernel-enforced protection mechanism that extends the SRM's access control to process-level protection. LSASS configured with RunAsPPL runs at the WindowsTcb-Light protection level. A process can only access another process of equal or lower protection level — so standard processes, even running as SYSTEM, cannot open handles to PPL-protected LSASS. The enforcement is in the kernel's process management code, not in a user-mode hook that can be bypassed. This is fundamentally more secure than ASR-based LSASS protection because the enforcement mechanism is not accessible from user mode at all.

Configuring RunAsPPL requires setting the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL to DWORD 1 (with UEFI persistence — cannot be disabled by modifying the registry alone, requiring the LSA Protected Process Opt-out tool) or DWORD 2 on Windows 11 22H2+ (without UEFI persistence — can be reversed by setting the value to 0 and rebooting). Value 1 provides maximum protection for environments where remote PPL disablement should not be possible. Value 2 provides the same runtime protection with the option to remotely disable for troubleshooting — appropriate for environments that need operational flexibility during the initial deployment phase. At NE, value 2 is recommended for the initial pilot deployment across 50 devices, with promotion to value 1 after two weeks of validation confirm no application compatibility issues.

The operational consideration with RunAsPPL is third-party software compatibility. Applications that interact with LSASS through non-protected code paths — some legacy single sign-on solutions, certain password management tools, third-party authentication providers — may break because they cannot open handles to a PPL-protected LSASS process. During the NE pilot, the IT team discovered that the company's legacy VPN client attempted to inject a credential helper DLL into LSASS at logon — an action that PPL correctly blocked. The remediation was a VPN client update that used the supported Credential Provider interface instead of DLL injection. This is a common pattern: PPL breaks software that was doing something it should not have been doing in the first place. The break is the correct behavior.

PPL bypass techniques exist but require kernel-level access: loading a vulnerable signed driver to patch PPL protection in kernel memory, or exploiting a Windows vulnerability that downgrades the protection level. Each bypass requires elevated privileges and generates detectable artifacts — Sysmon Event ID 6 (driver loaded) captures the vulnerable driver load, and DeviceEvents captures the NtLoadDriver call. PPL is not an absolute defense — it is a layer that raises the bar from "run Mimikatz" to "find and exploit a kernel vulnerability." The operational significance is that PPL transforms credential dumping from a trivial, commodity-tool operation into a multi-stage attack requiring kernel exploitation — a different class of attacker capability and investment. Combined with ASR, Credential Guard, and MDE behavioral detection, it forms the four-layer LSASS protection architecture from Section 1.2.