One method for MITM attacks is to set up a rogue DHCP server. In this situation you’re in a race with the real DHCP server and you may not always (if ever) win.
I’ve been sitting on an idea for a couple weeks where under certain circumstances you could have a distinct advantage in the race. Specifically when the DHCP client is on WiFi. Before WiFi clients pull DHCP they usually have to associate with the access point which involves an exchange of packets. The idea was that you could have your rogue DHCP server listen for clients associating then immediately start spamming the client with appropriate DHCP replies. In this scenario you may be able to get your reply in before the client has even finished sending the request. The cool thing here is that if the network is encrypted but you’re wired in and the wireless just bridges to the wired network you don’t necessarily need the encryption key. You can see the association in the clear then start sending your DHCP messages on the wired network destined for the new client on the wireless network. Because that MAC address hasn’t been seen yet the switching infrastructure should just unicast flood the message everywhere so it should get to the target.
This morning I realized I’d probably never get around to actually implementing this idea, which is a shame given the snazzy name. I was looking at the RFCs for DHCP and it looks like the client picks an ID number and if your replies didn’t have that ID number then the attack probably wouldn’t work. Since you’re sending replies before you’ve seen the request you can’t know what the request is. Perhaps if you’re on the wireless network and the DHCP server is on the wired network you have a few microseconds of a head start. Perhaps you could guess the ID number the client will use somehow. Perhaps I’ve misinterpreted the RFC, I didn’t read through it closely. All that aside, maybe this will give someone else some workable ideas.