Privilege Escalation
Currently there are two different path ways for privilege escalation routes in an SCCM environment:
Credential harvesting
Authentication Coercion
Credential Harvesting
SCCM Credentials
The following SCCM components can contain credentials:
Device Collection variables
TaskSequence variables
Network Access Accounts (NAAs)
Client Push Accounts
Application & Scripts (potentially)
Misconfigured NAA
SCCM, uses various accounts in a deployment. One of the accounts it uses is called the “Network Access Account” or NAA. The NAA serves a simple role in SCCM: allow a non-domain-joined computer to retrieve software from the SCCM distribution point.
The NAA does nothing on the host. It simply accesses resources over the network. Therefore, the account should be configured with the least privilege necessary to access the content on the distribution point. It should also be configured such that it does not have interactive logon rights. Can be misconfigured.
Retrieving the credentials
The SCCM server sends the NAA policy which includes the credentials for the account to every SCCM client. the NAA policy gets stored on the client and protected by DPAPI. Specifically, the credentials are protected by the system’s DPAPI master key then stored as blobs in the “CCM_NetworkAccessAccount” class of the “root\ccm\policy\Machine\ActualConfig” WMI namespace. We can manually query these blobs from a high-integriy PowerShell process:
Decypher the WMI blob via DPAPI
NAA sole purpose is to authenticate to the SCCM server if the machine is not domain join yet. (Normally SCCM client use its machine account)
Although widely use, NAA are not required, Enhanced HTTP is safer option
Secret from endpoint - Exploit
Prerequisite :
Local admin on a SCCM client
NAA via SCCMwtf Technique
Prerequisite :
Not local admin
Needs machine account
Extraction via Relay
Prerequisites :
No domain credentials? (only for variant 1: Poisoning )
Not local admin?
No fake machine account? ms-DS-MachineAccountQuota = 0
Only SMB machine account NetNTLMv2 hash is required (PetitPotam, Printer bug)
Authentication Coercion
Via client push installation
With a compromised machine in an Active Directory where SCCM is deployed via Client Push Accounts on the assets, it is possible to have the "Client Push Account" authenticate to a remote resource and, for instance, retrieve an NTLM response (i.e. NTLM Capture). The "Client Push Account" usually has local administrator rights to a lot of assets. In some case, the "Client Push Accounts" could even be part of the Domain Admins group, leading to a complete takeover of the domain.
Option 1 : Wait for Client Push Installation
Option 2 : Prepare Coercion Receiver
Last updated
Was this helpful?