Overview

Recently I’ve been working on writing a custom SMB client that implements the initial handshake and NTLM authentication functionality to perform port fingerprinting within Chariot Identify, our attack surface management product. While reading through the SMB specification, I got to thinking about Computer AdminTo Computer vulnerabilities we have exploited over the last few years since our publication of the initial blog post back in July 2020. We discussed the Computer AdminTo Computer vulnerability in a previous article titled Active Directory Computer Account SMB Relaying Attack.

This article is a follow-on to the previous article and discusses some frequent root causes of this vulnerability. We also discuss alternative methods of exploiting Computer AdminTo Computer issues when SMB signing is required.

Common Root Cause #1: Database Availability Groups

In some cases, administrators simply follow official Microsoft documentation to configure exchange database availability groups. The documentation guidance contains a critical security issue and may introduce vulnerabilities into customer environments if implemented. This vulnerability can result in a scenario where any domain user account can instantly elevate privileges to domain administrator.

In an article titled “Manage Database Availability Groups in Exchange Server” Microsoft advises adding the witness server to the local Administrators group within Exchange:

“If the witness server you specify isn’t an Exchange 2010 or later server, you must add the Exchange Trusted Subsystem universal security group (USG) to the local Administrators group on the witness server prior to creating the DAG. These security permissions are necessary to ensure that Exchange can create a directory and share on the witness server as needed.” [1]

The image given below shows the expected result in this scenario when running BloodHound within an environment with this configuration issue. However, it’s important to note that BloodHound for various reasons doesn’t always provide a complete picture of these attack paths due to limitations in the collection methods leveraged.

Common Root Cause #2: Service Account Configuration

We have also observed customers running applications requiring administrative privileges to other systems. However, instead of using a dedicated domain user service account, the customer has instead leveraged the associated computer account directly to run the service.

For example, one customer needed their SCCM instance to have high privileges within the environment to perform administrative tasks. However, instead of configuring SCCM to run as a service account, they configured SCCM to run as a local computer account. Next, they then granted the computer account domain administrator privileges within the environment by adding the computer to the domain administrators group.

Unfortunately, this led to a scenario where any user could then trigger an NTLM authentication from the SCCM server and relay the authentication to the Azure AD Connect server to compromise the domain. Below is an image of what the misconfiguration looked like.

We can also leverage the following query to list the groups computers are a member of within the domain. Often, it is worthwhile to review this list manually.

MATCH (c:Computer)-[:MemberOf*1..]->(g:Group) RETURN c.name,g.name,g.description

The image given below shows some example output in this scenario:

Tip for Identifying Azure AD Connect Instances

One of the challenges of exploiting relaying attacks is identifying a high-value target that could be compromised to elevate privileges further. One of my favorite systems to target in these scenarios is Azure AD Connect.

These systems often possess the same privileges as a domain controller, including full domain replication privileges without any of the tier separation or monitoring one would typically find surrounding a domain controller. Service accounts with domain administrator privileges are protected by default with a more restricted ACL due to the AdminCount attribute being true. However, this isn’t true for the Azure AD Connect service account even though it has the equivalent of full domain administrator privileges through domain replication rights. An attacker with a foothold can then perform replication and compromise the entire domain while bypassing many Active Directory monitoring solutions.

An easy way to identify Azure AD Connect systems within the environment by searching for service accounts of the format “MSOL_.*” with a random hex string at the end. The installer for Azure AD Connect automatically creates this service account to perform replication.

Alternative Exploitation Methods

One common misconception is that requiring SMB signing can remediate the vulnerability without removing the computer accounts from the privileged groups. Unfortunately, this isn’t always the case, as cross-protocol relaying attacks can often lead to scenarios where the issue is still exploitable.

Sylvain Heiniger describes an alternative method for performing relaying attacks when SMB signing is required in an article titled Relaying NTLM authentication over RPC by leveraging the Microsoft Windows Task Scheduler (MS-TSCH) RPC interface and lead to CVE-2020-1113.

Another method we have leveraged on several recent tests is relaying from SMB to MSSQL using the cross-protocol relaying capabilities of NTLMRelayX. We can then compromise the underlying host using xp_cmdshell (or other more stealthy methods if needed). However, this only works in certain limited scenarios such as when, for example, the SQL server is configured to grant “BUILTIN\Administrator” SA privileges. This is not the default configuration [2], but we have seen this configured in multiple customer environments so it is worth checking.

Testing Guidance

Identifying this issue can be tricky due to limited permissions and network segmentation from a testing perspective. Additionally, during red team engagements, we are often limited in the collection methods we can leverage within BloodHound to evade detection (or may be unable to leverage BloodHound in other cases).

Outside of leveraging the standard queries within BloodHound, we recommend also taking the following actions to identify these issues as in some cases we have observed scenarios where BloodHound has missed edges due to permissions issues:

1. Identify all groups that a computer is a member of in Active Directory. Pay special attention to groups with names that suggest higher-levels of privilege (e.g. admin). Additionally, examine the description fields of these groups as these can often be used to reveal hidden administrative rights not discovered by BloodHound. For example, the description field of a group may include information such as “provides administrative access to X system” which won’t always be discovered running BloodHound.
2. Even if BloodHound doesn’t identify administrative edges between Microsoft Exchange servers, it can still be helpful to attempt relaying between them since these edges aren’t always accurately identified.

From an operational perspective, it can often be difficult to exploit “Computer AdminTo Computer” vulnerabilities due to the limitations of performing SMB relaying attacks from a compromised Windows system. We have developed the PortBender utility to support exploitation from a compromised Windows host to overcome this limitation. This tool is covered in a previous blog post titled How to redirect traffic from an incoming TCP port using the Portbender utility which discusses the design and usage of this utility.

The PortBender utility does require elevated administrator privileges on the local Windows system in order to load the requisite device driver for traffic redirection. However, we are frequently able to escalate privileges by leveraging resource-based constrained delegation which then allows us to load this driver. We discuss this privilege escalation method in a previous article titled Red Team Privilege Escalation – RBCD Based Privilege Escalation – Part 2 which provides step-by-step instructions on accomplishing this through Cobalt Strike (but the instructions can fairly easily be adapted to other C2 agents).

Conclusion

In this article, we discussed some common root causes of the “Computer AdminTo Computer” vulnerability. We also discussed an alternative method of exploiting the vulnerability for escalating privileges in MSSQL. Unfortunately, as discussed previously, simply following Microsoft documentation can introduce critical vulnerabilities under specific configurations. Additionally, it’s not uncommon for administrators to add a computer account to an administrative account by accident and introduce a new attack path exploitable by any user.

References

[1]https://docs.microsoft.com/en-us/exchange/high-availability/manage-ha/manage-dags?view=exchserver-2019

[2]https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/cc280562(v=sql.105)?redirectedfrom=MSDN