Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
braimee opened this issue Dec 13, 2019 · 3 comments
Open

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

braimee opened this issue Dec 13, 2019 · 3 comments

Comments

@braimee
Copy link

@braimee braimee commented Dec 13, 2019

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 :-)

Screen Shot 2019-12-12 at 11 14 18 PM

Screen Shot 2019-12-12 at 11 14 27 PM

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

This comment has been minimized.

Copy link

@cyberfreaq cyberfreaq commented Dec 13, 2019

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: #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.

@braimee

This comment has been minimized.

Copy link
Author

@braimee braimee commented Dec 13, 2019

@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

@braimee

This comment has been minimized.

Copy link
Author

@braimee braimee commented Dec 16, 2019

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.