A Game Changer for Real World Security?
Hackers, incident responders, and penetration testers alike know that valid credential reuse is one of the most common real-world vulnerabilities in today’s networks. Valid credential reuse dominates as the top vulnerability in Verizon’s 2014/2015 Data Breach Investigations Reports.
Microsoft networks remain amongst the most vulnerable and exploited due to the way in which Active Directory is typically deployed: A base image is created with a standard local administrator password, which is duplicated on all workstations in the environment. When an attacker compromises any workstation, the local administrator password hash can be obtained and used to access every other workstation using the classic Active Directory exploit Pass-the-Hash (PtH). This methodology is described in detail in FireEye/Mandiant M-Trends 2015 case studies.
On May 1 Microsoft released a new tool, Local Administrator Password Solution (Security Advisory 3062591), which provides a solution to the Pass-the-Hash exploit. Local Administrator Password Solution (LAPS) changes each local administrator password to a unique value, preventing reuse. LAPS also provides complementary end-user software to manage local administrative accounts from a centralized server.
Since PtH is such an integral part of internal penetration testing and real-world incidents, we are taking a first look at how this security advisory addresses the underlying issues with PtH and how it affects hackers of all sorts, both good and evil.
Typical mitigations for PtH are disabling classical authentication for SMB, disabling printer and file sharing altogether, or manually creating and managing unique passwords for all local administrators across all workstations. Microsoft has delivered official mitigations in a series of updates. Clearly none of these mitigations are ideal from a management or functionality perspective.
LAPS takes a different approach. LAPS does not eliminate the ability to Pass the Hash, rather it reduces the impact of PtH by making each local administrator password (and therefore hash) unique. This effectively helps limit the “blast radius” after a single machine is compromised. Once an attacker gains access to a client workstation, they can no longer access every other workstation in the environment through the shared local admin account.
Has Microsoft provided a truly effective mitigation for PtH once and for all, or is this a partial fix for a fundamentally broken system? Our first take is that LAPS does provide protections from PtH attacks, but it requires significant configuration to current Active Directory environments. Given the prevalence with which local admin PtH is exploited, we do recommend implementing this countermeasure after lab testing.
–––
Demonstrating Local Administrator Attacks (aka Pass the Hash)
https://youtube.com/watch?v=EJNAZW_BBJo
–––
Our Testing Lab
In our testing lab we have a Windows Server 2008 R2 SP1 Domain controller with three Windows 7 clients on a single network segment. In this scenario the IT administrator has already disabled the built-in local Administrator account and created a new administrative account named praetorian, baked into the workstation image.
DC: 10.11.10.2 – Active Directory Domain ControllerWS1: 10.11.10.106 – Our patient zero workstation, infected with our malwareWS3: 10.11.10.108 – Unexploited user workstation
For our walkthrough, we first compromise WS1 using some type of malware, gaining a SYSTEM-level shell on the machine.
Next, we use a tool called mimikatz to dump users’ hashes from memory – including the praetorian account hash, which we know is the same throughout the environment.
Thereafter we use the psexec_psh module in Metasploit to effectively gain remote code execution by authenticating with the passed hash.
From this, we could run other tools to further compromise other machines on the network that share that common local administrator account. Eventually, we could compromise a system administrator’s workstation and become Domain Administrator or similar if their privileged account credentials or tokens are present.
So how can we fix this issue in our lab? A unique password for each local administrative account on the end users’ workstations is a great first step. In this guide we will set up the praetorian user with a unique-per-system password, managed by Active Directory.
Installation
There are two major components to LAPS: the first modifies the forest’s schema to include two new fields to store the password generated on the client; the second is a Group Policy extension that runs on the client to report the new password back to Active Directory. This requires modifying Active Directory and every client in the environment.
A couple of notes: Make sure you have all the latest patches and service packs installed from Microsoft, or outdated versions of PowerShell will fail to update the Active Directory schema. (We have tested this on Windows Server 2008 R2 SP1, but LAPS should work for all supported Microsoft OSes.)
You can follow the install guide and tools from Microsoft at this link: https://www.microsoft.com/en-us/download/details.aspx?id=46899
1. Download the required files and follow the Local Administrator Password Solution Setup.
On the domain controller, make sure you install the management tools.
2. Roll out the AdmPWD GPO Extension to all clients attached to the domain. This can be done via Group Policy by hosting the file on your domain controller, then using a computer startup script also served by Group Policy.
3. Modify the Active Directory Domain.
Next, you will need to add two fields to schema. You can do this via PowerShell using the AdmPwd.PS module.
Note: When we first ran this module the following error resulted: “This assembly is built by a runtime newer than the current and cannot be loaded.”
This means you don’t have .Net 4 installed and you need PowerShell 3.0 or later. (These caused our Domain Controller to reboot.)
Again, you need to make sure you have all the latest patches and service packs installed, or this step will not work.
Next, run the following two commands:
Import-module AdmPwd.PSUpdate-AdmPwdADSchema
Next, we need to set the security permissions on the newly created entries to restrict access to only privileged users, such as domain administrators and help desk personnel. Adjust as necessary for your organization’s needs.
As of the writing of this post, a tool that will query AD for a misconfigured LAPS configuration and retrieve all local administrator passwords has already been released: https://github.com/kfosaaen/Get-LAPSPasswords/blob/master/Get-LAPSPasswords.ps1
“[This tool] queries AD for the hostname, local administrator password, and password expiration for each computer account.”
In short, ensure that only privileged users (such as domain administrators and helpdesk) have read access to the attribute. For all other groups and users ensure “All Extended Rights” is unchecked. Meanwhile the client computers should be able to write the password and read and write to the ExpirationTime attribute.
The attacker’s perspective
On the red team side, where does this leave us? It takes away one avenue of attack to extend access from a single system to the rest of the Windows domain environment. However, there is now a centralized repository of cleartext passwords that, if accessed, provide local admin access on any machine configured therein. If your servers and other critical systems are brought under LAPS, the risk of misconfigured AD, unprotected AD store backups, or compromised accounts with permissions to LAPS information becomes a critical security issue.
[Update] Microsoft responded to Praetorian’s review saying:
If your servers and other critical systems are
notbrought under LAPS, theyremaina critical security issue. The randomization of local administrator passwords, authenticated and encrypted (KRB5+AES) network communication to a repository which allows for granular delegation and auditing are a security win. Active Directory is always going to be the keys to the kingdom and a high value prize. A misconfiguration, unprotected backup or a compromised high value account such as a Domain Admin wouldalwaysbe game over, whether the local account passwords are stored in Active Directory or not.This is why a holistic security approach which incorporates least privilege and protections against lateral movement such as credential tiering and firewall policies is (and has been) part of Microsoft’s Best Practices for Securing Active Directory and Pass the Hash Whitepaper guidance. LAPS enhances the investment, but local account passwords are only a portion of the problem. The fact a free tool has been released to market that operates in a least privilege model (the computer account has access only to write its password whereas many very expensive solutions requires a service account running as domain admin which is contrary to the principles of least privilege) is a massive win for the security state of infrastructure as a whole.
By addressing security as suggested in the guidance you’ll address security problems
beyondNTLM and Pass the Hash, you’ll also address other forms of credential theft – and just maybe the insider threat problem. A least privilege model on a segmented network to address lateral movement addresses it across the board – even if it’s the rogue help desk guy stealing a reorg plan.
Praetorian would like to stress that a properly hardened and correctly designed Active Directory environment helps to reduce the likelihood of complete or partial take over of the environment. It is important that LAPS be rolled out and configured correctly to effectually reduce the risk due to PtH.
–––
Conclusion
The major things to consider when rolling out this patch are as follows:
- Ensure AD attributes are set correctly and do not leak password information to general users.
- Ensure all AD accounts that have read access to the LAPS data are considered privileged accounts and treated accordingly (authenticating only to domain controllers, strong passwords, non-shared).
- Audit the environment on the client side (to ensure the password is correctly applied).
This technique effectively moves the risk from the end-user systems to the core AD environment – meaning greater control and less exposed attack surface.
Finally, let’s revisit the attack we were performing earlier. The unique hash that we retrieve via mimikatz is now unique for our local administrator (praetorian account), making it impossible to Pass the Hash in the traditional sense. As an attacker, we are no longer capable of logging into every machine using PtH.
