SCCM: Enterprise Backbone or Attack Vector? Part 2

Introduction

The first part of this blog post explored SCCM architecture and initial reconnaissance; this second part will delve into advanced attack phases like credential access and persistence. We examine how attackers extract network access account credentials and establish persistent control, plus detection strategies using logs and telemetry.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Deep Dive: SCCM Attack Tactic

Before we start, it’s recommended to understand the SCCM hierarchy, which we covered in Part 1. That section explained CAS, Primary Sites, Secondary Sites, clients, and more. You can revisit it for the full details, or skip ahead if you’ve already got the basics down.

Credentials Access

Network access account (NAA) is a domain account that administrators configure on the SCCM site server. Its fundamental and only purpose is to enable SCCM clients to access and retrieve software content like application packages, software updates, and operating system images—from a distribution point. The credentials associated with the NAA are delivered to clients as an integral part of their computer policy.

Attackers may attempt to extract the credentials of the NAA, which allows non-domain-joined computers to access software from the SCCM distribution point during client deployment.

By default, an SCCM client device will use a computer account to retrieve software from an Distribution point, but in cases where a client is not (yet) domain-joined, the account uses a NNA account.

Extract NAA via WMI\CIM repository

The credentials of NNA account are stored on SCCM client machines, protected by DPAPI (Data Protection API). Attackers can extract these credentials using WMI (locally or remotely) from the

CCM_NetworkAccessAccount class within the root\ccm\policy\Machine\ActualConfig WMI namespace. Alternatively, they can target the underlying CIM repository file at C:\Windows\System32\wbem\Repository\OBJECTS.DATA, where NAA credentials may persist even after the SCCM client uninstallment.
Attackers can extract the NAA account using the command line
Python sccmhunter.py dpapi -u <username> -p <password> -d <domain> -dc-ip <dc ip> -both

Example of execution of this command in Figures 1 and 2.

Figure 1. Extracting NNA account by WMI via sccmhunter

Figure 2. Extracting NNA account by DPAPI via sccmhunter

Extract NAA via Policy

SCCM policies are sets of rules and configurations applied to managed devices. Clients retrieve these policies by sending an HTTP request with the CCM_POST /ccm_system/request to the Management Point. This request includes XML data that identifies the client and specifies the desired policies. While unapproved devices can't access secret policies, attackers can exploit SCCM by registering a new device. This is done by creating a new machine account. Once the account is registered the the http request was sent http://<MP>/ccm_system_windowsauth/request, the device approved and allowed to access and dump secret policies from the management point. For accessing all the policies sending the http request http://<MP>/ccm_system/request and for specific policy sending the http request http://<MP>/SMS_MP/.sms_pol/{GUID}.
In this case the requested policy will be the policy that stores NNA credentials.

Figure 3 explains the http request to register a new device and get the policy that stores cardinals.

Figure 3. Communication between client to MP to receive policy

SharpSccm tool, for example, avoids creating a machine account by running under the context of SYSTEM or a local administrator. This is due to direct communication with the SCCM management endpoint and obtaining policies that include encrypted secrets.

Two examples of these cases are given in Figures 4 and 6 and network traffic in Figures 5 and 7.

Figure 4. Executing SharpSCCM.exe get secrets, obtaining NAA account without registering a new device via machine account

Figure 5. Wireshark capture: Requesting the list of policies and then the specific policy containing the NAA account

Figure 6. SharpSCCM.exe get secrets -r <MP> -u <computer accounm$> -p <password>, extract NNA account using a register new device via machine account — Figure 6. SharpSCCM.exe get secrets -r -u -p , extract NNA account using a register new device via machine account

Figure 7. Wireshark capture: Registering a new device with a machine account, then requesting the list of policies and the specific policy containing the NAA account

Persistence

Abusing SMS Admins Group

SCCM automatically creates "SMS Admins" local security groups on each SMS Provider in the hierarchy. Due to the group being a key element for SCCM function, its members have administrative access to the SCCM console and the site database. When a user account is added to this database table, SCCM automatically add it to the local SMS Admins group on all SMS Provider machines. What makes this group a prime target for persistence is that its membership is not managed through typical Active Directory group assignments. Instead, it is governed by entries in the

RBAC_Admins table within the SCCM site database.
Attackers can manipulate this mechanism by gaining access to the site database (e.g., via SQL injection or NTLM relay attacks targeting the AdminService API) to add their own accounts to the

RBAC_Admins table, thereby granting persistent administrative control over the entire SCCM hierarchy.

Figures 8 and 9 present user addition to RBAC_Admins table

Figure 8. SQL query add new admin to RBAC_Admins table

Figure 9. SQL query showcases permission addition to the new account in the group

Detection Strategies

Extract NAA via WMI\CIM repository detection

Organizations can monitor unusual file access activity (read and open operations) by unexpected users or processes of the file C:\Windows\System32\wbem\Repository\OBJECTS.DATA that store the NNA credentials. Moreover, it is highly recommended to monitor for WMI queries targeting CCM_NetworkAccessAccount class.

Figures 10 and 11 show examples of a Cortex XDR alert that detects these activities.

Figure 10. “Potential SCCM credential harvesting using WMI detected”,

“Suspicious CIM repository file access” - Cortex XDR Alerts

Figure 11. Example of a SCCM Incident causality view

Extract NAA via Policy detection

To detect suspicious activity, you should monitor the creation of new computer accounts using Windows Security Event ID 4741, "A computer account was created". Pay attention to anomalies, such as an account being created by a user who isn't typically authorized to perform this action.

Investigate abnormal processes authenticating via HTTP requests to http://<MP>/ccm_system_windowsauth/request. Similarly, monitor for unusual processes requesting policies through HTTP GET requests to URLs such as http://<MP>/ccm_system/request or specific policy requests to http://<MP>/SMS_MP/.sms_pol/{GUID}.

This data can be captured by parsing raw network traffic with tools like Cortex XDR. Correlating these network activities with the user context behind the requests is crucial for reducing false positives and distinguishing malicious behavior from benign administrative activity.

Figures 12 and 13 show examples of Cortex XDR alerts that detect these activities.

Figure 12. “Rare machine account creation” - Cortex XDR Alert

Figure 13. “Suspicious Microsoft Configuration Manager device registration and policy request” - Cortex XDR Alert

Abusing SMS Admins Group detection

It is recommended to monitor Event ID 4732 and Event ID 4733 on all SMS Provider machines.

A high-suspicion indicator is when users are added to the SMS Admins group and then removed within a very short period. This 'add-and-remove' pattern is a common defense evasion tactic used by attackers to achieve their objectives while minimizing their footprint and avoiding detection.

Figure 14 shows an example of event 4732 which monitors addition of users to the group SMS_Admins.

Figure 14. Windows Security Event ID 4732 “A member was added to a security-enabled local group”

Figure 15 shows an example of an alert generated by Cortex XDR to find this attack vector.

Figure 15. “User Added to SMS Admins local group” - Cortex XDR Alert

Alert Table

The alerts discussed in this blog are located under the 'Microsoft SCCM Analytics' UI tag on Cortex XDR.

Conclusion

This two-part series covered SCCM's dual nature as critical infrastructure and attack target. Part 1 detailed reconnaissance and enumeration techniques, while Part 2 examined credential theft and persistence methods.

Key takeaways:

- SCCM features that streamline enterprise management, like remote command execution and software distribution, also make it a prime target for abuse during cyber attacks.

- NAA credentials provide valuable lateral movement capabilities

- SMS Admins group manipulation enables persistent administrative access

- Detection requires monitoring WMI, HTTP traffic, file access, and Windows events

Organizations must treat SCCM as a privileged infrastructure component requiring dedicated security monitoring, not just an IT management tool.

Additional Resources

Tools

GitHub - Mayyhem/SharpSCCM: A C# utility for interacting with SCCM

SCCMHunter is a post-ex tool built to streamline identifying, profiling, and attacking SCCM related assets in an Active Directory domain.

GitHub - shelltrail/cmloot

SCCMSecrets.py: exploiting SCCM policies distribution for credentials harvesting, initial access and lateral movement

SCCM Exploitation: Compromising Network Access Accounts | GuidePoint Security

Exploring SCCM by Unobfuscating Network Access Accounts - XPN InfoSec Blog
Site Takeover via SCCM’s AdminService API | by Garrett Foster | Posts By SpecterOps Team Members

Looting Microsoft Configuration Manager | WithSecure™ Labs

SCCM: Enterprise Backbone or Attack Vector? Part 2

Introduction