Mitigating the Threat of Lateral Movement
You may have heard that many times in a complete network compromise, “it only takes one,” meaning that the attacker need only compromise one machine for the whole house of cards to fall. While this statement is oversimplified, many times, there is truth to it. In fact, I’ve personally worked an incident where this was true. Let’s walk through that briefly:
Step 1: Compromise the User
This was accomplished by exploiting an out of date Java plugin (did I mention that you should patch your stuff?) What’s worse, the user was a local admin. Although this is not necessary for the attacker to move laterally, it removes some extra steps necessary to dump the local admin user’s hash.
Step 2: Grab the Local Admin’s Password Hash
In many environments, the local administrator’s password is the same across all workstations in the domain. While this make’s it slightly easier for the helpdesk personnel, it also makes it easier for attackers. Because of the way Windows is designed, the attacker doesn’t actually need the cleartext password to move throughout the network, instead they use a technique called Pass the Hash (PtH).
Step 3: Find a logged in Domain Admin
In this scenario, helpdesk admins would log into workstations as their domain admin account to make changes. The attackers were able to find a machine with one of the helpdesk staff logged in with their DA account and used a tool (such as mimikatz) to dump the password (in cleartext) from RAM. Interesting tip: all passwords of logged in users are stored in the clear in RAM. So, if you can dump RAM (requires local admin), then you don’t need to bother with cracking hashes. At this point, the network was compromised and the attacker began to ex-filtrate data.
Like many of the suggestions we make to mitigate risk in the enterprise, this tool will cost you nothing but your time. Looking through the compromise, the initial attack vector was a missing patch, and we all know we need to patch. However, how can we make PtH a non-issue among local admin accounts? This is where Microsoft’s Local Admin Password Solution shines. Although it has many features, the most relevant to PtH is the ability to randomize the local admin password across all machines in the enterprise. In doing so, the attacker cannot utilize a stolen local admin’s password hash to move throughout the environment, because it’s only good for the machine it was stolen from.
Installation of LAPS
The first step is to actually download LAPS from the link above. Then, you can execute the installer from your admin workstation. Run through the installer and make sure to install all Management Tools as well.
Next, open a PowerShell window as a user with Domain Admin and Schema Admin rights (just do a Run As…) and run the following commands:
Import-Module AdmPwd.PS
Update-AdmPwdADSchema
This adds two additional attributes to the computer class, one for storing the password and the other for password expiration. Specifically, they are:
ms-Mcs-AdmPwd
ms-Mcs-AdmPwdExpirationTimeWe now need to allow computer objects to actually update these attributes, and this can be done by OU. So, go ahead and add the OU that contains all of your user workstations.
Set-AdmPwdComputerSelfPermission -OrgUnit "UserWorkstations"
Setting Up Access to Passwords
Now you need to set who will actually have access to view and reset passwords. First, you’ll need to create a LAPSAdmins group in Active Directory. Any user account added to this group will be able to manage passwords in the OUs you specify. Then, allow that group to manage the UserWorkstations OU.
Set-AdmPwdReadPasswordPermission -OrgUnit "UserWorkstations" -AllowedPrincipals LAPSAdmins
Now, anyone within the LAPSAdmins group can view/reset the local admin passwords of all the machines within the UserWorkstations OU.
Creating the GPO
First, copy the following files from your admin workstation to your domain controllers’ Central Store in their respective directories:
C:\Windows\PolicyDefinitions\AdmPwd.ADMX
C:\Windows\PolicyDefinitions\en-US\AdmPwd.ADML
Next, open up your Group Policy Management Console and create a new GPO named LAPS. From there, navigate to Computer Configuration > Administrative Templates > LAPS and configure it to your organizations standards. You can set policies here such as password complexity, expiration time, name of admin account to manage, etc. Make sure you Enable local admin password management.
From here, you can link it to whichever OUs you see fit.
Checking Who Has Access
It’s a good idea to know which groups actually have access to see the password tied to the computer objects. You can do this with the following command and replacing <OU> with your OU.
Find-AdmPwdExtendedRights -Identity "<OU>"Ideally, it will just be the SYSTEM account and Domain Admins.
Managing the Passwords
Remember earlier, we allowed the LAPSAdmins group to manage the passwords of the computer objects in the UserWorkstations group? Let’s test that functionality. My standard user account, SAVAGE\kyle is a member of the LAPSAdmins group. I can open up the LAPS UI and search for a computer name, in this case Win10–1, and retrieve the local admin password, as well as view/change the expiration time.
Wrapping Up
Hopefully this tutorial was informative and started you down a path of deploying LAPS in your own environment. If you have any questions, or just want to share some stories of your own, go ahead and leave a comment.
Until next time defenders… keep fighting, go Savage.
