Tradecraft-SCCM

---

#sccm #tradecraft #RedTeaming

TLDR

Setup a SACL/honey trap on the NAA account instead of removing it. It is a perfect trap.

SCCM

Microsoft System Center Configuration Manager (also known as SCCM) is a core component of enterprise IT infrastructure, enabling centralized software and device management of large-scale Windows environments. From an attacker’s lens, any client-server architecture offers significant value once you gain access to the centralized infrastructure. SCCM, however, can still provide meaningful opportunities even from systems that are not SCCM-managed clients.

Attack Surface

• From a low privileged foothold or beacon with network access, the primary SCCM infrastructure components of interest are typically the Distribution Point (DP) and Management Point (MP) servers.
• The Distribution Point (DP) hosts packages, applications, scripts, OS deployment content, and other files distributed to SCCM clients. Depending on configuration, package content may be accessible anonymously or to authenticated domain users over HTTP/HTTPS or SMB.
• The Management Point (MP) facilitates client policy retrieval, registration, inventory submission, and other client-management operations. Access controls and authentication requirements vary depending on SCCM configuration, Enhanced HTTP usage, and PKI deployment.
• Low hanging fruit in many SCCM environments is grabbing Network Access Account (NAA) credentials. These accounts are sometimes overprivileged. More about this in the tradecraft section
• Even when the NAA is not directly privileged, it still provides authenticated domain access and can be leveraged for standard Active Directory enumeration, LDAP queries, share enumeration, and identifying ACL/delegation misconfigurations that may enable broader attack paths.
• NAA accounts may also retain unintended local admin rights, delegated permissions, or access to sensitive deployment infrastructure.
• Attacks such credential discovery via PXE boot or SC_UserAccount from the SCCM DB are more narrowed towards the aforementioned servers. They only work when you already have access to DP . But if you already have logon access or code execution of any facet on the DP, I would assume you have enough privileges to compromise the domain without worrying about SCCM .
• From a more realistic low-privilege perspective, the attack chain is more commonly:

Initial Domain Access (Beacon / Network Foothold) → NAA Discovery → NAA Account Exploration

Tools and Tradecraft

Warning: Relaying is not opsec friendly

• Firstly , to perform recon about the SCCM infra we can utilize SCCMhunter. From a tradecraft lens , SCCMHunter’s find command simply queries LDAP . Specifically the following search_filter=f"(distinguishedName=CN=System Management,CN=System)". If you already have an AD snapshot, you can simply query bloodhound .
• To discover the NAA credentials, as attackers we have two options and both of them have equal tradeoffs .
• The first is via abusing SCCM client enrolment to extract Network Access Account credentials from Management Points through spoofed client registration. SCCMHunter can be used for the following as well .
• This method registers a new client (computer object), requests policies and the decrypts the policies for the NAA credentials. The client enrolment is performed via HTTP, specifically to the following urls http://{server}/ccm_system_windowsauth; http://{server}/ccm_system
• You can use existing computer account credentials if you have one or you create you create new using domain user credentials. By default, any domain user can create up-to 10 Machine accounts. I have noticed in some mature environments, the default value is set to 0 .
• The second option is when you have administrator access to a workstation , you can dump the NAA credentials. Instead of requesting policies, we can simply query for the NAA account creds that has been used on this workstation during deployment.
• Querying the local SCCM client storage for NAA secret, specifically the CCM_NetworkAccessAccount. These are stored in two locations wmi and on disk. SharpSCCMcan be used for this.
• Assuming you have access via a beacon, you have to inline execute SharpSCCM. The tradecraft for this revolves around ‘creating a computer account vs in-process injection’. Creating machine account is more noisier compared to executing and dumping dpapi provided that you have Opsec friendly way to execute .NET executables.
• While it is noisy, it can still work if the environment you are in is not monitoring for unmanaged hosts.
• Another SCCM credential access vector is PXE abuse, In environments where PXE boot images are not encrypted, an attacker with unauthenticated network access and line of sight to a PXE-enabled Distribution Point can initiate the PXE installation sequence and recover credentials from the deployed image post-installation.
• Broadly speaking, this can expose local SAM hashes, SCCM secrets, deployment artifacts, and other sensitive material present within the installed image. Operationally, this attack path is more relevant in environments with exposed PXE infrastructure and weak deployment hardening.
• Requirements for this technique are generally:
  • Unauthenticated network access
  • Line of sight to a PXE-enabled Distribution Point