IPv6 Attacks and LDAPS Relay (MITM6 + NTLMRelayX)

Background

Windows machines have IPv6 enabled by default, even when networks primarily use IPv4. Attackers can exploit this to perform man-in-the-middle (MITM) attacks using tools like mitm6 and NTLMRelayX.
When combined, these tools can relay NTLM authentication to LDAPS (LDAP Secure), potentially allowing domain privilege escalation or user creation.

Lab Setup

  • Attacker Tools: mitm6 + ntlmrelayx

  • Target: Windows Domain Controller (192.168.X.X)

  • Domain: ABC.local

  • Goal: Capture and relay NTLM authentication to LDAPS

Step-by-Step Attack Flow

    Step 1: Launch IPv6 Spoofing with mitm


  • This Creates a rogue IPv6 DHCP server.

  • Forces Windows clients to use attacker’s IPv6 DNS (since IPv6 > IPv4).

  • Intercepts DNS queries (including WPAD requests).

Step 2: Start NTLM Relay to LDAPS


  • -6:  Enables IPv6 relaying

  • -t:  Target LDAPS on DC

  • -wh: Fake WPAD hostname to trigger proxy authentication

  • -l: Loot folder to save dumps

Step 3: Trigger Authentication

  • Restarted the domain-joined PC to force a WPAD lookup.

  • During boot, client attempted auto-proxy discovery via wpad.marvel.local.

  • mitm6 intercepted it, NTLMRelayX captured NTLM hash, and relayed it to LDAPS.


Step 4: Successful Relay and Loot

Once the authentication was successfully relayed to LDAPS, ntlmrelayx automatically performed post-exploitation actions using the relayed credentials.
  • By default, NTLMRelayX attempts to:

    • Dump AD information (users, groups, policies)

    • Create a new user account in Active Directory (if the relayed user has enough privileges)

    In this case, the relay succeeded, and a new domain account was automatically created with credentials displayed in the console output


So I opened the folder called lootme/ as seen below, where all dumped AD information was stored.


To visualize this data, i used firefox to open on domain_users_by_group.html and i saw a lot more from Group policy creator owners, Domain Admins, Schema Admins, Enterprise Admins etc. as seen below 


Auto-Created Account

ntlmrelayx printed a success message with the new user details a seen below :


Then, I verified this user on my Domain Controller using Active Directory Users and Computers (ADUC), and confirmed the account was successfully created:


Note: The created account does not automatically have domain admin privileges, unless the relayed account had rights to create or modify privileged users/groups. In this lab, it was added as a standard domain user.

The credentials (username + password) provided in the ntlmrelayx output can be used to:

  • Log in to the domain as that user,

  • Enumerate AD objects, or

  • Attempt privilege escalation (if additional misconfigurations exist).

All AD data dumped during the relay (users, groups, computers, etc.) was stored inside the lootme/ directory.

Behind the Scenes (Technical Explanation)

 1. IPv6 Auto-Configuration Abuse

Windows gives IPv6 traffic higher priority than IPv4.
Even if your network doesn’t use IPv6, it’s enabled by default.
mitm6 abuses this by sending rogue DHCPv6 announcements, tricking clients to use the attacker as a DNS server.


 2. WPAD (Web Proxy Auto-Discovery Protocol)

  • WPAD allows clients to auto-detect proxy settings.

  • Clients query wpad.domain.local.

  • Attacker spoofs this hostname (e.g. fakewpad.marvel.local).

  • When the client tries to fetch proxy settings, it authenticates with NTLM.


 3. NTLM Relay via LDAPS

  • Captured NTLMv2 hashes are relayed to LDAPS (LDAP over SSL/TLS).

  • LDAPS doesn’t require user interaction  just valid auth.

  • NTLMRelayX uses the valid authentication to:

    • Enumerate AD

    • Create users

    • Modify group memberships


Why LDAPS Worked

  • LDAPS is encrypted, but not immune if LDAP Signing or Channel Binding is not enforced.

  • Relay succeeds because server trusts the NTLM authentication session.


Mitigation and Hardening

  1. Disable IPv6 if unused.

  2. Enforce LDAP Signing & Channel Binding via Group Policy.

  3. Disable WPAD (set via Group Policy).

  4. Use SMB/LDAP Signing and avoid NTLM where possible.

  5. Segment networks to reduce MITM exposure.


Summary

In this lab, I leveraged IPv6 auto-configuration and WPAD spoofing using MITM6, capturing NTLM authentication and relaying it to LDAPS via NTLMRelayX. The relay succeeded, creating a privileged domain account demonstrating the impact of unmonitored IPv6 traffic and unprotected LDAP channels.

That’s all for today’s post! In the next part of my AD lab journey, I’ll explore more stay tuned! πŸ”₯ 

Comments

Popular posts from this blog

Using Hydra to Brute-Force SSH And WI-Fi Login Portal

SMB Relay Attack in AD Lab (Step-by-Step)

Discover AWS Organization ID Via S3 Bucket