In an NTLM relay attack, why does the attacker never need the account's password?
answer
- the victim does the arithmetic
- two legs, one identity
- the challenge comes from the far end
- nothing is cracked, nothing is stored
- you inherit exactly that account
basics
~20 sThe coerced host computes the proof, not the attacker. The attacker sits between that host and a chosen service, forwards every authentication message unchanged, and the service grants the session to the attacker as that identity.
solid answer
~50 sChallenge-response authentication proves possession of a secret without ever sending it. In a relay, the operator first provokes a host into authenticating outward to a machine they control - pointing a multifunction device's scan-to-share destination at themselves is a classic way. At the same moment the operator opens a session to a real service, takes the challenge that service issues, hands it to the coerced host, and passes the host's response straight back. Nothing is modified and nothing is stored; the far end verifies the response against the account's real secret and hands the session to the operator's socket. So there is no secret to crack, and a longer password changes nothing. What the operator gains is exactly the coerced account's authorisation on that one service - if that account is a scanner's domain account with write on a single share, that is the entire prize.
go deeper
Be ready to say plainly that the coerced host does the computation and the attacker only forwards messages, so no secret is learned and nothing is cracked.
Explain the two legs of the exchange and where the challenge originates, and be able to say why password strength and rotation are irrelevant to this technique.
Show that you reason about what the relay actually buys: the coerced principal's authorisation on the specific service reached, which turns the technique into a search for a coercible principal that is useful somewhere.
Own the argument that secret-centric controls - complexity, rotation, vaulting - do not touch this class at all, and that the money belongs at the services that accept the identity.
## The shape of the technique A relay has two legs and one identity. On one leg, a host is provoked into starting an authentication toward a machine the operator controls. On the other, the operator is simultaneously starting an authentication of their own toward a real service. The operator's only job is to move messages between the two legs, unaltered and in order. At the end, the real service believes it has authenticated the coerced principal, and the session it opens belongs to the operator's socket. ## Why challenge-response makes this possible A password is never transmitted in a challenge-response scheme. The server sends a random challenge; the client returns a value computed from that challenge and a key derived from the account's secret; the server recomputes the same value using its own copy of that key and compares. The design goal is that an observer learns nothing reusable. It succeeds at that goal, and it says nothing at all about *who asked for the challenge*. That is the crack the technique lives in. The operator does not need to compute anything. They need only to be the party that asked the real service for a challenge, and the party that can get a legitimate principal to answer it. The coerced host does the cryptography with key material the operator never sees. ## Coercion: making a host authenticate on cue The technique is called *coerced* relay because the operator does not wait for authentication to happen; they cause it. Anything that makes a host reach out to a named destination and offer its credentials is a route in. A shared multifunction device is a particularly clean example: it is configured with a domain account so it can write scans to a share, it will authenticate to whatever destination its configuration names, and its configuration is usually reachable by anyone on the segment. Point the scan destination at the operator's machine, press the button, and a domain principal authenticates outward on demand. The list of ways to provoke an authentication is open-ended, which matters later: any feature that accepts a path or a location and then goes and fetches it is a potential trigger. ## What you inherit, and what you do not The most common misconception is that a relay is an escalation. It is not. Authentication succeeded as a specific principal, so the operator receives exactly that principal's authorisation on exactly the service they relayed to - no more. Relay to a file server as an account with read on one share and you get read on one share. The technique's value therefore comes from two searches running at once: which principals can be coerced, and which services will accept them for something useful. This is why device accounts are interesting out of proportion to how anyone thinks about them. A scanner's account is created once, given write somewhere so scanning works, given a password that will never be rotated because rotating it breaks the scanner, and then forgotten. Nobody in the estate pictures the printer as a principal with rights. The outcome of a successful relay is an authenticated write performed as that device account, and it looks entirely ordinary at the far end because, as far as the service is concerned, it is ordinary: the credential was accepted. ## Why cracking is not part of this Candidates often answer this question by describing an offline attack on captured material. That is a different technique with different economics. Cracking requires the secret to be weak; it costs compute and time, and it fails outright against a long random password or a machine account's automatically generated one. A relay is live forwarding: it costs nothing, it completes in the time of one handshake, and password strength is irrelevant to it because the password is never a factor the operator has to defeat. A machine account with a 120-character generated password is exactly as relayable as a user with `Summer2026`. The operator does not learn the credential either. There is nothing to store, nothing to sell, nothing to reuse tomorrow - which is also why a password reset is not a remedy. The session the operator obtained is already open, and the next coercion will mint a fresh one. ## The consequence for defence Because the secret is never the obstacle, controls aimed at secrets do not apply here: complexity policies, rotation, vaulting, even a strong second factor bolted onto interactive sign-in leave the technique intact. What removes it are properties of the authentication exchange itself - whether the session that follows can be used by a party that does not hold the key, and whether the exchange states which service it was meant for. Those are the controls worth arguing about, and they live at the destination that accepts the identity, not at the host that was coerced.
- The relay completed but every write was refused. What does that tell you?That authentication and authorisation are separate. The far end accepted the credential, so the identity is genuine, but the coerced principal simply has no rights on that service. The technique never grants more than the principal already had, so the next move is to find either a principal with rights there or a service that will accept the one you can coerce.
- Why does forcing longer, randomly generated passwords not reduce this risk?Because the password is never guessed, transmitted or stored by the operator. The coerced host computes the response with the real key and the operator only forwards it. A machine account with an automatically generated 120-character password relays exactly as well as a weak human password.
- What makes a shared multifunction device an attractive host to coerce?It holds a real domain account so it can write scans to a share, it authenticates outward to whatever destination its configuration names, that configuration is often reachable without credentials, and nobody in the estate thinks of the scanner as a principal with rights anywhere.
Someone rings your doorbell asking a security question only you can answer, while standing on the phone to your bank repeating what you say. They never learn the answer; they just carry it.
saying these in an interview costs you the question
- Says the attacker must crack the captured hash first
- Claims a longer or rotated password prevents relay
- Believes the credential itself passes through the attacker
- Assumes a successful relay grants administrative rights
- Treats a machine or device account as not a real principal