SCCM: The tree that always bears bad fruits
Mehdi Elyassa
DEF CON 33 · Day 1 · Main Stage
Overview
Microsoft Configuration Manager — still widely known in the industry as SCCM (System Center Configuration Manager) — is one of the most privileged and most abused systems in enterprise Windows environ

Key moments
- 1:44 So let's start with the SECM internals.
- 7:51 TLS bypass that I showed you earlier.
- 16:13 I disclosed ear earlier this year.
- 22:01 of concept for this uh issue right after this talk.
- 26:14 artifacts behind behind yourself.
- 37:36 me show you how we can extract the credential and decrypt them.
- 40:25 me show you a demo of this back door in action quickly.
SCCM: The Tree That Always Bears Bad Fruits
Speakers: Mehdi Elyassa
Conference: DEF CON 33
YouTube: https://www.youtube.com/watch?v=epyI3b8Vl0M
Overview
Microsoft Configuration Manager — still widely known in the industry as SCCM (System Center Configuration Manager) — is one of the most privileged and most abused systems in enterprise Windows environments. Deployed in organizations of all sizes to manage software deployment, patch distribution, and endpoint configuration, SCCM represents Microsoft's native command-and-control infrastructure for enterprise devices. For attackers operating inside a corporate network, a compromised SCCM instance is a force multiplier of the highest order: it provides code execution on every managed endpoint in the environment.
Mehdi Elyassa, a red teamer at Synacktiv, presents original CVE-level research into SCCM's attack surface alongside a practical toolkit built from real-world red team engagements. The talk covers three interconnected areas: new vulnerabilities in SCCM's web-facing components, post-exploitation techniques extracted from actual engagements, and methods for backdooring an SCCM instance to maintain persistent, covert access even after incident response has cleaned up the initial foothold.
The talk is explicitly positioned for both offensive practitioners — to extend their SCCM attack playbook — and defenders — to understand what detection and hardening measures are relevant against a knowledgeable attacker who targets their configuration management infrastructure.
Background
▶ Watch: So let's start with the SECM internals. (1:44)
SCCM was introduced by Microsoft in the 1990s as SMS (Systems Management Server) and has grown into one of the most complex enterprise management platforms in wide deployment. Its current form, Microsoft Configuration Manager (MCM/MECM), is deeply integrated with Active Directory, Azure AD, and Microsoft Intune. It is deployed in a majority of large enterprise Windows environments.
SCCM's privileged position in the network makes it both a primary red team target and a difficult defensive problem. The platform requires:
- An SCCM site server with SYSTEM-level access to managed clients (to install agents, deploy software, push scripts)
- A SQL Server instance (the Site Database) that stores all device and deployment data
- A hierarchy of distribution points (DPs) and management points (MPs) that serve software packages and relay client communication
- Client agents installed on every managed endpoint
Attackers who compromise the site server or an account with SCCM administrative rights can push arbitrary code to every managed machine in the environment. Prior public research (the MalSCCM and SharpSCCM toolkits, the "Misconfiguration Manager" research from SpecterOps) has documented how misconfiguration-based attacks work. Elyassa's contribution goes further: new CVEs in the web-facing components and persistence techniques that survive normal remediation.
Key Findings
▶ Watch: I disclosed ear earlier this year. (16:13)
New CVEs in SCCM's Web Components
Elyassa identified multiple vulnerabilities in SCCM's web-facing services, which include the Software Center portal, the Administration Service (AdminService) REST API, and the Software Update Point (SUP) web services. The CVEs are not fully disclosed in the public summary but the talk covers the vulnerability classes:
Server-Side Request Forgery (SSRF): An SSRF vulnerability in one of SCCM's web-facing components allowed an attacker with network access to the management point to make the SCCM server issue HTTP requests to arbitrary internal or external targets. In the context of an enterprise network, SSRF in a high-trust, highly-connected system like SCCM is particularly dangerous because the SCCM server typically has unrestricted access to internal resources (file shares, management APIs, the SQL database service).
Authentication Bypass / Privilege Escalation: A vulnerability in the AdminService REST API allowed an attacker with limited SCCM access to escalate to Full Administrator rights within SCCM, bypassing the intended role-based access control. This is particularly impactful in environments where multiple teams have partial SCCM access but should not have Full Administrator rights.
SQL Injection in SCCM internals: Elyassa found SQL injection opportunities in components that process client-supplied data and feed it into queries against the Site Database. While SCCM's SQL backend is not directly accessible from the network, a SQLi from a component that the SCCM service account has access to can be used to read or write database records — including records that control what code gets deployed to which clients.
All CVEs were responsibly disclosed to Microsoft prior to the talk, with patches included in Configuration Manager security updates.
Post-Exploitation Techniques
Elyassa's red team experience forms the backbone of the post-exploitation section. He describes techniques used in real engagements to escalate within SCCM and leverage SCCM access for lateral movement and impact.
Dumping credentials from the Site Database: The SCCM Site Database contains credentials used for network access accounts, distribution point communication, and client push installation. These are stored encrypted, but the decryption keys are accessible from the site server. Elyassa's tool can dump and decrypt these credentials, yielding domain credentials with varying levels of privilege.
Lateral movement via client push: The SCCM client push installation process, by default, runs as a domain account with local administrator rights on target machines. An attacker who controls SCCM can initiate client push to any machine reachable from the site server, achieving code execution on those machines as the push account. In poorly configured environments, the push account is highly privileged (sometimes Domain Admin).
Script execution via SCCM's built-in "Run Scripts" feature: SCCM has a legitimate administrative feature that allows admins to push PowerShell or other scripts to targeted device collections. With Full Administrator access, an attacker can use this feature to execute arbitrary PowerShell on every managed endpoint simultaneously — effectively turning SCCM into a direct C2 channel.
SCCM Backdoor Techniques
The most novel portion of the talk covers methods for backdooring an SCCM instance so that an attacker can maintain persistent access to the SCCM management capability even after the initial compromised account has been remediated.
Creating hidden SCCM admin accounts: SCCM's administrative account store is separate from Active Directory. By adding an SCCM Full Administrator account tied to a low-visibility AD account (e.g., a service account or a computer account), an attacker can maintain SCCM administrative access without it being visible to defenders who audit AD group memberships.
Planting malicious deployment objects: SCCM allows the creation of application deployments, task sequences, and configuration baseline items that execute code. By creating a malicious deployment targeting a broad device collection and setting it to run at a future time or on a trigger, an attacker can establish a persistent code execution mechanism that survives incident response cleanup of the initial foothold account.
Abusing SCCM's package source paths: SCCM distribution points serve software packages from UNC paths. By modifying a package's source path to point to an attacker-controlled share, an attacker can cause SCCM to distribute malicious content to endpoints when the legitimate package is deployed in the future.
Modifying SCCM service settings: Elyassa demonstrates that certain SCCM server configuration settings, accessible via the Site Database or the AdminService API, can be modified to create persistence or to weaken security controls (e.g., disabling script approval requirements for the "Run Scripts" feature).
Technical Deep Dive
▶ Watch: of concept for this uh issue right after this talk. (22:01)
SCCM Architecture Deep Dive
To understand the attack surface, Elyassa provides a detailed walkthrough of SCCM's internal communication model:
- MP (Management Point): The primary communication endpoint for SCCM clients. Clients submit hardware inventory, software inventory, and state messages to the MP via HTTP/HTTPS.
- DP (Distribution Point): Serves software packages to clients. Content integrity is verified via hash values stored in the Site Database.
- Site Server: Hosts the site services, SQL connection, and administrative interfaces. Runs as SYSTEM and typically holds site signing certificates.
- Site Database: SQL Server database that stores all device data, deployment definitions, package metadata, credentials, and administrative configuration.
- AdminService: A REST API (introduced in recent SCCM versions) that exposes management operations. Authenticated by Kerberos/NTLM.
The SSRF vulnerability affected a component that made outbound HTTP requests based on parameters from an incoming request. In the SCCM context, this allowed an attacker with network access to the management point to trigger requests to internal targets, potentially reaching the AdminService or other internal APIs that are not directly network-accessible.
SCCM Client Communication Protocol
SCCM clients communicate with the management point using a proprietary protocol over HTTP or HTTPS. Client messages are signed using a certificate issued by the SCCM site. The management point validates the client's certificate before processing messages. However, in the enrollment flow — where a new client registers with the site — the validation is weaker, and Elyassa identified opportunities for injecting malicious messages that the site processes as if from a legitimate client.
This is relevant to the SQL injection finding: client-side messages that reach the SQL backend without sufficient sanitization can carry injection payloads.
Tool Introduction
Elyassa introduces a new tool (developed based on the techniques in the talk) for SCCM red team operations. The tool provides:
- Automated credential dumping from the Site Database
- SCCM admin account enumeration and creation
- Script execution against device collections
- Persistence deployment via malicious deployment objects
- SCCM backdoor creation and management
The tool is designed to be used in conjunction with existing SCCM attack frameworks (SharpSCCM, MalSCCM) as an extension of their capabilities.
Demo / Proof of Concept
▶ Watch: me show you how we can extract the credential and decrypt them. (37:36)
Elyassa demonstrates the vulnerability chain and post-exploitation toolkit against a lab SCCM environment:
- An SSRF payload sent to the vulnerable SCCM web component, confirming that the site server can be induced to make requests to internal targets
- Exploitation of the AdminService privilege escalation to obtain Full Administrator in SCCM
- Using the Full Administrator access to deploy a script payload to a device collection, executing code on target machines
- Creating a hidden SCCM admin account and a malicious deployment to demonstrate persistence
- Running the credential dump module to extract service account credentials from the Site Database
Defensive Implications
▶ Watch: me show you a demo of this back door in action quickly. (40:25)
Hardening SCCM deployments:
- Apply the Microsoft Configuration Manager security updates that patch the CVEs disclosed in this talk
- Enable HTTPS-only mode for management point and distribution point communication — this does not prevent all attacks but raises the bar for network-based exploitation
- Implement the "Enhanced HTTP" or full PKI certificate mode for client communication
- Enable the script approval requirement for SCCM's "Run Scripts" feature so that all scripts must be explicitly approved by a separate administrator before they can be pushed to clients
- Audit SCCM Full Administrator accounts regularly — compare against expected service accounts and remove any unknown entries
Detection opportunities:
- Monitor SCCM's AdminService API for unusual calls, particularly those creating new admin accounts, modifying deployment objects, or reading credential-related database fields
- Alert on new SCCM application or script deployments targeting broad device collections, particularly those created outside of normal change management windows
- Monitor the SCCM Site Database for unexpected rows in the admin account tables or modification of package source paths
- Look for SCCM client push activity (SMB connections from the site server to unusual target machines) as a sign of SCCM-based lateral movement
Incident response:
- When responding to a SCCM-related compromise, audit all SCCM deployment objects, not just AD accounts — backdoors planted in deployment task sequences or application deployments will survive AD password resets
- Rotate all credentials stored in the Site Database (network access accounts, client push accounts, DP communication accounts)
Key Takeaways
- SCCM/Microsoft Configuration Manager contains web-facing vulnerabilities (SSRF, authentication bypass, SQL injection) that allow attackers to escalate from limited network access to Full Administrator within SCCM, then to code execution on all managed endpoints.
- Post-exploitation of SCCM provides access to stored credentials, lateral movement via client push, and bulk code execution via the "Run Scripts" feature — making it a critical red team objective in enterprise Windows environments.
- SCCM can be backdoored through hidden admin accounts and malicious deployment objects that persist even after initial incident response has removed the attacker's AD foothold.
- Defenders must audit SCCM's internal state (admin accounts, deployment objects, package source paths) as part of incident response, not just Active Directory.
- All CVEs were responsibly disclosed to Microsoft prior to the talk.
About the Speaker
Mehdi Elyassa is a red teamer at Synacktiv, an offensive security company based in Paris, France. He has eight years of IT security experience, beginning as a penetration tester and progressing to full-time red teaming. His primary technical focus areas are web application security and Active Directory, with SCCM/MCM representing a natural convergence of both domains in enterprise environments. He presented this research as the closing talk of Track 4 at DEF CON 33.
Reviews
Dr. Zero (Offensive Security Researcher) — MUST SEE
New CVEs in SCCM's web stack plus novel persistence techniques that survive incident response — this is critical enterprise red team research that every Windows defender needs to internalize immediately.
Heather Calloway (CISO) — MUST SEE
If your organization runs SCCM — and if you're a large enterprise running Windows, you almost certainly do — this talk describes an attacker using your own patch management infrastructure to own every endpoint in your environment and persist through incident response.