For organizations managing hundreds or thousands of servers, System Center Operations Manager (SCOM) provides a single pane of glass into system health, performance and availability. It is deeply integrated, broadly deployed and trusted with the access it needs to do its job.

That access is exactly what makes it dangerous. In the wrong hands, SCOM becomes a fully operational command-and-control platform hiding in plain sight, capable of taking an attacker from a standard domain account to code execution on every host it monitors.

This blog provides a practical primer for penetration testers and defenders. Using proven techniques and practices and based on real experiences, this article will help you identify, exploit, detect and remediate SCOM vulnerabilities in the environments you assess and protect, while demonstrating attack paths, tools and techniques that you’ll need to defend against.

TL;DR –

SCOM’s default configuration lets an attacker execute code on every monitored host, all from a standard domain account. By learning the full attack chain and understanding the tools attackers use to compromise the platform, you can greatly reduce the risk without diminishing the value of SCOM’s operational capabilities.

Key Takeaways:

SCOM is Microsoft’s enterprise monitoring platform. It puts an agent on every server it monitors, collects health and performance data and funnels everything back to a central Management Server. In most large Windows environments, that means SCOM has a footprint on nearly every host and the credentials to match.

Three pieces of that architecture matter here when it comes to an attack. The Management Server runs a Data Access Service authenticated by a domain account with a registered Service Principal Name (SPN). This is the entry point for the relay attack. The Operations Console gives SCOM administrators the ability to push scripts and commands to any monitored host, which becomes the execution mechanism. And MonitoringHost.exe on each agent stores the Action Account and Run As Account credentials locally. This is where the credential exposure can happen.

A SCOM Relay Attack compromises the Operations Console by relaying authentication from the Data Access Service account. This compromise gives an attacker full control over every monitored host in the environment.

It’s necessary to authenticate to the domain with a valid account to properly conduct this attack and enumerate for the Management Server and Data Access Service account SPNs. The associated SPNs have the prefixes “MSOMHSvc/” for the Management Server and “MSOMSdkSvc/” Data Access Service. Along with Garrett Foster’s research of SCOM, he released the tool SCOMHunter which contains a multitude of functions to attack SCOM, including one to conduct this enumeration for us, as demonstrated below.

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

The enumeration shows the Data Access Service SPN set to the Management Server, meaning the Management Server’s computer account has write permissions over the Operational Database. What is shown is the default configuration of SCOM’s Data Access Service SPNs.

Default configurations open the door to coerce this machine account and relay the authentication request to the Operational Database with a query that would add our user account into the “AzMan_Role_SIDMember” table. Anyone listed in this table has access to login to the Operations Console, signaling a full compromise of SCOM.

To perform this relay attack, create a database query that will be sent to the Operational Database to add our user into the “AzMan_Role_SIDMember” table. The query passes the SID of our user account to SCOMHunter’s MSSQL module.

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.

impacket-ntlmrelayx -t mssql://10.7.10.30 -smb2support --no-http-server -q "Use OperationsManager; INSERT INTO AzMan_Role_SIDMember (RoleID, MemberSID) Values ('1', 0x01050000000000051500000093049C924FB4E4100694AE6D5B040000);"

At the time of writing this blog, there is no concrete reliable way of identifying the operational database. The best way thus far is to look at the hostname of the MSSQL servers or their IP address proximity to the Management Server. Both methods are rather unreliable. By creating a function within the SCOMHunter tool, we can combines it MSSQL module to generate the query. It then takes a target file of MSSQL hosts for the authentication to be relayed to in hopes the query sticks somewhere. To cause this coercion between our host and the Management Server, use the PetitPotam tool. Due to how the authentication is relayed to the hosts in the target file, it may require multiple attempts to get through the file and its hosts.

As shown below, SCOMHunter successfully executed the query on a MSSQL host and created the new account automatically.

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.

We expanded our domain user access to authenticate to the Operations Console, which allows us to compromise the monitored hosts within SCOM. But the Operations Console application is on the same device as the Management Server, so how do we access it?

As mentioned in the intro, SCOM has a web console that can be created on the Management Server. Anyone contained in the “AzMan_Role_SIDMember” has access to remotely log in to this console. However, this is a limited version of the Operations Console that only contains the Monitoring page and personal dashboard for your user. You do not have access to the Auditing or Administration pages, which would allow us to create malicious tasks to execute on the monitored hosts. However, within the personal dashboard, there is a PowerShell widget which allows command execution on the underlying Management Server.

If we were unsuccessful in adding a domain user to “AzMan_Role_SIDMember” table, it is possible to relay authentications to the Management Server endpoint in hopes of gaining a session. The most reliable method to relay would be from a separate Management Server to relay to a second Management Server’s web console. However, by default, the computer account is not included in the “AzMan_Role_SIDMember” table, so we would hope that the administrators deploying SCOM misconfigured it by adding the computer accounts to the table.

Once on the dashboard, you can utilize the following PowerShell script and identify the user context associated.

$output = & whoami /all | Where-Object { $_ -ne "" }

$i = 1

foreach ($line in $output) {

$dataObject = $ScriptContext.CreateInstance("xsd://foo!bar/baz")

$dataObject["Id"] = $i.ToString()

$dataObject["Line"] = $line.ToString()

$ScriptContext.ReturnCollection.Add($dataObject)

$i++

}

Commonly, the account executing these commands is going to be “IIS AppPool\OperationsManager” who possesses the “SeImpersonatePrivilege” user right. If so, we can escalate privileges and add our domain user to the local admin role of the Management Server. By doing so, it will allow us to log in remotely and access the Operations Console.

For those that don’t have an obfuscated version of GodPotato, there is a more reliable route. Microsoft provides an evaluation download for SCOM which you can install on a Windows system here. With this you can choose to install just the Operations Console on your host.

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

It will then prompt for credentials for an account that has permissions to the Operations Console. You can provide the user you added to the “AzMan_Role_SIDMember” earlier and successfully log in.

On the Operations Console, we have control over any SCOM managed device. A list of these devices can be viewed under the Monitoring page.

The Monitoring page will display several items on the left-hand side. Under the Windows Computers item, we can identify potentially sensitive Active Directory servers or computers to target for compromise. In this lab, one such device is a domain controller.

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.

Any task we run on this host will be run as the SYSTEM account of the Domain Controller meaning we can execute commands such as adding our user to the Domain Admins group.

To create a task, access the Authoring page > Management Pack Objects > Tasks > Create a New Task.

When the Task Wizard appears, create a command line Agent Task and place it in a Management Pack. Creating a new one can be easier to clean up later, as these are basically folders to hold tasks. Under the General Properties, name it something you can identify and make sure the Task target is set to Windows Computer.

Under Command Line, we can set the task to execute cmd.exe and provide the following parameters to add our user to the Domain Admins group.

/c net group “Domain Admins” domainuser /add /domain

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:

/c net localgroup "Administrators" ludus\domainuser /add

Let’s target the SRV01 at 10.7.10.32 in my lab, which we saw earlier. Their Action account is “opsmgr_action”. Action accounts need a few specific permissions to operate in a least privileged manner including being a member of the local Users and Performance Monitoring Users groups and if prior to Operation Manager 2019, permissions to log on locally (SetInteractiveLogonRight). These could be done through a GPO to apply to monitored hosts, but you will often find that the action account will be SYSTEM or a domain user, making this technique simpler. If you want to verify that the Action account is an administrator, create a task that simply executes “whoami /all” to verify.

Our user has been added to the local Administrators group on SRV01 through a task executed by the Action account “opsmgr_action.” From here, extracting credentials from the system reveals that SCOM stores the Action and Run As account locally on the monitored host as DPAPI-protected blobs, located in the registry under the HealthService key. The Health Service stores the Action account to spawn MonitoringHost processes and Run As account credentials are stored when they are distributed to the agent. SCOMHunter’s DPAPI module establishes an SMB connection to the host, pulls those registry blobs, retrieves the DPAPI MasterKey via LSA secrets and decrypts any credentials found.

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.

The “sql_runas” account is set to “Less secure” distribution, which means its credentials are distributed to all monitored hosts. Why would they distribute it to all the hosts? The system administrator has two options:

SCOM utilizes a Health Service process on each monitored host that receives configuration and workflows from the Management Server. To execute those workflows, the Health Service spawns child MonitoringHost processes that run under the configured Action account. The Action account defaults to NT AUTHORITY\SYSTEM but, as shown here with “opsmgr_action”, it can be configured as a domain user. SCOM also allows workflows including rules, monitors, discoveries and tasks to run under a different account when the Action account lacks the required permissions. This is where Run As credentials play an important role. When SCOM distributes a Run As credential to an agent, the Health Service stores it in the registry as a DPAPI-protected blob. That blob can be decrypted by any attacker with local administrator rights on the host, which is what the SCOMHunter DPAPI module is doing. SCOM will only execute a workflow with a Run As account on hosts that have received those credentials. A host must either be on the More secure allow list or the Run As account must be configured to Less secure so all monitored hosts receive it automatically. This is why Less secure is more common in practice. If an administrator adds a new monitored computer that needs the credential, they must also manually add it to the More secure allow list. With Less secure, that extra step does not exist. A common example of convenience versus security.

What happens if we find all the Run As accounts are set to More secure? Are these credentials secure? No. As mentioned, these credentials are distributed to any host in its explicit list allowing us to harvest its plaintext credentials from any of the specified computers. For maximizing dumping credentials from SCOM, I’d suggest finding one host you are going to dump all the credentials from and add any computers that are More secure to the list. If you turn a Run As account from More secure to Less secure, it will lose the entire list, causing you to re-add all hosts back to its explicit list. It is much easier to just add one, dump the credentials, then remove it from the list afterwards.

Starting with the relay to the Operational Database, we need to change where the Data Access Service SPN, “MSOMSdkSvc/”, resides from the Management Server to a gMSA account. By default, SCOM sets this SPN to the Management Server allowing this attack to occur.

We first need to create a gMSA account to act as the Data Access Service account. To do this we will need the KDS Root Key. You can check if you already have one by logging into the domain controller as a domain admin and issuing the following PowerShell cmdlet.

Get-KdsRootKey

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

Add-KdsRootKey

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.

$groupParams = @{

Name = "SCOM-DAS-Hosts"

GroupScope = "Global"

GroupCategory = "Security"

Path = "CN=Users,DC=ludus,DC=domain"

Description = "Computers authorized to retrieve opsmgr_gmsa_das password"

}

New-ADGroup @groupParams

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

Add-ADGroupMember -Identity "SCOM-DAS-Hosts" -Members "scom-om1$"

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

$gmsaParams = @{

Name = "opsmgr_gmsa_das"

DNSHostName = "opsmgr_gmsa_das.ludus.domain"

PrincipalsAllowedToRetrieveManagedPassword = "SCOM-DAS-Hosts"

KerberosEncryptionType = "AES256"

Description = "SCOM Data Access Service gMSA"

}

New-ADServiceAccount @gmsaParams

With this account, we need to add read and write permissions to the OperationsManager and OperationsManagerDW databases. Access the SQL server hosting these databases and open SSMS to run the following queries.

First, create a server level login for the gMSA. A SQL login is a server level object that must exist before any database level permissions can be assigned. Without this, every subsequent query will fail. Note the $ suffix on the account name. This is required for SQL Server to recognize the account as a gMSA rather than a standard domain account.

If your OperationsManager and OperationsManagerDW databases exist on separate SQL servers, this query must be run on both servers independently.

USE [master]GO

CREATE LOGIN [LUDUS\opsmgr_gmsa_das$] FROM WINDOWS

GO

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.

USE [OperationsManager]GO

CREATE USER [LUDUS\opsmgr_gmsa_das$] FOR LOGIN [LUDUS\opsmgr_gmsa_das$]GO

EXEC sp_addrolemember 'sdk_users', 'LUDUS\opsmgr_gmsa_das$'

GO

ALTER ROLE [db_datareader] ADD MEMBER [LUDUS\opsmgr_gmsa_das$]ALTER ROLE [db_datawriter] ADD MEMBER [LUDUS\opsmgr_gmsa_das$]GO

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.

USE [OperationsManagerDW]GO

CREATE USER [LUDUS\opsmgr_gmsa_das$] FOR LOGIN [LUDUS\opsmgr_gmsa_das$]GO

ALTER ROLE [db_datareader] ADD MEMBER [LUDUS\opsmgr_gmsa_das$]ALTER ROLE [db_datawriter] ADD MEMBER [LUDUS\opsmgr_gmsa_das$]GO

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.

USE [msdb]GO

CREATE USER [LUDUS\opsmgr_gmsa_das$] FOR LOGIN [LUDUS\opsmgr_gmsa_das$]GO

ALTER ROLE [db_datareader] ADD MEMBER [LUDUS\opsmgr_gmsa_das$]ALTER ROLE [SQLAgentUserRole] ADD MEMBER [LUDUS\opsmgr_gmsa_das$]GO

Now that the gMSA has the correct SQL permissions, we need to migrate the “MSOMSdkSvc/” SPNs from the management server computer account to the gMSA.

This is the core of the relaying vulnerability. With this SPN set to the Management Server, an attacker can coerce its authentication to be relayed to the SQL server allowing them to send malicious queries to the databases including the ability to access the Operations Console. Moving the SPNs off the computer account and onto the gMSA removes the easy coercion target. You can no longer simply coerce the management server computer account and relay it to the SQL server. Because the gMSA is not a computer account, it cannot be coerced in the same way.

To move these SPNs, we first need to remove the SPNs from the Management Server computer account.

setspn -D "MSOMSdkSvc/scom-om1" "LUDUS\scom-om1$"

setspn -D "MSOMSdkSvc/scom-om1.ludus.domain" "LUDUS\scom-om1$"

Then, add them to the created gMSA.

setspn -A "MSOMSdkSvc/scom-om1" "LUDUS\opsmgr_gmsa_das$"

setspn -A "MSOMSdkSvc/scom-om1.ludus.domain" "LUDUS\opsmgr_gmsa_das$"

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

Add-LocalGroupMember -Group "Administrators" -Member "LUDUS\opsmgr_gmsa_das$"

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.

Install-ADServiceAccount -Identity "opsmgr_gmsa_das"

With this returning True, we can stop the dependent services and swap them to run as the gMSA.

Begin by stopping the OMSDK and cshost services that are currently running as the computer account.

Stop-Service -Name "OMSDK" -Force

Stop-Service -Name "cshost" -Force

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.

$svc = Get-WmiObject Win32_Service -Filter "Name='OMSDK'"

$svc.Change($null,$null,$null,$null,$null,$null,"LUDUS\opsmgr_gmsa_das$","")

$svc = Get-WmiObject Win32_Service -Filter "Name='cshost'"

$svc.Change($null,$null,$null,$null,$null,$null,"LUDUS\opsmgr_gmsa_das$","")

Then, start the services back up.

Start-Service -Name "cshost"

Start-Service -Name "OMSDK"

In addition to this, SMB signing and MSSQL Extended Protection for Authentication are worth enabling as defense-in-depth controls, as they raise the bar for conducting the relay itself. However, they do not address the root cause, which is the SPN sitting on a coercible computer account.

Regarding Run As credentials, the best method to ensure these credentials are not deployed across all monitored hosts is to set each account to More secure distribution and explicitly list only the computers that require the credential in the allow list. As covered in the credential dumping section above, accounts set to Less secure distribution are stored on every monitored host and can be decrypted by any attacker with local admin access, making them a reliable path to privilege escalation. Where possible, configure the action account for the MonitoringHost service to use NT AUTHORITY\SYSTEM. This prevents a domain user action account from being dumped if an attacker obtains local admin on a monitored host but will not prevent any Run As accounts from being dumped.

As for the web console attacks, it’s best to just turn this feature off. The PowerShell widget is a wide-open remote code execution issue and should be treated as such. If you must keep this on, it’s best to ensure only those that need access to the web console have it by regularly monitoring the “AzMan_Role_SIDMember” database table, ensuring only required accounts contain this permission. For this, below are some detections to help monitor the table.

Let’s walk through three detections for the attacks outlined above for a defender to implement into their SIEM solution. Each has a SIGMA rule that you can translate to be able to directly import, customize to your environment and deploy. To translate these, you can use AI or translators such as Uncoder or SOC Prime. Ensure that all detections are tested prior to being authorized for production use.

The first is an LDAP query detection specifically focused on the enumeration of Management Server or Data Access Service account SPNs. Attackers will search for these SPNs to identify if SCOM is present within the environment and if it is set up with a vulnerable configuration. This requires the domain controllers to send Event 1644 via NTDS Diagnostics to the SIEM solution to identify these LDAP queries.

title: SCOM SPN Enumeration via LDAP

id: 7e2b9c4a-3f81-4d6e-b5a2-9c8f1e4d7a23

status: experimental

description: |

Detects LDAP queries for SCOM Service Principal Names (MSOMHSvc, MSOMSdkSvc,

MSOMRMSSvc) used by adversaries to identify SCOM Management Servers and

determine the principal type holding the SDK Data Access Service (DAS) SPN.

references:

• https://specterops.io/blog/2025/12/10/scommand-and-conquer-attacking-system-center-operations-manager-part-1/
• GuidePointBlogURL

author: Ryan Voit

date: 2026/04/29

logsource:

product: windows

service: ldap_audit

definition: |

Requires Event 1644 enabled on domain controllers via NTDS Diagnostics

registry key "15 Field Engineering" set to 5

detection:

selection:

EventID: 1644

Message|contains:

• 'MSOMHSvc'
• 'MSOMSdkSvc'
• 'MSOMRMSSvc'

condition: selection

fields:

• SearchFilter
• Client
• User
• Computer

falsepositives:

• Legitimate SCOM agents performing SPN lookups during service start, network failover or config refresh
• Operations Console connections from sanctioned admin workstations
• Web Console backend SDK connections
• Third-party SCOM integrations (Squared Up, ServiceNow MID servers, custom SDK applications)
• SCOM PowerShell automation

level: medium

tags:

• attack.discovery
• attack.t1087.002
• attack.reconnaissance

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.

title: SCOM OperationsManager Database AzMan Role Membership Modified

id: b5d2f7a1-8c3e-4a19-b6d4-2e9f0c5a8d31

status: experimental

description: |

Detects modifications (INSERT, UPDATE, DELETE) to the AzMan_Role_SIDMember

table in the OperationsManager database via SQL Server Audit (Event 33205).

This table holds SCOM role membership of those that can access the Operations

Console. An attacker with sufficient SQL privileges can insert their own SID

into a privileged role, gaining full SCOM administrator access and enabling

lateral movement to all monitored endpoints via management pack script

execution or agent tasks.

references:

• GuidePointBlogURL

author: Ryan Voit

date: 2026/04/30

logsource:

product: windows

service: application

definition: |

Setup requirements:

SQL Server Audit must be enabled on the SQL Server hosting the

OperationsManager database. Run the following as sysadmin:

USE master;

CREATE SERVER AUDIT SCOM_AzMan_Audit

TO APPLICATION_LOG

WITH (QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE);

ALTER SERVER AUDIT SCOM_AzMan_Audit WITH (STATE = ON);

USE OperationsManager;

CREATE DATABASE AUDIT SPECIFICATION SCOM_AzMan_Role_Changes

FOR SERVER AUDIT SCOM_AzMan_Audit

ADD (INSERT, UPDATE, DELETE ON dbo.AzMan_Role_SIDMember BY public)

WITH (STATE = ON);

Audit events are written to the Windows Application log as Event ID

33205 from source MSSQLSERVER. Ensure your log collection agent is

gathering the Application channel from the OperationsManager DB server.

If your environment writes SQL audits to the Security log instead,

adjust the logsource service to 'security' accordingly.

detection:

selection:

EventID: 33205

Provider_Name: 'MSSQLSERVER'

keywords:

Message|contains|all:

• 'AzMan_Role_SIDMember'
• 'OperationsManager'

condition: selection and keywords

fields:

• Message

falsepositives:

• Legitimate role assignment via direct SQL
• SCOM upgrade, patching or migration activities
• Backup and restore operations on the OperationsManager database

level: high

tags:

• attack.persistence
• attack.privilege_escalation
• attack.t1078.002

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: “Microsoft.Mom.Sdk.ServiceHost.exe”.

title: Operations Console Connection to SCOM Management Server

id: a3f1c8e2-7b4d-4f29-9c5e-1d8e6a2b9f47

status: experimental

description: |

Detects inbound network connections to the SCOM SDK Service (TCP 5724) on a

Management Server from hosts not on the approved allowlist. The Operations

Console and any SDK client (PowerShell OperationsManager module, third-party

integrations) connect to this port. Legitimate sources are limited to other

management servers, Web Console hosts and sanctioned admin workstations.

Connections from any other source indicate a rogue Operations Console or

unauthorized SDK client pointed at the management server.

references:

• GuidePointBlogURL

author: Ryan Voit

date: 2026/04/29

logsource:

product: windows

category: network_connection

definition: |

Sysmon must be installed on all SCOM Management Servers and configured to

log Event ID 3 (Network Connection) for the SCOM SDK service binary.

Add the following rule to your Sysmon configuration's NetworkConnect

include block to ensure SDK service connections are captured:

Microsoft.Mom.Sdk.ServiceHost.exe

detection:

selection:

Image|endswith: '\Microsoft.Mom.Sdk.ServiceHost.exe'

DestinationPort: 5724

Initiated: 'false'

filter_known_good_sources:

SourceIp:

• '10.7.10.31' # scom-om1 (self / loopback)

Add additional management servers, Web Console hosts and admin workstations

condition: selection and not filter_known_good_sources

fields:

• SourceIp
• SourcePort
• SourceHostname
• User
• Image
• DestinationIp

falsepositives:

• Newly provisioned management servers or Web Console hosts not yet added to the allowlist
• Approved third-party SCOM integrations (Squared Up, ServiceNow MID, custom SDK applications)
• Scheduled SDK scripts running from unexpected hosts

level: high

tags:

• attack.discovery
• attack.t1018
• attack.lateral_movement
• attack.t1021

SCOM’s attack surface runs deeper than most organizations realize. A default deployment hands an attacker a clear path from a standard domain account to code execution across every monitored host. Moving the MSOMSdkSvc SPN off the Management Server to a gMSA closes the primary relay path and tightening Run As distribution and disabling the web console PowerShell widget removes the remaining footholds.

A special thanks to Garrett Foster, Matt Johnson and Zach Stein for their foundational research that made this work possible.