Did you know that if Active Directory were a person, it would be old enough to buy alcohol? While it isn’t quite old enough to rent a car, Active Directory is twenty-four years old! If Active Directory employed the exact authentication mechanisms today as it did twenty-four years ago, I, and every other penetration tester out there, would likely be a millionaire!

Authentication is the digital door lock keeping hackers from accessing your precious secrets. Just as lockpicks and door rams can circumvent locks, hackers have built up their own store of tools to defeat authentication. Today we’ll explore how Active Directory authenticates requests, and some of the virtual “Break-N-Rake” tools hackers have at their disposal. (Full disclosure: I spent far too long looking at door-breaching tools writing this blog post.)

Before we begin, if you’re unfamiliar with how authentication occurs inside Active Directory networks, let me offer a fundamental explanation. The purpose of a client-server architecture such as Active Directory is to centrally manage access to resources. The term “resources” can denote something as simple as a printer or as critical as an Excel spreadsheet with every employee’s social security number stored on a file server. When access is requested to one of these resources, the requesting party must first prove their identity to the domain controller using one of the following methods.

Let’s kick things off with a fan favorite, NTLM. NTLM, or NT LAN Manager, is a family of authentication protocols with a rocky security history. Challenge-response NTLM authentication is trivial to understand. Upon requesting access to a resource, the server responds with a random number, which is deemed the “challenge.” Varying versions of NTLM complete the next step differently, but the overarching goal is to combine the server’s challenge with the client’s password to cryptographically prove the client’s identity.  Our two modern methods of NTLM authentication are NTLMv1 and NTLMv2, also referred to as NetNTLMv1 and NetNTLMv2, respectively. NTLMv1 is hardly considered modern, sporting its MD4-based hashing algorithm, but there’s a chance you’ll see it in the wild yet. Thankfully, by default, NTLMv1 is disabled starting with Windows Server 2016. NTLMv2, utilizing a much more robust HMAC-MD5-based hashing algorithm with additional contextual information added to the hashing process, was Microsoft’s answer to NTLMv1’s shortcomings. Listed below are the updated characteristics of NTLMv2 and what security concerns they address.

Improvements to NTLMv2

Still yet, NTLMv2 is not entirely secure. While its HMAC-MD5-based algorithm slows down attackers, it’s still relatively easy to crack with modern hardware. Resistance to Pass-the-Hash attacks is a substantial upgrade from NTLMv1, but NTLMv2 is vulnerable to a more complex lateral movement technique known as NTLM relaying.

Microsoft is currently advising its Active Directory users to switch to a more secure authentication method, Kerberos. Kerberos’s ticket-based authentication is split between several different components. The Key Distribution Center (KDC) is the central administrative authority that issues tickets; this is the domain controller in ninety-nine percent of cases. Both subcomponents of the KDC, the Authentication Service (AS) and the Ticket Granting Service (TGS), play a crucial role in Kerberos authentication. Before a client can request service access, it must prove its identity to the AS. In turn, the client is provided with a Ticket Granting Ticket (TGT)- basically a ticket to request more tickets. The client then sends its newly acquired TGT to the TGS to request a resource-specific ticket. Finally, the client sends the resource-specific ticket to the desired resource, which cryptographically verifies the validity of the provided ticket. Kerberos authentication may sound complicated, but this video from CBT Nuggets makes it simple to understand.

While Kerberos’s mutual authentication scheme, data encryption, and ticket-based authentication are clear steps up from old-school NTLM, Kerberos has its quirks. Similar to how NTLM hashes can be cracked to reveal a user’s password, there exist two methods to reverse Kerberos credentials to service account passwords. AS-REQ Roasting targets accounts that do not require Kerberos Pre-Authentication, while Kerberoasting allows already privileged users to target TGS tickets. Compromising a TGT may allow attackers to conduct stealthy Silver Ticket attacks where they may enumerate access rights associated with a TGT. Most terrifying of all, the Golden Ticket attack consists of compromising the internal KDC secrets. While this attack is easier to detect than Silver Ticket attacks, the consequences are devastating to an Active Directory environment.

For the last authentication protocol of this blog post, we have Lightweight Directory Access Protocol (LDAP). LDAP authentication is unique because it allows endpoints other than Windows to communicate with Active Directory. Linux and MacOS devices will natively communicate with Active Directory with LDAP integration. While LDAP is known to be secure with proper configuration, its primary use isn’t to compromise the domain but to enumerate it. Attackers utilize tools such as BloodHound to request large volumes of LDAP queries. These queries map permissions and resources throughout a domain, allowing attackers to quickly move horizontally and vertically throughout a network. Worse yet, these queries may be conducted over encrypted LDAP channels (LDAPS), making detection more difficult.

It’s commonly said that the more functionality an application offers, the more attack surface it presents. Active Directory is undoubtedly not an exception to this rule. While Active Directory is necessary for enterprise organizations that can’t migrate to cloud solutions (Entra ID), it must be administered and maintained by security professionals to avoid leaving an opening for attackers.

Leave a Reply

Your email address will not be published. Required fields are marked *