Might help to post a diagram of the machines, how they are connected.
#ARPSPOOF INTERFACE MAC#
Once you get your MAC addresses sorted out, and when trying the attack again with the arpspoof, see what happens. If eth0 still shows the same as the host, then it's probably where things are causing issues with the arpspoof stuff, and I'm going to say try changing the NIC 's MAC manually once booted and then check arp -a again(do a ping to other machines to tell them your new MAC address), make sure it's bridge to the physical network, and not to the host only/shared by the host. You can also check the adapter settings on the VM to see what the MAC address is set to for eth0 and wlan0, and you can change this for all VM's manually or set to random new MAC before starting the VM. They should reset to what they are expected. Then ping each machine, and check the arp tables again. I think maybe something is out of whack from when you were playing with arp spoof, you should probably reset the MAC on the VM's adapters. If doing no attacks at all before even doing arp spoof, and just checking arp -a, and they look to be wrong, I'd say reboot your VM and make sure all network settings are back to normal, no ipfoward set in the VM too.
#ARPSPOOF INTERFACE PC#
What I mean, is that when using the onboard wireless interface as the vbox/vmware bridged interface, then when I'm "arp -a" from another physical machine (on the same network), I see that the MAC of host PC (on which kali vm is) AND the kali VM are same (equals to the host PC MAC). And it's not the attacking wireless interface, it's just the one used for bridging. and they vary by virtual product, ie: vbox, vs vmware, vs qemu, etc. Virtual machines are great, they just don't do everything 100% as expected. More than likely, the wifi adapter also doesn't do injection and monitor mode properly under vbox, which has also been my experience, and why I tend ot use wifi stuff on my laptop, or Vmware which sort of works for most of my adapters. All else fails, use native hardware, or try VMware to see if you can get around the issue for the wifi adapter.
Bridged to the physical network and getting DHCP from the actual home router is what you ideally want to test with, but I have a feeling for wifi, it's not doing this physical dongle setup properly in VBox. Can try changing the adapter settings when the VM is off to things like NAT or Bridge, althogh NAT will prevent ARP attacks(in theory) since they need to be on the same subnet, where NAT will divide the network(s). VBox, from the sounds of it, passes the device by proxy and not as a physical device attached over USB, so seems to me it's cloning the host machines MAC and just passing it across. Best thing is run on native hardware, test, works, then work out the kinks on the VM side since that seems to be the issue, not Kali, but the virtual machine architecture.
On VBox, the wifi, for whatever reason, never seems to work properly(for me anyway) but I chalk this up to the virtual machine side, and not a Kali issue. IP= `route -n |grep ^0.0.0.0 |cut -d ' ' -f 10 `Įcho "Sorry, you must run this script as root.Was this uses only in VBox before, or was it Vmware? Vmware will pass the physical adapter mac. #Kills the ip in the argument, all if there is no argument. Nmap -sP $IP-254 -e $INTERFACE #Hopefully the gateway is on x.x.x.1 Using sudo we can access to the mac address and the nic vendor.Įcho "Looking up hosts on your network, this could take a while. Learn more about bidirectional Unicode charactersĮcho "Usage: $0 "Įcho " -list: list devices on the network (nmap) "Įcho " -all: block all devices on the network (arpspoof) "Įcho " : block the provided ip (arpspoof) "Įcho " -i: choose interface (wlan0,eth0 etc) " To review, open the file in an editor that reveals hidden Unicode characters. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below.