{
	"id": "047ffdf4-4a68-443c-b036-73f0d232f65f",
	"created_at": "2026-04-06T02:11:59.804278Z",
	"updated_at": "2026-04-10T13:12:28.809662Z",
	"deleted_at": null,
	"sha1_hash": "ee267e148919d91380f23a3978a6024adc8f3b5d",
	"title": "Cached and Stored Credentials Technical Overview",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 58169,
	"plain_text": "Cached and Stored Credentials Technical Overview\r\nBy Archiveddocs\r\nArchived: 2026-04-06 02:03:19 UTC\r\nApplies To: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2,\r\nWindows Server 2012 R2, Windows Server 2012, Windows 8\r\nThis topic for the IT professional describes how credentials are formed in Windows and how the operating system\r\nmanages them.\r\nWhen a user or service wants to access a computing resource, they must provide information that proves their\r\nidentity. Their identity is typically in the form of their account’s user name. This might be the user name that is the\r\nSecurity Accounts Manager (SAM) account name or the User Principal Name (UPN). But to prove their identity,\r\nthey must provide secret information, which is called the authenticator. An authenticator can take various forms\r\ndepending on the authentication protocol and method. The combination of an identity and an authenticator is\r\ncalled an authentication credential.\r\nThe process of creating, submitting, and verifying credentials is described simply as authentication, which is\r\nimplemented through various authentication protocols, such as the Kerberos protocol. Authentication establishes\r\nthe identity of the user, but not necessarily the user’s permission to access or change a specific computing\r\nresource. That process is known as authorization.\r\nCredentials are typically created or converted to a form that is required by the authentication protocols that are\r\navailable on a computer. Credentials can be stored in the Local Security Authority Subsystem Service (LSASS)\r\nprocess memory for use by the account during a session. Credentials must also be stored on a hard disk drive in\r\nauthoritative databases, such as the SAM database and in the database that is used by Active Directory Domain\r\nServices (AD DS).\r\nFor more information about storage, see Credentials storage in this topic.\r\nThe authenticator types used in the Windows operating system are as follows:\r\nWhen a user signs in to a computer running Windows and provides a user name and credentials (such as a\r\npassword or PIN), the information is provided to the computer in plaintext. This plaintext password is used to\r\nauthenticate the user’s identity by converting it into the form that is required by the authentication protocol. Some\r\nversions of Windows also retain an encrypted copy of this password that can be unencrypted to plaintext for use\r\nwith authentication methods such as Digest authentication.\r\nNote\r\nWindows operating systems never store any plaintext credentials in memory or on the hard disk drive. Only\r\nreversibly encrypted credentials are stored there. When later access to the plaintext forms of the credentials is\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh994565(v%3Dws.11)\r\nPage 1 of 5\n\nrequired, Windows stores the passwords in encrypted form that can only be decrypted by the operating system to\r\nprovide access in authorized circumstances.\r\nThese protections, however, cannot prevent a malicious user with system-level access from illicitly extracting\r\nthem in the same manner that the operating system would for legitimate use.\r\nThe NT hash of the password is calculated by using an unsalted MD4 hash algorithm. MD4 is a cryptographic\r\none-way function that produces a mathematical representation of a password. This hashing function is designed to\r\nalways produce the same result from the same password input, and to minimize collisions where two different\r\npasswords can produce the same result. This hash is always the same length and cannot be directly decrypted to\r\nreveal the plaintext password. Because the NT hash only changes when the password changes, an NT hash is valid\r\nfor authentication until a user’s password is changed.\r\nNote\r\nTo protect against brute-force attacks on the NT hashes or online systems, users who authenticate with passwords\r\nshould set strong passwords or passphrases that include characters from multiple sets and are as long as the user\r\ncan easily remember. For password complexity guidelines, see the Strong passwords section in the Passwords\r\nTechnical Overview.\r\nLAN Manager (LM) hashes are derived from the user password. Legacy support for LM hashes and the LAN\r\nManager authentication protocol remains in the NTLM protocol suite. Default configurations in Windows and\r\nMicrosoft security guidance have discouraged its use.\r\nLM hashes inherently are more vulnerable to attacks because:\r\nLM hashes require a password to be less than 15 characters long and they contain only ASCII characters.\r\nLM hashes do not differentiate between uppercase and lowercase letters.\r\nThese verifiers are not credentials because they cannot be presented to another computer for authentication, and\r\nthey can only be used to locally verify a credential. They are stored in the registry on the local computer and\r\nprovide credentials validation when a domain-joined computer cannot connect to AD DS during a user’s logon.\r\nThese “cached logons” or more specifically, cached domain account information, can be managed using the\r\nsecurity policy setting Interactive logon: Number of previous logons to cache (in case domain controller is not\r\navailable).\r\nThe following sections describe where credentials are stored in Windows operating systems. Windows credentials\r\nare composed of a combination of an account name and the authenticator. These are stored and retrieved from the\r\nfollowing locations depending on the status of the user’s session, which might be active or inactive, and local or\r\nnetworked.\r\nThe SAM database is stored as a file on the local hard disk drive, and it is the authoritative credential store for\r\nlocal accounts on each Windows computer. This database contains all the credentials that are local to that specific\r\ncomputer, including the built-in local Administrator account and any other local accounts for that computer.\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh994565(v%3Dws.11)\r\nPage 2 of 5\n\nThe SAM database stores information on each account, including the user name and the NT password hash. By\r\ndefault, the SAM database does not store LM hashes on current versions of Windows. No password is ever stored\r\nin a SAM database—only the password hashes. The NT password hash is an unsalted MD4 hash of the account’s\r\npassword. This means that if two accounts use an identical password, they will also have an identical NT\r\npassword hash.\r\nThe Local Security Authority Subsystem Service (LSASS) stores credentials in memory on behalf of users with\r\nactive Windows sessions. This allows users to seamlessly access network resources, such as file shares, Exchange\r\nServer mailboxes, and SharePoint sites, without re-entering their credentials for each remote service.\r\nLSASS can store credentials in multiple forms, including:\r\nReversibly encrypted plaintext\r\nKerberos tickets (TGTs, service tickets)\r\nNT hash\r\nLM hash\r\nIf the user logs on to Windows by using a smart card, LSASS will not store a plaintext password, but it will store\r\nthe corresponding NT hash value for the account and the plaintext PIN for the smart card. If the account attribute\r\nis enabled for a smart card that is required for interactive logon, a random NT hash value is automatically\r\ngenerated for the account instead of the original password hash. The password hash that is automatically generated\r\nwhen the attribute is set does not change.\r\nIf a user logs on to Windows with a password that is compatible with LM hashes, this authenticator will be present\r\nin memory.\r\nThe storage of plaintext credentials in memory cannot be disabled, even if the credential providers that require\r\nthem are disabled.\r\nThe stored credentials are directly associated with the LSASS logon sessions that have been started since the last\r\nrestart and have not been closed. For example, LSA sessions with stored LSA credentials are created when a user\r\ndoes any of the following:\r\nLogs on to a local session or RDP session on the computer\r\nRuns a task by using the RunAs option\r\nRuns an active Windows service on the computer\r\nRuns a scheduled task or batch job\r\nRuns a task on the local computer by using a remote administration tool\r\nA Local Security Authority (LSA) secret is a secret piece of data that is accessible only to SYSTEM account\r\nprocesses. Some of these secrets are credentials that must persist after reboot, and they are stored in encrypted\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh994565(v%3Dws.11)\r\nPage 3 of 5\n\nform on the hard disk drive. Credentials stored as LSA secrets might include:\r\nAccount password for the computer’s AD DS account\r\nAccount passwords for Windows services that are configured on the computer\r\nAccount passwords for configured scheduled tasks\r\nAccount passwords for IIS application pools and websites\r\nThe Active Directory Domain Services (AD DS) database is the authoritative store of credentials for all user and\r\ncomputer accounts in an AD DS domain. The two types of domain controllers in AD DS that manage credentials\r\ndifferently are:\r\nWritable   Each writable domain controller in the domain contains a full copy of the domain’s AD DS database,\r\nincluding account credentials for all accounts in the domain.\r\nRead-only   Read-only domain controllers (RODCs) house a partial local replica with credentials for a select\r\nsubset of the accounts in the domain. By default, RODCs do not have a copy of privileged domain accounts.\r\nThe database stores a number of attributes for each account, which includes user names types and the following:\r\nNT hash for the current password\r\nNT hashes for password history (if configured)\r\nNT hash values are also retained in AD DS for previous passwords to enforce password history during password\r\nchange operations. The number of password history NT hash values retained is equal to the number of passwords\r\nconfigured in the password history enforcement policy.\r\nLM hashes may also be stored in the AD DS database depending on the domain controller operating system\r\nversion, configuration settings, and password change frequency.\r\nUsers may choose to save passwords in Windows by using an application or through the Credential Manager\r\nControl Panel applet. These credentials are stored on the hard disk drive and protected by using the Data\r\nProtection Application Programming Interface (DPAPI). Any program running as that user will be able to access\r\ncredentials in this store.\r\nCredential Manager can obtain its information in two ways:\r\nExplicit creation   When users enter a user name and password for a target computer or domain, that information\r\nis stored and used when the users attempt to log on to an appropriate computer. If no stored information is\r\navailable and users supply a user name and password, they can save the information. If the user decides to save the\r\ninformation, Credential Manager receives and stores it.\r\nSystem population   When the operating system attempts to connect to a new computer on the network, it\r\nsupplies the current user name and password to the computer. If this is not sufficient to provide access, Credential\r\nManager attempts to supply the necessary user name and password. All stored user names and passwords are\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh994565(v%3Dws.11)\r\nPage 4 of 5\n\nexamined, from most specific to least specific as appropriate to the resource, and the connection is attempted in\r\nthe order of those user names and passwords. Because user names and passwords are read and applied in order,\r\nfrom most to least specific, no more than one user name and password can be stored for each individual target or\r\ndomain.\r\nCredential Manager uses the Credential Locker, formerly known as Windows Vault, for secure storage of user\r\nnames and passwords.\r\nPasswords Technical Overview\r\nWindows Logon and Authentication Technical Overview\r\nCredential Locker Overview\r\nSource: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh994565(v%3Dws.11)\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh994565(v%3Dws.11)\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh994565(v%3Dws.11)"
	],
	"report_names": [
		"hh994565(v%3Dws.11)"
	],
	"threat_actors": [],
	"ts_created_at": 1775441519,
	"ts_updated_at": 1775826748,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ee267e148919d91380f23a3978a6024adc8f3b5d.pdf",
		"text": "https://archive.orkl.eu/ee267e148919d91380f23a3978a6024adc8f3b5d.txt",
		"img": "https://archive.orkl.eu/ee267e148919d91380f23a3978a6024adc8f3b5d.jpg"
	}
}