The traditional approach to monitoring endpoints focuses on detecting malicious software: signature analysis, behavioral detection, EDR. This is necessary but not enough to protect critical information systems, such as Microsoft Configuration Manager (SCCM / ConfigMgr). Whoever manages the SCCM server manages the infrastructure of an entire enterprise. That’s why SCCM requires a special monitoring, auditing, and change control mode.
In this article, we’ll show how a logical vulnerability CVE-2025-47179 allows gaining full control over SCCM, and how to monitor such attacks that are not detected by traditional anti-malware tools.
Vulnerability in the role model#
The built-in CMPivot Administrator role, according to the documentation, should only grant the right to run CMPivot, a diagnostic tool for sampling data from clients in real-time. The minimum required set of permissions for this is: Collection.Read and Collection.Run CMPivot.
However, as discovered by researchers at SpecterOPS, the role contained three additional permissions:
| Permission | What it allows |
|---|---|
| Users.Add | Create a new administrative user and assign them any security role |
| Users.Modify | Modify an existing administrative user and assign them any security role |
| Security Roles.Modify | Modify an existing custom role and add any permissions to it |
Thus, any member of the CMPivot Administrator role could, in a few API calls, assign themselves or any other account the Full Administrator role and gain full control over SCCM.
This is a logical vulnerability: there’s no buffer overflow, injection, or authentication bypass. SCCM worked strictly according to the rules that were built into it. The error lies in the rules themselves: the documented purpose of the role and its actual powers contradict each other.
Such vulnerabilities are particularly dangerous because they are not detected by traditional anti-malware tools: there’s no anomalous network traffic, no exploit, no malicious file. There’s only a legitimate administrator performing legitimate API calls with legitimate rights — but not the ones they should have been granted.
Exploitation technique#
The attack mechanics boil down to three steps, implemented through the native WMI interface of SCCM.
Step 1. The attacker, with the Users.Add right, creates an instance of the SMS_Admin class — a record about an administrative user in the SCCM storage.
Step 2. An array of SMS_APermission objects is attached to this instance, each describing a single permission assignment:
- RoleID = “SMS0001R” — the ID of the Full Administrator role
- CategoryID = “SMS00ALL” — the scope of “All”
- CategoryTypeID = 1 / 29 — the category type (collection / security scope)
Step 3. The ManagementObject.Put() call saves the instance on the SCCM server.
No additional tools are required — everything is implemented through System.Management (.NET), available in any version of PowerShell. The request to SCCM looks indistinguishable from standard Configuration Manager console actions.
This technique is reproduced by the AddSMSAdmin_Hybrid.ps1 script, used during vulnerability verification (this is a logical vulnerability, so it’s not an exploit, just a script):
The script was run under the account with only Users.Add / Users.Modify rights on SCCM. This was enough:
How to detect#
Our SCCMInfo tool implements SCCM server monitoring by subscribing to WMI events. For each of the monitored classes, a watcher is registered:
SELECT * FROM __InstanceCreationEvent WITHIN 1
WHERE TargetInstance ISA 'SMS_Admin'The event triggers when a new administrative user record is created, which is exactly what happens during the exploitation of CVE-2025-47179 through Users.Add.
The SmsAdminEnricher component extracts from the event and writes to a structured log (and possibly to the Windows log) fields that show what administrative user was added with such SID:
You can see that this user was added by someone named LOGAN_CABRERA…
…and the Full administrator role was assigned to him:
The detection logic uses two independent alarm signals:
CreatedBy — unknown user. Standard addition of SCCM administrators is performed by site administrators (in the vast majority of cases). If CreatedBy is an account that is not in the list of known site administrators, this is a reason to immediately start an investigation. This is exactly the situation that arises during exploitation through Users.Add: a user with a limited role (CMPivot Administrator) acts as the initiator.
RoleNames contains Full Administrator. Assigning the most privileged role in the hierarchy is an event that requires verification. In combination with a non-standard CreatedBy, this is an unequivocal indicator of compromise.
Adding new SCCM administrators can also be monitored on audit event 4732. However, it’s essential to know that from this event, it’s impossible to accurately determine who exactly added the administrator, as the SubjectUserName will always indicate the SCCM machine account:
Universality of the approach#
The vulnerability CVE-2025-47179 was fixed in November 2025, and the affected versions were Configuration Manager 2403, 2409, 2503. However, this is just one specific case that demonstrates a universal approach to monitoring SCCM. The SCCMInfo tool tracks several WMI event classes:
| WMI class | What the event trigger means |
|---|---|
| SMS_Admin | New administrative user — change in the access model |
| SMS_Scripts | New script added — potential code execution mechanism |
| SMS_SCI_Reserved | Site configuration change — change in infrastructure parameters |
| SMS_DeploymentInfo | New deployment — code execution/installation on endpoints |
| SMS_CombinedDeviceResources | New device in inventory — expansion of the management perimeter |
None of these events are directly related to malicious software. Each of them is a legitimate action within the standard operation of SCCM. That’s why they’re essential to monitor: attackers who gain access to SCCM act through legitimate mechanisms, not through exploits; such attacks are not detected by traditional anti-malware tools.
Conclusions#
Microsoft Configuration Manager (SCCM) deserves a special level of monitoring, as it can turn into a genuine command and control center when captured by attackers:
Secrets storage. Credentials used for SCCM network operations are stored in the site database and are accessible to Full Administrators.
Centralized code execution. One script or package can be executed on thousands of devices simultaneously.
Configuration changes without traces on endpoints. Modifying policy through SMS_SCI_Reserved does not leave artifacts on managed machines until the policy is applied.
Therefore, adding users with high privileges, the appearance of new scripts, and changes to site configuration — all this should be recorded, verified, and, if necessary, investigated. Monitoring SCCM at the WMI event level allows detecting exactly such changes in the management model — in real-time, without agents on the SCCM server side. This is orthogonal to traditional anti-malware tools and closes the blind spots that they don’t see.
Other techniques for attacking SCCM, as well as methods for detecting them, can be learned by watching the recording of DEF.CAMP our presentation “C2 by Microsoft: What can go wrong if SCCM ends up in the wrong hands”.
