Finally Deploy and Audit LAPS with Project VAST, Part 1 of 2

Hi folks – today I’d like to start the first of a two-part series about the Visual Auditing Security Tool (Project VAST) and the LAPS tool. LAPS stands for Local Administrator Password Solution and it (or a tool like it) should be a key component of your organization’s lateral account movement mitigation strategy. Mitigating lateral account movement, in turn, should be one of the first activities your organization commences in securing itself against credential theft attacks.

In this entry, we’ll briefly review lateral account movement and why you should care about it, how LAPS can dramatically slow down lateral account movement and why you should use it, some of the challenges with LAPS, and how VAST can help.

Quick Review: Lateral Account Movement

Lateral account movement, or the action of an attacker “pivoting” between computers, is a well-understood part of the known attack playbook. At simplified attack might go something like this: An attacker compromises a first “patient zero” machine with a drive by, an exploit, or likely some form of social engineering like a phishing attack. At this point and with virtually no effort or cost, the attacker has already bypassed perimeter-based security. With little effort, he or she can steal credentials out of memory or out of the Security Accounts Manager (SAM) database using free tools such as Mimikatz, pwdump7 or the like.

You might be surprised to learn that one of the credentials attackers are looking to steal is your local administrator. That’s right – the one in the local workstation or server’s SAM database. Your surprise might come from the fact that the local administrator only grants access to the machine – in this case, the machine that he or she already owns. Except that it doesn’t.  😊  Not if your organization has created the same local administrator password for all or even for large groups of the machines in your organization. In this scenario, the attacker simply re-uses the stolen credential to pivot between machines; put differently, the attacker may now move throughout the environment, often with total impunity.

At this point in the known playbook, the attacker has breached the perimeter security, stolen credentials, and is able to move freely throughout the environment. If the computers that contain the matching local admin password contain trade secrets, personal information, or other sensitive material, the attacker may simply steal it, destroy it, or perform some similar nefarious activity. At the same time, the attacker looks for escalation possibilities – namely, privileged credentials in the environment – to steal and with which to escalate entitlements.

There are multiple opportunities in the kill chain during the (oversimplified) attack that I’ve described so far. As I mentioned, installing and carefully using LAPS is one of the most effective mitigation techniques for dramatically slowing down the attacker’s lateral movement.

What is LAPS?

LAPS is a free, supported tool from Microsoft which “provides management of local account passwords of domain joined computers. Passwords are stored in Active Directory (AD) and protected by ACL, so only eligible users can read it or request its reset” (source: LAPS download page here). In simple terms, LAPS creates unique, random passwords and automatically changes them on a schedule that you specify (between one and 365 days; pro tip: don’t choose 365 days  😊). Installation steps and prerequisites are all documented in the LAPS Operations Guide, available on the download site:

1. Install and register a client-side extension (cse) dll on each computer to be managed
2. Extend the schema for two new attributes and a class change
3. Set Active Directory (AD) permissions
4. Configure and activate LAPS via Group Policy (GPO)

That’s pretty much it. The cse code calls a .NET randomizer, creates a new password in memory, commits it to the directory, and writes it back to the SAM database. Password changes occur when one of the two attributes on the computer object – the one that holds the expiration date – value expires and a GPO refresh occurs.

LAPS-managed passwords viewed in AD Users and Computers (ADUC) and also in PowerShell. Note that msmcsadmpwd is a confidential attribute; only authentication principals that you delegate can view it.

By implementing and configuring LAPS thoughtfully and carefully, organizations can insert a mitigation into the attack chain. Namely, by enforcing a non-matching local administrator account password, organizations can slow down the lateral account movement. Put enough roadblocks in front of an attacker, and you might be able to create an attacker’s dilemma, in which the advanced persistent threat (APT) has to choose whether or not to continue attacking your organization. In schematic terms, it might look something like this:

LAPS is very effective at what it does (and it only does what it is very effective at). It is so effective, in fact, that implementing LAPS comprises two of the very first actions on the Securing Privilege Access (SPA) roadmap, our prescriptive, public guidance for securing identities.

Okay, I’m convinced – what’s the problem?

Well there’s not necessarily a problem, per se. On the other hand, I’ve seen organizations really struggle in three areas:

1. Comprehensive roll-out to workstations and servers. LAPS doesn’t really provide a built-in method of reporting which machines are and are not under password management. I have worked with many organizations who have previously implemented LAPS partially, on only their workstations and not their servers, vice-versa, or who believe LAPS is managing the password for many more local admin accounts than it actually is. Certainly not all organizations struggle with successful rollout. But if there’s one gotcha off the bat, it’s that LAPS requires one (and only one) initial implementation (the cse dll) on each machine. This can get a bit complex and time consuming, especially for larger organizations or organizations without a robust software management solution. Additionally, decision makers often (and should!) ask what they are spending their security budget on, when it comes to any tool implementation – and LAPS is no exception. Decision makers from the CISO down increasingly need to understand their organization’s big data in order to make informed decisions and to gauge the impact of their intentional spending.
2. Delegating permissions to the accounts (and only the accounts) that they truly want to be able to view the passwords in AD. Recently, I worked with a company that saw a *lot* of LAPS password retrievals in its audit log through VAST. Upon investigation, we discovered that authenticated users had been accidentally granted the ability to view LAPS passwords. This undoubtedly made them less secure than they were before. Which leads me to the third area in which organizations struggle with LAPS.
3. Auditing usage of the shared password. Remember when I said LAPS does what it does very well? That’s still true. But auditing usage of managed passwords has never been its strong suit. VAST goes a long way toward solving the problem of making the LAPS audit trail really usable for these shared accounts. I will discus LAPS auditing next month, in the second part of this blog series.

Enter Project VAST

VAST actually contains two LAPS tabs: LAPS Deploy and LAPS Audit. Let’s examine LAPS Deploy.

By querying the non-confidential attribute msmcsadmpwdexpirationtime, VAST can display the current state of an organization’s LAPS deployment down to the machine. Using VAST, we can also view the current deployment by operating system, by workstation or server, by groups of machines that do or do not have LAPS deployed, and we can provide specific progress reports for each of these categories.

I typically like to start with a high-level overview of the data without filtering this tab just yet. In the lower right-hand corner, we have two needles representing progress. Overall LAPS Deployment % is a visual representation of the percentage of machines under LAPS management. In my lab, it’s 50% of all machines. LAPS Password Freshness represents the number of machines, of those 50% under management, whose local admin passwords are fresh (that is, are not past their expiration date). These machines measure 100%.

At this point, a narrative begins to make itself clear: half the machines are managed in my lab. Of those half, all of them are being managed as we desire. The solution is working well, but it is not, or not yet, fully deployed.

We can drill deeper. Setting isServerOS to True filters to only servers.

This “organization” (my lab) has not yet begun its deployment to any servers.

Clicking isSeverOS to False, we get a report of our LAPS rollout progress on workstations only.

Filtering in this way typically makes sense for several reasons. First, different teams almost always manage LAPS deployments to different types of computers (workstations and servers). Also, many organizations struggle with LAPS and different workstation operating systems. Many successfully add the cse dll to their images and then the GPO to the organizational unit (OU) for new machines, but struggle with their existing workstations. This can often manifest as a Windows 10 and Windows 7 problem, respectively. I’ve seen the opposite scenario as well.

Finally, as I said earlier, any single machine in question may be checked, by simply using the ComputerName filter.

 

Using VAST in this way, both engineers and decision makers can understand their LAPS deployment in ways that they simply couldn’t (or struggled to) previously. By aggregating a large amount of data and rendering it truly actionable, VAST can display exactly where an organization is succeeding and where it is struggling with its LAPS deployment.

That wraps it up for LAPS deployment and Project VAST. Stay tuned next month when we’ll discuss VAST and LAPS auditing.

I invite you to follow me on Twitter @securitypfe. And until then, happy auditing.