Introduction

This article is the first in a multi-part series on SCCM exploitation. Part 1 focuses on the background, architecture, and fundamentals of Microsoft Endpoint Configuration Manager to learn what it is and how it works before attempting to exploit it.

Microsoft Endpoint Configuration Manager - previously known as System Center Configuration Manager - is an important backbone of many large Windows enterprise environments, responsible for orchestrating software delivery, OS deployments, configuration baselines and patch management for endpoints across the enterprise saving IT administrators time and a headache.

MECM integrates deeply into Active Directory for service location, authentication and discovery. Configuration data for systems and roles are published directly into the Active Directory schema so clients can locate the assigned management point (MP) while Kerberos or NTLM handles the authentication between those clients, MPs and distribution points (DPs).

Architecture and Components

At the core of the architecture is the primary site database which is a Microsoft SQL Server instance storing all the configuration and operational data for the MECM environment including hardware and software inventories for managed devices, installed applications, deployment histories, site configurations, boundary definitions and stored credentials for automated tasks. Every single action within MECM is recorded or referenced from this database.

Another important aspect of MECM that sits between the database and administrative tools is the SMS Provider role which acts as the interface between the configuration manager console and the SQL database. When an IT admin uses the console for configuring a deployment, the SMS provider translates the actions into SQL operations that modify the database. It also retrieves data from the database for displaying it back in the console. While the SMS provider can run on the primary site server itself, it is often recommended to run it on a secondary, separate system if possible for both performance and security benefits.

Next, the Primary Site Server. This is the orchestration engine, hosting all the core site roles, including SMS Provider and is responsible for processing data retrieved from the database into policies that can be actioned upon for the endpoint clients. It decides what devices should receive the policy being pushed, manages the content distribution and scheduling and the replication of the data to other site systems if configured to.

In large or geographically distributed enterprises, it's typical you may see Secondary Site Servers to improve efficiency. These servers are essentially intermediaries sitting between the primary site and the clients in a specific region or separate network segments. Secondary servers maintain a local version of the database by replicating the primary database for independence - i.e. if the primary site is slow or down for maintenance, it can still operate. It can also store client inventory data, content metadata and policy information locally, synchronising any changes with the primary regularly (similiar to DCSync, but for MECM).

The policies and content need to be able to reach the clients/endpoints, but how? There are two main roles - Management Points (MPs) and Distribution Points (DPs). An MP is a client's primary communication interface - clients will connect to their own assigned MP for policy update requests, sending inventory data reports and status messages. These policies are sent in XML format over HTTP or HTTPS and contain a set of instructions for software installs, configurations, compliance checks or scheduled task executions.

DPs are responsible for actually serving the deployment content - think software packages, OS images, updates and scripts. When a policy from the MP tells a client it needs specific content, the client downloads it directly from a DP using SMB or HTTP(S). Multiple DPs are typically deployed for efficiency and bandwidth reasons, allowing clients to connect to the closest one.

How do the clients map to specific MPs and DPs? This is defined by what are called boundary groups. A boundary group specifies which clients can use which site systems based on subnets, AD sites or other identifiers the IT admins want to use. A key fact to think about is that boundary groups can not only control which site systems a client uses, but also define fallback relationships; for example, it can allow a client to retrieve content from another DP if its assigned one is unavailable.

The final component are the clients themselves - the endpoints, devices, users, whatever you want to call them. Each client runs the Configuration Manager client agent (ccmexec.exe) which executes the policies it receives. The agent periodically checks in with its MP, downloads the content from the DP and runs what it needs to (installs, config changes, etc..). For management purposes, it also performs inventory scans and sends reports back to the MP.

For summary, the whole workflow is a continuous cycle; the database stores the configuration and state of the enterprise environment, the SMS provider and site server generate policies and instructions, MPs distribute those policies, DPs serve the content, and clients execute the actions and then feed updates about themselves back into the system.

MECM Client Installation Methods

As stated above, the Configuration Manager client agent must be installed on the endpoint. There are a variety of ways to do this including:

- Client push
- Software update-based
- Group Policy
- Manual
- Logon scripts
- Package and programs

Client push is the default method and the most common. The site server initiates the install remotely over SMB/WMI to systems, copying the setup files and executing the installers with administrative rights. It's important to note that these use dedicated client push accounts which are service accounts, typically with local admin rights on the devices where SCCM clients are deployed.

For a standard enterprise, endpoints will likely be grouped logically depending on an attribute like geographical location, department or specific permissions and each group would have a single client push account.

Now, when a client push deployment gets triggered, MECM tries to install an agent on each device by trying the configured push accounts. If authentication with one account fails, it moves on to the next account in the list sequentially, continuing through each account until one works (hopefully!).

Software update-based uses WSUS (Windows Server Update Services) to push the client agent as an update package to systems.

Group Policy assigns the client MSI via an AD group policy from a network share or some form of media.

Manual involves running the client installer locally, typically from a network share or via media.

Logon script runs the installer as part of the user or computer logon scripts, typically from a shared location.

Finally, Package and program uses MECM's package delivery mechanism to push the client agent to endpoints that are already running MECM or another management framework.

Deployment Types

MECM can deliver content and the various changes to clients through four main methods:

1. Applications
2. Packages and programs
3. Task sequences
4. Software updates

Applications are the modern method and suport multiple install methods in a single application. They include detection logic to verify installs and have the option to target specific OS versions, architectures or configurations.

Packages and programs are an old, legacy method that consist of content (package) and a command to execute (program). Deployments using this way have no detection logic, meaning the program is ran every time it is triggered.

Task sequences are ordered workflows that chain multiple actions together like OS deployments. They can do more complex administrative tasks like disk partitioning, applying images, installing various drivers, running administrative scripts or deploying apps in a specific sequence.

Software updates are integrated with WSUS and deliver Microsoft and approved third-party updates to the endpoints. Clients can scan against the catalog of updates, report compliance problems and if appropriate, download any required patches from DPs.

Regardless of deployment, they all follow the same workflow: the site server generates a policy, the management point delivers it to the client, the distribution point serves the content, and the client executes the instructions before reporting back.

References

1. Microsoft Learn – Introduction to Configuration Manager:
Introduction to Configuration Manager

2. Microsoft Learn – Configuration Manager Architecture:
Configuration Manager Architecture

3. Microsoft Learn – Deploy the client to Windows computers:
Deploying SCCM Client

4. Microsoft Learn – Client push installation:
Client Push Installation

5. The Hacker Recipes – SCCM/MECM Overview:
SCCM/MECM Overview

6. System Security Blog – Active Directory Spotlight: Attacking the Microsoft Configuration Manager:
Attacking the MECM