NOTES
Responder helps validate whether hosts rely on insecure local name-resolution behavior and whether authentication material can be coerced toward an untrusted listener.
I separate three claims: poisoning is possible, a challenge-response was captured, and relay or cracking creates additional impact. They require different evidence and should not be collapsed into one finding.
WORKFLOW
- Confirm the authorized interface, broadcast domain, testing window, and prohibited services.
- Start in analyze mode to observe name-resolution traffic without answering.
- Enable only the responders required for the approved test.
- Deduplicate captured identities and avoid repeatedly provoking the same users or systems.
- Stop once the security condition is demonstrated.
- Protect captures as sensitive credentials and follow the engagement retention plan.
COMMANDS
sudo responder -I eth0 -A
sudo responder -I eth0 -w
sudo responder -I eth0 --lm
GOTCHAS
- Built-in HTTP, SMB, DNS, DHCP, and proxy behavior can be disruptive; review configuration before enabling them.
- A NetNTLMv2 challenge-response is not an NT hash.
- Cracking difficulty does not remove the relay or credential-exposure risk.
- SMB signing, EPA, channel binding, target protocol, and privileges determine relay feasibility.
- Report the poisoned protocol and source host, not only the captured username.