A coworker asked me why I thought encrypting internal AD Bind communication was important. I said because I follow a standard security practice, but couldn't actually articulate how an attacker would grab the credentials over the wire. Would an attacker have to own a piece of our networking equipment or is there an easier way to listen?

  • 1
    Another argument would be that building defense in depth will make your infrastructure as a whole more resistant. In such context, encrypting all communication that can reasonably be encrypted will make it harder to attack an unknown or unpatched flaw.
    – Stephane
    Nov 22 '13 at 10:48

ARP poisoning and IP spoofing are one way to do this with nothing more than a node on the network.

In general, what you end up doing is impersonating the AD server during negotiation. The technical details probably aren't interesting in this context, but if you pretend to be the AD server, you can do a lot of things.

One of these things might be to pretend to support only NTLM authentication, and thereby invoke a very weak protocol which involves passing a very weak hash that you can crack in a few hours on your laptop, and thereby recover passwords.

You may also be able to exploit a weakness in Kerberos if you happen to have one, as bind authentication can be done using that as well. The other authentication method you could force would be digest-md5, which is stronger than NTLM, but not by too much.

If you're really good, you can then pass the authentication through to the real AD server, and proceed to proxy (MitM) all the communication between the client and the server for as long as you can keep up the spoof. Nobody will notice much. However, Kerberos makes this hard.

So, the long and short of it is, the attacker doing this could possibly recover password hashes, and has the ability to influence them to be very weak. This can compromise passwords.

The attacker might also be able to sniff (kerberos) authentication happening, though this is harder in switched network segments, and basically impossible with 802.1x.

Kerberos in particular makes this kind of thing fairly hard to accomplish. For instance, the password is only used to generate a key that is shared between the server and workstation (the server retains the key, changing it only when the password changes), so there isn't really a password to crack. This key is used to secure communications. However, the key is symmetric and an attacker could theoretically sniff any of the kerberos data that transits the network, find the key for it, and then find a password that generates this key (honestly though the key is usually enough). This is hard. Microsoft has an article including exact details of how all this works, including Kerberos.

If, however, you are binding to AD as though it were LDAP and doing things like resetting passwords or authenticating using the plain method, you should definitely provide an SSL certificate and encrypt your traffic.


ARP spoof to obtain the credentials passing over the network, then pass the hash.

Arpspoofing is a way to intercept traffic by attacking layer 2 of the OSI model. In this example, the attacker would send arp responses to the target host with the same IP of the default gateway but a different MAC address which is owned by the attacker. This causes the target host to believe the default gateway resides at the MAC provided by the attacker and not the true MAC of the default gateway. At this point the attacker wins and is able to proxy traffic. With full access to network traffic the attacker can extract necessary information to carry out attacks such as pass the hash.

In this example, additional equipment is unnecessary though the attacker must already have a presence on the network. This could be insider threat or an already compromised host.

There are mitigations for this in modern (and intelligent) network equipment. Such that one can control which MACs are allowed to communicate and on what physical ports. Thus if one tries to spoof a MAC the traffic won’t get past the switch.

@Stephane has a great point regarding defense in depth. While encrypting traffic will mitigate a number of threats, it also makes you "blind" on the network as traffic will silently pass by intrusion detection systems. Uninspected. Implementing a control such as network encryption really depends on your unique circumstance.


Well, it really depends on what you mean by local AD traffic. If you mean that it is on your server machine only, you are pretty much done for if it is compromised anyway, so encrypting stored Username/Password data would only be marginally useful - if you had strong, separately encrypted usernames and passwords, encrypting them could make it very difficult to practically put them to use, assuming you promptly discover that your server has been compromised. If you mean local as in only within your network, the most likely options for an attacker are MITM, and then either a dictionary attack or a pass the hash. Because a previous answerer actually got marked down for saying this, I will go into detail as to what they are.

MITM - This is basically where an attacker tells your router he is you and you he is your router. So he ends up sending you his information (in this case, username and password) and you copy it and pass it on to the router. APR stands for Advanced Poison Routing, and is basically a fancy version of MITM

Pass the Hash - An attack in which you either sniff a (hashed) password or capture it by some other means. What many servers do is they "tell" your machine to hash the password locally. By "telling" your computer to send the hash without hashing it again you can make it appear that you entered a valid username/password and it was hashed and sent on its way.

Dictionary Attack - Your computer runs through a list of words, hashing each one until it finds one that hashes out so that is identical to a previously captured hash (really the only viable way of converting a decent hash back into plaintext)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.