Newest Kali + mitm6 + ntlmrelay = crickets(?!)

[7MinSec]

Hi there,

I have two fresh Kali boxes (2019.4) that I've really only done the round of apt-get update/upgrades on, as well as download Responder, Mitm6, ntlmrelay, etc. I've also run the necessary "pip" and/or setup scripts to install dependencies.

One system is at a client environment, one is in my lab. But when I run mitm6 for the target domain, and ntlmrelayx in a second window, I get absolutely no activity from either one - even after an hour. Here are screenshots from my lab north.pole (Santa works here :-)

Admittedly this is my first time ever running mitm6 so I don't know what to expect, but by looking at pretty much any other blog/video out there, I should start seeing spoofed replies pretty quickly (or do I just need to wait this out? I can report back tomorrow...gonna leave these run overnight).

Can you think of anything I can test/troubleshoot to figure this out?

Thanks! Brian

[cyberfreaq]

Hi Brian!

One good way to troubleshoot this is running Wireshark on both your Kali and the victim system and filter for dhcpv6 and icmpv6 (dhcpv6 || icmpv6). This way you can see which packets leave the victim system and which packets arrive at your Kali machine.

Start mitm6 with this command: mitm6 -i eth0 -d <domain.local> --no-ra

To simulate a network change/reboot on the victim system you can:

1. Physical: Simply pull the network cable on the victim system and reconnect it
2. Physical/VM: start a CMD as admin and use netsh to disable and enable the network interface again

   netsh interface show interface 
   netsh interface set interface "<name>" disabled
   netsh interface set interface "<name>" enabled

3. VM: Disconnect and reconnect the network interface in VMware Workstation

I'm not sure if option 2 or 3 was working with VMware. One of them caused Wireshark to stop listening because it "found no interface".

Shortly after that the Windows system should start with the following process:

1. The victm sends a DHCPv6 SOLICIT to the all-dhcp-agents multicast address in order to discover the DHCPv6 servers.
2. mitm6 will reply with an DHCPv6 ADVERTISE message to the link-local IPv6 address of the client.
3. The victim then sends a DHCPv6 REQUEST message to the multicast group.
4. mitm6 replies with a final DHCPv6 REPLY message.

Warning: If your lab is running on an ESXi environment your Kali won't see the DHCPv6 messages coming from the client because vSphere virtual switches implement the MLDv2 protocol. Windows sends ICMPv6 solicit to the all-dhcp-agents multicast address and your Kali machine is not part of this group (although this functionality could be added to mitm6 I guess).

To overcome this problem you can:

• Enable Promisicous Mode on the switch forcing it to act like a hub and send all traffic to all ports
• Use mitm without the --no-ra message. However, I wouldn't do this on large networks because I had problems with victim systems which didn't "forget" the DHCPv6 options after 5 minutes and needed to be rebooted. I described part of this issue here: https://github.com/fox-it/mitm6/issues/11 (which I will update in a second).

You should now find Kali's IPv6 address set as DNS server if you type ipconfig /all on your victim system. If not, compare your Wireshark logs on both systems and look for missing packets on either side.

[7MinSec]

@cyberfreaq thank you so, SO much for all this crazy detailed information! I am indeed using ESXi so your post explains a lot. I will definitely try promiscuous mode when I get back to the office today and report back. Also thanks much for the "--no-ra" tip. All the how-tos and vids I'd seen the last few days leave that flag out, and I'm operating in an environment where they want as little disruption as possible, so good to know that flag helps in that regard.

Again thanks a million. I went to bed feeling like I was just a little bit insane (more than usual anyway).

Good news to follow soon!

Brian

[7MinSec]

@cyberfreaq whoohoo, the promiscuous mode thing was totally it, thanks again! For those of you who find this thread later, the setting changed on the ESXi Web console was:

Networking -> VM Network -> Edit Settings -> Promiscuous Mode: Accept

I ran mitm6 with the --no-ra, then followed @dirkjanm 's article (https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/) on using his fork of impacket to simulate some attacks in my lab. I'm blown away...thanks both of you for your wonderful work.

I can start a new issue/question but just wondering as I plan to do this on a client engagement...besides the --no-ra are there any other command flags or gotchas you can think of to play things on the safe side? I imagine a nightmare scenario where my mitm6 interrupts valid DNS comms which then also prevents me from remoting into my pentest dropbox :-(

Thanks, Brian

[t0wb0at]

Thanks a lot for your thread, guys! This is helped me a lot, I'm using VMWare Workstation and met the same problem, but everything is started working well when I enabled Promiscuous Mode on the network interfaces of my VMs.

This is how to enable Promiscuous Mode on a VMWare machine:

Shut down the VMware host. Locate the VMX file associated with it. Edit the file and locate the Ethernet section. Add a new entry for each Ethernet you want to be in promiscuous mode:

ethernet%d.noPromisc = "FALSE"

(replace %d with the Ethernet number) Start the machine and the interface will now operate in promiscuous mode.

Sources: https://superuser.com/questions/1139028/configuring-promiscuous-mode-in-vmware-workstation-running-on-windows-10-serving https://s3.amazonaws.com/virtuallyghetto-download/hidden_vmx_params.html

[mrasecure]

Just tested this on Hyper-V

Kali Host: (Version 2021.2) -> DHCPv6 SOLICIT Message from client is received, Advertisement is sent to target by Kali host.

Windows Host: (Version 21H1 Build 19043.928) -> DHCPv6 Advertisement is not received...

Any ideas?

ps. IPv4 is set manually (no DHCP) but I'm sure this worked back in 2019 when i first played with mitm6.

Edit1: CC @dirkjanm @cyberfreaq

Edit2: In the tests above, all VMs are connected to the same 'private' switch on Hyper-V. Microsoft's description of private switch: "Only allows communication between virtual machines on the same Hyper-V server. A private network is isolated from all external network traffic on the Hyper-V server. This type of network is useful when you must create an isolated networking environment, like an isolated test domain."

When the VMs are connected to the default switch, it works!

i think this issue should be closed, as the problems have been proven to come from the hypervisors repeatedly ;)

[estebanramos]

Hi Brian!

One good way to troubleshoot this is running Wireshark on both your Kali and the victim system and filter for dhcpv6 and icmpv6 (dhcpv6 || icmpv6). This way you can see which packets leave the victim system and which packets arrive at your Kali machine.

Start mitm6 with this command: mitm6 -i eth0 -d <domain.local> --no-ra

To simulate a network change/reboot on the victim system you can:

1. Physical: Simply pull the network cable on the victim system and reconnect it
2. Physical/VM: start a CMD as admin and use netsh to disable and enable the network interface again

   netsh interface show interface 
   netsh interface set interface "<name>" disabled
   netsh interface set interface "<name>" enabled

3. VM: Disconnect and reconnect the network interface in VMware Workstation

I'm not sure if option 2 or 3 was working with VMware. One of them caused Wireshark to stop listening because it "found no interface".

Shortly after that the Windows system should start with the following process:

1. The victm sends a DHCPv6 SOLICIT to the all-dhcp-agents multicast address in order to discover the DHCPv6 servers.
2. mitm6 will reply with an DHCPv6 ADVERTISE message to the link-local IPv6 address of the client.
3. The victim then sends a DHCPv6 REQUEST message to the multicast group.
4. mitm6 replies with a final DHCPv6 REPLY message.

Warning: If your lab is running on an ESXi environment your Kali won't see the DHCPv6 messages coming from the client because vSphere virtual switches implement the MLDv2 protocol. Windows sends ICMPv6 solicit to the all-dhcp-agents multicast address and your Kali machine is not part of this group (although this functionality could be added to mitm6 I guess).

To overcome this problem you can:

• Enable Promisicous Mode on the switch forcing it to act like a hub and send all traffic to all ports
• Use mitm without the --no-ra message. However, I wouldn't do this on large networks because I had problems with victim systems which didn't "forget" the DHCPv6 options after 5 minutes and needed to be rebooted. I described part of this issue here: DNS server spoofing only working once #11 (which I will update in a second).

You should now find Kali's IPv6 address set as DNS server if you type ipconfig /all on your victim system. If not, compare your Wireshark logs on both systems and look for missing packets on either side.

Reviving old issue but there's something I don't understand. In Non Esxi Envinroment, wouldn't be the same way? I mean, the Windows machine is sending multicast to DHCPv6 Servers (ff02::1:2), how the kali can response to that if it's not part of the group either way if there a switch with mldv2 or not?

[cyb3rw0lf]

For me it worked forcing the kali vm to join the all-dhcp-agent multicast group with this command sudo atk6-fake_mld6 wlan0 add ff02::1:2

atk6-fake_mld6 is part of thc-ipv6 tools https://www.kali.org/tools/thc-ipv6/

In my setup I had the Windows VMs on ESXI and the Kali VM connected via wifi dongle.

[estebanramos]

For me it worked forcing the kali vm to join the all-dhcp-agent multicast group with this command sudo atk6-fake_mld6 wlan0 add ff02::1:2

atk6-fake_mld6 is part of thc-ipv6 tools https://www.kali.org/tools/thc-ipv6/

In my setup I had the Windows VMs on ESXI and the Kali VM connected via wifi dongle.

Nice workaround, I've used the same tool but using a fake dhcp server with the kali machine along with mitm6