There are several post-exploitation techniques that an attacker can utilize to gather information and compromise assets. One of these techniques is OS credential dumping, and some relevant areas of interest are the Windows Registry and the LSASS process memory. By obtaining additional credentials, an attacker could look to move laterally in the environment by utilizing these credentials to compromise additional systems or services.
Extracting Account information from Windows Registry
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 settings for applications. 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 developed in 1987 and is enabled by default for backwards compatibility on Windows versions before Windows Vista/Windows Server 2008. However, Microsoft recommends disabling storage of all LM hashes wherever possible as LM hashes are now considered to be cryptographically insecure. 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 a brute force password guessing attack within a few minutes to a few hours.
The SAM registry can be found in %SystemRoot%System32configSAM. 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%System32configSYSTEM. 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/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 secretsdumpy.py from Impacket, look for backup SAM files in C:WindowsRepairSAM, or utilize other tools such as CrackMapExec. CrackMapExec extracts the SAM and LSA Secrets using functions from secretsdump.py. Alternatively, there was a recent vulnerability discovered, CVE 2021-36934, denoted as HiveNightmare, that allowed non-admin users to potentially read the SAM file at C:WindowsSystem32configSAM. More details for this particular vulnerability can be found here.
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 hklmsam C:tempsam.savereg.exe save hklmsystem C:tempsystem.save
The SAM can be decrypted using secretsdump.py from Impacket:
[image id=”3136″ filter=”false”]
One thing to note is that most modern Windows versions do not store passwords in LM format by default, and the string aad3b435b51404eeaad3b435b51404ee, called the Null LM hash, signifies that it is empty.
Once we have extracted an Administrator password hash, we can try to perform Pass-the-Hash with the retrieved hash to compromise additional systems. Oftentimes, we discover that local Administrator passwords are re-used between systems within an environment. One solution that we typically recommend to our clients 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. Other software such as CyberArk and Thycotic Secret Server are also potential solutions for managing local administrator access.
Another area where credentials are stored is LSA Secrets, located at HKEY_LOCAL_MACHINESecurityPolicySecrets. 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 during engagements, we can find 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. From a privileged command prompt, we can run
reg.exe save hklmsecurity C:tempsecurity.savereg.exe save hklmsystem C:tempsystem.save
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 with the command:
python3 secretsdump.py -security security.save -system system.save LOCAL
Detection
There are several methods we could use to monitor for unauthorized access to the registry. The reader should keep in mind that the detection methods discussed below may be noisy, and some of the registry keys may already be monitored by the EDR solution, depending on the solution.
To detect suspicious attempts to access the registry, we must enable Registry Auditing so that Windows Security Event Logs will be generated. To enable registry auditing for a system, we must go to “Local Security Policy” settings and turn on “Audit object access” for both success and failed events in the “Audit Policy” under “Local Policies”. The full path for the setting is Security SettingsLocal PoliciesAudit PolicyAudit object access.
[image id=”3137″ filter=”false”]
This setting can also be set in the domain through the Group Policy Management Editor from the domain controller by going to Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesAudit PolicyAudit object access.
Once auditing for object access has been enabled, we need to create audit policies for the specific registry keys we are interested in monitoring. We want to limit registry auditing to only keys and subkeys we are interested in because these policies will generate a lot of noise that may become difficult to filter through over time. To create an audit policy for the SAM registry and its subkeys, we need to use Registry Editor and browse to HKEY_LOCAL_MACHINE/SAM. You can edit the audit permissions of this hive by right clicking SAM -> Permissions -> Advanced -> Auditing. Within the settings dialogue, we can specify the following audit permissions:
- Query Value – audits any attempts to query the value of a registry key
- Enumerate Subkeys – audits any attempts to identify the subkeys of a registry key
- Read Control – audits any attempts to open the ACL on a key
This will generate an event log entry whenever the value of the registry or its subkeys are queried. Lastly, we want to make sure that the Principal is set to Everyone so that all users are audited.
[image id=”3138″ filter=”false”]
The registry permissions can also be applied through GPO using the Group Policy Management Editor and browsing to Computer ConfigurationPoliciesWindows SettingsSecurity SettingsRegistry. We can then right click to Add key, select the relevant key, and add audit permissions for that specific key.
[image id=”3139″ filter=”false”]
After applying these settings, we can attempt to again save the SAM registry hive with reg.exe as discussed earlier in the blog post. After looking in Security Event Logs in Event Viewer, we can see that Event ID 4656 was generated when we tried to save the SAM registry key with reg.exe.
[image id=”3140″ filter=”false”]
However, these settings will likely still generate a lot of logs, as these registry keys are often queried by legitimate system processes. To help parse through events, there have been several pre-written Sigma signatures that we can use. Sigma is an open-source generic signature format that can be used to convert into SIEM signatures that each SIEM can understand. This signature can be used to detect handles requested to the SAM registry hive. This signature can be used to detect when reg.exe is used to query or copy the SAM registry hive.
Similar settings should also be used to monitor the SYSTEM and SECURITY registry hives, as the SYSTEM hive is needed to extract the SysKey to decrypt the SAM and LSA Secrets, while the SECURITY registry hive contains LSA Secrets.
Another recommendation we often give our clients is to turn on process creation auditing. This will generate Windows security event log ID 4688, which will document each program that the computer executes, the process that started this process, and who the process ran as. Process creation auditing can be extremely noisy, but it is vital in helping investigators and responders understand the chain of events and the processes that were created in the event of an incident. To turn on process creation auditing, we need to go to Security SettingsAdvanced Audit Policy ConfigurationSystem Audit Policies – Local GroupDetailed TrackingAudit Process Creation in Local Security Policy settings. Auditing for success and failure events should both be enabled. This setting can also be enabled via GPOs in Windows SettingsSecurity SettingsAdvanced Audit Policy ConfigurationAudit PoliciesDetailed TrackingAudit Process Creation.
[image id=”3141″ filter=”false”]
After attempting to save a copy of the SAM registry hive, we see that a 4688 event is generated in Windows Security Logs. The event was a Type 2 Token Elevation Event (%%1937), indicating that a PowerShell process was run with administrator privileges.
[image id=”3142″ filter=”false”]
Though this may not be evidence of malicious activity by itself, it may warrant a deeper investigation by a security analyst if it was from an abnormal user or if it is not expected behavior.
This blog covers some common and basic OS credential dumping techniques that an attacker may use to extract credentials from the Windows Registry with local Administrator privileges. With sufficient registry auditing and process monitoring, it is possible for defenders to quickly detect and respond to malicious activity and contain an incident before it spreads.
References
https://attack.mitre.org/techniques/T1003/001/
https://www.praetorian.com/blog/microsofts-local-administrator-password-solution-laps/
https://medium.com/threatpunter/detecting-attempts-to-steal-passwords-from-the-registry-7512674487f8
https://helpcenter.netwrix.com/NA/Configure_IT_Infrastructure/File_Servers/EMC_VNX_VNXe/EMC_Audit_Object_Access.html
https://logrhythm.com/blog/how-to-enable-process-creation-events-to-track-malware-and-threat-actor-activity/
https://www.sentinelone.com/blog/windows-security-essentials-preventing-4-common-methods-of-credentials-exfiltration/
https://moyix.blogspot.com/2008/02/decrypting-lsa-secrets.html
https://isc.sans.edu/forums/diary/Pillaging+Passwords+from+Service+Accounts/24886/
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-registry
https://www.andrew.cmu.edu/user/tgoyal1/Credential_Stealing_NATO.pdf
https://logrhythm.com/blog/how-to-enable-process-creation-events-to-track-malware-and-threat-actor-activity/
https://nakedsecurity.sophos.com/2021/07/21/windows-hivenightmare-bug-could-leak-passwords-heres-what-to-do/
