Introduction

In the first two parts, we explored how SCCM is built, how it handles collections, task sequences, client push, PXE boot and the variety of accounts and policies that make it function in an enterprise environment.

Now comes the fun part: reconnaissance.

The goal is simple: identify if SCCM is present, work out which servers hold which roles, and begin mapping the attack surface. Recon can start from two positions: unauthenticated or authenticated. SCCM has to advertise itself on the network and expose services to function, which gives us opportunities to pick up on it without credentials. But once you have even a single domain account, the picture changes drastically and you can start harvesting real detail.

Unauthenticated Reconnaissance

On a pentest, the first inkling that there may be a SCCM/MECM environment running would be from Nmap scans.

Running a version scan (-sV) against suspected SCCM infrastructure can reveal various things: IIS running on odd ports, SQL services open, and occasionally custom RPC interfaces. Some of the more interesting ports to look out and scan for include 80, 443, 445, 1433, 10123, and 8530–8531 which can return some information about the SCCM infrastructure.

1nmap -p 80,443,445,1433,10123,8530,8531 -sV 192.168.32.11-12

Nmap TCP scan results

Each of these ports corresponds to a role: IIS on 80/443 underpins Management and Distribution Points, 445 may expose SMB shares such as SMSPKG$ if ACLs and shares are misconfigured, 1433 links to the SQL site database, 10123 is tied to the remote control service, and 8530/8531 typically point to WSUS when integrated as a Software Update Point.

You also want to sweep the UDP side because PXE and DHCP live there. A quick targeted scan is enough to tell you which PXE model you’re dealing with:

1nmap -sU -p 67,68,69,4011,547 192.168.32.11

Nmap UDP scan results

If 4011/udp is responsive, you’re almost certainly looking at legacy WDS/ProxyDHCP. If 4011 is closed but PXE still works in the environment, that usually indicates the modern PXE Responder (no WDS). Port 69/udp is TFTP; seeing it open on a DP lines up with WDS-based PXE where the NBP (wdsnbp.com,wdsmgfw.efi) is pulled via TFTP. In PXE Responder setups you may not see 69/udp at all even though OSD works, because the responder pushes boot details via DHCP vendor extensions and the client transitions quickly to HTTP(S) for policy/content.

67/udp and 68/udp are the DHCP server/client ports. Don’t be surprised if Nmap reports them as open|filtered; DHCP is broadcast-oriented and many servers ignore unicast probes. Their ambiguous state doesn’t mean DHCP isn’t there - it just means your unicast scan isn’t a perfect oracle. 547/udp is DHCPv6; useful to note if the environment runs v6, but not SCCM-specific.

For a definitive read on PXE behavior, pair the scan with a live PXE attempt and watch the wire if possible during your test. A WDS environment will answer on 4011/udp with ProxyDHCP and hand out a Bootfile Name, while PXE Responder mode will skip 4011 and tuck the bootfile into PXE vendor-specific options in the normal DHCP exchange - covered in part 2.

NetExec

With SMB exposed on 445, the natural step is to throw a quick NetExec scan at it. Even without valid credentials, sometimes the NetBIOS name and domain information can give hints about the system's purpose.

1nxc smb 192.168.32.10-13

NetExec SMB scan results

In my lab this revealed four systems:

- MECM – the site server itself
- DC – domain controller for sccm.lab
- CLIENT – a domain-joined workstation
- MSSQL – separate SQL server hosting the site database

With the hostnames, it reveals that SCCM is likely in use and that the MECM machine is the site server but also that the site database is not co-hosted, but on a separate MSSQL machine. As a side note, the /etc/hosts file can be generated by NetExec to make it easy to add these entries:

1nxc smb 192.168.32.10-13 --generate-hosts-file /tmp/hostfile

Hosts file

Beyond hostnames and domains, NetExec also reports details like SMB signing (useful for attacks later on).

If the system is hardened you'll get "access denied"; in misconfigured setups you may be able to enumerate SCCM’s content shares like SMSPKGC$ or SCCMContentLib anonymously. That’s rare - most modern deployments SHOULD block null sessions — but it’s worth testing.

1nxc smb 192.168.32.10-13 -u '' -p '' --shares

NetExec anonymous share access

OpenSSL

A quick trick is to grab SSL certificates from the IIS endpoints that SCCM exposes. Certificates can often leak clues about the internal setup. Running the following command against port 10123 (the SCCM remote control service) returns the certificate details:

1openssl s_client -connect 192.168.32.11:10123 -showcerts

OpenSSL certificate

The output here is especially telling:

1Certificate chain
2 0 s:CN = MECM, CN = SMS
3   i:CN = MECM, CN = SMS

The certificate subject lists both the machine name (MECM) and SMS. The SMS string is a giveaway as it refers to Systems Management Server - the old name for SCCM. Even in current versions, you’ll still see “SMS” scattered in around.

The certificate also isn’t issued by an internal PKI or external CA but is generated by SCCM itself in this case which matches Microsoft’s defaults for internal site roles. Seeing self-signed, long-lived certs (10-year validity is common) is consistent with a vanilla SCCM deployment, which can provide a hint about the potential security awareness of the organization (i.e. a preference to run default settings across the environment).

RPC Enumeration

The site server and distribution points expose a number of RPC interfaces that can be queried remotely without authentication. Using rpcdump.py, you can enumerate registered RPC interfaces and their associated protocols:

1rpcdump.py 192.168.32.11 | grep Protocol | grep -v 'N/A'

Rpcdump.py output

This lists every RPC protocol UUID the host advertises. Many are the usual suspects you’ll see on any Windows server but the key one for SCCM reconnaissance is Protocol: [MS-WDSC]: Windows Deployment Services Control Protocol.

It shows that Windows Deployment Services (WDS) is running on this host. Since earlier Nmap scans showed UDP/4011 in play, it tells us that SCCM is using WDS as its PXE provider in legacy mode.

cURL Requests

Another low-effort step is to probe the IIS virtual directories that SCCM publishes on it's Management and Distribution Points. These endpoints are how clients fetch policies and content and while most require authentication, their presence alone is often enough to confirm the role a server is playing.

In older SCCM builds, Distribution Points exposed directories like SMS_DP_SMSPKG$ and SMS_DP_SMSSIG$. These were directly backed by file system folders such as C:\SMS_DP_SMSPKG\ and could sometimes be browsed unauthenticated if IIS was misconfigured, meaning an attacker could walk through package content directly over HTTP.

In modern MECM environments, Microsoft shifted to the Content Library model (C:\SCCMContentLib\). The old DP virtual directories typically return 404, so they’re no longer reliable for recon. Instead, Distribution Points are best fingerprinted by checking for SMB shares such as SMSPKG$ and SMSSIG$ or by watching client traffic to the DP with Wireshark/tcpdump if you are on the same network.

Since these endpoints are IIS virtual directories, we can probe them directly with curl the same way a client would, and use the HTTP status codes to tell us what role the server is playing.

For example, one of the most common MP endpoints is /ccm_system/request. You won’t get policy data back without creds, but an unauthenticated request usually returns 403 Forbidden, which still proves that the MP channel is alive and IIS is routing the traffic correctly:

1curl http://192.168.32.11/ccm_system/request

CCM System request - 403 forbidden

More interesting are the site discovery endpoints. These are designed to be hit by clients before they are even domain-joined, so they respond unauthenticated by design:

1curl -s http://192.168.32.11/SMS_MP/.sms_aut?mplist | xq
2curl -s http://192.168.32.11/SMS_MP/.sms_aut?mpcert | xq

MPList output

MPCert output

The mplist endpoint responds with XML that provides some information about the SCCM configuration including the Management Point’s logical name, its FQDN, the build version, and whether it’s operating over HTTP or HTTPS. The mpcert endpoint returns the Management Point’s certificate as a hex-encoded DER blob. It can be decoded with PowerShell:

1$xml = Invoke-WebRequest http://192.168.32.11/SMS_MP/.sms_aut?mpcert
2$hex = ([regex]'<Certificate>([0-9A-F]+)</Certificate>').Match($xml.Content).Groups[1].Value
3[IO.File]::WriteAllText('mpcert.hex',$hex)
4certutil -decodehex mpcert.hex mpcert.cer
5certutil -dump mpcert.cer

Decoded, you’ll see certificate fields like the subject CN, issuer CN, validity period, and public key size. In this environment, it showed:

1Subject: CN=SMS, CN=MECM
2Issuer: CN=SMS, CN=MECM
3NotBefore: 13/08/2025
4NotAfter : 09/02/2026
5Public Key: RSA 2048 bits

Certificate decoded by powershell

In lab or hardened environments this can seem useless, but in real-world setups these certs often embed site codes, internal FQDNs, or naming schemes that help attackers map the SCCM attack surface:

- Where the Management Point is (hostname/FQDN)
- What version it’s running
- How it identifies itself cryptographically

The table below is a quick reference for probing SCCM endpoints with curl. Each path corresponds to the same URLs that ConfigMgr clients use when bootstrapping or requesting policy. From an unauthenticated perspective, the status codes and responses are often enough to fingerprint SCCM, confirm whether a host is a Management Point or Distribution Point, and in some cases leak XML or certificates.

IIS Manager View

For me, it's important to understand where all of these endpoints come from. All of these curlable endpoints exist because when you install SCCM roles, setup extends IIS with virtual directories and handler mappings. That’s what makes requests like /SMS_MP/.sms_aut?mplist work, even if there’s no .sms_aut file anywhere on the filesystem.

If you open IIS Manager on a site server and expand the Default Web Site, you’ll see SCCM-specific applications like SMS_MP, ccm_system, and SMS_DP_SMSPKG$. These are created automatically when you add roles like the Management Point or Distribution Point.

IIS Manager - Site Folders

Clicking into the SMS_MP application shows that it maps into the ConfigMgr binaries under C:\Program Files\SMS_CCM\SMS_MP. This is where the Management Point DLLs live, and why IIS can dynamically respond to requests like .sms_aut.

IIS Manager - Physical path

If you dig into Handler Mappings on the SMS_MP application, you’ll find entries for .sms_aut and .sms_pol. These don’t map to static files but IIS routes them through the IsapiModule, which loads mp.dll and generates responses on the fly.

IIS Manager - Handler mappings

This explains why curl probes work:

- /SMS_MP/.sms_aut?mplist: routed to mp.dll, generates an XML with MP details.
- /SMS_MP/.sms_aut?mpcert: same handler, returns the MP’s self-signed certificate.
- /SMS_MP/.sms_pol: same DLL, but challenges with 401 before serving client policy.

On the Distribution Point side, the SMS_DP_SMSPKG$ virtual directory historically pointed to C:\SMS_DP_SMSPKG\. In modern MECM builds, it instead maps into the Content Library (C:\SCCMContentLib). That’s why in Current Branch environments, curl against /SMS_DP_SMSPKG$ usually just gives you a 404.

IIS Manager - DP directory

From a recon standpoint, this makes the whole picture clearer. You’re calling into IIS virtual directories that SCCM configures by design, and the ISAPI handlers translate your request into SCCM-specific responses.

Windows-Specific Checks

From a Windows host on the same network, there are a couple of built-in utilities that can give away SCCM infrastructure. One of the simplest is nbtstat, which queries the NetBIOS name table of a remote machine. Pointing it at a suspected SCCM server can reveal the hostname, domain and potentially SCCM-specific service identifiers.

1nbtstat -A 192.168.32.11

Nbtstat command output

In the output you’ll typically see:

- The hostname of the server (e.g. MECM).
- The Active Directory domain it belongs to (e.g. SCCMLAB).
- A <20> entry, showing that SMB file sharing is enabled (important for Distribution Points).
- Most importantly, an entry like MP_P01 <1A>.

The <1A> suffix is key. In NetBIOS, each two-digit hex value is a “service code” that represents a registered service. <00> usually marks a workstation name, <20> marks the file server service, <03> is the old messenger service and <1A> is normally reserved for Remote Administration. SCCM hijacks it for something very specific: when a Management Point is installed, it registers itself in NetBIOS as MP_ with a <1A> suffix.

NSLookup

SCCM also publishes service location (SRV) records into Active Directory–integrated DNS. These let clients discover their Management Points and, in some cases, site servers. The records live under _mssms_mp_ and _mssms_site_ with the three-character site code embedded in the name.

From a Windows machine that can resolve the domain’s DNS, you can query them directly:

1nslookup -type=SRV _mssms_mp_p01._tcp.sccm.lab
2nslookup -type=SRV _mssms_site_p01._tcp.sccm.lab

NSLookup command output

The MP query usually resolves and returns the FQDN of the Management Point. The site record may or may not exist depending on the environment. In my lab, only the MP record was published as can be seen from the DNS records on the DC:

DNS manager records

Without the site code, you won’t get a result unless you guess or brute force common ones like PRI, P01, P02, CAS, DEV, HQ. Remember that site codes can not be longer than three characters.

Authenticated Reconnaissance

Before diving into the tools, it’s worth pointing out that a lot of useful techniques are already documented in the Misconfiguration Manager repo which is a great catalogue of SCCM techniques from recon to priv esc. I highly recommend giving it a read.

ADSISearcher

From a foothold on a domain workstation you can ask AD and the local SCCM provider exactly where the client thinks the site lives. The ADSI lookup below shows the SCPs ConfigMgr publishes and the binding information clients consume:

1([ADSISearcher]("objectClass=mSSMSManagementPoint")).FindAll() | % { $_.Properties }

ADSISearcher command

What that returns are the raw SCP objects: the cn for the SCP itself, the serviceBindingInformation lines which contain the Management Point logical names and sometimes the HTTP paths the clients will call, and the DN under System Management which tells you where SCCM published that entry in AD.

From the same host you can query the local SCCM client provider via WMI to get the runtime, agent-centric view. These two equivalent commands will give you the SMS authority record the client has:

1Get-WmiObject -Namespace 'root\ccm' -Query 'SELECT * FROM SMS_Authority' | Format-List *
2Get-CimInstance -Namespace 'root\ccm' -Query 'SELECT * FROM SMS_Authority' | Format-List *

Get-WmiObject command output

The CurrentManagementPoint entry tells you the MP host the agent is configured to use, the authority Name is the local site identifier, and other properties (policy target endpoints, capability blobs or certificate hints) give you clues about whether the MP is speaking HTTPS, whether tokenised DP delivery is in play, and which log lines to parse next.

Pyldapsearch

From a domain account you can ask AD two useful things with pyldapsearch: where the Management Points are published, and which computer objects have “sccm” in their name or DNS hostname. Both questions are simple LDAP filters and return potentially useful output.

To show the Management Point SCP entries (ask AD for the mSSMSManagementPoint objects and pull back the MP hostname and the site code):

1pyldapsearch sccm.lab/carol:"SCCMftw" "(objectclass=mssmsmanagementpoint)" -attributes dnshostname,msSMSSiteCode

In the lab this returned:

1dNSHostName: MECM.sccm.lab
2msSMSSiteCode: P01

Pyldapsearch management point search

If you want to hunt hosts that include “sccm” in either their cn or their DNS name (so you catch servers and machines responsible for various roles), use a filter that checks both attributes:

1pyldapsearch sccm.lab/carol:"SCCMftw" "(&(objectClass=computer)(|(cn=*sccm*)(dNSHostName=*sccm*)))" -attributes dNSHostName

Pyldapsearch sccm name search

The example run in the screenshots returned four rows:

1dNSHostName: CLIENT.sccm.lab
2dNSHostName: MSSQL.sccm.lab
3dNSHostName: MECM.sccm.lab
4dNSHostName: DC.sccm.lab

Ldeep

ldeep is an LDAP crawler that pulls ConfigMgr-related attributes out of Active Directory. Point it at a domain controller with a user account and it will return the SCCM schema objects and service connection points that ConfigMgr writes into AD, the three-letter site codes, and the computer objects that are advertising MP/DP roles.

Running it in sccm mode wraps several LDAP queries together and prints out the servers it identifies.

1ldeep ldap -u carol -p SCCMftw -d sccm.lab -s ldap://192.168.32.10 sccm

Ldeep sccm mode

The output shows MECM.sccm.lab listed as the primary site, confirms that it is acting as the Management Point, sets the site code as P01, and flags the MECM computer object as a potential Distribution Point.

If you want to see the underlying entries that this summary is built from, you can fall back to a direct LDAP search, using a filter like (objectclass=mssmsmanagementpoint), targeting the service connection point objects that SCCM publishes whenever a Management Point role is installed.

1ldeep ldap -u carol -p SCCMftw -d sccm.lab -s ldap://192.168.32.10 search "(objectclass=mssmsmanagementpoint)" dnshostname,msSMSSiteCode

Ldeep custom search command

The DN reveals the MP object under the System Management container, the dnshostname attribute confirms the FQDN of the host, and the msSMSSiteCode field ties it to site P01.

SharpSCCM

SharpSCCM talks straight to the ConfigMgr WMI providers on the host and returns the live, runtime picture the client and site server use. Because it reads root\ccm and / root\SMS namespaces it gives you authoritative site properties, package IDs, site system roles and the exact WMI classes that map to packages, DPs and collections.

1.\SharpSCCM.exe local site-info

SharpSCCM site info enumeration

That call reads the local SMS authority and prints the site identity the agent uses. If you need to run a direct WQL query, SharpSCCM will execute it against the provider such as: .\SharpSCCM.exe local query "SELECT CurrentManagementPoint FROM SMS_Authority"

The triage command is the most immediately useful output you can get from a low-privileged context:

1.\SharpSCCM.exe local triage

The triage option attempts to read the local cache and then scans SCCM logs for UNC paths and URLs the agent actually uses. Below, it found a long list of runtime artefacts inside logs: http://MECM.sccm.lab/ccm_system/request, http://MECM.sccm.lab/SMS_MP/.sms_aut?SITESIGNCERT ,http://MECM.sccm.lab/CCM_Incoming/ and tokenized DP URIs containing CCMTOKENAUTH_SMS_DP_SMSPKG$/P0100005.

SharpSCCM triage command

These are the endpoints the client has contacted. The presence of CCMTOKENAUTH entries means the site is using tokenised, authenticated DP delivery for at least some packages.

To see WMI types the provider exposes, enumerate classes:

1.\SharpSCCM.exe local classes

SharpSCCM classes enumeration

That prints a very long list which proves the provider is responding and that you can query specific SCCM classes.

SharpSCCM has a ton of different options. I recommend playing around on your environment and reading the wiki to learn more about its power - https://github.com/Mayyhem/SharpSCCM/wiki.

PSSRecon

A useful tool for quick info gathering ispssrecon which can enumerate a primary site server or DP over winreg to get a quick list:

1./pssrecon -host mecm.sccm.lab -d sccm.lab -u carol -p SCCMftw

PSSrecon output

NetExec SMB Shares

Once you know where the site server is, a natural next step is to enumerate it's SMB shares with valid domain credentials.

1nxc smb 192.168.32.11 -u carol -p SCCMftw -d sccm.lab --shares

NetExec smb share enumeration

MECM exposes a whole collection of SCCM-specific shares alongside the standard administrative ones.SCCMContentLib$ is the the Configuration Manager Content Library for site P01, where all distributed content ends up. SMSPKG$, SMSSIG$ and SMS_CPSC$ are legacy-style package and compressed storage shares that still exist in modern builds. There’s also SMS_DP$, which is the Distribution Point share, and SMS_SITE which maps back to site-specific binaries.

Each of these shares is automatically created when you add the Distribution Point role, and together they give you a filesystem-level view of how content is being distributed.

NetExec SCCM Recon

With valid domain credentials, NetExec can also gather more information. NetExec comes with the recently published sccm-recon6 module, which queries Active Directory and SCCM’s own published data to gather info about the environment.

Running it against the MECM site server with just a low-privileged account confirms the core of the deployment:

1nxc smb 192.168.32.10 -u 'carol' -p 'SCCMftw' -M sccm-recon6

The output shows:

- Site Code: P01, which uniquely identifies the SCCM site.
- Site Server: MECM.sccm.lab (the central orchestration point).
- Management Points: MECM.sccm.lab is hosting the MP role over HTTP.
- Distribution Point: The same server is also doubling as a DP.
- PXE: Detected as installed and maps to CRED-1 where it may be possible to retrieve secrets from PXE boot media unauthenticated.
- Site Database: Located on MSSQL.sccm.lab, meaning SQL is split onto a separate server.
- Anonymous Access: Disabled for the DP (as expected in a hardened setup).
- SMB Signing: False, which is a red flag (labeled as TAKEOVER-2 from Misconfiguration Manager since it opens the door for relay attacks).

NetExec sccm-recon6 module output

SCCMHunter

SCCMHunter is a Python-based reconnaissance tool that pulls SCCM-related data from Active Directory and other sources (like SMB and registry queries). It consolidates information about site servers, databases, management points, PXE capability, and the SCCM service accounts in use.

The find module performs LDAP lookups against Active Directory and correlates SCCM objects (site servers, MPs, DPs, NAAs, SQL, etc.) into tables:

1python3 sccmhunter.py find -u carol -p SCCMftw -d sccm.lab -dc-ip 192.168.32.10 -debug

SCCMhunter find flag output

It gathers everything AD knows about SCCM including site codes, where the SQL backend is, which servers are MPs/DPs, and even the service accounts and groups tied to SCCM. The find mode is essentially scraping SCCM’s own published schema extensions.

There is also an smb module which works differently. Instead of LDAP, it authenticates over SMB and tries to pull SCCM-specific configuration from the registry, file system shares, and local policies on the target servers. For example, it can pull registry keys under HKLM\SOFTWARE\Microsoft\SMS, check which SCCM shares are present (SMSPKG$, SCCMContentLib), and enumerate which binaries are being served to clients.

1python3 sccmhunter.py smb -u carol -p 'SCCMftw' -d sccm.lab -dc-ip 192.168.32.10

It finds information such as:

- Site Server: MECM.sccm.lab confirmed again, with CAS = False (so this is a standalone primary, not a central admin site).
- MSSQL Database: MSSQL.sccm.lab registered, confirming SQL is split out.
- Management Point: Active on MECM.sccm.lab with site code P01.
- Distribution Point: Same host is also a DP, but note the detail — SCCM=True, WDS=False, meaning PXE is running in modern responder mode, not legacy WDS.
- Computers Table: Both entries map back to the same MECM host, showing it’s multitasking across roles.

SCCMhunter smb flag output

SCCMSecrets

sccmsecrets looks for the things SCCM intentionally distributes - policy bundles, package manifests, installer payloads and the occasional script - and follows the references those artefacts create back to registry keys, scheduled tasks and file paths that often contain important context. Be aware that some operations (for example the policies flow) register a client on the site and are persistent until you remove them, so treat those probes like any other active test.

Starting with the policy probe against the Management Point:

1python3 SCCMSecrets.py policies -mp http://mecm.sccm.lab -cn 'test'

SCCMsecrets policies command

This registers a fake client named test, waits for the MP to generate policies for that client, and then requests the list of policies the MP would deliver. If a successful client registration is done (it returned a GUID), it waits for 3 minutes and then requests device policies.

In this case, there were two policies and zero “secret” policies. In the GOAD lab, the MP is handing out normal configuration policy bundles rather than any special secret policies. The important thing is that the MP will happily hand out XML policy blobs to any registered client and those blobs are worth inspecting because they often include references to installation scripts, registry keys, package IDs and any special behavior the client should perform.

The files command attempts to pull content from a Distribution Point. Running it without credentials shows the common failure case:

1python3 SCCMSecrets.py files -dp http://mecm.sccm.lab

SCCMsecrets anonymous files command

It reports that anonymous access is not allowed which can be seen as true in the IIS Manager:

Anonymous access disabled in IIS manager

When you run the same files command with domain credentials it proceeds to enumerate packages and download whatever target file extensions you asked for:

1python3 SCCMSecrets.py files -dp http://mecm.sccm.lab -u 'carol' -p 'SCCMftw'

SCCMsecrets files command output

For example, it returned eight packages, iterated them and downloaded XML payloads such as ep_defaultpolicy.xml, amd64__Config_AppsAndSettings.xml, and arch-specific config XMLs for x86/arm64/amd64. These XML files are the canonical representations of SCCM policies and package manifests.
ep_defaultpolicy.xml in particular is Endpoint Protection policy expressed as XML; it declares policy sections, registry keys to set on clients, and values like whether real-time scanning is enabled, schedule windows, AV exclusions, and similar settings. The package config XMLs contain structured metadata for how an application or update should be installed, which files to drop, what registry keys to touch and which scripts to run as part of deployment.

Typical findings inside these XML files are installer step definitions that call a script path, scheduled task names, service account names, or a reference to a connection string blob (which could be stored elsewhere). For example, an ep_defaultpolicy.xml fragment will show and a list of entries that map directly to registry changes the client will apply. A package manifest will list filenames and GUIDs and often include an InstallCommand or a Script element pointing at a \\\SMSPKG$\\InstallScript.ps1 path. Those referenced script files are where cleartext credentials or tokens sometimes appear, or where you can find the run-as account name that the automation expects.

In short, policies gives you the policy XML the MP will hand a client, and files fetches package manifests and payload files from a DP when you have privileges. Policies works without requiring anonymous DP access because it talks to the Management Point as a client, while files talks to the Distribution Point’s HTTP/file endpoints and will fail if anonymous browsing is disabled.

CMLoot

CMLoot is the “file grab” step of SCCM recon: once you’ve found which servers are acting as Distribution Points or Content Library hosts, CMLoot helps you enumerate the descriptors SCCM publishes and then pull the actual package files that those descriptors point to.

If you don’t already know the CM hosts, you can discover them from AD or locally on a workstation that has the ConfigMgr client installed. The registry on a client contains the management points the client talks to; query it like this to get the list of MPs:

1(Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\SMS\DP -Name ManagementPoints).ManagementPoints

Get-ItemProperty command output

That returns one or more hostnames. There may be multiple CM servers and multiple DPs, and each can contain different packages, so take the time to enumerate every host you find.

CMLoot works in two phases. First you build an inventory of available file descriptors by parsing the .INI/manifest files SCCM stores on the server. Run the inventory command against an SCCM host and write the results to a plain text file:

1Invoke-CMLootInventory -SCCMHost mecm.sccm.lab -Outfile sccmfiles.txt

CMLoot inventory command

That sccmfiles.txt file is the canonical list you’ll use for downloads. Each line is a descriptor that maps to one or more real files on the ContentLib or SMSPKG$ tree.

Once you have the inventory, you can pick the files you want. If you enjoy a visual selection method, GridView will pop a GUI selector:

1Invoke-CMLootDownload -InventoryFile .\sccmfiles.txt -GridSelect

CMLoot download files via grid list

What you’re seeing in the grid are the raw content descriptors SCCM publishes for packages. Each P0xxxxx.y folder maps to a PackageID (the same IDs you’ll see in WMI/SMS_Package). Inside those package trees you’ll find a few recurring categories: manifests, replacement manifests, download (DL) manifests, payload binaries (MSI/EXE/CAB/DLL), and helper scripts or XML configuration files. The manifests are the index that tell the client what files make up the package, where to download them from, how to install them, and any registry changes or policy bits the client should apply. The payloads are the installers and libraries the manifest references.

The files whose names end in .man in your listing are SCCM manifests (replacement manifests, DL manifests, etc.). DLManifests are download manifests: small XML-like records that specify which files to fetch, the expected hash, the size and the content GUIDs. ReplacementManifests are used for OS/feature replacement scenarios (servicing, migration or OS upgrade packages) and describe which components are replaced or updated.

You’ll also see XML payloads that look like Config.xml, MigApp.xml, ep_defaultpolicy.xml and so on. ep_defaultpolicy.xml is an endpoint-protection policy expressed as XML: it contains registry keys and values the client must set, scheduled-task or behavior settings, and sometimes module names. Package config XMLs and PkgInfo-style files list install commands, pre/post scripts, component GUIDs and the relative paths inside the package. If a manifest references an InstallScript.ps1 or a *.bat, that script is where automations run and where you often find service account names, command-line arguments and in poor setups, hardcoded credentials or tokens.

Then there are the obvious binary artifacts: .msi, .exe, .dll, .cab. Those are just the installers and libraries. They’re not necessarily secret, but they’re useful to pull because they reveal the exact software versions deployed, and MSIs can be unpacked to inspect embedded transform files or custom actions which might call external scripts or authenticate with credentials. If a package contains a .pfx, that’s immediately interesting because those can include private keys used by the site. Likewise any .config, .json, .ini or .xml files in the inventory deserve priority because they’re human-readable and frequently contain connection strings, endpoint URLs, or references to service accounts.

A few realistic caveats: many of the .man/replacement manifests you see will be large component lists (Windows servicing parts) that are noisy and not immediately useful for credential hunting; they’re useful for inventory and mapping clients to OS components. Also, modern deployments try not to put plaintext credentials in scripts. What you’ll often find instead are account names, scheduled task names, or encrypted blobs.

By default CMLoot writes files into a CMLootOut folder under the current working directory. Files are conserved with a name scheme that encodes the source folder and a hash fragment so you don’t get collisions; expect paths of the form (folder:filext)\(first4hash)_originalfilename.

Summary

At this point we know the environment contains a Management Point published as MECM.sccm.lab and the site is identified as P01. DNS/AD SCPs and SRV records point clients to that MP and the MP advertises a self-signed “SMS / MECM” certificate. Distribution content lives in the Content Library/DPs (shares observed as SCCMContentLib$, SMSPKG$, SMS_DP$, SMS_SITE) but anonymous HTTP pulls are blocked in this case.

DP delivery is tokenised (CCMTOKENAUTH) so files require authentication or a client token. WMI/SharpSCCM output (the SMS_Authority view and triage logs) corroborates the MP/DP hostnames and shows the exact MP/DP URLs clients use (/SMS_MP/.sms_aut?mplist, /ccm_system/request, tokenised DP URIs). AD and LDAP queries list the site systems and computer objects (MECM, MSSQL, DC, CLIENT), and inventory tools (CMLoot / SCCMSecrets) returned package manifests and policy XMLs such as ep_defaultpolicy.xml plus package GUIDs (e.g. P0100005) and references to install scripts (InstallScript.ps1).