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
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
-
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
-
Disable IPv6 if unused.
-
Enforce LDAP Signing & Channel Binding via Group Policy.
-
Disable WPAD (set via Group Policy).
-
Use SMB/LDAP Signing and avoid NTLM where possible.
-
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
Post a Comment