Microsoft LAPS - Blue Team / Red Team

Published: 2019-01-14. Last Updated: 2019-01-14 16:49:29 UTC
by Rob VandenBrink (Version: 1)
3 comment(s)

The story is all too familiar, the chain of events almost the same every time:

  • A malicious email makes its way in past the SPAM filter.
  • The recipient person clicks on a link or downloads an attachment with a macro in it
  • Malware executes
  • The malware uses Mimikatz (or some variation thereof) to harvest the local administrator password from the machine
  • The malware then uses that password for lateral movement to infect other workstations and servers
  • then bad things start to happen, and the phone rings!

The Blue Team "fix" for this?  Well, there are lots of them (starting with the SPAM filter, user education and blocking macros), but the one I'll discuss today is that local administrator password, the one that's the same on all workstations (and often on all servers as well).  Microsoft LAPS (Local Administrator Password Solution) is a nifty, free download that allows you to set the local admin password for each workstation to a random string of configurable length.  Not only that, it allows you to schedule resets of those passwords, and it's all configurable through Group Policy:


The passwords are stored in a field in AD, which is part of the schema extension for this product.  You can then set rights on that field so that only authorized folks can use those passwords.

LAPS can be downloaded here (note that this link is subject to change over time):
https://www.microsoft.com/en-us/download/details.aspx?id=46899

Note to the Blue Team / IT Ops Team- don't include your Domain Controllers in the scope of your LAPS workstations, or you're in for a bad day

Neat eh?  If done right, this fixes the lateral movement problem nicely right?

... Time for the Red Team Point of View ....

LAPS works great, except that authorized folks can read those passwords in clear text (because they need to).  What this does is focus the efforts of the attackers on the IT Administration team.  If you can compromise the right helpdesk password, you'll be able to collect all the workstation local administrator passwords with a simple PowerShell one-liner, then save that off to a spreadsheet as part of your Penetration Test findings (or L00T if the attack is malicious):

To collect one password:

Or, as they say in Pokemon Universe, if you want to collect them all - dump out all hosts in the domain, and collect the hostname, the OS and the local admin passwords:

Your data will look something like:


Note that all stations don't have set - you normally enforce the LAPS GPO by OU in Active Directory.  Try to get the coverage you want for this tool by building your OUs and enforcing the GPO appropriately, but again, be sure not to apply this to any domain controllers.

If you're running a penetration test, exporting it to a CSV so you can do some more analysis in Excel is a handy final step (be careful where this data goes though!)

Note to the Blue Team or Ops Team - DON'T RUN THIS LAST COMMAND - EVER.  SAVING ALL OF YOUR PASSWORDS IN A SPREADSHEET IS AN EPICALLY BAD IDEA!

The "moral of the story"?  A few actually:

  • No security measure is 100% effective, and every security measure can be exploited if it's not done right (or even if it is done right). 
  • Approaches like this work best against malware and other automated / semi-automated attacks.  If you have an intelligent adversary, they'll likely get administrative fairly quickly in most domains.
  • "Defence in Depth" is a thing people say for a reason, it's the most effective way to protect your assets.  If you put all of your eggs in one basket, count on the fact that at some point, you'll drop that basket (or someone will do that for you)
  • LAPS is a great tool, but it should be one tool of many that you use to protect your infrastructure. 
  • Implementing things like this start to focus attackers on your helpdesk and domain admins - be sure that those admin accounts are protected as much as possible - start by making sure that folks can't browse or check email while using an admin account!!

Have I missed anything?  Please use our comment form if so!

===============
Rob VandenBrink

 

3 comment(s)

Comments

Reminds me of this article I read the other day...
Malicious use of Microsoft LAPS
https://hk.saowen.com/a/38f98d5a93868c2facd432d27f552967f591eeb27a268e9820e140178cdfd113
The article you're referring to is also digging into compromising things from the workstation side as well (that whole section on poisoning AdmPwd.dll for instance) - nice write-up!

The stuff in my write-up above is all just using documented administrative functions in a not-so-administrative / evil way - Microsoft has a fancy script documenting this at https://gallery.technet.microsoft.com/scriptcenter/Retrieve-LAPS-password-for-c0e74288
You should never give mail / interactive accounts the ability to be local admin - or to read secrets such as LAPS passwords...
Issue personal admin accounts that are used via RunAs, even if all they are used for is to retrieve LAPS passwords for a few machines (classroom etc).

And/or you could give admin accounts that need LAPS passwords access to run the AdmPwd tool or a powershell script using the credentials of a #readlaps user that has its password changed often / after every execution. This should be done via your runas/password management tool, and must log who did it!

Not to forget: An important thing of any tool is to audit the implemented solution and the use of it.. See https://blogs.technet.microsoft.com/askpfeplat/2015/12/28/local-administrator-password-solution-laps-implementation-hints-and-security-nerd-commentary-including-mini-threat-model/ and https://blogs.technet.microsoft.com/b/kfalde/archive/2015/11/18/laps-audit-reporting-via-wef-posh-and-powerbi.aspx

#edit to fix typos

Diary Archives