23 februari 2017

This post will detail how it is possible to compromise a System Center Operations Manager (SCOM) server and extract the plaintext RunAs credentials from the database. We will also provide tips on how to detect such attacks.

What are RunAs credentials?

In brief, when creating a SCOM workflow, RunAs profiles (and in turn RunAs accounts) are required in order for the agent to run on the targeted computer, whenever the “default action account” privileges are insufficient for the requirements. A further explanation can be found on the Microsoft website [1].

Depending on the use-case, this may result in an organisation having a large number of “RunAs accounts” configured in SCOM.

For example, if the organisation has a large number of Linux hosts, it may need to create multiple RunAs profiles in order to monitor these hosts.

Furthermore, these accounts are likely to be highly-privileged (usually with sudo permissions).

From an attacker’s perspective, this may sound like an absolute gold mine. If they are able to compromise the SCOM database and extract these credentials, they can be reused to gain access to the configured hosts.

Where are credentials stored?

Credentials are stored centrally in the database. The location of this can vary depending on configuration, but can be found by querying the following registry keys:

hklm:SOFTWAREMicrosoftSystem Center2010CommonDatabaseDatabaseServerName

hklm:SOFTWAREMicrosoftSystem Center2010CommonDatabaseDatabaseName

The default DatabaseName is “OperationsManager”

Credentials within the database are stored in the following table:

dbo.CredentialManagerSecureStorage

How are RunAs credentials stored?

Carrying out a quick Google search for “SCOM database encryption” doesn’t reveal much, apart from a forum post which states:

“As far as I know, there is no document indicate how we encrypt SCOM database, including ACS database.”[2]

This doesn’t sound too promising – but reading the deployment guide [3] we find reference to the following registry key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftSystem Center2010CommonMOMBins

The guide states that “If value1 and value 2 exist, the encryption key has successfully been restored”. Bingo! It sounds like if we can extract the value of this key, we might be able to use it to decrypt the database values.

Encryption

So now we know that the RunAs credentials are encrypted (but we’re not sure how), and we have some information as to where the key may be stored.

To get further, we are going to need to dig into the SCOM DLLs and figure out the encryption mechanism.

Thankfully the DLLs are written in .NET so we can simply decompile the Microsoft DLLs and read the source code. But where to start? Looking in the installation dir reveals a large number of potential candidates:

Looking again at the database, we can see the following columns:

SecureStorageElementId
SecureStorageId
Name
Description
UserName
Domain
Type
Data
DataHash
IsSystem
AssemblyQualifiedName
ConfigurationXml
ConfigExtensionData
LastModified

There are several mentions of “SecureStorage”. Doing another search on the file-system for “SecureStorage” finds 1 DLL:

Loading this up in your favourite .NET decompiler, you can see the SecureStorageManager class defined here:

Reading through the source code, we’re able to determine that it carries out the following tasks to decrypt the credentials stored in the database (condensed for brevity):

● Calls the SecureStorageManager.Initialize() method and reads in the encrypted RSA private key value stored at: “SOFTWAREMicrosoftSystem Center2010CommonMOMBins”
● Queries the dbo.MachineKey table to retrieve the following values:
○ servername (string)
○ publicKey (byte[])
○ masterKey (byte[])
○ masterIV (byte[])
● Decrypts the private key using DPAPI.
● The private key is used to decrypt the masterKey and masterIV
● The masterKey and masterIV are used to decrypt the credential data using AES 256.

Decrypting the data ourselves

Rather than reinventing the wheel, and seeing as Microsoft has already done all the legwork for us, we can simply reuse the existing Dlls to create an instance of the SecureStorageManager class and decrypt the database using either C# or PowerShell.

We have released both a C# and PowerShell version of our decryption tool “SCOMDecrypt” on our Github.

The tool simply looks up the registry keys to find where the database is located, dumps out the CredentialManagerSecureStorage table and decrypts the content using the built-in functionality.

Protecting against SCOM attacks

From a Red Teaming perspective this is obviously a great and powerful position to be in, we can now dump highly-privileged credentials in clear-text from the SCOM database – provided we can gain access to the SCOM server.

This is likely to potentially contain things such as service account passwords, root-capable Linux passwords or even Domain Admin credentials. The keys to the kingdom.

However, from a defence perspective this represents a problem. What if an attacker gets onto our SCOM server? How do we protect against this? Well, one option is to use SCOM to monitor SCOM for access to the MomBins registry key (insert xzibit meme here).

This can be achieved by setting up “Object Access Auditing” in Group Policy. This should be set to Audit Registry access as shown below:

Once enabled in Group Policy, you can then enable auditing by navigating to the MOMBins registry key, right-clicking and selecting “Permissions”.

Click the advanced button, then select the “auditing” tab. From here you can enable auditing on any read accesses made by any user, as shown below:

Now, if the SCOMDecrypt tool is run on the server, you should see the following event (ID 4663) registered in the Security Event Log.

This event shows that the user “EVILCORPAdministrator” attempted to access the MOMBins registry key, from the powershell.exe process:

This should enable you to monitor any accesses to the key value, and thus, hopefully detect if an attacker is attempting to compromise the database.

Note that determining whether access is malicious should not be based solely on the process name, as it would be simple for an attacker to inject directly into the trusted SCOM process.

Instead, logs should be looked at in context to determine whether the access could be deemed malicious. This is left as an exercise for the reader.