Dumping Credentials from the Windows Registry

There are numerous post-exploitation techniques that an attacker can utilize once an initial foothold has been obtained. One of most prominent techniques is?OS credential dumping, and some relevant areas of interest are the Windows Registry and the LSASS process memory. An attacker could look to move laterally in the environment by utilizing these credentials to compromise additional servers or services.

One place of particular interest for an attacker is the Windows Registry. The Windows Registry is a collection of databases that stores low-level configuration settings and application settings. A registry hive is a section in the registry that contains registry keys, subkeys, and registry values. The Security Account Manager (SAM) is a particular registry hive that stores credentials and account information for local users. User passwords are stored in a hashed format in the SAM registry hive either as an LM hash or an NT hash, depending on Group Policy settings. The LM hash is a legacy hashing algorithm enabled by default for backwards compatibility on Windows versions before Windows Vista and Windows Server 2008. Microsoft however recommends disabling storage of all LM hashes wherever possible as LM hashes are now considered to be cryptographically weak. It is possible for an attacker to brute force the entire key space within a relatively short amount of time. If the hashes were captured by an attacker, the hash can be easily cracked with the use of rainbow tables or password guessing attacks.

The SAM registry can be found in?%SystemRoot%\System32\config\SAM. Starting with Windows 2000 and above, the SAM hive is also encrypted by the SysKey by default in an attempt from Microsoft to make the hashes harder to access. However, the SysKey can be extracted from the SYSTEM registry hive, which can be located at?%SystemRoot%\System32\config\SYSTEM. If an attacker can extract or copy these two files, then the attacker can successfully obtain the LM/NT hashes of all local accounts on the system. The SAM file is locked from reading and copying while the system is on. However, there are still several ways that an attacker could obtain the SAM if the attacker has local administrator privileges. An attacker could use a python program named secretsdumpy.py from Impacket, look for backup SAM files in?C:\Windows\Repair\SAM, or utilize other tools such as CrackMapExec. CrackMapExec extracts the SAM and LSA Secrets using functions from secretsdump.py. Alternatively, we can also exploit the vulnerability described in, CVE 2021-36934, denoted as HiveNightmare, that allowed non-admin users to potentially read the SAM file at?C:\Windows\System32\config\SAM. To get a copy of the SYSTEM and SAM registry hives, we can save them using reg.exe from a privileged shell with following commands:

reg.exe save hklm\sam C:\temp\sam.savereg.exe save hklm\system C:\temp\system.save

The SAM can be decrypted using secretsdump.py from Impacket. Once we have extracted an Administrator password hash, we can try to perform Pass-the-Hash attack with the retrieved hash to compromise additional systems. Oftentimes, we observe that local Administrator passwords are re-used between systems within an environment. One solution that we can implement to combat this is by implementing Microsoft’s Local Administrator Password Solution (LAPS). LAPS acts as a password manager and generates unique local Administrator passwords for each system. The passwords can also be rotated on a regular basis. Another area where credentials are stored is LSA Secrets, located at?HKEY_LOCAL_MACHINE\Security\Policy\Secrets. LSA Secrets is used by the Local Security Authority (LSA) as storage, and oftentimes information such as auto-login service accounts or VPN credentials may be stored here. Credentials for service accounts may be found stored in plaintext as the actual password must be read for the service account to start as that service. Oftentimes it is observed that cleartext passwords for service accounts saved within LSA Secrets, and these service accounts are often highly privileged, which allows us to move laterally to compromise additional systems. To extract LSA Secrets, we will need SYSTEM privileges on the host. LSA Secrets is stored within the Security Registry, and we still need the Syskey from the System hive so we can decrypt the contents of LSA Secrets. We can then extract the LSA Secrets using secretsdump from Impacket.

Thanks to Jimmy Chang from Praetorian for the original idea.