Another Lap Around Microsoft LAPS

I recently landed on a client’s network with an implementation of Microsoft LAPS on a few thousand hosts. This blog post will walk through how to identify the users sysadmins delegated to view LAPS passwords, and how to identify the users sysadmins have no idea can view LAPS passwords.

Getting Started

Microsoft’s Local Administrator Password Solution (LAPS) tool has already been discussed and blogged about quite a bit (using titles equally as clever as this one). If you haven’t seen these already, I highly encourage checking out the work and blog posts below:

• https://adsecurity.org/?p=1790
• https://blog.netspi.com/running-laps-around-cleartext-passwords/
• http://www.harmj0y.net/blog/powershell/running-laps-with-powerview/

A while ago, I leveraged functions from the industry standard tool for auditing Active Directory environments, Will Schroeder’s (@harmj0y) PowerView project; and referenced Sean Metcalf’s (@PyroTek3) brilliant Microsoft LAPS post to create the LAPSToolkit. The main idea was to simplify lengthy PowerShell oneliners I was writing while using PowerView functions.

You can pick up the (recently updated) LAPSToolkit at https://github.com/leoloobeek/LAPSToolkit

This post will assume the reader has a basic understanding of how Microsoft LAPS works, reference the above links to get up to speed. Quick reminder: Microsoft LAPS manages all local administrator accounts by pulling it into Active Directory and assigning random, secure passwords, different for each host. Sysadmins then delegate group(s) permission to view the passwords for each host.

I have set up a Microsoft LAPS implementation in a lab with the groups and their members listed below. The next few PowerShell examples are being run from the user context of ‘hsmith’. With football coming up, I couldn’t help myself!

Auditing LAPS

As an attacker, I want to identify users who can read these passwords so I can hunt them down and leverage their access to further escalate my privileges. This functionality is included in the Find-LAPSDelegatedGroups function of the LAPSToolkit. This essentially wraps around the oneliner @harmj0y had in the blog post above.

Ok, looks like the ‘Coaches’ group has been delegated to read the Microsoft LAPS passwords for all computers in the OU listed. Once identifying the users, an option can be to use the function Invoke-UserHunter (in PowerView) then find ways to compromise those accounts. It seems obvious, but sysadmins will probably place service accounts or other accounts that are more protected in the group they delegate. These accounts may not be Domain Admins, which may still make it an easier stepping stone on your path to DA.

As @PyroTek3 references this in his blog post, some users may be able to read these passwords that IT hasn’t specifically delegated. In short, the Microsoft LAPS password is stored in a confidential attribute of a computer object in active directory. If a user has “All Extended Rights” to the object, they can read all confidential attributes. A user automatically gets the “All Extended Rights” permission when adding a computer to the domain.

The LAPSToolkit’s function Find-AdmPwdExtendedRights will pull down all ACLs from Active Directory and display users with the “All Extended Rights” permission. As we see below, looks like more than just members of the Coaches group can view the password for VICTIM1.

While at the client with Microsoft LAPS enabled, the Find-AdmPwdExtendedRights function found numerous users that were not in the delegated group, including a user who could view 240 LAPS passwords! I later found out the employee used to help with IT many years ago but now was in an entirely different department.

As attackers, finding one or two things that have been overlooked may be what is needed to continue privilege escalation. By using those two commands we easily gained additional targets on the domain that may allow us to gain further access to other systems and user accounts.

Using the third function from the LAPSToolkit, Get-LAPSComputers, we see that the ‘tbridge’ account can in fact view the password (yes, its been changed), where ‘hsmith’ cannot.

If you don’t want to use this project, the command below will use PowerView to do the same thing.

PS C:\> Get-NetComputer -FullData -Filter '(Ms-Mcs-Admpwdexpirationtime=*)' | Select dnshostname, ms-mcs-admpwd,ms-MCS-AdmPwdExpirationTime

OR you can use @kfosaaen’s Get-LAPSPasswords

PS C:\> Get-LAPSPasswords

A note on Find-AdmPwdExtendedRights: Due to the amount of ACLs in Active Directory, the running time of this can take quite a while. While I continue to identify a performance enhancement, I’ve noticed it is best to export this to a CSV (see below). It should also be noted, that the only traffic is between your host and the domain controller, your host is NOT connecting with each and every other computer on the network.

Output Results to CSV

As noted above, Find-AdmPwdExtendedRights can take some time. You might find it best to output these results to a CSV file that you can further parse and to reference later on. Below is an example to do so.

PS C:\> Find-AdmPwdExtendedRights | Export-Csv -Path C:\temp\LAPS_Audit.csv -NoType

Execution from a machine not on the domain

The three functions all support a PowerShell credential object which allows executing these from a system not on the domain. This can help during internal assessments where you have access to a user account. The top level of the domain will need to be included when specifying –Credential: i.e.

PS C:\> Find-AdmPwdExtendedRights -Domain testlab.local -DomainController 1.1.1.1 -Credential testlab.local\user

Removing Special Permissions

You can remove the “All Extended Rights” on a single host by following these steps:

1. Open up ADSI Edit
2. Right click on the computer object -> properties
3. Choose the security tab and select advanced
4. Find the affected user and select the row with ‘Special’ permission 
5. Uncheck ‘All Extended Rights’ 

Conclusion

In closing, I still do feel that Microsoft LAPS is a great product that can really help an organization prevent the sharing of these passwords and other common issues that attackers have used for years to pivot around a Windows environment.

As mentioned in the msdn post, this really highlights a best practice organizations should be following where joining computers to the domain should be used by a dedicated service account or with another automated measure, not by allowing users to do this themselves.

I am always open to recommendations, issues, or performance improvements. If it hasn’t been obvious already, another thanks to @harmj0y and @PyroTek3 as I stood on their shoulders to quickly put together a tool to audit Microsoft LAPS more efficiently.

Share this article