Unique Local Admin Passwords – How and Why.

So here we are, early 2019 and just a few months removed from a data breach at Marriott that saw over 500 million guests’ personal information hit the public internet. If that sounds like an insane number you’re absolutely right! That’s nearly 6% of the world population and about 150% the population of the US.

So the big question is how. How do things like this happen, how do attackers gain so much information, how do they exfiltrate the data, and how is it so common that Forbes is over here making cyber predictions for 2019!?

A while back I wrote about securing privileged access with a brief, high level overview of how an attacker will work to gain access in an organization and work to keep it. Part of that process is by making use of local admin credentials harvested from the first compromised machine to pivot around the network to see what else those credentials will work on. Sounds harmless enough, but what if the machine they gain access to is a domain controller? Or an admin’s workstation who happens to have administrative privileges on his daily account?

During this process it’s difficult to detect because the attacker is using valid credentials to pivot around the network digging for more information or waiting for an admin to slip up. The first step to stopping this is by attacking the first link in the kill chain and limit privileged escalation of other workstations. How? By making sure that other workstation doesn’t have the same administrative password as the one the attacker already has.

Enter LAPS! The first part of the solution involves deploying an agent to each workstation and server on the network. That agent can be downloaded here. Since Microsoft was kind enough to provide the package as an MSI it’s easy enough to deploy with a script (msiexec /i \\fileserver\share\LAPS.x64.msi /quiet), Intune if you’re into comanagement, or good ole’ fashion SCCM. Definitely be sure to update your images to include the agent as well! Once that’s deployed and imaging has been updated, admin users need to install the management client on their PAWs (you are using a privileged access workstation, right?) to get the management client, powershell module, and GPO templates for management.

The next step is to make sure that the Active Directory Schema is taken care of. We need to extend the schema to include the attributes that we’ll be working with and then make sure to update permissions so we’ve accounted for users who shouldn’t be able to see those attributes. To extend the schema we need to use one of the admin workstations we just installed the management tools on and import the module in a powershell session and update the schema:

Import-module AdmPwd.PS
Update-AdmPwdADSchema

After waiting a short while for that schema change to replicate we’ll move on to making sure only specific users and computers have access to the AD attribute that now stores these passwords. The first step is to remove permissions for groups at the OU level. If you’ve blocked inheritance you’ll need to make sure to take care of any nested OUs as well.

1. Open ADSIEdit
2. Right Click on the OU that contains the computer accounts that you are installing this solution on and select Properties.
3. Click the Security tab
4. Click Advanced
5. Select the Group(s) or User(s) that you don’t want to be able to read the password and then click Edit.
6. Uncheck All extended rights

*Be sure to preview all extended rights permissions first to make sure you aren’t removing permissions required by that group of users

Now that we’ve taken care of scoping away permissions from unintended users/computers, we need need to make sure that the machines themselves have access to write to this attribute so they’re able to update their own passwords as they expire.

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Servers,DC=domain,DC=com"

We’ll grant individual admin groups access to read those randomized admin passwords:

Set-AdmPwdReadPasswordPermission `
-OrgUnit "OU=Admins,DC=domain,DC=com" `
-AllowedPrincipals Domain\PasswordAdmins

And of course we need to account for password resets as well so let’s add reset permissions:

Set-AdmPwdResetPasswordPermission `
-OrgUnit "OU=Admins,DC=domain,DC=com" `
-AllowedPrincipals Domain\PasswordAdmins

Finally, you’ll want to hop into Group Policy on that admin workstation you installed the tools on to establish the password policy settings you’ll be enforcing on those workstations and servers.

There’s quite a bit here to chew on but it’s not technically challenging so give it a try in a lab, then roll it out to your user workstations and eventually the servers as well! Again, the idea here is to limit lateral movement and make elevation of privilege more and more difficult for bad actors.

We’ll have another shorter session to go over some of the day to day admin tasks like looking up those passwords and resetting them, but that day is not today!