SCCM Shenanigans 101

Background information 

SCCM is a management tool that helps IT organisations centrally manage and maintain a large fleet of systems. Practically this can be used to:

• Deploy the operating system on devices (imaging);
• Deploy software to devices or allow users to install software themselves (Software Center);
• Deploy patches to systems in order to keep them up to date;
• Remote control and troubleshooting allowing administrators to execute commands on devices.

The SCCM installation can consist of a large number of servers and services but in this blogpost, we will only be talking about the following key components:

• Site Server: The central component of SCCM, hosting key site system roles for management and communication;
• Management Point (MP): Provides policy and content location information to clients and receives data such as inventory and status reports from clients;
• Distribution Point (DP): Helps reduce the load on the primary site server by offloading content distribution;
• Site Database: A SQL Server database that stores all the configuration, operational, and inventory data.

In order to achieve the tasks mentioned above, every machine in the domain is regularly connecting to SCCM servers to verify if tasks must be performed onto the system. If an attacker manages to compromise the SCCM deployment, they could use it to remotely execute commands and take control over the enrolled machines.

The rest of the blog will go into the details of the misconfigurations in commonly used SCCM configurations as seen at numerous clients. 

Minimum recommended actions

If you do not want to read the full explanation as to why you should harden your SCCM components, we recommend that you at least perform the following:

• Lower the ms-DS-MachineAccountQuota from the default 10 to 0 to prevent against unprivileged users adding computers to the domain and having an easy way to gain access to computer accounts that can aide in further attacks;
• Enable SMB signing on all the SCCM components (and ideally on all other systems) in order to prevent against relay attacks;
• Enforce encryption and enable Extended Protection on the SCCM Site Database;
• Limit the permissions granted to Client Push, Task Sequence, and NAA accounts. Additionally, make sure these passwords aren’t reused anywhere;
• Do not manage Tier 0 assets through SCCM (e.g. Domain Controller, or critical infrastructure/business components ...).
   

Compromising the provisioning of machines 

Description
One of the main features that organisations use SCCM for is to aid the provisioning process, this is done to save both time and ensure the homogeneity of the systems they set up. The Network Access Account (NAA) allows a non-domain-joined computer to retrieve software from the SCCM distribution point.

Network Access Account (NAA)

NAA are usually granted elevated permissions despite Microsoft’s recommendations (documentation):

“Client computers use the network access account when they can't use their local computer account to access content on distribution points. It mostly applies to workgroup clients and computers from untrusted domains. This account is also used during OS deployment, when the computer that's installing the OS doesn't yet have a computer account on the domain.” 

For context, Microsoft recently added a note stating that this account should never be used as the security context to run programs, install software update, or run task sequences but most organisations don’t follow these recommendations. We have noticed at numerous clients that these accounts have elevated permissions ranging from local administrator permissions on all workstations to domain, and enterprise administrator.

This note was added because there are multiple ways for attackers to obtain this password. Both active methods where an attacker adds a new computer to the SCCM deployment or re-adds an existing computer by relaying it to the MP. And passive ways where an attacker with elevated permissions on the workstation retrieves the encryption key (Microsoft Data Protection API) and decrypts these credentials offline.

Am I vulnerable?

In order to view the NAA account, open the SCCM console (Configuration Manager) and go to Administration > Site Configuration > Sites. Select your site, then click Configure Site Components > Software Distribution. Under the Network Access Account tab, check which account is listed. Validate the permissions granted to this user by checking both their domain groups (Active Directory Users and Computers) and their effective access (this can be achieved using tools like BloodHound or manually).

Recommendation

We recommend that you do not use NAA credentials for this initial authentication to prevent these credentials from being stored on the computers. Instead, Microsoft recommends using Enhanced HTTP to query SCCM resources because it does not store the credentials on the system and eliminates the need for NAA completely. More information can be found on https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/enhanced-http.

Once you have migrated to Enhanced HTTP, we recommend disabling or removing the NAA users from Active Directory because even after the migration these credentials are still available on the workstation.

If it is not possible to migrate away from NAA credentials, we recommend that you strictly limit the rights of these users and monitor what actions are done with these users. Furthermore, we also recommend that you all SCCM-related service accounts a unique password not reused anywhere in the organisation.
 

Tasty TaskSequences

In SCCM, a Task Sequence Variable is a parameter used to control the behaviour of a task sequence during an OS deployment or software installation process. These variables store and pass data between different steps in the sequence, enabling dynamic configurations based on system conditions or deployment requirements. These variables can also be used to pass on credentials to these sequences. During our testing, we noticed that a lot of organisations are using highly privileged accounts in these Task Sequences, not knowing that attackers may retrieve these sequences and decrypt these credentials.

Am I vulnerable?

In the SCCM console go to Software Library > Operating Systems > Task Sequences. Click on edit on the Task Sequence, for every step check that the "Run this step as the following account" is empty. Otherwise validate the permissions assigned to this account.

Recommendation

Similar to the NAA credentials, we recommend following the principle of least privilege when granting permissions to the task sequence accounts. One of the misconfigurations we often see is Domain joining computers with an account with local administrator permissions using a Task Sequence. This should not be done using elevated permissions. Instead, a normal domain join account should be used and configured as follows:

• A normal Domain User that is only used for domain joining
• Configure a strong randomly generated password
• Grant the domain join user the permissions on the OU:
  
  
  • Open “Active Directory Users and Computers”
  • Go to the OU that you want the user to be able to add computers to (recommended) or select the domain
  • Right click on the OU or domain and select Delegate Controlo Select the Domain Join user in the search window
  • In the “Delegate the following common tasks” select “Join a computer to the domain”
  • Select finish

The password for this account should never be reused and should be periodically updated (e.g. rotate it once per year). Unexpected actions for the TaskSequence user should also be rather easy to spot as it should only perform a very limited set of well-defined actions such as domain joining the workstation. 
 

Reliable relay

Description
Attackers have been using relay attacks for years and one of their favourite ones is probably SMB relays, both because tools to perform these relays have improved and because the default behaviour for older Windows clients is still to connect to unsigned SMB servers. Microsoft is however looking into changing this default behaviour in the future.

When it comes to SCCM, there are 2 types of relays:

• SMB to SMB: Site Server to Site Server relay
• SMB to MSSQL: Site Server to Site Database

SMB to SMB

We noticed that a lot of organisations aren’t enabling SMB signing on the Site Servers. The problem is that these Site Servers have local administrator permissions on each other. Practically this means that an attacker that manages to trigger an SMB connection from one of these servers can relay it to one of the other Site Servers in order to obtain local administrator permissions. These permissions could then be used to take control over the rest of the SCCM infrastructure (e.g. login to the Site Database and add a new SCCM administrator ). There are many ways to trigger SMB connections from the machine accounts to be used for relay purposes, including one discovered by one of our Deloitte colleagues in France.

Am I vulnerable?

To know whether you are vulnerable you should log into all the Site Servers in the SCCM deployment and executing the following PowerShell query:

Get-SmbServerConfiguration | FL RequireSecuritySignature

If this returns False for any of the Site Servers, then you are affected by this misconfiguration and should consider applying the fixes discussed in the “Recommendation” step.

Recommendation

We recommend enabling SMB signing everywhere but especially on these
critical network assets as this could be abused by an attacker to obtain
elevated permissions in the domain. SMB Signing can be enabled by using the
following guide: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-server-message-block-signing.

SMB to MSSQL

The second relay we encountered is the relay from the Site Server (SMB) to the Site Database (Microsoft SQL) as described by Chris Thompson. The machine account for the Site Servers is used to authenticate to the database. By default, the Microsoft SQL (MSSQL) servers are not protected against relay attacks and the Site Servers connect to unsigned SMB servers. This allows an attacker to trigger a machine connection from the Site Server and send the authentication over to the MSSQL database gaining administrative access. This could then again be used to login to the Site Database and add a new SCCM administrator.

Am I vulnerable?

Unfortunately, the default configuration is vulnerable except for the case where the SCCM deployment only has 1 Site Server which also hosts the Site Database. In order to validate whether your SQL server is protected against relay attacks open the SQL Server configuration Manager and then select “SQL Server Network Configuration → Protocols for MSSQLSERVER”. Open the properties menu on the “Protocols for MSSQLSERVER” and go to advanced. If extended protection is not enabled, then you are vulnerable.

Recommendation 

There are 3 ways of preventing this, the first is enabling extended protection and enforcing encryption on the MSSQL server. This is however hard to configure so should this not be possible we recommend limiting the access to the database to only the Site Server on the network level by performing strong network filtering and not allowing anyone else to connect. Lastly, should that also not be possible we recommend not allowing the Site Servers to connect to unsigned SMB servers by applying a GPO that sets “Microsoft network client: Digitally sign communications (always)“ under “Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options” to enabled.

Detections

Most of these attacks will of course leave indicators that could be detected, and which could (and should) be monitored for. In this section we will go over each of the observations and indicate what could be used to detect these attacks in the wild.
 

Network Access Account (NAA)

There are multiple ways for an attacker to obtain these credentials, so pay attention for suspicious WMI queries. Specifically look for queries targeting the CCM_NetworkAccessAccount class in the root\ccm\policy\Machine\ActualConfig namespace as multiple tools to automate these attacks will perform queries to retrieve the encrypted NAA credentials from here. 

As there are multiple ways to retrieve these encrypted credentials (including some passive ways) you could also try to monitor for DPAPI calls where someone tries to decrypt these blobs. 

Finally, the NAA account should only be used to connect to the Distribution Point. Any other actions performed using this account should be investigated and followed-up upon.

Tasty TaskSequences

Again, there are multiple ways to obtain the credentials store in these Task Sequences but the action this account makes should be well defined in the Task Sequences.

Additionally, one of the easiest ways to retrieve these task sequences is by relaying an existing computer account to the Management Point. A lot of attackers use the same tool (ntlmrelayx.py), luckily there is already a lot of research about detecting the Impacket tool suite.

Reliable Relay - SMB to SMB and SMB to MSSQL

The theory of detecting relay attacks is very simple, it is simply looking for an authentication using the machine account from an IP address not assigned to this machine. In practice this is however not as easy.

This can be achieved by looking at Windows Event ID 4624: An account was successfully logged on. Here it is then possible to compare the “Account Name” (the system authentication) with the “Source_Host” field and comparing the values therein. 

Alternatively, it is also possible to validate that the “Source Network Address” field contains the IP of SCCM Site Server for whom the authentication is being performed.

More information can be found on https://github.com/subat0mik/Misconfiguration-Manager/blob/main/defense-techniques/DETECT/DETECT-1/detect-1_description.md.
 

Generic Detections

The SCCM groups are high value groups in the organisation and can be used to take control over a large number of computer accounts in the organisation. Even if not a single tier 0 asset is managed, they quite often provide an indirect path to these accounts.

So, we recommend monitoring for group changes related to both the Active Directory groups used to grant access to the SCCM infrastructure as well as group changes on the Site Database.