Relay again. Mastering relevant NTLM Relay attack techniques implemented via SCCM

A brief historical journey. In late 2023, my colleagues at Specterops published a detailed research on privilege escalation techniques in the AD domain involving the exploitation of SCCM (System Center Configuration Manager) servers. Since then, a number of other cool studies on that subject have been published. More information is available in the Misconfiguration Manager repository on GitHub: its owner collects and organizes SCCM-related techniques used to steal accounts, elevate privileges, and perform post-exploitation. This article presents a few practical examples of NTLM Relay attacks on SCCM.

Theory

For those unfamiliar with SCCM: System Center Configuration Manager (since 2020 known as Microsoft Endpoint Configuration Manager, MECM) is a centralized management software. In the official documentation, I couldn’t find a clear definition of this entity and why it’s required; so, I had to formulate it myself.

One might say that my definition essentially describes Active Directory (hereinafter AD). Yes and no: Configuration Manager was created to make life of IT administrators easier and reduce administration costs.

A simple example. If your company has a thousand employees, five people can handle its administration, but what if the company has grown to ten thousand or even one hundred thousand people? Would you hire fifty or five hundred IT specialists, respectively? Of course, every boss wants to avoid such a linear correlation. AD was initially invented for this purpose, and then Configuration Manager appeared.

SCCM is typically used in fairly large companies where the number of users exceeds ten thousand. It accommodates almost all existing AD management tools and ensures more efficient management of workstations, software, etc.

Below is a screenshot from the official documentation.

The core statement is: “with the potential to affect every computer in your organization” (provided that this computer is under the control of an SCCM instance).

The diagram below helps to comprehend the SCCM/MECM site structure.

The key SCCM features are as follows:

• Client–server architecture. All domain nodes (e.g. DC or Exchange) act as clients; while the SCCM master acts as a server;
• Fault tolerance is implemented by adding a passive server ready to take over master’s duties if it fails;
• Operation in terms of sites. All terms were taken from the official documentation; you just have to get used to this terminology: there might be several sites in one AD domain;
• Site hierarchy is implemented. Sites can be linked to each other by child relationships. Each site can be attacked independently of others;
• Role model is implemented. SCCM sites use a sophisticated role model for both users and servers. Its details are beyond the scope of this article; in terms of NTLM Relay attacks, only two roles are important: Full administrator for users and Site system servers for servers. More information on this role-based server model is available in the official documentation and there; and 
• MSSQL is used. SCCM cannot exist without MSSQL. This database stores all service information, including tables containing entries related to roles. A MSSQL snap-in can be deployed on the master, but a separate server is often allocated for it.

Reconnaissance

Done with theory; time for some practice. I used a GOAD lab as a test system. If you want to recreate all operations described below, you can easily deploy such a system and run tests yourself. Its layout is quite clear: a SCCM/MECM server, a domain controller that is not managed by SCCM, an SCCM client, and a MSSQL server storing all service information.

All subsequent actions assume that the attacker has an account in the AD domain.

First of all, you have to find out whether SCCM exists in the domain. This can be done with a single LDAP request:

The community has also developed a tool that automates reconnaissance: sccmhunter.py. I suggest to use it so that all collected information will be presented in neat tables.

After LDAP reconnaissance, you can also perform SMB reconnaissance. This can be done either manually…

…or automatically.

Such reconnaissance makes it possible to discover SiteCode and check SMB Signing. The absence of the SMB Signing requirement and SiteCode are mandatory prerequisites for subsequent attacks.

Servers have been identified; time to escalate privileges in several ways.

TAKEOVER1

Let’s examine the test system layout again.

It can be seen that the account of the MECM$ computer is the administrator of the database on the Microsoft SQL server. But how to get the MECM$ account? Time to remember the NTLM Relay attack and the authentication coercion technique.

Starting ntlmrelayx.

Delivering an authentication coercion attack with PetitPotam.

Success! An Microsoft SQL session has been established on behalf of MECM$.

Connecting to SCCM using the established session.

After getting the shell, I attempt to execute code in the classic way using xp_cmdshell.

Now I can perform RCE on the SCCM/MECM server, but is it my ultimate goal? Especially taking that the sccm-sql account is a local administrator on the server.

As you might remember, at the very beginning of this article, I mentioned that SCCM sites are built on Microsoft SQL, and all information about roles is stored in the DB. Now I am going to execute several SQL queries to assign the administrator role and script execution rights to my account.

Let’s figure out what happens in the above screenshot. I insert a row into the RBAC_Admins table (a self-explanatory name, isn’t it?). The long value consisting of obscure characters is a hexadecimal representation of the SID assigned to the user who should be added as an administrator. The SourceSite value is the name of the site discovered during the SMB reconnaissance phase.

Next, you have to assign permissions to certain types of objects.

In fact, only the underlined value will differ on different sites. This is the unique user ID within the SCCM site. This ID is assigned automatically when a user is added to the table, and I listed it in the second last screenshot.

Sccmhunter can be used to generate correct SQL queries automatically so that all you have to do is execute them.

To summarize: at this stage, I have successfully extended privileges within the SCCM site. The subsequent exploitation will be discussed a bit later. Let’s examine other privilege escalation techniques first.

TAKEOVER2

Remember the diagram discussed at the beginning of the TAKEOVER1 section? Let’s examine it again.

The diagram clearly shows that the account of the MECM$ computer belongs to the local administrators group on the Microsoft SQL server. Such a configuration enables an attacker to implement NTLM Relay on SMB or RPC. This is the essence of TAKEOVER2, but there are certain nuances. Let’s examine them.

Starting ntlmrelayx to deliver an attack.

Coercing to authenticate with PetitPotam.

Success!

An SMB session has been successfully established, and I immediately attempt to dump the HKLM\SAM and HKLM\SECURITY registry branches.

As a result, I get a local administrator account on the attacked server, the server account, and the sccm-sql account with the password in plain text.

At this point, I recall the diagram again and realize that the sccm-sql account is a DB administrator on the Microsoft SQL server. So, I try to connect to the DB.

First, I get a shell on Microsoft SQL again, and the subsequent attack is delivered similar to TAKEOVER1. As in the previous case, I execute four SQL queries to escalate privileges within the SCCM site and execute arbitrary code on the target device (e.g. domain controller).

TAKEOVER5

The creators of the GOAD lab used in my tests didn’t intent it for the technique described below, but nothing is impossible to a willing heart.

The main idea is as follows: you deliver an NTLM Relay attack on HTTP to escalate privileges via WMI. To deliver such an attack, you have to patch ntlmrelayx.

You’ll need any account on the AD domain, and you have to know the SID of this account. You can look it up in BloodHound in the user attributes or request it over LDAP (as in the screenshot below).

I start ntlmrelayx to deliver an attack and elevate privileges on the SCCM site for the user eve. NTLM Relay targets the SMS server that can be either set up on the master or deployed on a separate node.

Next, I perform authentication coercion (e.g. using PetitPotam) against the master server or backup server. But the test lab doesn’t feature two such servers; so, I artificially relay authentication to ntlmrelayx.

The attack result is shown below. The SCCM site administrator role has been assigned to the account under my control.

As a result of this simple, but efficient attack, I assign the SCCM site administrator role to the account under my control again.

Privilege escalation in AD domain

I managed to elevate my account to full SCCM site administrator three times, but what’s the use of it? The answer is: the possibility to execute commands via SCCM API. This can be done via the snap-in using SharpSCCM or sccmhunter.

To start interacting with any computer in the domain, you first have to find the target host ID on the SCCM site. Using sccmhunter, this can be done in one command.

The ResourceId field in the output is exactly what you need.

Now let’s try to execute commands directly on the host.

I managed to list its directories, which is good, but let’s find out whether it’s possible to do something more exciting (e.g. add a user to the local administrators group). For this purpose, I create a simple script to add the account under my control to the local administrators group.

But prior to its execution, one aspect has to be clarified. By default, SCCM is configured so that a newly-created script must be approved by another administrator (to make sure that it doesn’t contain errors or malicious code). Experience shows that this security feature is deliberately disabled in most systems. Should such a situation occur, you can assign the SCCM administrator role to another AD user, and this operation doesn’t require the involvement of another administrator.

The mechanism responsible for script approval by a second administrator is implemented in sccmhunter; so, I immediately specify two accounts and perform the required operations.

After the successful command execution, I try to list network drives again. Access to the ADMIN$ and C$ network drives indicates that my user is now a local administrator.

Protection

Protection techniques against NTLM Relay attacks have been actively discussed since the invention of this attack type. You goal is to prevent the attacker from getting NTLM authentication (spoofing, MITM, Coerce, and other techniques) and protect endpoints that can be targeted by NTLM Relay attacks (SMB, MSSQL, HTTP, LDAP, and RPC). More information is available in the official Microsoft article and in my previous publications about NTLM Relay. This article analyzes in detail the protection against NTLM Relay attacks on Microsoft SQL (since this technique wasn’t so effective in the past).

Microsoft SQL

Microsoft has understood the need to protect against NTLM Relay a long time ago and developed standard tools for this purpose. They are called Extended Protection and Enforce Encryption. The tools can be configured using the standard SQL snap-in from Microsoft.

1. Open the snap-in;
2. Expand SQL Server Network Configuration;
3. Right-click Protocols for MSSQLSERVER;
4. Select Properties;
5. Click Advanced;
6. Change the Extended Protocols Protection value to Required;
7. Click Flags;
8. Change the Force Encryption value to Yes;
9. Click Apply; and 
10. Click OK.

Bonus

A small bonus for attackers and security specialists. How can you massively check the target infrastructure for the Microsoft SQL signature requirement? There is a handy tool called mssqlrelay. It cannot yet check subnets or files with targets, but you can always run it in a loop.

Using mssqlrelay, you can easily check whether protection is enabled on endpoints.

In real-life pentesting audits, Microsoft SQL endpoint protection is often disabled.

Conclusions

This article discusses three types of NTLM Relay attacks on SCCM, but, as you understand, their number is much greater. Importantly, all of them are based on techniques described in my previous articles (e.g. NTLM Relay on LDAP + case with RBCD or ShadowCreds; or NTLM Relay on ADCS to issue a certificate on behalf of the master server with its subsequent capture).

The second conclusion is as follows: it’s too early to discard the oldie-goodie NTLM Relay attack. In my opinion, NTLM will persist in infrastructures for a long time. It’s not that easy to abandon it, and it will be present even in Windows 11 and Server 2022 to ensure support for some legacy products.