Home Blue Team NTLM is (finally) Dying

NTLM is (finally) Dying.

June 6, 2024

A few days ago Microsoft formally announced the deprecation of NTLM, so as of June 2024 it will no longer be developed. It’s been a long time coming, but we got our first glimmer of hope in October 2023, when Steve Syfhus and Zak Whittington gave a BlueHat talk announcing the roadmap for deprecation and ultimately removal of the archaic authentication protocol that’s been around since 1993 when it was released in NT 3.1. Microsoft also published an accompanying blog, which we’ll provide the highlights of shortly.

Whilst this is a big, positive and much needed step for security, tears of sadness will be shed across the globe by both IT teams managing huge estates of apps that hardcode NTLM, as well as offensive security teams who no longer have their “easy win” button, otherwise known as responder and can no longer pass-the-hash with psexec.

So what’s going to happen? Let’s have a look at the details that came from the BlueHat talk.

Why is it being phased out?

It’s been with us since NT 3.1 so that in itself should be a sign. It’s also based on the extremely cryptographically weak MD4 hashing algorithm and doesn’t require server authentication, so it’ll talk to untrusted servers and there allow attacks like pass-the-hash and relaying.

What’s the new and shiny replacement?

At it’s core, Kerberos! So nothing new and shiny in that respect. But NTLM doesn’t require direct access/line of sight of a Key Distribution Centre (KDC) whereas Kerberos does, so as Kerberos is replacing NTLM, Microsoft need to account for all the Windows hosts out there that don’t have line of sight of a domain controller, as well as ensuring local user accounts are covered too.

These two requirements are being addressed in IAKerb for domain accounts and local KDC for local accounts. They’re being implemented as sub-protocols of the SPNEGO (negotiate) protocol which already exists in all modern Windows operating systems.

IAKerb

IAKerb will allow clients without line of sight of a DC to authenticate via a target server that does have it. At it’s core, standard Kerberos authentication is still used within, but IAKerb will effectively “proxy” or “pass through” the Kerberos authentication process via the target server (e.g. application server, SQL server etc). Think of it as the target server playing man-in-the-middle between you and the DC, but just blindly forwarding the messages back and forth until authentication is complete and you (the client) is able to present your service ticket to the target server.

The image below is sourced directly from the BlueHat talk mentioned earlier.

Local KDC

The local KDC will be built on the existing SAM and will, leveraging IAKerb as it’s transport mechanism, allow for remote Kerberos authentication to happen using local accounts without having to worry about things like DNS. The Local KDC will also use AES by default (happy tears – no more RC4!).

The below image again taken directly from the BlueHat talk.

If these will be in SPNEGO, how is that changing?

SPNEGO has been around for ages and already tries to negotiate Kerberos and falls back to NTLM. Microsoft are simply adding IAKerb in the middle, so the authentication flow will become:

  • Kerberos, falling back to
  • IAKerb, falling back to
  • NTLM

What do I need to do?

If you’re currently using SPNEGO (already advised my Microsoft) then everything should just work when they upgrade as SPNEGO will hit IAKerb before NTLM. Business as usual.

Microsoft are of course aware that there’ll be plenty of apps/services that hardcode NTLM. They recommend that this be changed to negotiate wherever possible:

  • Look for calls to the AcquireCredentialsHandle function and replace “ntlm” with “negotiate”
  • Look for calls to the RpcBindingSetAuthInfo function and replace RPC_C_AUTHN_DEFAULT with RPC_C_AUTHN_GSS_NEGOTIATE

For non-Windows authentication stacks, NTLM is still being preserved for now, but this WILL be a problem eventually as NTLM will ultimately be completely removed, meaning other systems will need to be able to talk/operate with IAKerb and local KDC.

Above and beyond the above recommendations Microsoft advise that you start to audit NTLM usage in your environments to get a head start.

How long do I have?

As Microsoft have announced that NTLM will continue to work on the “next release of Windows Server and the next annual release of Windows”, this means it should continue to work on Windows 11 24H2 and Server 2025.

Whilst it’s on life support, I’d like to say to NTLM, on behalf of all security testers, thanks not just for the hashes, but for letting me throw and relay around networks! We’ve had fun.