Distributing SCOM Run As Accounts and Security Implications

Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.

Account distribution is one of those things that is very easy to do inside of SCOM, and it’s also very easy to do wrong. Unfortunately, this is the type of mistake that could inadvertently give an attacker a quick means to compromise the entire environment.

First, let’s start with the basics:  what and why. Account distribution effectively allows SCOM to run workflows on a target system with credentials other than the agent action account, which should always be the local system account. Some applications have application level security built into them (SQL is a perfect example of this, as out of the box, there’s no rights defined for the system account). As such, an admin will need to distributed a runas account.

We have two options in SCOM for distributing these accounts, and they are exactly as they sound. A “More secure” distribution forces an admin to target which system or systems that the account will run on. The less secure option will run it on every single SCOM agent. From a pass-the-hash standpoint, what this effectively does is create an interactive logon with this account. If it has any permissions at all across the domain (which it would need to set things up in this capacity), you’ve effectively given an attacker a tier 1 or tier 0 account which can be re-used by an attacker. 

If you don’t believe me, believe the demo. I’ve created an account called test. I’m following bad practices in this setup and I’ve made my test account a domain admin (though carte blanche local admin would give us the same vulnerability) and I’m using less secure distribution:

Within a minute or so of doing this, you’ll see the following event in the SCOM event log:

This is SCOM telling me that we have successfully logged on with said account.

From my “compromised system” I’m launching Mimikatz. I’ve put task manager right next to it so that you can see what an attacker sees versus what a user sees. Note that that there is no RDP session for my test account. It is running in memory only. Mimikatz confirms this:

Just a quick note on credential theft, but this a simple example on how an organization can be quickly compromised. All the attacker needs is to compromise a system (very easy to do) and then mine the credentials of other accounts running on said system (again, very easy). They reuse those credentials to move laterally throughout an organization until they find a set of credentials that allows them to move up (aka administrative tier). In this case, if an attacker was sitting on any system that has a SCOM agent on it, they would be able to mine the creds to this test account. Since it’s a domain admin, they could go straight to my DC and export a copy of my entire domain database, and then do whatever they intended to do. Even if said account was just a “local admin”, the process is still very dangerous, as they could essentially hit every single one of my servers at this point with said account, even if they hadn’t compromised my domain. My data is effectively theirs.

There are a few morals to the story, and to be fair, any competent security person is going to lay out what I’m going to say next, but it certainly bears repeating:

1. Only distribute accounts to the systems that need to run said accounts. This will lessen the scope of which accounts an attacker can reuse.
2. Restrict the accounts permissions in the domain to only the machines that need the account. At this point, if the account is compromised, it will only work on the machines that need said account, meaning that if the account is compromised, the attacker can only use it on the handful of systems that need it.

From where SCOM stands, that’s about all that we can do. I would simply note that there are many other things needed to ‘secure’ an environment, all of which are laid out in much more detail in our pass the hash whitepapers. Bottom line is that organizations should be using firewalls to block inbound connections, disabling local accounts from RDP, randomizing local admin passwords, and using a tiered approach to their environment which prevents high level accounts from accessing less secure tiers.

Comments

• Anonymous
  July 11, 2018
  Excellent Post.
• Anonymous
  July 24, 2018
  Very interesting. Thanks, Nathan!