Attack Path
Tech sites have published articles that walk a Windows Systems Administrator through the process of adding a machine account to the Local Administrators group on another machine. These accounts end in a $ (dollar sign) and look like SERVER$ in Active Directory. While this may be useful for simplifying the installation of clusters such as Lync, Exchange, or SQL Server, it’s not always the best idea.
Servers that are set up in this way weaken the overall security posture of the cluster, and ultimately the organization, by allowing a single vulnerability or misconfiguration on one server the ability to move laterally without having to escalate privileges or compromise additional credentials. Using SQL Server as the example, any user who has READ permissions to a database essentially has SYSTEM-level permissions on a remote server. We’ll walk through that path below.
It may take you some guesswork to identify servers that are set up in this configuration. You’ll need to look at the organization’s naming standard for keywords such as LYNC, CLUS, SQL, and sequential numbering. If low-level credentials are already obtained by the attacker, tools such as BloodHound or PowerView‘s Invoke-EnumerateLocalAdmin can be used to find affected servers and significantly reduce the effort involved.
CoreSecurity‘s Impacket tool contains an example script for relaying NTLM authentication named, well, ntlmrelayx.py. Relaying NTLM authentication is not new in the penetration testing world and has been well-documented for years, but seemed to make a resurgence in mid-2017. Prior to then, capturing and cracking NetNTLM hashes was easier, but as organizations strengthen their password policy or move to alternate forms of authentication such as Kerberos, these hashes can be time-consuming to crack. Since relaying has received a significant amount of coverage, we won’t review it here.
The first piece you need to pull off this attack path is forcing a machine account with local administrator access on a remote computer to authenticate to our attacker-controlled relay system. Any tool that can run SQL queries is capable of performing this piece of the attack, but since we’re in Linux for ntlmrelayx, we’ll use the auxillary/admin/msssql/mssql_sql Metasploit module.
Since 2005, Microsoft SQL Server has shipped with the old favorite xp_cmdshell disabled, but attackers are always finding new and novel ways to abuse additional default functionality. Two of the latest SQL Server stored procedures to be abused are xp_dirtree and xp_fileexist, both of which accept a UNC path and can force a SQL Server to authenticate against a destination of our choosing. In this case, it’s our system running ntlmrelayx. By sending an SQL Query using one of the stored procedures mentioned above, we can force the client to connect through our NTLM Relay to the victim machine, and by default NTLMRelayx will dump the local account hashes. These hashes can then be used for further lateral movement such as PSExec. You can skip the additional PSExec step by using the -c (COMMAND) flag or -I for an Interactive shell.
A Low Privileged User’s credentials are used to connect to the SQLSERVER server and execute the xp_dirtree against an SMB Share exposed by the ATTACKER controlled computer.
NTLMRelayX is then used to relay the connection from SQLSERVER to VICTIM, and execute the ‘whoami’ command, resulting in NT AUTHORITY\SYSTEM
Identification
To identify if this configuration exists in your environment, you need to audit the local administrator group on every server to ensure the principle of least privilege is followed and that other machine accounts do not hold Local Administrator rights on another server. This can be quite challenging in a large environment, but there are several tools that can make it easier.
BloodHound is an information gathering tool used by both penetration testers and security defense teams to map multiple relationships into an easily digestible format. The backend is a neo4j graph database that holds a wealth of information that isn’t directly exposed to the Bloodhound GUI. If you haven’t seen this before, I’d highly recommend watching the DEF CON 24 presentation by Andy Robbins, Rohan Vazarkar, and Will Schroeder, and giving it a try. This configuration can be identified by making a raw cypher query against the database, but that’s a whole different blog post.
MATCH p=(n:Computer)-[r1:MemberOf*1..]->(g:Group)-[r2:AdminTo]->(m:Computer) RETURN n,m
Prevention
You can prevent this attack path in several ways. The first being auditing of the Local Administrators group as mentioned above, but the other ways include Restricting NTLM Authentication on the domain in favor of more modern protocols such as Kerberos. This is a potentially impactful change if you’re still running legacy applications that may not support Kerberos, or are unaware of the consequences of the change. Consider auditing your server event logs for NTLM Authentication and tracking down the source, then disabling NTLM Authentication once these have been remediated.
Once the Local Administrator groups have been audited, you may want to consider the use of Restricted Groups enforced through Group Policy to minimize any changes and keep permissions creep from weakening the security posture any further.
Another way to prevent this type of attack is by enforcing SMB Signing. SMB Signing, provided optionally since Windows 2000, is a severely overlooked security feature. It works by enforcing a cryptographic signature for each transaction if both server and client are configured to enforce signatures in order to prevent Man-In-The-Middle attacks.
Closing
Even though using xp_dirtree for NetNTLM hash collection and NTLM Relaying are both relatively older techniques, they can still prove fruitful for attackers in certain environments with large Lync configurations or SQL Clusters, allowing for a combined lateral movement and privilege escalation to SYSTEM in one pass. It should be relatively easy for you to prevent this technique from being used in your environment during the system design phase and SQL Server hardening. If unchecked, this configuration can provide a simple path to privileged access for an attacker.
