IPv6 DNS Takeover & LDAP Relaying (mitm6)

What is

mitm6 is a tool that abuses IPv6 network configuration mechanisms to position an attacker-controlled machine as the DNS server for Windows clients.

This can be particularly interesting in Active Directory environments where IPv6 is enabled but is not properly managed. Windows hosts may prefer IPv6 configuration obtained through DHCPv6 over the existing IPv4 configuration.

When a Windows client subsequently performs an NTLM authentication, the authentication can potentially be relayed to another service instead of being directly captured and cracked.

In this scenario, we combine mitm6 with ntlmrelayx from Impacket to relay NTLM authentication to an Active Directory Domain Controller over LDAPS.

The general flow is:

Windows Client
     |
     | DHCPv6 / DNS configuration
     v
  mitm6
     |
     | NTLM authentication
     v
ntlmrelayx
     |
     | LDAPS
     v
Domain Controller

The important difference compared with traditional LLMNR poisoning is that mitm6 abuses IPv6 network configuration and DNS rather than relying exclusively on LLMNR/NBT-NS name-resolution requests.

Requirements

For this technique to work in a controlled lab, the following conditions should be verified beforehand:

IPv6 is enabled on the Windows clients.
The attacking machine and the Windows clients are on the same network segment.
The Domain Controller provides LDAP over TLS/LDAPS.
The attacker can reach the Domain Controller’s LDAPS service.
The relayed account has permissions that allow the intended LDAP operation.
NTLM authentication is available from the Windows client.

It is also important to understand that successful NTLM relay does not automatically mean that arbitrary Active Directory modifications are possible. The permissions of the relayed account and the specific LDAP operation determine the resulting impact.

How to

Summary

The basic workflow is:

Start mitm6

Start mitm6 on the interface connected to the network.

sudo mitm6 -d <domain>

Start ntlmrelayx

In a second terminal, start ntlmrelayx and configure it to relay incoming NTLM authentication to the Domain Controller’s LDAPS service.

impacket-ntlmrelayx -6 -t ldaps://<DC_IP> -smb2support

Trigger authentication

Wait for a Windows client to perform an action that causes it to authenticate using NTLM.

The important part is that the authentication must reach ntlmrelayx and be accepted by the LDAPS target.

Verify the relay

If the relay succeeds, ntlmrelayx will report the incoming authentication and the LDAP connection to the target.

Detailed

1. Start mitm6

The first step is to start mitm6.

sudo mitm6 -d marvel.local

The -d parameter specifies the Active Directory DNS domain.

The tool will listen for IPv6 configuration traffic and attempt to make Windows clients use the attacker’s machine as their DNS server.

A simplified example of the output is:

mitm6
[*] Starting mitm6
[*] IPv6 address: ...
[*] DNS server: ...

At this point, we should leave mitm6 running.

2. Configure ntlmrelayx

In another terminal, start ntlmrelayx.

impacket-ntlmrelayx -6 -t ldaps://<DC_IP> -smb2support

The important parameters are:

-6 enables IPv6 support.
-t specifies the relay target.
ldaps:// specifies that the LDAP connection must use TLS.
-smb2support enables SMB2 support for incoming SMB connections.

For example:

impacket-ntlmrelayx -6 -t ldaps://172.16.14.10 -smb2support

The target should be the Domain Controller providing LDAPS.

Before starting the attack, it is useful to verify that LDAPS is actually available on the target:

nmap -p 636 <DC_IP>

A successful result should show port 636 as open.

3. Wait for an authentication

Once both tools are running, a Windows client that has received the attacker’s IPv6 DNS configuration may generate authentication traffic.

The authentication is received by ntlmrelayx, which then attempts to authenticate to the configured LDAPS target.

A successful relay will produce output indicating that an NTLM authentication was received and successfully relayed.

The exact output varies depending on the Impacket version and the LDAP operation being performed.

A simplified example is:

[*] (LDAP): Received connection from ...
[*] Authenticating connection from MARVEL/user@...
[*] LDAP: Authenticating to ldaps://172.16.14.10
[*] LDAP: ... SUCCESS ...

The important distinction is that the NTLM authentication is relayed, rather than being recovered as a crackable password hash.

Understanding the attack

The complete chain can be represented as:

             IPv6 configuration
Windows ------------------------------> mitm6
   |                                      |
   |                                      | DNS spoofing
   |                                      v
   |                                Attacker DNS
   |
   | NTLM authentication
   v
ntlmrelayx ---------------------------> Domain Controller
                                             |
                                             | LDAPS
                                             v
                                      Active Directory

The attack relies on combining several independent behaviours:

Windows supports IPv6.
IPv6 configuration is not sufficiently controlled.
The client accepts the attacker’s DNS configuration.
The client subsequently performs an NTLM authentication.
The authentication can be relayed.
The LDAPS endpoint accepts the relayed authentication.
The authenticated account has sufficient privileges for the desired LDAP operation.

Breaking any of these conditions can prevent the attack from succeeding.

Common problems

No authentication reaches ntlmrelayx

If ntlmrelayx does not receive any authentication, verify that:

mitm6 is running on the correct interface.
The Windows client and attacker are on the same Layer-2 network.
IPv6 is enabled on the Windows client.
The client has actually received the IPv6 configuration.
The client generates an authentication after receiving the new DNS configuration.

LDAPS connection fails

Verify that the Domain Controller is listening on TCP/636:

nmap -p 636 <DC_IP>

Also verify that the LDAPS certificate and LDAP-over-TLS configuration are correctly configured in the lab.

Authentication reaches ntlmrelayx but relay fails

Receiving an NTLM authentication does not guarantee that it can be relayed successfully.

Check:

The target is actually accepting LDAPS connections.
The target is the intended Domain Controller.
NTLM is available for the authentication.
LDAP signing/channel-binding requirements do not prevent the relay.
The relayed account has the permissions required for the LDAP operation.

Defensive considerations

This attack demonstrates why IPv6 should not be ignored when securing an Active Directory environment.

Useful mitigations include:

Disable or properly manage IPv6 where it is not required.
Prevent unauthorized DHCPv6 servers.
Use network controls that prevent rogue IPv6 router/DHCPv6 advertisements.
Require SMB signing where appropriate.
Enable LDAP signing.
Configure LDAP channel binding appropriately.
Reduce unnecessary NTLM authentication.
Monitor for unexpected DHCPv6/DNS configuration changes.
Monitor Domain Controllers for unusual LDAP authentication and object modifications.
Follow the principle of least privilege for domain users and service accounts.

The combination of IPv6 poisoning and NTLM relay is particularly important because simply disabling LLMNR does not address the underlying IPv6-based attack path.

Notes

mitm6 and ntlmrelayx are highly dependent on the exact Windows, Active Directory, LDAP, and network configuration.

Therefore, a successful result in one lab does not necessarily mean that the same chain will work against another environment.

When documenting a lab, it is useful to record:

Domain Controller IP.
Active Directory domain.
Client IP.
IPv6 configuration.
Whether LDAPS is enabled.
LDAP signing configuration.
LDAP channel-binding configuration.
NTLM configuration.
Permissions of the relayed account.

This makes it considerably easier to understand why a particular relay succeeds or fails.

SMB Relay Kerberoasting