NTLM relay
In internal network attacks, NTLM relay is a technique where an attacker forwards a victim’s authentication attempt to a third system instead of cracking it, and is accepted there as the victim. Nothing is decrypted and no password is recovered: the authentication is genuine, and it is simply used against a destination the victim never chose.
How it works
NTLM is the challenge and response protocol that predates Kerberos and is still enabled almost everywhere. The server issues a challenge, the client returns a response computed from the password hash, and the server verifies it with the domain controller. Nothing is recovered, so this is not pass-the-hash: the hash is never in the attacker’s possession. Nothing in that exchange binds the response to the server that issued the challenge, so an attacker positioned between the two can pass the challenge through from a different destination and pass the response back, authenticating to that destination as the victim.
Getting the victim to authenticate is the easy part. Broadcast name resolution protocols answer for names that do not exist, so an attacker on the same segment can claim to be any mistyped share. Various Windows features can be induced to make a host authenticate to an address of the attacker’s choosing. Public tooling, principally Responder and the relaying utilities in Impacket, implements all of this.
What goes wrong
The countermeasures are configuration, they are well documented, and they are absent in most estates we test. Signing on the SMB protocol prevents relaying to file services and is not required by default everywhere. Channel binding and extended protection prevent relaying to services over TLS such as directory services and web enrolment endpoints. Both are switches, and both break something old, which is why they are still off.
The high-value destination in a modern estate is the certificate service. Relaying a machine or user authentication into a web enrolment endpoint and obtaining a certificate for that identity converts a transient authentication into a durable credential that survives a password reset, which is where this meets certificate services abuse. Disabling the legacy protocol altogether is the real fix, and it is a project rather than a setting, because inventorying what still depends on it is the hard part.
Where this shows up in an audit
We report it as a chain with the destination named, since relaying to a workstation and relaying to a directory service are different findings. The evidence is the captured authentication, the destination reached, the identity we were accepted as and what that identity could do, along with the signing and channel binding state of the affected services, because that is the configuration table the client will work from. It is one of the most reliable routes from a network cable to domain privilege, and it needs no missing patch, which is why it belongs in how we test Windows network authentication in an internal engagement.