Windows Cached Logon Credentials – A Hidden Risk to Enterprise Security

Introduction

In the world of enterprise IT, ensuring availability and usability is as critical as securing the environment. One such Windows feature that exists to help users log in during domain controller (DC) unavailability is “Cached Logon Credentials.” While this feature may seem harmless—or even useful—at first glance, it poses serious risks when viewed from a cybersecurity lens. Attackers often take advantage of it during lateral movement and post-exploitation scenarios.
This blog explores the vulnerabilities posed by cached logon credentials, focusing on Qualys Vulnerability ID 90007, and provides insights into mitigation strategies, real-world attack vectors, and the security trade-offs associated with disabling this feature.

What Are Cached Logon Credentials?

Windows operating systems use cached credentials to allow users to log on to a machine even when it cannot contact a domain controller. This behavior is designed to support productivity in environments where laptops or desktops may occasionally be disconnected from the network—like when a user is traveling or experiencing network issues.
By default, Windows caches the credentials of the last 10 users who logged in interactively. These credentials are stored in the registry in a hashed format, and while not in plain text, they can still be extracted and cracked by an attacker with sufficient access.

Default Registry Path:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Key of Interest:
CachedLogonsCount
Type: REG_SZ
o Values:
  0 = Disabled (no caching)
  1–50 = Number of logon credentials to cache
o Default: 10 (except Windows Server 2008)

When Do Cached Credentials Come into Play?

Here’s what happens when a user tries to log in while a domain controller is unavailable:
• With Caching Enabled:
The user sees:
“A domain controller for your domain could not be contacted. You have been logged on using cached account information.”

• With Caching Disabled:
The user sees:
“The system cannot log you on now because the domain is not available.”
Thus, caching helps maintain productivity in limited cases. However, what is intended as a usability feature can become a significant attack surface if exploited.

Threat Analysis: Qualys ID 90007

Qualys ID: 90007
Threat: Cached credentials stored on Windows machines can be harvested by attackers during post-exploitation activities.
Severity: High
Affected Systems: All Windows versions (client and server)

Risk Summary

If an attacker gains local admin privileges on a Windows system, tools like Mimikatz or Metasploit modules can be used to extract these cached hashes. These hashes can then be cracked offline using brute-force or dictionary attacks. The risk multiplies when privileged accounts (e.g., domain admins or local administrators) have their credentials cached—these can be used for lateral movement or privilege escalation across the network.

Exploitation in the Wild

Penetration Testing Scenarios

In a typical red team engagement or real-world attack scenario:
1. The attacker compromises a system (often through phishing or an unpatched vulnerability).
2. Gains SYSTEM or administrator access.
3. Executes a post-exploitation module:
   o In Metasploit: post/windows/gather/cachedump
   o In Mimikatz: lsadump::cache
4. Extracts and exfiltrates NTLM hashes.
5. Uses password cracking tools (e.g., Hashcat) to convert NTLM hashes to plaintext credentials.
6. Reuses valid credentials on other machines via RDP, SMB, or PSExec—often without triggering security alerts if network segmentation or LAPS isn’t used.

Real-World Risks

1. Lateral Movement

Attackers use cached credentials to move laterally through an environment. If a domain administrator logs onto a vulnerable machine even once, their credentials can be cached and reused later—even after logout.

2. Persistence

Even if a user no longer logs into a system, cached credentials remain for days or weeks until overwritten by other logins or manually cleared.

3. Offline Attacks

Cached credentials allow for offline brute-force attacks. Since there’s no account lockout threshold or detection on offline cracking tools, attackers can eventually recover weak passwords.

4. Privileged Account Exposure

Any cached privileged account can lead to domain-wide compromise if reused or cracked.

Mitigation Strategy

Step 1: Disable Cached Logons

To disable caching entirely, set the following registry key:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon]
“CachedLogonsCount”=”0”
This ensures that no credentials are stored on disk. You can automate this change using GPO, Intune, or configuration management tools like Ansible or SCCM.
Note: Setting this value to 0 disables logon caching. Values above 50 are not accepted.

Step 2: Limit Privileged Logons

Enforce a policy where privileged accounts (domain admins, service accounts) are restricted from logging into non-secure systems such as workstations. Use Group Policy to prevent domain admin logins on workstations or member servers.

Step 3: Implement Microsoft LAPS (Local Administrator Password Solution)

LAPS automatically randomizes and rotates the local administrator password for every device in your environment and stores it securely in Active Directory. This minimizes the risk of lateral movement and ensures that cached credentials of local accounts aren’t reusable across systems.

Step 4: Harden Password Policies

Strong passwords reduce the likelihood of successful cracking attempts. Consider the following:
• Use 14+ character complex passwords.
• Implement password managers to avoid reuse.
• Enforce periodic password changes with MFA.

Challenges with Disabling Caching

While disabling cached credentials significantly improves security, it comes with operational challenges:

1. Remote Worker Access

If a domain controller is unavailable (e.g., during VPN issues or remote access problems), users may be unable to log in.
Mitigation: Ensure that remote users have always-on VPN or cached VPN credentials to maintain DC connectivity.

2. Field Engineers or Traveling Staff

Users traveling or working offsite may face login failures if no domain controller is reachable.
Mitigation: Create a secondary secure local user account or enable limited caching (e.g., CachedLogonsCount=1) for select systems.

3. Break-Glass Scenarios

Some emergency accounts may need cached credentials for DR.
Mitigation: Clearly document and audit any system where caching is enabled intentionally.

Detection and Auditing

How to Check for Cached Credentials
You can query the registry locally or remotely to identify the setting:
Get-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon’ -Name CachedLogonsCount
A value of 0 indicates caching is disabled.

Auditing Tools
• Qualys, Tenable, and Rapid7 provide detections (e.g., QID 90007) for environments where caching is enabled.
• Use Microsoft Defender for Endpoint or Sysmon to log credential access behavior.
• LAPS reporting tools help validate password rotation across endpoints.

Closing summary

While cached logon credentials are meant to enhance user experience, especially during outages, they also represent a soft underbelly in Windows enterprise security. As attackers get smarter and use legitimate features for malicious purposes, it is our duty to lock down low-hanging fruit.
By disabling cached logons, enforcing least privilege, and deploying tools like Microsoft LAPS, organizations can dramatically reduce the attack surface and secure their environment against lateral movement and credential harvesting.