The Pass the Hash briefing at Black Hat
August 29, 2013 | Uncategorized | CyberArk
By Cory Friend, Systems Engineer, Atmos Energy
Mark Simos and Patrick Jungles from Microsoft disclosed some new features in Windows 8.1, and the yet to be released Windows 2012 R2, that make it more difficult to steal user credentials on a Windows system.
In previous versions of Windows, the Local Security Authority Subsystem Service (LSASS) was an open book to tools like Mimikatz, disclosing account and password data for any account that has logged in since the last reboot. Microsoft has removed the LM hash (LanMan) entry, and they have removed the WDigest entry which both allowed plain text password transparency. Additionally, when an account logs out the associated entries will be removed from LSASS which will help to reduce the number of accounts exposed when a computer is compromised.
All of this is great, but does it prevent Pass the Hash attacks from being used to move laterally through an organization? No. The same problem still exists. If you can get admin privileges on a Windows system, which allow you to access the LSASS, you can then use the hash to login to other computers that accept the same account. Microsoft’s whitepaper “Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques” discusses several mitigation recommendations for this problem.
One of the mitigations discussed addresses the way many organizations choose to set the same local administrator account password on several if not all of their work stations and/or servers to ease administration. This approach leaves every one of those computers susceptible to Pass the Hash lateral movement. Microsoft’s recommendations for this include the following:
- Enforce the restrictions available in Windows Vista and newer that prevent local accounts from being used for remote administration.
- Explicitly deny network and Remote Desktop logon rights for all administrative local accounts.
- Create unique passwords for local accounts with administrative privileges.
This is good advice – but we recommend taking it a step further, automating the enforcement of unique password policies that create unique, one-time passwords for privileged users.