Abusing Unsafe Defaults in Active Directory Domain Services: A Real-World Case Study

This past July, Kevin Robertson from NetSPI released a blog post entitled, “Beyond LLMNR/NBNS Spoofing – Exploiting Active Directory-Integrated DNS,” which introduced a new technique (to us at least) targeting weak default access control in Active Directory Domain Services. At GoSecure, since most of our engagements require some level of Active Directory security assessment, we followed our interest and decided to find a way to reliably exploit it.

Our blog post details a software bug in the Antidote suite, which causes the software to continuously try to reach a network file share on the local domain using a known subdomain name. This software, used as a self-learning spellchecker, is popular and commonly used in most companies conducting business in French, meaning we often assess environments where this software is heavily deployed. Attackers are able to abuse the weak default access control on the Active Directory Domain Services to register this known subdomain, and making the record point to their machine. By doing so, every time Antidote is fired up, the process attempts to reach the network file share on that subdomain, thereby forcing the operating system to authenticate against that machine, which then points to the attacker’s machine. A constant stream of authentication attempts coming from all users with Antidote installed are then received by the malicious actor, who would then be allowed to perform NTLM relaying attacks or crack the received hashes.Using the details in this research meant the intrusion testers could reliably obtain and relay authentication hashes for most employees of an organization in a passive, non-intrusive, and timely manner.

Technical Details

The NetSPI post explained how, by default, all members of the “Domain User” group are able to create arbitrary DNS records under the main zone of the Domain Services. Since we had been recommending that our clients disable LLMNR and NetBIOS name resolution in their environments for years, we took particular interest in this blog post, given that its content could potentially allow us to go beyond Local Area Network name spoofing.

For the rest of this blog post, we will use the fictive Active Directory Domain company.int .

The Antidote Bug

The bug is related to the naive way Antidote handles the version checking for its plugins. It creates an unintended side effect that forces Windows to access the \\PLUG-INS.company.int\Antidote network share. Later we detail how this bug was introduced in the software, but first, look at how the bug can be misused for nefarious purposes. The bug, present in default configuration installations, is caused by a faulty string concatenation where a null string is appended to a subfolder. This ends up forcing the software to query a file path with a null prefix, resulting in a path with a leading backslash ( \ ). Because of this, Windows presumes that the process is looking to load a UNC path (which follows the \\server\folder\file URI scheme). This has the direct effect of looking up the PLUG-INS name and browsing it as if it were a network file share. Under Windows, the default process of name resolution can be resumed to the following steps:

Perform DNS Query

In the case of a machine that is joined to a Domain, a single-item query (meaning without a TLD) will be queried under the main domain zone. In this case, since the operating system queries for PLUG-INS , the DNS query will be for PLUG-INS.company.int . Most likely, this record does not exist in the Active Directory environment, so we move on to the next step; Perform NetBIOS Query

Local Area Network query targeting the neighboring hosts. If an attacker is in the same broadcast domain, they will see this request and be able to reply for it — aka spoofing the response; Perform LLMNR Query

Another protocol which will ask neighboring hosts on the Local Area Network for an answer. This type of response can also be spoofed by hosts in the same broadcast domain.

Why is this information pertinent in any way? When trying to read from a UNC path, Windows will perform an NTLM handshake with the target, meaning a challenge-response will be performed between the requesting machine and its target. As an attacker, if we are able to have machines in the domain perform authentication attempts against our machine, it allows us to intercept the authentication attempt, and potentially abuse it in order to either obtain their cleartext credentials or to relay the authentication to a 3rd machine.

Abusing the authentication process is not difficult, and is outside the scope of this blog post. Once a remote machine tries to authenticate against our machine, we are able to use tools like Hashcat or John The Ripper in order to obtain the cleartext representation of the victim’s password. Should that technique fail, either because the password complexity is too strong, or because you don’t have a fancy cracking rig, attackers can still perform NTLM relaying. With NTLM relay, we use the hash we capture from the NTLM challenge-response and relay it instantly to a 3rd machine under the same domain (or forest with appropriate trusts). Relaying allows the attacker to authenticate against any service in that domain, under the context of the victim. This can be used to access sensitive information, like the victim’s emails, file servers, and sometimes even remote code execution if the victim has Local Administrator rights on the machine an attacker is relaying against.

Now that we detailed how name resolution works and why it would be interesting from an attacker’s perspective to have machines authenticate against ours, we show that when put together these can be leveraged to exploit the Domain Services access control weakness. We know that most user machines in the domain will be querying for the PLUG-INS.company.int record, therefore we need to register this record and make it point to our machine. This can be done using Kevin Robertson’s technique, allowing all domain users to create DNS records under the main zone. Since Microsoft’s Domain Services’ default configuration for “Create all child objects” is set to “Allow” for the group “Authenticated Users”, all authenticated users can create new records freely. Using the Powermad project, it is then possible to create a record called PLUG-INS that would point to our attacker machine. This would mean that all machines with Antidote installed would constantly try to authenticate against our machine, as such:

Before creating the record, let’s confirm that PLUG-INS.company.int does not exist. We can check this with the nslookup utility:



Next, we’re going to create the PLUG-INS record:



To confirm the record was created properly, we can use nslookup again:

From this point on, all machines running Antidote will constantly try to authenticate against our attacker machine on 172.24.0.5 , allowing us to crack the hash or relay the authentication.

To demonstrate the reliability of this scenario, we used this technique on one of our clients, where approximately 90 provisioned endpoints were running Antidote. We registered the PLUG-INS record and made it point to one of our machines where Responder was running in analyze mode . In analyze mode Responder does not perform any spoofing, it simply listens for inbound connections and saves the hash. We plotted the results, showing how easy it is for an attacker to passively collect hashes from all domain users over time.

After creating the record, at around noon, we can see a steady and linear amount of collected password hashes. The multiple black X marks represent the time of day we obtained hashes for high-profile accounts (1 account member of the Domain Admins group, 2 members of an OU with access to sensitive information).

Underlying Issue in Antidote