Privilege Escalation
Theory
Currently there are three different pathways for privilege escalation routes in an SCCM environment and take control over the infrastructure:
Credential harvesting: includes all the ways that could permit to retrieve SCCM related credentials in the environment.
Authentication Coercion: 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.
SCCM site takeover: a NTLM authentication obtained from the SCCM primary site server can be relayed to the SMS Provider or the MSSQL server in order to compromise the SCCM infrastructure.
SCCM site takeover from a passive site server: as describer by Garrett Foster in this article, when a passive site server is setup for high availability purpose, its machine account must be a member of the local Administrators group on the active site server. It must also be administrator on all the site system deployed in the site, including the MSSQL database
Credential harvesting
The following SCCM components can be found on SCCM clients and may contain credentials
Device Collection variables
TaskSequence variables
Network Access Accounts (NAAs)
Client Push Accounts
Application & Scripts (potentially)
Find more details about these components in this blog post.
Network Access Accounts (NAAs)
NAAs are manually created domain accounts used to retrieve data from the SCCM Distribution Point (DP) if the machine cannot use its machine account. Typically, when a machine has not yet been registered in the domain. To do this, the SCCM server sends the NAA policy to the machine, which will store the credentials encrypted by DPAPI on the disk. The credentials can be retrieved by requesting the WMI class in the CIM store in a binary file on the disk.
NAA doesn't need to be privileged on the domain, but it can happen that administrators give too many privileges to these accounts.
It is worth to note that, even after deleting or changing the NAA in the SCCM configuration, the binary file still contains the encrypted credentials on the enrolled computers.
SystemDPAPIdump
From UNIX-like systems, with administrative privileges over a device enrolled in the SCCM environment, SystemDPAPIdump.py (Python) can be used to decipher via DPAPI the WMI blob related to SCCM and retrieve the stored credentials. Additionally, the tool can also extract SYSTEM DPAPI credentials.
Manualy
On the other hand, it is possible, from a controlled computer account, to manually request the SCCM policy and retrieve the NAAs inside.
The tool author (Adam Chester) warns not to use this script in production environments.
Step 1: Gain control over a computer account password.
For this step, it is possible to create a new computer account (if permited by the domain policy), instead of compromise a domain computer.
Step 2: Use sccmwtf.py
to extract NAA secrets
A controlled computer account is needed to send the authenticated request (this is why a computer account has been created previously) to retrieve the policy, but the account to spoof doesn't need to be the same.
Here, $SCCM_MP_NetBiosName
takes the value of the SCCM Management Point server NETBIOS name.
Step 3: Obtain obfuscated NAA secrets
The obufscated NAA secrets will be saved in a local file.
Values to decode are the long hexadecimal strings in the CDATA sections (<![CDATA[String_here]
).
Step 4: Decode obfuscated strings
To decode username and password use .\DeobfuscateSecretString.exe
contained in SharpSCCM or sccmwtf
SCCMHunter
HTTP
Alternatively, sccmhunter (Python) automates all the attack with, or without, an already controlled computer accounts. For this purpose, the http
module uses the result from the find
command and enumerates the remote hosts for SCCM/MECM enrollment web services. If it finds one, it performs Adam Chester's attack for the specified computer account. If no account is already under control, the -auto
flag can be indicated to create a new computer account.
DPAPI
sccmhunter (Python) DPAPI's module can also be used, with valid credentials for a local administrator on the target system, to remotely extract NAA credentials located in the local WMI repository.
TaskSequence variables
TaskSequence are steps that can be configured by an administrator to perform specific actions, for example "Sequence for adding a machine to the domain". Think of it as a script that runs. These TaskSequences can contain variables that can contain credentials. These sequences can use device collection variables (presented in the next section) as conditions.
From UNIX-like systems, with administrative privileges over a device enrolled in the SCCM environment, sccmhunter (Python) can be used to extract the TaskSequence variables remotely.
Device Collection variables
Devices enrolled in an SCCM environment can be grouped by collection. These exist by default, but administrators can create custom collections (for example "Server 2012 devices"), and add variables for these collections that will be used, for example, during application deployement to check some conditions. These variables may very well contain credentials and be found locally on the clients.
From UNIX-like systems, with administrative privileges over a device enrolled in the SCCM environment, sccmhunter (Python) can be used to extract the TaskSequence variables remotely.
PXE/OSD (Operating System Deployment)
Credential harvesting
The Pre-Boot Execution Environment (PXE) is a mechanism for booting a computer over the network. Specifically, instead of booting from a CD drive, USB key or hard disk and finding the boot program, the PC will use the network to read such a program from the PXE server.
Several secrets could be retreived from Operating System Deployment (OSD)
Collection variables
Account to write image to SMB share
Account to pull files from SMB share
Set local admin password
Run arbitrary command
Account to join the domain (Apply Network Settings)
No Password
Without PXE password protection, we can use pxethiefy.py (Python) as follow, to extract secrets from the Operating System Deployment.
Password Protected
If a PXE password is set, we can use pxethiefy.py (Python) as follow. It will automaticly download encrypted files and extract the hash.
We can then try to crack it using Christopher Panayi’s hashcat module.
Decrypt the file using the found password
Missconfiguration
If "Enable command support" is enabled, we can spawn a shell during OS deployment by pressing F8.
Authentication Coercion via Client Push Installation
In some case, the "Client Push Accounts" could even be part of the Domain Admins group, leading to a complete takeover of the domain.
The client push installation can be triggered forcefully or - if you're lucky - your compromised machine might not have the SCCM client installed, which mean you could capture the client push installation as it occurs.
Option 1: Forcefully "coerce" the Client Push Installation
Important note: You want to read this blog post before you continue this route, as this attack might leave traces behind and might junk up the SCCM environment.
Step 1: Prepare coercion receiver
Note that you could either capture & crack received credentials or relay them to a suitable target system (or both).
Step 2: Trigger Client-Push Installation
Step 3: Cleanup
If you run the above SharpSCCM command with the --as-admin
parameter (cause you have admin privileges over the MP), there's nothing to do. Otherwise get in contact with the administrator of the SCCM system you just messed up and provide the name or IP of the attacker server you provided in the -t <AttackerServer>
parameter. This is the device name that will appear in SCCM.
SCCM Site Takeover
The primary site server's computer account is member of the local Administrators group on the site database server and on every site server hosting the "SMS Provider" role in the hierarchy (See SCCM Topology).
The user account that installs the site must have the following permissions:
Administrator on the following servers:
The site server
Each SQL Server that hosts the site database
Each instance of the SMS Provider for the site
Sysadmin on the instance of SQL Server that hosts the site database
(source: Microsoft.com)
This means that it is possible to obtain administrative access on the site database server, or interact as a local administrator with the HTTP API on the SMS Provider, by relaying a NTLM authentication coming from the primary site server, for example by coercing an automatic client push installation from it, and granting full access on the SCCM site to a controlled user.
For more details about how these attacks work, refer to the article "SCCM Site Takeover via Automatic Client Push Installation" by Chris Thompson for the database attack, and "Site Takeover via SCCM’s AdminService API" by Garrett Foster for the HTTP one.
Relay to the MSSQL site database
Some requirements are needed to perform the attack:
automatic site assignment and automatic site-wide client push installation are enabled
fallback to NTLM authentication is enabled (default)
the hotfix KB15599094 not installed (it prevents the client push installation account to perform an NTLM connection to a client)
PKI certificates are not required for client authentication (default)
either:
MSSQL is reachable on the site database server
OR
SMB is reachable and SMB signing isn’t required on the site database server
knowing the three-character site code for the SCCM site is required (step 3 below)
knowing the NetBIOS name, FQDN, or IP address of a site management point is required
knowing the NetBIOS name, FQDN, or IP address of the site database server is required
The first four requirements above apply to the client push installation coercion technique. But without them, a regular coercion technique could still be used (petitpotam, printerbug, etc.).
Retrieve the controlled user SID
The first step consists in retrieving the hexadecimal format of the user's SID (Security IDentifier) to grant "Full Administrator SCCM role" to, on the site database server. The hex formatted SID is needed in a part below: https://github.com/v4resk/red-book/blob/main/ad/movement/sccm-mecm/sccm-mecm.md#4.-obtain-an-sql-console.
Setup NTLM relay server
The target of the NTLM relay attack must be set to the site database server, either on the MS-SQL (port 1433/tcp
), or SMB service (port 445/tcp
) if the relayed user has admin privileges on the target. The rest of this page is focusing on relaying the authentication on the MS-SQL service.
From UNIX-like systems, Impacket's ntlmrelayx.py (Python) script can be used for that purpose. In the examples below, the -socks
option is used for more versatility but is not required.
Fore more insight on NTLM relay attacks and tools options, see the corresponding page on The Hacker Recipes: NTLM Relay.
Authentication coercion
The primary site server's authentication can be coerced via automatic client push installation targeting the relay server with SharpSCCM (C#). For more information, see the corresponding article "Coercing NTLM authentication from SCCM" by Chris Thompson. Alternatively, the server's authentication could be coerced with other, more common, coercion techniques (PrinterBug, PetitPotam, ShadowCoerce, DFSCoerce, etc.).
From UNIX-like systems, authentication can be coerced through PrinterBug, PetitPotam, ShadowCoerce, DFSCoerce, etc. (not based on triggering the client push installation).
There isn't any UNIX-like alternative to the SharpSCCM.exe invoke client-push
feature (yet).
The rest of this page is focusing on relaying the authentication on the MS-SQL service.
Obtain an SQL console
If the NTLM relay attack is a success and was targeting the MS-SQL service with SOCKS support, an SQL console could be obtained on the SCCM database through the opened socks proxy. From UNIX-like systems, Impacket's mssqlclient (Python) can be used for that purpose.
Once the console is obtained, the attack can proceed to granting the user full privileges by running the following commands in the SQL console.
It is then possible to verify the new privileges on SCCM.
Post exploitation via SCCM can now be performed on the network.
Relay to the HTTP API AdminService
Some requirements are needed to perform the attack:
The HTTP API for the AdminService service is reachable on the SMS Provider server
knowing the NetBIOS name, FQDN, or IP address of a site management point is required
knowing the NetBIOS name, FQDN, or IP address of the site SMS provider server is required
Setup an NTLM relay server
The target of the NTLM relay attack must be set to the SMS Provider server, on the HTTP/S service (port 80/tcp
or 443/tcp
).
From UNIX-like systems, this PR on Impacket's ntlmrelayx.py (Python) script can be used for that purpose.
Fore more insight on NTLM relay attacks and tools options, see the corresponding page on The Hacker Recipes: NTLM Relay.
Authentication coercion
The primary site server's authentication can be coerced via automatic client push installation targeting the relay server with SharpSCCM (C#). For more information, see the corresponding article "Coercing NTLM authentication from SCCM" by Chris Thompson. Alternatively, the server's authentication could be coerced with other, more common, coercion techniques (PrinterBug, PetitPotam, ShadowCoerce, DFSCoerce, etc.).
From UNIX-like systems, authentication can be coerced through PrinterBug, PetitPotam, ShadowCoerce, DFSCoerce, etc. (not based on triggering the client push installation).
There isn't any UNIX-like alternative to the SharpSCCM.exe invoke client-push
feature (yet).
If the NTLM relay attack is a success and ntlmrelayx.py has effectively sent the request to the sms provider server, the controlled should be now a SCCM site admin.
It is then possible to verify the new privileges on SCCM.
Relay from a passive site server to the active site server
Some requirements are needed to perform the attack:
a passive site server is present on the network and its reachable
knowing the NetBIOS name, FQDN, or IP address of the passive and active site servers is required
SMB signing is not required on the active site server (default)
Setup an NTLM relay server
The target of the NTLM relay attack must be set to the active site server, on the SMB service.
From UNIX-like systems, Impacket's ntlmrelayx.py (Python) script can be used for that purpose.
Fore more insight on NTLM relay attacks and tools options, see the corresponding page on The Hacker Recipes: NTLM Relay.
Authentication coercion
The passive site server's authentication can be coerced with (PrinterBug, PetitPotam, ShadowCoerce, DFSCoerce, etc.).
If the NTLM relay attack is a success and ntlmrelayx.py has effectively sent the request to the active server, a SMB session through socks proxy has been opened with administrative rights.
Dump active site server account credentials
Through the socks session, it is possible to dump the local credentials stored in the SAM database, and the secrets from the LSA, with Impacket's secretsdump.py (Python).
Retrieve the LM:NT hash of the server account.
Add a new SCCM
Full Admin
Since the active site server must be a member of the SMS Provider administrators (it is member of the SMS Admins
group), its credentials can be used to add a new controlled user to the Full Admin
SCCM group. sccmhunter (Python) can be used for this purpose.
Post exploitation via SCCM can now be performed on the network.
The tool author (Chris Thompson) warns that SharpSCCM is a PoC only tested in lab. One should be careful when running in production environments.
Resources
Last updated