This is the companion post to CVE-2019-14510 – Abusing the Kaseya LAN Cache FSAdmin – Blue Team Edition. If you would like a full description of what function the Kaseya LAN Cache performs and how it creates the default FSAdminxxxxxxxxx accounts, please see that post. This post focuses entirely on how those accounts can be abused by red teamers and external threat actors. I discovered this during an assessment at a customer and proved how it could be abused within their environment. This post shows well known techniques being used against a commercial piece of RMM software in an environment where the systems admins simply did not understand what risk had been introduced by enabling a commonly used feature.

To provide a quick overview, the FSAdminxxxxxxxxx account gets created locally on each computer assigned to a LAN Cache. This includes Domain Controllers, domain members, WORKGROUP computers, and the LAN Cache host. When the account is created on a Domain Controller, it is created as a domain account. On each host, an identical password is set, and membership in the builtin\Administrators group is granted (even in the domain). This provides an easy mechanism to compromise a single host and pivot directly to a Domain Controller.

As previously mentioned, this engagement was not a red team engagement. We were performing a routine entitlement review of a customer environment. We noticed that the FSAdminxxxxxxxxx account existed locally on every machine we reviewed. This led to more research. We checked to see if the account also existed in the domain. Then it became clear to us that there may be a single step mechanism for compromising the domain. The following set of screenshots show how to abuse the FSAdminxxxxxxxxx account when it exists in the domain with the same password as on local computers.

Endpoint Compromise and Domain Controller Compromise

We manually deployed Mimikatz to an endpoint and ran it as an Administrator. This provided us with access to all the hashes in the local SAM of the computer. This also shows why users should not be granted local Administrator permissions. While it is usually possible to elevate permissions on an endpoint, defenders should not be making it easy for the attackers.

After gaining access to the hash, we attempted the same hash against an account in the domain. To perform this, we used Invoke-TheHash found at https://github.com/Kevin-Robertson/Invoke-TheHash. You can see that we pivoted directly to a Domain Controller with enough rights (Administrators membership) to enumerate the root of the C: drive from across the network. This server also happened to be a DHCP server.

At this point, the attacker would have administrative control of a Domain Controller. It’s trivial to elevate to Domain Admin and further from this point. The following screenshot shows the full attack chain.

Pass-the-Hash using a SAM Account?

It’s clear that this was a simple pass-the-hash attack. In 2019, why does this still work successfully? It’s important to understand that all the pass-the-hash protections Microsoft has put in place since Windows Vista do not apply to domain accounts (except for the in-memory protections which don’t apply to this situation). Additionally, some organizations have set the LocalAccountTokenFilterPolicy registry DWORD entry incorrectly which could result in local accounts being used in the now decades old Pass-the-Hash attacks. Harmj0y at SpecterOps wrote a great blog post about this which I refer to often. (http://www.harmj0y.net/blog/redteaming/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy/)

What can we learn?

Penetration testers should always check compromised local account hashes against the domain. Admins reuse passwords all the time. In this case, a reputable software company is doing it automatically when setting up the LAN Cache feature using default settings. Start by just checking to see if the account exists in the domain, then try the hash. Even if the account doesn’t exist, you may consider performing a password spray. We simply guessed that the password may be the same on both accounts.

Network defenders and Administrators should take some time to learn some basic offensive techniques and tooling. Also, understand that local accounts store their password in the same format (NTLM) as domain accounts. Reusing passwords is a recipe for compromise. We often see this on internet facing DMZ machines that may not even be joined to the domain. Even though it creates some administrative overhead, just don’t reuse passwords. It’s simply not worth it. Also, understand what the security implications could be of setting registry keys or creating accounts that a vendor or Internet post instruct you to create. There could be massive repercussions.

From a management perspective, how can CIO’s, CISO’s, IT Directors, and even the Board of Directors prevent this type of thing from happening?

1. 1. Mandate periodic entitlement and risk reviews.
   2. Don’t assume that all enterprise software is secure by default. Require the implementation team to understand the implications of each change to the environment. This is especially true when new accounts are created for the software.
   3. Consider having an outside entity to review your environment configuration and practices even when not required to do so as part of a compliance program. The unbiased perspective usually shows holes in the environment that you and your team wouldn’t have considered otherwise.
   4. Don’t assume that workstations are low risk to the environment. They are nodes on your network and frequently the entry point for malware. They can be dangerous, and the accounts that exist on them can be dangerous as well.

BE SAFE OUT THERE!