Context

This presentation stems from two research papers that were published by the speaker at the beginning of 2025:
- « Abusing multicast poisoning for pre-authenticated Kerberos relay over HTTP with Responder and krbrelayx » (link)
- « Taking the relaying capabilities of multicast poisoning to the next level: tricking Windows SMB clients into falling back to WebDav » (link)

The techniques introduced in both these papers describe new ways to perform authentication relaying through local name resolution poisoning. They also reinforce each other and can be exploited jointly, making it interesting to showcase them together in a single presentation.

During the presentation, emphasis will be placed on the concrete exploitability of the described techniques ; as a result, several live demonstrations will be included using Responder and krbrelayx (pull requests were submitted to both tools following the aforementioned research, and merged into the main branches).

Here follows an overview of the presentation plan.

1. Relaying is always better in HTTP: tricking Windows SMB clients into falling back to WebDav

a. Standard name resolution poisoning and the SMB authentication blues

This first section will provide some context and reminders regarding local name resolution poisoning attacks. The basic principles of said attacks will be clarified:
- Victim computers or users on a local network may fail to resolve names using DNS (due to typos or automated tasks trying to reach non-existing resources).
- An attacker opportunistically sends responses using the LLMNR, mDNS or NBNS protocols to the victims in order to redirect them to a machine under the attacker’s control.
- The attacker asks for authentication on a variety of services and captures NTLMv2 encrypted challenges.

The standard way to exploit this attack primitive will then be presented. Traditionally, capturing NTLM authentication data can be used for one of two things :
- Attempt to crack the NTLMv2 encrypted challenge in order to retrieve the cleartext password.
- Perform NTLM relaying attacks in order to interact with a target service on the network as the relayed target.

Limitations related to this approach will then be highlighted. More specifically, cracking NTLMv2 hashes only makes sense for user accounts, as machine accounts generally have a long, random password that cannot be bruteforced. When it comes to authentication relaying, the possibilities are limited by the client that was tricked into authenticating to the attacker.

[TABLE OF NTLM RELAYING POSSIBILITIES DEPENDING ON CLIENT AND SERVICE]

It will then be mentioned that, in many cases, within an internal network, authentication from SMB clients will be captured while performing local name resolution poisoning (due to the prevalence of the SMB protocol in Windows environments). This kind of authentication is rather limited from a relaying standpoint – in a nutshell, the Windows SMB client supports integrity checking mechanisms such as signing. As a result, services that enable signing when the client supports it will implement integrity checks after the SMB client authenticates – making the relay attack fail. This is most notably the case of the sensitive LDAP service by default. Consequently, for instance, SMB to LDAP relaying cannot be performed.

b. Rocking with HTTP authentication

This section will present to what extent HTTP authentications are more interesting from an attacker standpoint when performing local name resolution poisoning. More specifically, when performing plain NTLM authentication, Windows HTTP clients will generally not support signing. This means that services such as LDAP will not perform such integrity checks, making NTLM relaying from HTTP to the sensitive LDAP service succeed.

Although more interesting, it will be noted that HTTP authentications are less common / rarer to come across when performing local name resolution poisoning attacks.

What if there was a way to trick Windows SMB clients into falling back to the WebDav HTTP client when the latter is available, thus turning what would be SMB authentications into HTTP ones? This would make local name resolution poisoning a much more efficient authentication relaying vector.

c. Turning SMB into HTTP with a simple error code

After having explained, in the two previous sections, the interest in turning SMB authentications into HTTP ones, this section presents the simple – yet potentially powerful trick discovered in early 2025.

When a computer has the WebDav client enabled and running, the Windows SMB client can actually fall back to it in certain cases if presented with specific error codes:
- STATUS_LOGON_FAILURE (0xc000006d)
- STATUS_BAD_NETWORK_NAME (0xc00000cc)

Up until now, local name resolution poisoning tools (such as Responder) returned a STATUS_ACCESS_DENIED error code after client authentication, which does not trigger the fallback.

As a result, an attacker could attempt to trick a Windows SMB client that it poisoned through local name resolution to fall back to WebDav, and thus turn an SMB authentication into an HTTP one, allowing it to be relayed to LDAP for instance. If the authenticated account is a machine account, a shadow credentials or RBCD attack could be performed to fully compromise the machine.

A demonstration will be performed at this point of the presentation, using Responder, impacket’s SMB server and ntlmrelayx to perform WebDav fallback and compromise a machine account from an SMB connection.

In order to transition to the next part, it will be noticed that although this trick offers interesting opportunities for NTLM relaying, it can also be used in the context of Kerberos relaying. The next part will explain how Kerberos relaying can be performed through local name resolution poisoning.

2. Local name resolution poisoning living with its time: Kerberos relaying shenanigans

a. A little refresher on Kerberos relaying, and how to do it via local name resolution poisoning

This first section will provide some generic reminders regarding Kerberos relaying, which relies on the ability to make a victim fetch a service ticket for an arbitrary service, and send it to the attacker instead of said service. The attacker can then extract the AP-REQ message and relay it to the service.

Up until early 2025, two main implementations of Kerberos relaying attack vectors were available to pentesters :
- 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 service ticket. Several implementations exist, and Hugo Vincent integrated it into krbrelayx.

The research published by James Forshaw on Kerberos relaying in 2021 mentioned another Kerberos relaying vector relying on local name resolution poisoning that was not, until early 2025, implemented in Active Directory offensive tooling.

In a nutshell, this alternate vector takes advantage of the way HTTP clients (browsers, .NET clients, WebDav clients) use the answer name of the name resolution response to determine the SPN for which a service ticket should be retrieved, before submitting the ticket to the IP address associated with the answer. Kerberos relaying can thus be achieved by poisoning LLMNR to construct a name resolution response with the relay target as the answer name, and a record pointing to the attacker machine. As a result, the HTTP client would ask for a service ticket for the relay target, construct an AP-REQ, but send it to the attacker machine which can then relay it.

We implemented the attack into Responder and krbrelayx early 2025. Pull requests were merged shortly after.

b. A demonstration using Responder and krbrelayx

This section will showcase a demonstration of Kerberos relaying performed via local name resolution poisoning in order to relay authentication data to an ADCS Web Enrollment service, or an SMB service.

c. Pros and cons of local name resolution Kerberos relaying

This section will handle the advantages and limitations of Kerberos relaying through local name resolution poisoning.

Kerberos relaying is particularily useful if:
- Outgoing NTLM authentication is prevented on the relaying victim.
- The relaying target does not implement NTLM authentication (e.g. hardened ADCS Web Enrollment endpoints).

It also has some limitations:
- Relaying targets are more limited than with NTLM (relaying to LDAP will not work due to the use of the SPNEGO protocol).
- The attack relies on LLMNR (and it does not seem to be possible to implement it via NBNS or mDNS).

The last limitation is that the behaviour on which the Kerberos relaying attack relies (the victim takes the name resolution response as the SPN for which a service ticket is retrieved) only works with Windows HTTP clients – Windows SMB clients will simply take the SMB URI as the SPN for which a service ticket should be fetched.

This is where the WebDav fallback trick previously described comes into play, and could allow overcoming this last limitation.

3. Now this is local name resolution poisoning! Exploiting WebDav fallback to perform Kerberos relaying

We previously mentioned that the WebDav fallback trick does not only have implications for NTLM relaying, but also for Kerberos relaying. The reason should now be clear: making the WebDav client authenticate instead of the SMB client opens the door to Kerberos relaying since an HTTP client is now authenticating.

A last demonstration will be performed, showcasing how to force an SMB client to fall back to WebDav in order to perform Kerberos relaying to an ADCS Web Enrollment service.