Cached Domain Credentials (T1003.005) is a credential access sub-technique for Windows and Linux. Systems cache domain credentials so a user can still authenticate when a domain controller is unavailable. Adversaries try to read those caches.
How attackers use it
On Windows Vista and newer, the cached hash format is DCC2, also called MS-Cache v2. MITRE notes this hash does not allow pass-the-hash style attacks. Instead the adversary has to crack the password offline. The number of cached credentials varies by system and can be changed.
On Linux, Active Directory credentials may be cached by software such as the System Security Services Daemon (SSSD) or Quest Authentication Services. MITRE gives the default cache locations, a file under /var/lib/sss/db for SSSD and a file under /var/opt/quest/vas/authcache for Quest. Utilities such as tdbdump can dump the cached hashes, which are then cracked offline. With SYSTEM or sudo access, tools such as Mimikatz, Reg and secretsdump.py on Windows, or Linikatz on Linux, can extract the cached credentials.
How to detect it
MITRE's analytics cover both platforms:
- Windows: access to the cached credential data using tools like Mimikatz, reg.exe or PowerShell, often combined with registry exports or LSASS memory scraping.
- Linux: access to the SSSD or Quest cache databases using tdbdump or other file access patterns, which requires sudo or root.
Use process creation logs with command lines, registry auditing, and on Linux, auditd file watches on the cache locations. Reads of those database files by anything other than the cache daemon itself are rare and meaningful.
How to reduce the risk
MITRE lists:
- Active Directory Configuration: consider adding users to the Protected Users security group, which helps limit the caching of plaintext credentials.
- Operating System Configuration: consider limiting the number of cached credentials with the cachedlogonscount value under the Winlogon registry key.
- Password Policies: complex, unique local administrator passwords.
- Privileged Account Management: keep domain accounts out of local administrator groups across systems unless tightly controlled.
- User Training: no password reuse across accounts.
Strong passwords matter more here than elsewhere, because cracking is the only way the cached hash becomes useful.
Understanding the trade-off
Cached credentials exist for a good reason. A laptop that cannot reach a domain controller still has to let its owner log on. Setting the cache to zero everywhere would break that. MITRE's advice is to consider limiting the number, which is a middle path.
A practical split:
- Always-on servers in a data center rarely need a cache, so set a low number there.
- Laptops need a few entries so people can work offline.
- Shared kiosks and lab machines depend on how they log on.
Document the choice per group of machines, and apply it through group policy.
Why strong passwords carry this one
The DCC2 hash cannot be passed along as it is. An adversary has to crack it, and that is a race against your password quality. Long passphrases make the race hard to win. A password policy that encourages length, and a check against known breached passwords, helps more than complexity rules alone.
On the Linux side
Hosts joined to Active Directory through SSSD or similar software keep their own cache. Keep that directory readable only by root and the daemon, audit reads of the cache files, and treat sudo rights on joined hosts as a route to domain credentials. Limiting who has sudo on those machines is part of the control.
Check your own environment
To see how many credentials a Windows host caches (reg.exe, read-only):
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount
Servers that are always online usually need a low number. Laptops that travel need more.
On Linux hosts that join a domain through SSSD, list who can read the cache directory:
ls -ld /var/lib/sss/db
Only root and the daemon should have access.
Quick check
Can a cached DCC2 hash be used for pass-the-hash?
No. MITRE says it does not allow pass-the-hash style attacks and instead requires password cracking to recover the plaintext.
