You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've set up a Kali Host and a Win10 machine on VMware residing on the same network. No changes have been made to the IPv6 configuration of the Win10 machine:
When i start wireshark on Kali I can't see any DHCPv6 requests. Update: I now know, that this is because of my lab running on an ESXi. Kali won't see the DHCPv6 messages because vSphere virtual switches implement the MLDv2 protocol. Windows sends DHCPv6 solicit to the all-dhcp-agents multicast address and the Kali machine is not part of this group (although this functionality could be added to mitm6 I guess).
If I start mitm6 with mitm6 -i eth0, Win10 will recognise Kali (due to the RA or Router Advertisement I guess) and send a DHCPv6 request. mitm6 sends the reply and Win10 sets the IPv6 parameters as intended:
The interesting (or annoying) thing now is that I cannot get the attack to work a second time. If I start mitm6 again with mitm6 -i eth0, a RA is sent via multicast but Win10 doesn't send a DHCPv6 request:
Win10 only sets the Default Gateway and that's it. No DNS server is set, no DHCPv6 messages are exchanged:
The IPv6 gateway stays there for a while (I guess 1800s as announced in the RA) and then disappears. If I start mitm6 again the same thing happens again.
I tried the following things which didn't help:
Assigning a new MAC and IPv6 address to Kali
Starting mitm6 with --no-ra: Nothing happened at a network level because Win10 never sent DHCPv6 requests on its own. It only reacted to RAs. Update: I now know, that this is because of my lab running on an ESXi. Kali won't see the ICMPv6 messages because vSphere virtual switches implement the MLDv2 protocol. Windows sends ICMPv6 solicit to the all-dhcp-agents multicast address and the Kali machine is not part of this group (although this functionality could be added to mitm6 I guess).
These things did help:
Rebooting the Win10 machine
Deactivating the IPv6 protocol on the network adapter on Win10 an re-enable it.
Reading the second last comment from bigjoesmithh indicates that this could be a problem within Windows 10:
Windows client will not correctly pull DNS information from a DHCPv6 server after correctly doing stateless address configuration using router assignment [...]
So the problem maybe occurs only if Win10 doesn't send DHCPv6 Solicit messages on its own but only reacts to router advertisements.
The following questions occur to me:
Do you have an idea why Win10 behaves this way?
Is there a way we could tell the victim, that it should forget everything it learned from mitm6? Some message that notifies the Win10 machine, that the DHCP/DNS server no longer exists?
Do you have an idea why some Win10 machines send DHCPv6 Solicit messages but others don't?
The text was updated successfully, but these errors were encountered:
KBCShared
changed the title
DNS Server Spoofing only working once
DNS server spoofing only working once
Jul 17, 2019
Hey @KBCShared Did you ever get any further with your research on this one? I just opened an issue for what is likely a totally different issue, but part of my issue is seeing some of the Win10 behavior you mention above.
Hi,
I came across the following problem in my lab:
I've set up a Kali Host and a Win10 machine on VMware residing on the same network. No changes have been made to the IPv6 configuration of the Win10 machine:
When i start wireshark on Kali I can't see any DHCPv6 requests.
Update: I now know, that this is because of my lab running on an ESXi. Kali won't see the DHCPv6 messages because vSphere virtual switches implement the MLDv2 protocol. Windows sends DHCPv6 solicit to the all-dhcp-agents multicast address and the Kali machine is not part of this group (although this functionality could be added to mitm6 I guess).
If I start mitm6 with
mitm6 -i eth0
, Win10 will recognise Kali (due to the RA or Router Advertisement I guess) and send a DHCPv6 request. mitm6 sends the reply and Win10 sets the IPv6 parameters as intended:The corresponding wireshark log looks like this (IPv6 ending in 9cd6 being Kali, 8df2 being Win10):
mitm6 is sending fake DNS responses and I get connections from Win10 to ntlmrelayx.py. Everything OK so far!
If I stop mitm6 on Kali, everything regarding IPv6 is reverted in Win10 after the lease timeout:
The interesting (or annoying) thing now is that I cannot get the attack to work a second time. If I start mitm6 again with
mitm6 -i eth0
, a RA is sent via multicast but Win10 doesn't send a DHCPv6 request:Win10 only sets the Default Gateway and that's it. No DNS server is set, no DHCPv6 messages are exchanged:
The IPv6 gateway stays there for a while (I guess 1800s as announced in the RA) and then disappears. If I start mitm6 again the same thing happens again.
I tried the following things which didn't help:
These things did help:
I found the following Microsoft thread:
https://social.technet.microsoft.com/Forums/office/en-US/b16e7d78-e390-4ada-a24b-3ccba60fa571/no-ipv6-dns-statelessdhcp-since-windows-10-anniversary-update
Reading the second last comment from bigjoesmithh indicates that this could be a problem within Windows 10:
So the problem maybe occurs only if Win10 doesn't send DHCPv6 Solicit messages on its own but only reacts to router advertisements.
The following questions occur to me:
The text was updated successfully, but these errors were encountered: