Authentication
AD authentication uses NTLM (legacy) and Kerberos (default) protocols. NTLM is vulnerable to brute force; Kerberos uses tickets and session keys but can be abused (e.g., ticket theft). Credentials are cached in LSASS memory for SSO, and can be extracted using tools like mimikatz if attackers gain SYSTEM-level access. Defenses include LSA Protection, disabling WDigest, and endpoint monitoring.
For enumeration or post-authentication interaction, when using AD credentials with tools that rely on impersonation or token delegation, RDP is preferred over PowerShell Remoting or WinRM:
RDP cleanly passes credentials through the session
Remoting protocols are impacted by the Kerberos double-hop limitation.
NTML
NTLM (NT LAN Manager) is a legacy authentication protocol that still appears in modern AD environments, particularly in fallback situations, such as when connecting to resources via IP address rather than hostname, or when a service isn’t properly registered in AD DNS. Some third-party applications also continue to prefer NTLM over Kerberos due to compatibility reasons.
The client creates an NTLM hash from the user’s password (Step 1) and sends the username to the server (Step 2).
The server replies with a randomly generated nonce, aka challenge (Step 3).
The client sends the response (the NTML-encypted nonce) back the server (Step 4).
The server forwards the username, nonce, and response to the DC (Domain Controller) (Step 5).
The DC uses the stored NTLM hash for that user to encrypt the nonce (Step 6) and if the result matches the response, authentication succeeds (Step 7).
NTML stores unsalted hashed passwords in SAM database (c:\windows\system32\config\sam) which cannot be copied while the Windows OS is running. Local Security Authority System (LSASS) runs with SYSTEM privileges and caches NTLM hashes.
Although NTLM hashes are non-reversible, the algorithm is very fast, making brute-force attacks relatively easy. Despite its weaknesses, NTLM remains in use primarily for compatibility with legacy systems and fallback scenarios.
Kerberos
For Kerberos-related information, see here.
Cached Credentials
The Local Security Authority (LSA) is a fundamental Windows subsystem responsible for enforcing security policies, managing authentication, and handling credential storage. Its functionality is carried out by the Local Security Authority Subsystem Service (LSASS) — the lsass.exe process — which runs in memory and performs tasks such as logon validation and credential caching.
OPSEC: LSASS is the core auth component which makes it the most monitored process on a Windows host!
To support Single Sign-On (SSO) and optimize user experience, Windows stores authentication material (e.g., NTLM hashes, Kerberos tickets, and sometimes plaintext credentials) in the memory of LSASS. When users authenticate (via local login, RDP, runas, scheduled tasks, services, etc.), their credential artifacts are stored in LSASS. Although this memory is encrypted and undocumented, with sufficient privileges (typically SYSTEM-level), attackers can extract its contents to harvest credentials.
Credentials Vault
The Windows Credentials Vault, also known as Credential Manager, is a secure credential storage mechanism in Windows that retains user credentials for websites, network shares, remote desktop connections, and applications. It enables seamless authentication by allowing the OS and applications to retrieve saved credentials without prompting the user repeatedly.
Stored credentials are encrypted and kept in a protected location on the system. They can be accessed via the Control Panel (Credential Manager UI) or programmatically through the Windows Credential API.
While not as commonly targeted as LSASS, the vault can contain plaintext domain credentials, particularly for scheduled tasks or service accounts. Tools like Mimikatz can extract these credentials using commands like vault::cred /patch, provided the attacker has elevated privileges.
Last updated