A new vulnerability in Windows 10 and Windows 11 was discovered a few days ago. The vulnerability - SeriousSAM , allows attackers with user account access to perform a Pass-the-Hash (and potentially Silver Ticket) attack. By leveraging this vulnerability, attackers can access hashed passwords that are stored in the Security Account Manager (SAM) and the Registry.
This post will cover:
- SeriousSAM vulnerability.
- How to mitigate SeriousSAM.
- Mitigate without causing damage to production.
SeriousSAM vulnerability:
The vulnerability sources in a default configuration set by Microsoft in Windows 10 and 11. This setting allocates 'read' permissions to the built-in user's group that contains all local users.
As a result, all built-in local users have permission to read both the SAM files and the Registry and can access the hashes stored in them. An attacker gaining 'User' access can use a tool such as Mimikatz to enter the Registry or the SAM, steal the hashes and convert them to passwords. By using it to intrude Domain users, attackers can access the network with elevated privileges.
Your best option for mitigating SeriousSAM vulnerability is to implement hardening actions.
Mitigating SeriousSAM:
Dvir Goren, CTO at CalCom, offers 3 optional hardening actions for mitigation:
- Delete all the users from the built-in users’ group - this is a good place to start from, but won't protect you in case that Administrator credentials will be stolen.
- Restrict SAM files and Registry permissions - allow access only for Administrators. This will, again, solve only part of the problem since if an attacker will steal Admin credentials, you'll be exposed to this vulnerability.
- Do not allow storage of passwords and credentials for network authentication - this rule is also recommended by the CIS in their benchmarks. By implementing this rule, no hash will be stored in the SAM or in the Registry, therefore it is complete mitigation of this vulnerability.
When using GPOs for implementation, make sure that the following UI Path is Enabled:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Network access: Do not allow storage of passwords and credentials for network authentication
Note! Although the last recommendation offers the best solution for the SeriousSAM vulnerability, it may affect your production. You must test this policy’s impact on your production before pushing it!
Applications using scheduled tasks and applications that need to store locally users' hash will fail if this setting is enabled.
Mitigating SeriousSAM without risking causing damage to production
The following are Dvir’s recommendations for mitigating without causing downtime:
- Build a test environment that will simulate your production. Try to be as accurate as possible, to simulate all possible dependencies you have in your network.
- Perform an impact analysis of this rule on your test environment. This way, if you have applications depending on hashes being stored locally, you'll know in advance and prevent production downtime.
- Push the policy where possible. Make sure new machines are also hardened and that no configuration drifts occur over time.
- These three tasks are complex and require in-house expertise and a lot of resources. Therefore, Dvir's final recommendation is to automate the entire hardening process to save the need to perform stages 1,2, and 3.
This is why you should consider using a Hardening Automation Tool:
1. Automatically generate the most accurate possible impact analysis report - hardening automation tools 'learns' your production dependencies and report to you the potential impact of each policy rule.
2. Automatically enforce your policy on your entire production from a single point of control - using these tools, you won't need to do manual work, such as using GPOs. You can control and be certain all your machines are hardened.
3. Maintain your compliance posture and monitor your machines in real-time - hardening automation tools will monitor your compliance posture, alert, and remediate any unauthorized changes in configurations, therefore preventing configuration drifts.