TL;DR: Misconfiguration Manager is a central knowledge base for all known Microsoft Configuration Manager tradecraft and associated defensive and hardening guidance. We’re also presenting this material at SO-CON 2024 on March 11, 2024. We’ll update this post with a link to the recording when it becomes available.

Suppose you’ve been following offensive security research over the past two years. In that case, we’re hopeful that you’ve stumbled across some of our research targeting Microsoft’s Configuration Manager, formerly known as System Center Configuration Manager or SCCM.

Configuration Manager was first released in 1994. Thirty years later, it’s still going strong and widely deployed in almost every Windows and Active Directory environment we encounter. Like Active Directory, Configuration Manager installations are victims of 30 years of technical debt and compounding misconfigurations.

Configuration Manager has been a known tool for attackers for at least 12 years when Dave Kennedy and Dave DeSimone presented about attacking it at DEF CON 20.

Fast forward a few years, and Matt Nelson released a few blog posts and PowerSCCM with Will Schroeder. There were a few other blog posts during this time, but after early 2016, Configuration Manager research largely fell dormant…

Fast forward again to 2021… Chris Thompson and I were on a red team operation together where we found ourselves with domain admin, but that wasn’t enough for our objective. We had to find a specific user’s workstation, and the typical approaches weren’t an option. Chris had the idea to use the customer’s Configuration Manager server to find where the user’s workstation was via user device affinity. Long story short, Chris ported PowerSCCM to C#, resulting in the creatively named SharpSCCM. Much more research stemmed from this, leading to (at least) eight more blog posts from myself, Chris, and our fellow Specters, Garrett Foster and Diego Lomellini. Additionally, other members of the community have contributed excellent Configuration Manager research and tooling: Evan McBroom, Benjamin Delpy, Christopher Panayi, Phil Keeble, Carsten Sandker, Matt Creel, Adam Chester, Tomas Rzepka, Brandon Colley, and Sanjiv Kawa.

So here we are, ~2 years after we kicked off this SCCM research marathon, and there’s so much to know that it’s easy to feel lost or overwhelmed with so many different blogs, tools, and resources. We’re here to help!

Microsoft Configuration Manager is a software platform first released in 1994, designed for the wide-scale deployment of applications, software updates, operating systems, and compliance settings. It enables the real-time management of servers and workstations.

As with most 30-year-old technologies, Configuration Manager was not designed with modern security considerations. Many of its default configurations enable various components of its attack surface. Couple that with the inherent challenges of Active Directory environments and you have a massive attack surface suffering from a combined 55 years of technical debt.

The responsibility of SCCM typically belongs to desktop or server admins and may be overlooked by information security teams.

We encounter Configuration Manager installations in almost every Active Directory environment. The adoption rate is significant, and with good reason. The utility of the platform speaks for itself. Unfortunately, without deliberate attack path management, the attack surface of Configuration Manager inherently decreases an environment’s security posture.

To emphasize our point, we’d like to share a few stories from our own experiences, of our colleagues, and of the community.

The Most Common Misconfiguration

The most common and arguably the worst misconfiguration we see is overprivileged network access accounts (NAA). Now, Configuration Manager uses many different accounts for many other things. It’s overwhelming to configure, and a novice or unknowing administrator may choose to use the same privileged account for all of the things.

• After gaining access to a standard user’s SharePoint, we found we had read access to Configuration Manager PXE boot media, which was not password protected. We extracted the certificate to request the network access account, which was a local administrator on every Configuration Manager client.
• We (very) commonly find the network access account to be configured as the client push installation account (local admin on all clients), SCCM Administrator, or even domain administrator.
• Russ shared that they dumped the NAA from a client and found not one but two domain admin accounts for two disparate domains. That’s because a common deployment scenario for Configuration Manager is cross-forest management.

A Domain Controller’s Unexpected Journey

A prominent feature of Configuration Manager is its operating system deployment (OSD) feature, which makes use of PXE booting and task sequences.

When a computer PXE boots from Configuration Manager, a task sequence executes to join that computer to the domain. The account that takes this action is called the task sequence domain join account. The credentials for this account are accessible by any PXE client. Now, when an account joins a computer to the domain, it creates a corresponding computer object in Active Directory. That account becomes the owner of the newly-created computer object.

Therefore, if OSD is used to join many computers (workstations or servers) to the domain, the domain join account will have ownership over all of them. If a server is promoted to domain controller, or granted other Tier Zero roles, the domain join account serves as a direct path to those assets.

Domain Controller or SCCM Client?

Configuration Manager sites can be configured to enroll domain controllers as clients. You may be thinking, “that sounds like a bad idea!” and you’d be correct. If a standard site manages Tier Zero assets without itself being treated as Tier Zero, we violate the tiering principle.

Therefore, if we can take over the site (much more of this coming later in this blog!), we can achieve remote code execution via Configuration Manager’s various features: application, script, and package deployment.

Crawling Through the Darkness

This is my favorite Configuration Manager tale. While triaging task sequence logs, we found an interesting script in a readable network location. We downloaded the script, which contained credentials for an MSSQL database. We authenticated to the MSSQL database and discovered a SQL link to another instance. Rinse and repeat two more times. After crawling three SQL links, we landed in the Configuration Manager CAS site database. Then, we cracked the DBA credentials to log into the database directly. We got code execution on the server via xp_cmdshell. Also, we granted ourselves the “Full Administrator” role in the RBAC_Admins table. Finally, we hosted a payload on a network share and used Configuration Manager to execute the payload on a domain controller client.

You’re probably thinking: “OK, Duane. We get it. Configuration Manager is bad. This is overwhelming and scary, and you’ve only shown us the tip of the iceberg.” You’re right in that it is only the tip of the iceberg, but there is hope!

We (Chris Thompson, Garrett Foster, and myself) would like to introduce “Misconfiguration Manager.” Misconfiguration Manager is a central knowledge base for all known Microsoft Configuration Manager tradecraft and associated defensive and hardening guidance. We aim to help demystify SCCM tradecraft and simplify SCCM attack path management for defenders while educating offensive professionals on this nebulous attack surface. Designed to go beyond the static nature of whitepapers, this living repository not only documents SpecterOps’ real-world application of misconfigurations but also encourages ongoing contributions from the community to enhance its relevance and utility.

At SpecterOps, we’ve leveraged many misconfigurations highlighted in this repository in real-world environments, while some represent experimental and exploratory research projects proved out in a lab environment.

We’ve curated this repository to raise awareness of the rapidly evolving SCCM threat landscape, drawing inspiration from the MITRE ATT&CK framework, with a few deviations. We were also strongly influenced by Push Security’s SaaS attack techniques matrix.

Our colleagues, Lee Chagolla-Christensen and Will Schroeder, also provided feedback and guidance on lessons learned from their Certified Pre-Owned research, resulting in strongly influencing the format of this project.

Our approach extends beyond cataloging the tactics of known adversaries to include contributions from the realms of penetration testing, red team operations, and security research. We openly invite and value the submission of both proven and exploratory SCCM-focused attack techniques and defensive strategies.

You’ll find a rendering of the matrix in its current state in the figure below. You may notice some tactics were removed from the table as we felt they were not directly applicable or valuable.

The project currently contains 22 techniques for attacking Configuration Manager or using it for post-exploitation. This is only an early release version, and we have several additional techniques that have not yet been added. There is much more work to do!

• https://misconfigurationmanager.com
• https://github.com/subat0mik/Misconfiguration-Manager

While Misconfiguration Manager contains many attack techniques, this blog is simply not the avenue to introduce all of them. However, we will highlight our taxonomy with a basic description of the various techniques. In addition to the technique IDs listed here, we’ve assigned some techniques with sub-techniques, as slight variations exist that did not warrant their own ID. There is MUCH more detail, resources, examples, citations, and defensive guidance on the repo. Please reference that for more information!

First up are the credential access-related techniques, which we’ve named CRED. The project currently catalogs five CRED techniques:

1. CRED-1 — Retrieve credentials via PXE boot media
2. CRED-2 — Request a policy containing credentials, then deobfuscate
3. CRED-3 — Extract currently deployed credentials stored as DPAPI blobs and decrypt
4. CRED-4 — Extract legacy credentials stored as DPAPI blobs and decrypt
5. CRED-5 — Extract and decrypt the SC_UserAccount table from the site database

Next, we added two techniques for privilege escalation. These can be used for privilege escalation and lateral movement. We named this category “ELEVATE” because “ESCALATE” would be too confusing with the mega-popular ADCS ESC* techniques.

1. ELEVATE-1 — Coerce NTLM authentication over SMB from the site server, then relay SMB on-site systems
2. ELEVATE-2 — Coerce NTLM authentication via automatic client push installation, then relay to other clients or site systems

“EXEC” is the next category. Here, we curate the various methods that Configuration Manager offers to execute code on its clients. We currently have two documented but there are more to be added!

1. EXEC-1 — Deploy an application to a device or collection
2. EXEC-2 — Execute a custom script on a device or collection

Next up, RECON! This category encompasses methods for identifying SCCM systems, as well as using SCCM to perform recon and discovery.

1. RECON-1 — Enumerate LDAP for SCCM-related assets
2. RECON-2 — Enumerate SMB for SCCM-related assets
3. RECON-3 — Enumerate HTTP(S) for SCCM-related assets
4. RECON-4 — Leverage CMPivot to query information from clients
5. RECON-5 — User hunting via SMS Provider

Lastly, we have the TAKEOVER category. TAKEOVER techniques are composed of various steps required to take over an SCCM hierarchy. Complete domain compromise will usually follow shortly after a hierarchy takeover. Note: many of these IDs have sub-techniques.

1. TAKEOVER-1 — Hierarchy takeover via NTLM coercion and relay to MSSQL on remote site database
2. TAKEOVER-2 — Hierarchy takeover via NTLM coercion and relay to SMB on remote site database
3. TAKEOVER-3 — Hierarchy takeover via NTLM coercion and relay to HTTP on ADCS
4. TAKEOVER-4 — Hierarchy takeover via NTLM coercion and relay from CAS to origin primary site server
5. TAKEOVER-5 — Hierarchy takeover via NTLM coercion and relay to AdminService on remote SMS Provider
6. TAKEOVER-6 — Hierarchy takeover via NTLM coercion and relay to SMB on remote SMS Provider
7. TAKEOVER-7 — Hierarchy takeover via NTLM coercion and relay to SMB between primary and passive site servers
8. TAKEOVER-8 — Hierarchy takeover via NTLM coercion and relay HTTP to LDAP on domain controller

Here, we show what this looks like in the repo itself. The repo is organized by category (E.g., TAKEOVER) and then technique ID (E.g., TAKEOVER-1).

Each ID has a description.mdfile containing the article. This file is structured with a high-level description of the technique in plain English, relevant MITRE ATT&CK TTPs, and any requirements necessary to execute this technique.

Then, it includes a summary of the technique at a more in-depth level, followed by the potential impact of the technique. The defensive IDs section cross-references similar articles for defensive guidance for the technique. The sub techniques section references similar variations of the technique, usually varying only by the systems abused but largely the same procedure. The examples section contains step-by-step procedural walkthroughs for how to execute the technique. We’ve tried to include examples from both Windows and Linux workstations where feasible.

The last section is references, where we’ve tried to capture relevant references and give credit where credit’s due. If you feel an article is missing information (let us know!), you can likely find the answer in the references.

Finally, it is not enough to merely show you how to break Configuration Manager without telling you how to fix it! Each offensive ID has defensive IDs meant to prevent the components of the attack techniques discussed.

In the repo readme, you’ll also find a matrix that correlates the various defensive IDs to the offensive IDs, simplifying the search for the “most bang for your buck” remediations.

We introduce three defensive ID categories: PREVENT, DETECT, and CANARY.

PREVENT IDs (mostly) describe configuration changes that directly mitigate or affect an attack technique.

DETECT IDs offer detection guidance and strategies for detecting various attack techniques.

CANARY IDs offer deception-based detection strategies using features that attackers commonly abuse.

Here, we demonstrate a PREVENT article. These articles are shorter and more modular than offensive ones, as each covers a specific configuration.

This project has been a long time coming and a lot of work has gone into it but we have so much more to do. We greatly appreciate your feedback and contributions and sharing this project with your network.

The SCCM attack surface is vast. Consuming, understanding, and actioning all the released research and content is challenging. Through our commitment to transparency, SpecterOps strives to demystify adversary tradecraft so that the community can better protect and defend their environments.

Please reach out to us on X or the #sccm channel BloodHound Slack with any feedback or questions!

This blog post accompanies our presentation at SO-CON 2024 on March 11. We will update the blog to include a link to the recording when it becomes available.

Duane Michael — X, GitHub, @ subat0mik on Slack
Chris Thompson — X, GitHub, @ Mayyhem on Slack
Garrett Foster — X, GitHub, @ Garrett on Slack