Microsoft’s Local Administrator Password Solution (LAPS)
Posted by Richard Penshorn
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.
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 Controller
WS1: 10.11.10.106 – Our patient zero workstation, infected with our malware
WS3: 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.
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
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:
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
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.
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.