The lab machines are displayed in the same corners of the screen as in the diagram above. The following demo video depicts the full attack path, including all commands executed on each system. If you’re using the same system for both the attack and relay, detailed instructions can be found here. The attacker host and relay server can be the same system if you have administrator privileges, but for the sake of simplicity for this demonstration, we’re going to use a Linux system on the same network. Lab Configuration = FQDN IP PURPOSE = ATLAS 192.168.57.50 Primary Site Server and Management Point P-BODY 192.168.57.51 Site Database Server GLaDOS 192.168.57.100 APERTURE.SCI Domain Controller CAVE-JOHNSON-PC 192.168.57.101 Windows Attacker Host KALI 192.168.57.130 NTLM Relay Server = This may present other opportunities for site or client takeover that I may dive into another time. It is also the default account used to install SCCM roles on other servers (e.g., distribution points, software update points, etc.). If there is a central administration site (CAS) or secondary sites, the site server’s computer account must be an administrator on the site servers and databases there as well. Not only does the primary site server computer account have to be a member of the local Administrators group on the site database server, but also on every site server hosting the “SMS Provider” role in the hierarchy.
Knowing that the primary site server’s computer account is a member of the local Administrators group on the site database server means that we can relay coerced SMB authentication for this computer account to SMB or MSSQL on the site database server and grant ourselves privileges over the site. Typically, computer accounts are not added to the local Administrators group on other machines, which is required for successful SMB to SMB relay attacks, so I didn’t pay much attention to the SMB authentication being useful for anything other than client takeover, until now. However, the required configurations for site takeover may be more common than I previously thought.īy default, when client push installation occurs, the primary site server connects to the remote system via SMB and attempts to authenticate with each configured account, followed by its computer account.
This service is not typically installed on Windows Server versions, so I thought it would be fairly uncommon to see in the wild.
In this scenario, it is possible to coerce and relay HTTP NTLM authentication to LDAP to conduct RBCD, Shadow Credentials, or AD CS attacks. When I posted about coercing NTLM authentication from SCCM servers last year, I thought that the only way to take over an SCCM site via automatic client push installation was when the WebClient service was running on the site server.
0 kommentar(er)
