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.

[Report]: Josh Abraham, the author of Praetorian’s recent report, released the third video in a five part series covering the top attack vectors used in kill chains that compromised 75 unique organizations over 100 internal penetration tests. This one covers Local Administrator Attacks (aka Pass the Hash). Watch the videos to get a firm understanding of the issues and detailed recommendations for mitigating risk with Microsoft LAPS.


Download the full report

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:    – Active Directory Domain Controller
WS1: – Our patient zero workstation, infected with our malware
WS3: – Unexploited user workstation

For our walkthrough, we first compromise WS1 using some type of malware, gaining a SYSTEM-level shell on the machine.

pass the hash successful

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.

retrive hash

Thereafter we use the psexec_psh module in Metasploit to effectively gain remote code execution by authenticating with the passed hash.

pass the hash metasploit setup

pass the hash metasploit

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.

install microsoft laps

On the domain controller, make sure you install the management tools.

install laps

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.

install laps client software

install laps client

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.)

  1. http://go.microsoft.com/fwlink/?LinkID=242919
  2. http://go.microsoft.com/fwlink/?LinkID=240290

powershell error

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.PS

powershell setup

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.

querey local admin laps ui

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:

  1. Ensure AD attributes are set correctly and do not leak password information to general users.
  2. 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).
  3. 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.

pass the hash stopped

Your World, Secured.

Tech Puzzles

Try our Puzzles

Test your problem solving skills. Do you have what it takes?

Try puzzles »