Welcome to Part Two of Defending Against Pass-the-Hash attacks straight from your favoriate penetration tester! In Part 1 – “Defending Against Pass-The-Hash”, we covered what “Pass-the-Hash” attacks are, how they occur, and how you can defend against them on your network (including installing Microsoft’s LAPS). If you didn't read Part 1, I recommend you go check that out right now before proceeding.
Picking up where I left off, let's go through getting LAPS up and running on your Windows network, or as I like to call it:
Installing Microsoft LAPS for Fun and Profit!
So, as was discussed in the last article, LAPS is the shorthand form of "Local Administrator Password Solution" (because honestly, try to say that three times fast). LAPS allows system administrators to continue using local administrator accounts on Windows servers and workstations securely. It accomplishes this by having different, randomly generated passwords on each system, storing the password in plaintext in Active Directory (AD).
Wait. Plaintext? Yes, but it's in an Attribute in AD, and once it's configured properly, only the user accounts that you WANT to read it will be able to. The thought process is simply this: If an attacker has access to *this* password, then they already have access to some other higher level admin account, which makes access to this password the least of your worries.
Let's get started!
PART 1 - Installing LAPS
Ok, so now we're familiarized with why we should be using LAPS, let's get to the actual installation, shall we?
Side note – Download LAPS and all of Microsoft’s formal docs for installing LAPS from here:
Management Server -
First things first, we need to install the LAPS Management Tools on the "Management Server" - this is generally a Domain Controller.
Open the file, click Next. Accept the license agreement and click Next again.
Here, the default option will be to install the "AdmPwd GPO Extension", by itself. However, for the management server, we need to install the "Management Tools". Click on Management Tools and "Entire feature will be installed on local hard drive".
NOTE: If you want to install the "AdmPwd GPO Extension", on the server (for example, the management server is not a DC), then leave this checked. Otherwise, you may want to uncheck it for installation.
Click Install, then Finish.
Clients (Servers and Workstations) -
The Client installation portion uses the same install file, but this time we only install the "AdmPwd GPO Extension", which is the default option. Again, open LAPS.x64.msi (or LAPS.x86.msi), click Next, Next, Install, Finish. Simple.
But who wants to install this on a few machines like this, let alone 100's or 1000's of machines? Good grief.
Well, fortunately, Microsoft knows how to automate, and do it well. As stated in the "LAPS_OperationsGuide.docx" document:
"These can be installed/updated/uninstalled on clients using a variety of methods including the Software Installation feature of Group Policy, SCCM, login script, manual install, etc. " [1]
I'm going to show you how to install LAPS with Group Policy (GPO), using Software Installation Policy, to any systems you like. I'm going to assume at this point that you, dear Reader, know what GPOs are and how to set them up, so I'll skip that part.
Open Group Policy Management Editor, create a new GPO, and store it where you like. For our example, I'm just going to store it at the root of the domain (aarontest.local).
Right click, edit the GPO. Open Computer Configuration > Policies > Software Settings, and then right click on "Software Installation".
Click New, then Package...
At this point, you probably want to place the LAPS .msi files in NETLOGON of your domain (or any other software installation network share, of course), or you may get an error like below:
I placed mine in the NETLOGON share of the aarontest.local domain.
"Assigned" should be the default option selected on the Deploy Software screen, so just click OK.
And now, we're ready to push this to our systems...
It's installed!
PART 2 - Configuring Active Directory
Ok, now the fun part - configuring Active Directory. Some of you PowerShell Gurus out there might find this a breeze, but as someone who is *not* familiar with PowerShell, this was... Fun. Yeah, we'll say fun.
So, the first thing we need to do is update the AD Schema to add a couple new attributes to the computer objects in the domain - the local administrator password itself, and the password expiration timestamp.
Here are the new attributes:
- •ms-Mcs-AdmPwd
- •ms-Mcs-AdmPwdExpirationTime
NOTE: This information and installation is for a very small domain (it only has one DC and one workstation). If you have a larger domain, particularly with an RODC, then you will want to take a look at the Microsoft documentation directly for some extra configuration information.
Here's a look at the small setup I have for my test domain:
This information is provided simply because when I put in "Computers" or "Users" in PowerShell, it errored out (like it didn't know how to find the OU I was typing), but when I created the new OUs, they worked like a charm.
First things first, import the "AdmPwd.PS" module in PowerShell: Import-Module AdmPwd.PS
Then update the AD schema: Update-AdmPwdADSchema
If you receive the error "The user has insufficient access rights." you will want to place yourself in the Schema Admin group, but only until the process is complete, then immediately take the account back out of the group because Schema Admins have access to make changes to the Active Directory Schema, which is the entire backbone of the Active Directory forest environment.
After I gave myself Schema Admin rights (placed myself in the Schema Admins group), the Schema update was successful.
The next step is to disable the "All Extended Rights" attribute from any users/groups that don't need to see the new passwords stored in the AD attributes, that is, anyone who is not at least a Domain Admin.
You can check to see what users and groups have access to these with PowerShell:
Find-AdmPwdExtendedrights -identity <OU of systems> | Format-Table
If you see any users or groups in there that shouldn't be (notice how mine only has “NT Authority\SYSTEM” and “Domain Admins”, which, to my knowledge should be the default), then use ADSI Edit to remove the permissions. Most organizations should not have to complete this step, as the extended permissions should not be readable by any unprivileged accounts by default. If you find accounts that you would like to restrict, please refer to the Microsoft documentation for more information on how to complete this step.
Now, we need to add the systems themselves to the “Write” permission of the new attributes. The systems will be updating their own passwords and timestamps and will need to have the permission to do so.
NOTE: You will want to repeat this at the root of any other OUs that you have systems in.
Set-AdmPwdComputerSelfPermission -OrgUnit <OU of systems>
Next step, we need to add the "CONTROL_ACCESS" extended permission to the new password attribute (ms-Mcs-AdmPwd) to the users or groups that will be allowed to read the new passwords. NOTE: you can comma separate several users or groups to configure more than one at a time.
Set-AdmPwdReadPasswordPermission -OrgUnit <OU of groups> -AllowedPrincipals <users, groups>
Now, we can add the Write permission for the Password Expiration to certain users or groups to allow them to force password expiration of systems. Again, you can add multiple users or groups by comma separating them.
Set-AdmPwdResetPasswordPermission -OrgUnit <OU of systems> -AllowedPrincipals <users, groups>
That's it for the PowerShell commands! Finally.
Now, let's do the last step...configuring Group Policy.
PART 3 - Configuring Group Policy
Ok, we're in the homestretch now! Time to configure the Group Policy settings. These are the actual settings that configure the local administrator password policy for each computer, based on your criteria.
I've setup a new GPO for this policy, different from the previous one for the LAPS installation. Right click on the GPO, click Edit, and head to Computer Configuration > Policies > Administrative Templates > LAPS.
The first thing we're going to set is the "Password Settings". Notice that the default password options are uppercase/lowercase letters, numbers, and symbols, fourteen (14) characters long, and a Password Age of 30 days.
This may be fine for your organization, but I generally prefer to make it a little longer. I just like longer passwords, and if you haven't disabled LM in your network for passwords yet, then a LM password hash can be *EASILY* cracked in a few minutes. Not that an attacker can use that password to traverse your network (it is limited to this system with LAPS), but they could use the cracked password to access Remote Desktop on your server. That would be bad.
I prefer 16 characters, all types of characters, and a 14-day age. Again, set this to your own password complexity policies or standards.
Ok, this next part is a little tricky - "Name of administrator account to manage".
Before you configure it, ask yourself four questions:
- Are you using LAPS on the default (built-in) local admin account - "Administrator"?
- Did you rename the default (built-in) local admin account?
- If not, what is the local admin account you're going to manage?
- Are you feeling lucky, punk?
If you answered "yes" to question 1 or 2, then skip the “Name of the administrator account to manage” step, you don't need to configure it. As a matter of fact, Microsoft very specifically states this in the "Help:" section of the setting:
"DO NOT configure when you use built-in admin account. Built-in admin account is auto-detected by well-known SID, even when renamed. (emphasis mine)"
I'm using the default (built-in) admin account, so this remains "Not Configured".
If you are configuring this for a different local admin account that was created and NOT renamed, then set the policy to Enabled, and type in the admin account name in the "Administrator account name:" box. Again, only do this if you are not using the default (built-in) “Administrator” account, renamed or not.
Next step, configuring the password expiration timeframe. If you want to enforce that the password is changed every so many days as set in the "Password Settings" policy, then this needs to be set to Enabled.
Last step! We made it! Now, we have to enable all the work that we have done.
Open "Enable local admin password management” and click Enabled.
That's it! Congratulations, you just installed and enabled Microsoft LAPS on your network. You just made it a lot harder for an attacker (like me) to traverse your network using your local admin hash and/or cracked password.
BONUS ROUND - How to Check the New Passwords
Welcome to the bonus round! You were probably wondering "ok, I have this configured now...how the heck do I check and see what the new password is?"
Great question! I'll show you.
So, once the GPO has installed the LAPS software and the changes have propagated through your network (it will take some time, maybe a couple days especially in larger networks, at least that's been my experience), then you can see the new password in the AD computer object's attributes.
NOTE: To see attributes of objects in AD, you'll need to turn on "Advanced Features" in AD Users and Computers (ADUC).
To test quickly on a machine to make sure it's working, I usually setup a test machine in the OU, run gpupdate /force, reboot, and then look at the Attribute Editor for the computer in ADUC.
Here you can see the "WIN10TEST" computer object, and the Attribute Editor for it. Find "ms-Mcs-AdmPwd", and there's the plaintext password for your local admin for that server. The ms-Mcs-AdmPwdExpirationTime attribute contains the timeframe to change the password.
I hope you've enjoyed this little foray into making your Windows network a little more secure. Thanks for joining me! For more information on our penetration testing services and how TRUE can help protect you against the pass the hash, contact the team at True Digital Security today!