Chris Campbell Nov 3, 2023 7:00:00 AM 11 min read

NTLM Hardening

To support Inde customers throughout 2023's Cyber Smart Week we will be publishing a blog post each day that details a category of mitigation that you can implement to harden yourself against popular adversary techniques. These blogs are to help technical managers and practitioners get a better grasp on how to manage security risks within their business. Our selection is based upon our practical experience in responding to incidents, researching threat actors and adversary simulation engagements.
Today we'll discuss NTLM Hardening.
What is NTLM?

New Technology LAN Manager (NTLM) is a suite of security protocols used within Active Directory (AD) environments to authenticate users and protect the integrity and confidentiality of their activity. This is done using a challenge-response protocol that allows for confirmation of a user without requiring submission of their password. At its core, this consists of six steps:

1 - A user requests access to a resource by sending their username.
2 - The server generates a 16-byte challenge and sends it to the client.
3 - The client encrypts the challenge with a hash of their password and responds with it.
4 - The server forwards the user information, challenge, and response to the domain controller.
5 - The domain controller compares the encrypted challenge with the client’s response, and the server is notified of the result.
6 - The server sends the appropriate response back to the client.
How is it Abused?

While NTLM has been superseded by the more robust Kerberos authentication protocol since Windows 2000, it is still widely used either to support legacy requirements or as a hangover of domain upgrades. Aside from cryptographic weaknesses which make them practical to crack offline, numerous vectors exist to coerce NTLM hashes from across the network to relay against other hosts. Providing authentication is successful, and SMB signing is not required, this can be used to execute commands in the context of the user to which the hash belongs or carry out tasks such as exploiting weak certificate templates or dumping LSA and SAM secrets. The most common techniques used to coerce hashes are:

  • Poisoning: Link Local Multicast Name Resolution (LLMNR), NetBIOS Name Resolution (NBT-NS) and Multicast DNS (mDNS) are all protocols that are used to resolve hostnames to IPs without the need for DNS. They do this via multicast packets which are sent across the network that ask network interfaces to reply if they're known by the name in a request. For example, this may be used when attempting a connection to a host that there is no associated DNS record for. Tools such as Responder exploit this by spoofing an authoritative response to these requests, forcing poisoned clients to authenticate against a rogue server.

    NTLM blog image

MDNS poisoning leading to capture of an NTLMv2 hash via WebDAV.

NTLM blog image 2

NTLM connection being relayed to a list of target servers that do not require SMB signing.

  • Vulnerabilities: Specific endpoint configurations or bugs in services and protocols may introduce vulnerabilities that can be exploited to coerce an authentication request. Often, these are exposed as an RPC interface and may be remotely triggered. Examples include PetitPotam, ShadowCoerce, SpoolSample and DFSCoerce (seen below).

NTLM blog image 3Request sent to a Domain Controller using the credentials of a low-privilege user.

NTLM blog image 4Domain Controller account hash captured.

Hardening

Due to the constantly evolving nature of techniques that rely upon the coercion or replay of NTLM hashes, hardening against this class of attacks is essential:

  • Enable SMB signing, LDAP signing and UNC hardening.
  • Disable SMBv1, LLMNR and NBT-NS.
  • Do not permit WDigest credential storage.
  • Require NTLMv2 responses, and refuse LM and NTLMv1. See recent guidance here.
  • Reduce NTLM usage. Consider disabling it on domain controllers, web servers and certificate servers. If NTLM cannot be disabled, enable Extended Protection for Authentication. You can follow Microsoft guidance to enable EPA and disable NTLM for ADCS web services, and this same guidance applies elsewhere too.
  • Review certificate templates to ensure permissions are tight and certificates cannot be issued by those not authorised to do so.
  • Leverage the Windows Firewall to permit inbound traffic to only the required services. Pay particular attention to SMB, NetBIOS, RPC, WinRM, RDP – it’s rare for workstations and most servers to have a genuine requirement for all of these to be made available.
  • Deploy patches to workstations and domain controllers as soon as they're made available.
  • Ensure all endpoints are onboarded to CrowdStrike or Defender for Endpoint, and that network protections are set to Block.

It goes without saying that hardening NTLM is fraught with complexity and must be preceded with auditing NTLM usage. If hosts or services are not adequately prepared to support the enforcement of NTLMv2 or Kerberos, then disabling NTLMv1 will break authentication.

Further Reading
About the author

Chris Campbell

 Chris was that notoriously disobedient kid who sat at the back of the class and always seemed bored, but somehow still managed to ace all of his exams. Obsessed with the finer details and mechanics of everything in both the physical and digital realms, Chris serves as the Security Architect within the Inde Security Team. His ventures into computer security began at an early age and haven't slowed down since. After a decade spent across security and operations, and evenings spent diving into the depths of malware and operating systems, he brings a wealth of knowledge to Inde along with a uniquely adversary focused approach to defence. Like many others at Inde, Chris likes to unwind by hitting the bike trails or pretending to be a BBQ pitmaster.

COMMENTS