Theory — LLMNR poisoning
When a computer cannot resolve a name on the network (a typo, a non-existent server), Windows asks the whole network via /NBT-NS: «does anyone know this name?». The attacker answers: «yes, me» — and the victim sends them their authentication.
This is where relay comes in: instead of cracking the hash (which can take time), the attacker forwards the authentication in real time to another service — a file server, the DC's , or the HTTP interface (that is ESC8). The service receives a perfectly valid authentication — belonging to someone else.
The main defender is signing: and Signing/Channel Binding require the authentication to arrive directly from the source — relay breaks the signature and the service rejects the connection.
Practice — lab only
Detection
- Event ID 4624 type 3 (network logon) from computers with no reason to connect to the target — relay produces an «odd» logon.
- /NBT-NS answers from a single address for many different names — the signature of .
- /SMB connections to the DC itself from computers that are not DCs/servers.
- Defender for Identity detects relay and poisoning — enable the alerts.
Mitigation
- Disable and NBT-NS across the organization (: Computer Configuration → Administrative Templates → Network → DNS Client → Turn off multicast name resolution).
- Enforce on all servers and workstations (: Microsoft network server/client: Digitally sign communications → Always).
- Enforce Signing and Channel Binding on the domain controllers.
- Enable on the HTTP interfaces (blocks ESC8).
- Put sensitive accounts in Protected Users — is blocked there entirely.
- Make sure users do not have broad local admin rights — an SMB relay is worth exactly as much as the victim is worth.