Look, a rainbow

As beautiful as a rainbow may be as a natural spectacle, it has nothing to do with Google’s announcement of the release of rainbow tables. Rainbow tables are an effective means of decrypting NTLMv1 passwords within minutes using standard hardware, thereby gaining control of the account in question. If this happens to a highly privileged account, such as the domain controller’s computer account, any other account can be compromised without being noticed.

All of this was already discovered in the late 1990s, and common hardening recommendations (such as those from Microsoft or CIS) have been urging the deactivation of NTLMv1 for years. However, the publication of rainbow tables has significantly increased the pressure to act.

Specifically, the following measures should be taken in the short term:

1. 1. 1. Disable LM/NTLMv1 via group policy
      2. Monitor domain controller logs for the use of LM or NTLMv1 and issue appropriate alerts

NTLM, the second

As far as NTLMv1 is concerned, that’s the end of the story. However, glaring vulnerabilities have also been discovered over the years in the successor version NTLMv2, which was introduced back in 1998. In the meantime, the outdated HMAC-MD5 encryption in particular has become an easy hurdle for attackers to overcome. NTLM is a challenge/response procedure and is therefore, by design, vulnerable to pass-the-hash, NTLM relaying, and offline cracking.

The alternative to NTLM* is called Kerberos and has been integrated into Active Directory since 2000. The most important difference to NTLM is the integration of a Key Distribution Center (KDC) service on the domain controllers. Kerberos works with tickets and requires mutual authentication. Parallel support for different encryption types (cipher suites) allows the use of the highest possible encryption level (currently AES-256) while maintaining defined backward compatibility.

Kerberos has therefore been the standard in Active Directory for years.

* Another alternative to NTLM is OAuth. However, this modern method is based on web tokens and therefore plays only a minor role for Active Directory-integrated services.

So let’s get rid of NTLM quickly, right?

Thanks to Kerberos, the way is basically clear to completely disable NTLM. And TEAL recommends consistently pursuing this goal.

Unfortunately, however, especially in historically grown environments, there are often a significant number of use cases or products where NTLM is unavoidable or Kerberos simply cannot be used due to technical dependencies. The fallback to NTLM can therefore be much more frequent than expected and cause unforeseen problems if NTLM is switched off prematurely.

A prerequisite for Kerberos is the trust relationship between the systems involved:

• • the system on which authentication was initiated
  • the domain controller
  • the target system

For members (i.e., Windows systems) of a domain, this trust relationship is generally established.

In addition, Kerberos requires name resolution (DNS) that functions at all times and the use of the fully qualified domain name (FQDN) of the target system. For example, the use of Netbios names or IP addresses in RDP connections causes a fallback to NTLM.

It is also important that all systems involved are running on the same clock. A time difference of more than 3 minutes can already lead to errors in the authentication process. Therefore, the DCs ideally serve as the source for synchronizing the time signal.

We therefore recommend disabling NTLM according to the following rough schedule:

1. 1. 1. Ensuring Kerberos requirements are met on all relevant systems
      2. Monitoring NTLM authentication processes using consolidated event logs
      3. Identifying and resolving relevant use cases and services
      4. Testing and piloting
      5. Complete shutdown of NTLM