Alternatively, during my time researching SCOM, I created a NetExec LDAP module to conduct this enumeration, as shown below.

This query can be passed into ntlmrelayx, allowing us to coerce the Management Server to connect to the attacker machine, so we may relay the authentication to the target Operational Database.

Add a list function to verify that the account was successfully created.

To know who else is listed with permissions to access the Operations Console, add a SID reverse flag under the MSSQL module that you can use to reverse any one of these “MemberSID” users back to their original SID.

Once downloaded, connect to the Management Server by providing its IP address.

Now knowing our target device, we can confirm the Action account on the host that would be executing our malicious tasks. We can confirm this under Administration > Device Management > Agent Managed, as demonstrated below. This will show the default Action accounts used for these servers.

Once created, browse back to the Monitoring page and return to the Windows Computers. Highlight the domain controller and click on our newly created Windows Computer Task.

It will open a Run Task pop up. Make sure to set the Task credentials to “Use the predefined Run As Account”. This is the Action account we established as being set to SYSTEM earlier.

Once you hit run, it will execute our command as SYSTEM and notify us that our task has been completed successfully. We can confirm this by authenticating to the domain controller to confirm that our user is now a domain administrator.

If the domain controller isn’t a monitored host that we can execute code on, we can still execute code on other hosts and give ourselves local administrative rights. We can do this by creating a new task with the same configuration as before that executes cmd.exe with the following parameters:

Two sets of credentials were compromised: the “opsmgr_action” account, which is the host’s Action account and the “sql_runas” account. But where did the “sql_runas” credentials come from? The following screenshot and explanation answers this question.

If this returns with nothing, you will need to create one. For this, use the following PowerShell cmdlet.

For your awareness, this will take 10 hours to complete gracefully. Wait the full 10 hours before proceeding. Once you have created the key, we can create a group of computers that are allowed to pull our gMSA user password, as shown below.

Then, add the Management Servers for SCOM into the group.

Now, create a gMSA account that will be used as the Data Access Service account.

Next, grant the required permissions on the OperationsManager database. This is the core operational database for SCOM. The sdk_users role is a SCOM specific role created during installation. The Data Access Service must be a member of this role for the SDK to function. db_datareader and db_datawriter grant the account read and write access to the operational data SCOM needs to function, including alerts, state changes and configuration.

The OperationsManagerDW database also requires permissions. This is the SCOM data warehouse used for reporting and long-term data retention. The DAS account needs read and write access here so that performance data and alert history are written correctly for reporting purposes.

Finally, the MSDB database also requires additional permissions. MSDB is a SQL Server system database that manages SQL Agent jobs. SCOM uses SQL Agent jobs to handle maintenance mode scheduling. Without these permissions, creating or deleting maintenance schedules from the SCOM console will time out and generate a flood of invalid SQL Agent jobs. SQLAgentUserRole grants the minimum permissions needed to interact with SQL Agent without granting broader access.

Then, add them to the created gMSA.

Now on the Management Server, we need to add this gMSA to the local Administrators group.

Install the gMSA on the management server so the Service Control Manager can retrieve the password from AD. If this fails, the management server computer account may not have refreshed its Kerberos ticket since our modifications. A reboot of the Management Server can resolve this.

Then, execute the following commands to alter who is running this service. The password field is left blank as the Service Control Manager handles password retrieval automatically for gMSAs.

Then, start the services back up.

The next portion of the outlined attack we can detect is the manipulation of the AZMan_Role_SIDMember table within the OperationManager Database. This table lists what accounts have permissions to access the Operations Console to manage SCOM monitored devices. If this table is altered, it is possible an attacker is aiming to gain access to the Operations Console to compromise these hosts. This will require the computer to be auditing this table for updates to it to be sent to the SIEM and to be alerted upon.

If an attacker has gained access to the Operations Console, it is possible they are making this connection from an attacker-controlled host utilizing their own Operations Console that can be connected to a Management Server and compromise the SCOM monitored hosts. This connection is conducted over port 5724 and utilizing Sysmon, we can detect incoming connections and identify any rogue Operations Console installations. The Sysmon configuration will require the following within the NetworkConnect section: “<Image condition=”end with”>Microsoft.Mom.Sdk.ServiceHost.exe</Image>”.