In this video tutorial, you will learn how to implement a Local Admin Password Solution (or Local Password Management) called LAPS. First, we are going to install it onto the domain controller and on the endpoints. Then I will show you how to configure it with PowerShell, how to configure the group policy, and effectively how it works, including grabbing the hashes.
Pass the Hash attack
Before we learn how to implement LAPS, I would like to show you where the problem is by performing the Pass the Hash attack with our customized version of Mimikatz (an amazing tool written originally by Benjamin Delpy). It is important to understand the problem first so that we get the solution later.
The first thing we will do is an elevation using PsExec tool using: -s to run it as a local system, -i to run it interactively, -d to run the CMD.EXE is a separate window because of the “don’t wait” feature.
We’ve got the console running as a Local System. We need that in order to get the hashes from the local SAM database. This scenario represents the situation where someone is a regular domain user and at the same time being a member of the local Administrators group. In order to perform the Pass the Hash you need to be, somehow, a local administrator.
CQHashDumpV2.exe is a tool that our team wrote. You can use it with the parameter /samdump in order to get the list of the local hashes.
What we see in the result, especially after the colon, it’s something that we call NT hash and we will cover it deeply in another video. We need to copy it as we’re going to use this to perform the Pass the Hash. If you check out who we are over here, we are Freddy Kruger and this is, as I already mentioned, the local Administrator’s group member, being a Domain User at the same time. We will try to use the hash for authentication on some other machines. If the password on the other machines is the same we will be able to move forward and get access to them. It works because of the Single Sign-On feature in Windows.
Let’s dig in into our custom version of Mimikatz. Thanks to Benjamin Delpy who wrote an amazing tool and thanks to our cooperation with Benjamin – we have our own personal team’s edition with a couple of interesting options. One of the things that you can do but you can also do it in a public version, is to perform the Pass the Hash. Let’s do it.
Commands are:
privilege::debug to be able to interact with, for example, Local Security Authority Subsystem, so LSASS.exe process
sekurlsa::pth for the pass the hash attack, with parameters:
/user:Administrator
/domain:localhost for the localhost access. I am in the domain now but the Administrator is a local user, so so why don’t we do a Pass the Hash locally?
/ntlm:<value> to specify the hash that we know.
The result looks quite funny because if we run whoami in this new console that we have just opened, here we can see that we are Freddy Krueger. Well for real, we are actually the local administrator, we’ve got a token of the local administrator but a whoami utility will not show us this.
We should be ready for now and in order to jump further. In order to hop in between the workstations and servers, we can use PsExec tool:
Please make note that in the PsExec’s license, it’s mentioned that this is not a hacking tool, so we play to understand, correct? 🙂 In this case, we open a session using a PsExec to the server with IP 10.10.2.202. As a result, we’re going to have a remote command prompt opened. Now, we should be on the other server and we can also run whoami again.
We are a local administrator through the remote console! That proves the point that we were previously a local administrator and we performed the Pass the Hash thanks to the Single Sign On possibility in Windows.
How to install the Local Admin Password Solution (LAPS)?
In order to mitigate this problem, we need to install the Local Admin Password Solution (LAPS). LAPS will help us to randomize local administrator’s passwords amongst all of the computers. Please note that the solution mitigates Pass the Hash attack only on a local level, not for the domain accounts.
We have to install it on the managed machines and also on the domain controller. We are going to do it on the managed machine first. Here we’ve already got LAPS downloaded from the Microsoft website.
LAPS is free, so you can freely use it and it’s also very easy to implement it. On the managed machine we only install the Group Policy Extension since it’s just a managed box. At this stage, it is important to mention what kind of requirements we’ve got for LAPS. First of all, Active Directory needs to be running on Windows Server 2003 SP1 or anything higher and from the managed endpoints perspective it needs to be Windows Vista with the current Service Pack or Windows Server 2003 with the current Service Pack. When we are all set, now it’s time to switch to the Domain Controller and configure everything from there.
First, what we need to do is to install LAPS on the Domain Controller. I will install a bit more components because we will also install the Powershell module that we are going to use for the implementation and management. We may also need the LAPS fat client and the group policy editor templates.
For the demo, we have created a sample container PWDClients, where I have moved the W81-CLI computer account. There is also a group that we will be managing the passwords of the local administrators within this OU.
When it’s all installed, we can perform the implementation. Let’s start the Powershell. The first thing we need to do is to run the command:
Import-Module AdmPwd.PS
Technically you don’t even have to do that but I want to show you everything step by step so that it’s all nice and clear. We have just loaded the whole set of commands that you’ve got for LAPS.
Implementation is also very simple, the first thing we need to do is to update the Active Directory Schema to include two new attributes:
Now the next step. We need to specify the computer rights and also the user rights. We need to specify which computers will be managed and for that we use this particular cmdlet from the module. We need to make sure that all the computers within this OU have ‘Self’ on a list of permissions with a right to update its own attributes:
The next two operations that we will do is to specify who will be able to manage local administrators’ passwords in this OU. We issue Set-AdmPwdReadPasswordPermission with the parameters -OrgUnit for our PwdClients OU and -AllowedPrincipals for CQURED\HelpDesk group. A similar operation should be performed for reset password permission so we have to issue Set-AdmPwdResetPasswordPermission. Perfect! This is the implementation.
In the meantime, we need to make sure that none of the other users in our environment is allowed to read the local administrators’ password and in order to do that within the ADSI Edit, within the default naming context, you need to:
- Go to the properties of the OU that you want to manage.
- Go to the Security tab and then to the Advanced settings.
- Find people that you don’t want to be able to display the local administrator’s password. In this scenario, you can choose, for example, account operators,
- Click edit and verify if for this group the “All extended rights” checkbox is not selected. This is in order to make sure that a particular group is not able to read the values of the ms-Mcs-AdmPwd attribute.
We can use ADSI Edit to manually verify who has permissions mentioned above but we can also use a PowerShell cmdlet Find-AdmPwdExtendedRights with -Identity parameter. It is easy to see that our HelpDesk group has these permissions.
The last step
Now we have implemented LAPS. The last step is to implement a group policy. We’ve got our PWD clients OU, we create a GPO in this domain and link it here.
Let’s name it LAPS. When we edit it under Computer Configuration -> Policies -> Administrative Templates -> LAPS we can see Password settings allowing us to configure the complexity, length of the password, and change period. We have also to enable LAPS under “Enable local admin password management”. We’ve got these two policies configured in the GPO and then we are ready to update the policy on the client level. Let’s switch to the client and run gpupdate /force. While the policy is being updated we can check if the password for the local administrator was generated so we can go to the Active Directory Users and Computers and in the Attribute Editor for our managed computer we can observe the new password. The password was generated and that’s the one that we will be using for this machine.
Of course, there is also LAPS client I mentioned briefly. So in the LAPS UI we are able to specify the computer name and observe what the password is and at what time it expires. We are also able to set a certain expiration time including a moment in the past to force the password reset.
On the Windows client, we are able to check if the password was changed. So one more time we need to run gpupdate /force and let’s verify how it works from the hash perspective, is it changed? Let me remind you which hash we used for the Pass the Hash attack: for the local administrator it started with the E19 so right now we can check with the CQHashDumpV2 /samdump if it was changed, now we’ve got the 9C 53 C7, etc.. That proves the point that the password was actually changed.
You have just learned how to implement LAPS. This tutorial shows the technical steps, how we are able to make sure that the LAPS will be working and the rest of the little but very important details that you are able to set up after the implementation.
We didn’t talk about auditing, which is a subject for the next video, are you interested?
P.S. HERE you will find a great guide for the LAPS implementation
Did you like this article? See how much YOU really know about cybersecurity! Test yourself.
