Another Lap Around Microsoft LAPS

Author: Leo Loobeek Posted In Penetration Testing Tutorials On: 2016/08/04 Comments: 3

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:

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!

laps-group_members

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.

find-lapsdelegatedgroups

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.

find-admpwdextendedrights

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.

get-lapscomputers

get-lapscomputers-2

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 special-permissions
  5. Uncheck ‘All Extended Rights’ 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

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
3 Comments
  • The ComputerName property is the hostname of the computer object in Active Directory. The Identity properties listed are the groups/users that can read the local Administrator password (LAPS password) for the host. So in the example, both the Coaches group and tbridge account can read the local Administrator password for the victim1 computer.

    It may make more sense when LAPS is enabled on many computers, it will come in handy when determining which users can access which passwords.

    Hope this helps.

  • Could you explain the meaning of ComputerName property of Find-AdmPwdExtendedRights function output ? What’s the use of that value ?

    Thanks

  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    Follow Pentest Geek

    twitterrssyoutubetwitterrssyoutube

    Subscribe to Pentest Geek

    Recent Posts

    Penetration Testing

    Categories

    Metasploit

    Web Application Hacking

    css.php