ES1.5 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. The user enters credentials at the logon screen (Winlogon process, which runs in Session 0 and hosts the Credential Provider UI). Winlogon passes the credentials to LSASS through a secure channel. LSASS loads the appropriate Security Support Provider (SSP) — Kerberos for domain authentication, NTLM for legacy or fallback scenarios — through the SSPI interface. The Kerberos SSP constructs an Authentication Service Request (AS-REQ) containing the user’s encrypted credentials and sends it to the domain controller’s Key Distribution Center (KDC). The KDC validates the credentials against Active Directory, generates a Ticket-Granting Ticket (TGT), and returns it to the endpoint. LSASS stores the TGT in memory (this is the Kerberos ticket that attackers extract with Mimikatz). 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. SSP injection (MITRE T1547.005) — an attacker registers a malicious SSP with LSASS that receives credentials during every authentication event. SAM database dumping — an attacker extracts local account hashes from the SAM registry hive. These are not theoretical — they are documented techniques used in production incidents.

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. Credential Guard isolates the Kerberos tickets in LSAIso. The LSASS ASR rule blocks unauthorized handle access. 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, 4648 for explicit credential logon).

The authentication flow: from keyboard to Kerberos ticket

When a user types their password at the Windows logon screen, the authentication traverses the entire security subsystem. Understanding this flow reveals where each endpoint security control intercepts the chain and where attackers target their credential theft techniques.

Step 1: Credential capture. The user types their password into winlogon.exe (the logon UI process). Winlogon passes the credentials to the Local Security Authority Subsystem Service (LSASS) through the SSPI (Security Support Provider Interface).

Step 2: LSASS processing. LSASS receives the credentials and selects the appropriate Security Support Provider (SSP) based on the authentication context. For domain authentication, the Kerberos SSP handles the request. For local authentication or NTLM fallback, the MSV1_0 SSP processes the NTLM hash.

Step 3: Kerberos ticket request. The Kerberos SSP sends an AS-REQ (Authentication Service Request) to the domain controller’s KDC (Key Distribution Center). The KDC validates the credentials against the Active Directory database (ntds.dit) and returns a TGT (Ticket Granting Ticket) encrypted with the user’s password hash.

Step 4: Token creation. After successful authentication, LSASS creates a security access token for the user’s session. The token contains: the user’s SID, group SIDs, privilege assignments, and integrity level. Every process spawned in the user’s session inherits this token — it is the identity credential for all subsequent access decisions.

Step 5: Credential caching. LSASS caches the credential material in memory for Single Sign-On (SSO) — the user does not need to re-enter their password for each resource access. The cached material includes: the Kerberos TGT, NTLM hash, and (if WDigest is enabled) the plaintext password. This cache is exactly what Mimikatz and other credential dumping tools extract (ES8.4). Credential Guard (ES1.2) moves this cache into an isolated virtualization-based security (VBS) container that is inaccessible from the normal OS process space.

The endpoint security controls from this course intercept this chain at multiple points: Credential Guard protects step 5 (cached credentials), ASR’s LSASS protection rule guards step 2 (process access to LSASS), advanced audit policy logs steps 1-4 (authentication events 4624/4768/4769), and MDE detects credential dumping tools that target step 5 (custom detections NE-CRED-001 through NE-CRED-005).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

DeviceLogonEvents
| where Timestamp > ago(7d)
| where LogonType in ("Interactive", "RemoteInteractive", "Network")
| summarize
    KerberosCount = countif(Protocol == "Kerberos"),
    NTLMCount = countif(Protocol == "NTLM"),
    NegotiateCount = countif(Protocol == "Negotiate")
    by DeviceName
| where NTLMCount > 0
| sort by NTLMCount desc

Protected Process Light (PPL) and its security implications

Windows Protected Process Light (PPL) is a kernel-enforced protection mechanism that prevents non-protected processes from accessing protected process memory — even with administrator or SYSTEM privileges. LSASS can be configured to run as PPL (RunAsPPL), which prevents standard credential dumping tools from reading LSASS memory because the dumping tool is not itself a protected process.

The PPL protection hierarchy: a process can only access another process of equal or lower protection level. LSASS running as PPL (level: WindowsTcb-Light) can only be accessed by processes with the same or higher protection level. Mimikatz running as a standard process (no protection level) is denied access to LSASS memory by the kernel — not by an API hook that can be bypassed, but by a kernel-level check that enforced before the access reaches LSASS. This is fundamentally more secure than ASR rule-based LSASS protection (which monitors API call patterns) because the enforcement is in the kernel’s process management code, not in a user-mode hook.

Configuring RunAsPPL. Enable through registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL (DWORD). Two values are available: value 1 configures PPL with a UEFI variable (persistent — cannot be disabled by modifying the registry alone, requires the LSA Protected Process Opt-out tool), and value 2 (Windows 11 22H2+ only) configures PPL without a UEFI variable (can be reversed by setting the registry value to 0 and rebooting — appropriate for environments that need the ability to remotely disable PPL). For NE, value 1 with UEFI persistence is recommended for maximum protection (DWORD). After the next reboot, LSASS runs as PPL. The security benefit is immediate: standard credential dumping tools (Mimikatz, procdump, comsvcs.dll MiniDump) fail with “Access Denied.” The operational consideration: some legitimate applications that interact with LSASS (third-party authentication providers, password management tools, legacy SSO solutions) may break if they access LSASS through non-protected code paths. Test before fleet deployment.

PPL bypass techniques. PPL is not a complete defense. Known bypasses include: loading a vulnerable signed kernel driver to disable PPL protection (the “PPLdump” technique), exploiting a Windows vulnerability that downgrades LSASS’s protection level, and using a signed Microsoft binary that has PPL access to proxy the memory read. Each bypass requires elevated privileges and leaves detectable artifacts — making PPL a strong layer in the defense-in-depth architecture rather than a standalone solution.

The combined LSASS protection stack: Credential Guard (isolates the credential cache in VBS) + RunAsPPL (kernel-enforced process access control) + ASR rule (blocks known access patterns) + Custom detection NE-CRED-001 (detects any process accessing LSASS memory) + Sysmon Event ID 10 (captures process access with full context). Five layers, each catching techniques the others miss. This is the defense-in-depth principle applied to a single critical component.

Troubleshooting

“We see Event ID 4648 (explicit credential logon) for processes we don’t recognise.” Event ID 4648 fires when a process explicitly provides credentials (rather than using the current session’s token). Legitimate sources include: task scheduler (running tasks as a specific user), IIS application pools (using configured identities), and backup software (using stored credentials). Malicious sources include: pass-the-hash tools, lateral movement frameworks, and credential stuffing. Investigate the source process (SubjectUserName, ProcessName) and determine whether the explicit credential use is expected.

“We want to disable NTLM entirely but don’t know the blast radius.” Enable NTLM auditing first. Group Policy: Network security → Restrict NTLM → Audit incoming/outgoing NTLM traffic. This generates Event IDs 8001-8004 in the Microsoft-Windows-NTLM/Operational log, showing every NTLM authentication attempt with the source application. Collect 2-4 weeks of data. The audit results identify every application and service that depends on NTLM. Address each dependency before enforcing NTLM restriction.

“Can I enable RunAsPPL on domain controllers?” Yes, and Microsoft recommends it. DCs are the highest-value LSASS targets — PPL protection on DCs prevents DCSync credential extraction from non-protected processes. Test with third-party AD management tools first — some older tools access LSASS through code paths that PPL blocks. Monitor the Application event log for PPL-related access denied events (source: Wininit, event ID 12) during testing to identify incompatible components before fleet deployment. If a third-party tool requires LSASS access and is incompatible with PPL, evaluate whether the tool can be replaced with a PPL-compatible alternative — the security benefit of PPL on domain controllers justifies replacing legacy tooling.