Cached AD Credentials

When attacking a Windows domain, one of the most valuable targets is cached authentication material. Modern Windows systems are designed for usability and performance, and features like Single Sign-On (SSO) rely heavily on credentials being stored in memory. From a red team perspective, this design choice creates a powerful opportunity.

Microsoft’s implementation of Kerberos authentication enables users to log in once and access multiple domain resources without repeatedly entering their password. To make this possible, Windows must store credential material so it can renew Ticket Granting Tickets (TGTs) when needed.

On modern Windows systems, these credential artifacts—such as password hashes and Kerberos tickets—are stored in the memory of a highly sensitive process called:

Local Security Authority Subsystem Service (LSASS)

LSASS is responsible for enforcing security policies, handling logons, and managing authentication secrets. If an attacker can read LSASS memory, they can often extract credential material for logged-on users.

If we gain access to cached hashes, we can:

• Crack them offline to recover cleartext passwords
• Reuse them directly in attacks like Pass-the-Hash
• Extract Kerberos tickets for Pass-the-Ticket attacks

The challenge is access control. LSASS runs as NT AUTHORITY\SYSTEM, which means:

• A normal user cannot read its memory
• Even a standard administrator is restricted

To interact with LSASS, we must first achieve local privilege escalation to obtain Administrator or SYSTEM privileges. This step is critical in almost every real-world Windows attack chain.

Once we have elevated privileges, specialized tools can be used to extract credentials from LSASS. The most well-known tool for this purpose is Mimikatz.

Mimikatz allows attackers to:

• Extract password hashes from memory
• Dump Kerberos tickets
• Bypass certain cryptographic protections
• Abuse authentication mechanisms without knowing passwords

Detection Considerations

Mimikatz is extremely well-known and has strong detection signatures. Running it directly as a standalone executable is likely to trigger antivirus or EDR alerts.

From an offensive perspective, safer approaches include:

• Executing Mimikatz directly from memory (for example, via PowerShell injection)
• Dumping the LSASS process memory using built-in Windows tools (such as Task Manager)
• Transferring the memory dump to another machine and analyzing it offline with Mimikatz

Dumping Credentials from LSASS

After gaining administrative access, a typical workflow looks like this:

1. Open a PowerShell session as Administrator
2. Launch Mimikatz
3. Enable debug privileges to interact with protected processes

Inside Mimikatz, the first step is enabling SeDebugPrivilege, which allows interaction with processes owned by other accounts:

privilege::debug


Once enabled, we can extract credentials for all logged-on users using the Sekurlsa module:

sekurlsa::logonpasswords


Understanding the Output

The output typically includes several credential types. Depending on the Windows version, you may see:

• NTLM hashes
• SHA-1 hashes
• WDigest credentials (on older systems)

For example:

• Windows Server 2003 often exposes only NTLM hashes
• Windows Server 2008 and newer systems usually expose NTLM and SHA-1
• Older systems may store WDigest credentials, which can reveal cleartext passwords directly

Once hashes are obtained, attackers can crack them offline or reuse them in authentication attacks without cracking at all.

Mimikatz is not limited to password extraction. One of its most powerful capabilities is abusing Kerberos tickets.

When a user accesses a domain resource, Windows stores their:

• TGT (Ticket Granting Ticket)
• TGS (Service Ticket)

These tickets are cached in LSASS memory to support future authentication requests.

If an attacker extracts these tickets, they can authenticate as the user without knowing the password.

This technique is known as Pass-the-Ticket.

Creating and Stealing Tickets

To demonstrate ticket caching, an attacker can force the system to authenticate to a service. For example, listing an SMB share on a remote server will generate a service ticket:

dir \\web04.corp.com\backup


After this action, Kerberos tickets are loaded into memory. Using Mimikatz, we can list all cached tickets:

sekurlsa::tickets


The output typically shows both TGTs and TGSs.

Why TGTs Matter More

• A TGS allows access only to the specific service it was issued for
• A TGT can be used to request new service tickets for any service in the domain

This means stealing a TGT gives far broader access and significantly increases attacker mobility inside the domain.

Exporting and Reusing Tickets

Mimikatz can also:

• Export Kerberos tickets to disk
• Import stolen tickets back into LSASS

This allows attackers to move tickets between systems or reuse them at a later time, extending persistence without passwords.

Active Directory often uses PKI and AD Certificate Services (AD CS) to issue digital certificates for purposes such as:

• HTTPS
• Smart Card authentication
• Client authentication

Some certificates are configured with non-exportable private keys, meaning even administrators should not be able to extract them.

From a red team perspective, this protection is not absolute.

Mimikatz includes a crypto module that can bypass these restrictions by patching cryptographic components in memory:

• crypto::capi – patches legacy CryptoAPI functions
• crypto::cng – patches the Key Isolation (KeyIso) service used by CNG

By doing this, Mimikatz enables the export of private keys that were explicitly marked as non-exportable.