How to Prevent High Risk Authentication Coercion Vulnerabilities

Most of us already know the basic principle of authentication, which, in its simplest form, helps us to identify and verify a user, process, or account. In an Active Directory environment, this is commonly done through the use of an NTLM hash. When a user wants to access a network resource, such as a file share, their password is hashed and sent over a cryptographically secure channel to the resource.

During the authentication process, this is typically used as the method to verify the identity of the user. These hashes can be as good as gold from an attacker’s perspective, especially when they can be obtained “on-demand” through coercion. Authentication coercion is when an attacker is able to force a machine to initiate an authentication attempt back to their “attacker” machine.

Many times, this response comes in the form of an NTLM hash, as noted previously. PKF O’Connor Davies’ penetration testing team regularly leverages stolen NTLM hashes during client penetration tests to move laterally and escalate privileges. The remainder of this article will provide a technical deep dive into these tactics, techniques, and procedures used by penetration testers and attackers, as well as the mitigations an organization can implement to prevent this type of abuse.

How NTLM Hashes Are Used

Once a hash is stolen, an attacker can use a group of available tools to discover a hash collision, which will reveal the plaintext credentials. Alternatively, the NTLM hashes can sometimes be used in relay attacks. Commonly known as a “Pass the Hash” attack, this occurs when an attacker receives an authentication request in the form of an NTLM hash and forwards it to a resource of their choice. The attacker is then able to authenticate as the targeted user by using the relayed hash. This gets especially dangerous when administrative credentials are relayed. Fortunately, these hashes are typically quite hard to obtain if the attacker is not already inside the network.

Internally, the highest risk of hash disclosure is through the use of Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Server (NBNS) protocols. While these are considered outdated and “legacy” protocols, they are commonly overlooked and are still present in many Windows environments because they are enabled by default. These come into play when a machine can’t resolve a host to which it is attempting to authenticate. After checking the internal host list and querying DNS, it will fall back and send out a LLMNR or NBNS request to the entire subnet looking for the host. Attackers will use tools like Responder or Inveigh to listen to these requests and then spoof responses saying, “it’s me, I’m the machine you’re looking for!”. This results in the hash being sent as part of the authentication request directly to the attacker’s machine, as noted in the process diagram below.

This process often relies on sheer luck. The attacker usually has to wait for machines on the network to generate these requests so responses can be spoofed and hashes can be obtained. But in certain cases, it is possible to force a system to attempt authentication, rather than simply waiting around for a vulnerable request.

Authentication Coercion Basics

One of the most common methods of forcing authentication within the security community is known as PetitPotam. The principle of this attack utilizes the Encrypting File System Remote Procedure Call (MS-EFSRPC) to coerce a Domain Controller into disclosing NTLM hashes to the attacker. The MS-EFSRPC protocol is used to allow users remote access to data stored on a network. By sending a specific SMB request to a Domain Controller’s MS-EFSRPC interface, the authentication process is initiated, which then leads to disclosure of the Domain Controller’s machine account hash. This machine account hash can then be relayed to other services on the network, such as the Certificate Enrollment service, to obtain administrative privileges over the entire domain.

Another recent example of an authentication coercion vulnerability is DFSCoerce. Similar to the PetitPotam attack, it instead uses the MS-DFSNM protocol which enables remote administration for the Windows Distributed File System (DFS). Again, remote procedure calls are used as the method of initiating the attack, resulting in the forced disclosure of an NTLM hash over the network. These are not the only examples of authentication coercion vulnerabilities affecting Windows environments, and this is an active area of information security research.

Authentication Coercion in MSSQL

One of the most overlooked methods of authentication coercion utilizes misconfigurations in Microsoft SQL Servers. While not a new method for attackers and is not a vulnerability in the software itself, it relies on the misconfiguration of two stored procedures present by default in MSSQL. This is an example of malicious actors “living off the land,” and abusing misconfigurations in a given system, rather than relying on any specific technical vulnerability. This technique is regularly identified and exploited during penetration tests as a mechanism for lateral movement and privilege escalation.

When configuring an MSSQL server, the administrator must choose an account for the server to run as. Many times, this is a domain-joined account service account, or a local administrator account. Usually, these accounts have elevated privileges to run the processes needed by the SQL server. This makes these accounts especially juicy in the eyes of an attacker. The technique outlined below will allow an attacker to obtain the password hash of the account running the database server.

The xp_dirtree and xp_fileexists stored procedures allow database administrators and developers to generate a list of all files in a chosen directory and verify the existence of a specific file in a directory, respectively. MSSQL servers are commonly misconfigured with these stored procedures being executable by the PUBLIC role, allowing any authenticated account to make calls to the procedure. The only prerequisite to call these procedures is that access to the SQL database is required. An attacker would either need an account on the database server or need to have identified an SQL injection point in an application supported by the MSSQL server. Calling either procedure is fairly straightforward and requires only a few parameters. For the xp_dirtree procedure, the directory and the depth must be specified. The xp_fileexists procedure call only requires a filename, which then returns whether the file exists or not. Below is an example of what is returned when the xp_dirtree procedure is called via SQL Server Management Studio against a local directory created for testing purposes.

The interesting thing about both procedures is that they are not restricted to the local machine or current working directory and can be used to connect to external file shares. Knowing this, it is possible for an authenticated attacker to force the SQL server to attempt to connect to any machine, even over the internet! The example below shows the execution of the Metasploit module designed to abuse this feature to capture the NTLM hash of the account running the SQL server by directing the server to authenticate to an attacker-controlled machine.

Similarly, this technique can be exploited via SQL injection in a vulnerable application that is supported by a misconfigured SQL server. The example below outlines an example of the process.

Potential Risks

Once obtained, there are few things which can be done with the machine’s NTLM hash. The first is that an attacker can take the compromised NTLM hash and attempt to crack it offline with a utility, such as Hashcat. If the account has a long and complex password, it will be very difficult to crack the password in a reasonable amount of time. Relaying the hash is the other option which an attacker may attempt to utilize. If the account is a domain account with elevated permissions, it can be used to log into other machines and move laterally across the network. Oftentimes, the SQL server service account can be relayed to other SQL servers on the internal network to obtain additional access.

Attack Avoidance

This attack chain is preventable, however, and an attacker can be stopped in their tracks by using several different methods. The most important method is to restrict the permissions and configure the MSSQL account securely. The account should only have the permissions required to complete the necessary tasks. The account likely does not require domain administrator permissions, and is equally unlikely to need local administrator rights to other servers.

Password reuse is also a common finding during penetration tests, especially for service accounts. Many times, service accounts are “standardized” across the network. One compromised account could lead to an attacker gaining access to servers across the entire network.

The second method to preventing this attack chain is to enable SMB signing. Enabling and enforcing this configuration setting will immediately restrict the ability for an attacker to relay the hash over the network. The final protection, and perhaps the most important, is to restrict external traffic from the SQL server. If traffic is not restricted, the hash could potentially be sent anywhere, including over the internet. By restricting outbound traffic to the internal network or, even better, restricting to specific internal addresses, this technique becomes much harder to leverage, as the attacker has to have access to an in-scope system before this feature can be abused.

Takeaway

When most of us think of a “hack,” we think of some exploit in technology, or a vulnerability in software being used as the method of entry. It is important to realize that misconfigurations can be just as dangerous and are just as commonly abused as technical vulnerabilities. Outdated protocols, incorrect permissions, password reuse, lack of SMB signing, and lack of outbound traffic restrictions are great examples of misconfigurations which can lead to your network being compromised just as easily as an unpatched system.

About the Author: Scott Fingar, PNPT, eCPPT, AWS CCP is a Cybersecurity Analyst in the firm’s Business Advisory Group and a team member of the Cybersecurity and Privacy Advisory practice. Scott is a skilled infrastructure penetration tester, and has demonstrated this by attaining multiple Penetration Tester certifications. His recent experience also includes performing cybersecurity gap assessment and controls testing, helping companies understand where they stand against best practices. Scott maintains the Practical Network Penetration Tester (PNPT), Certified Professional Penetration Tester (eCPPT), and AWS Certified Cloud Practitioner certifications.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.