Arpspoof - Not working from VM eth0 to Physical Machine

[trogne]

Today, if I want to arpspoof a physical machine form a VM, I have to arpspoof from the physical adapter (wlan0), not from the virtual eth0.

Before (like one month ago), I was able to arpspoof a physical machine even when I arpspoof from the virtual eth0.

Why does it not work today ? I've tried with my old snapshot and it's not working. I tried on vmware and virtual box too.

[digip]

Without knowing your setup, it's hard to say what is happening. For this to work, they need to be on the same subnet, so if the the VM is bridged to the physical network, then in theory should work. Note though, wireless to wireless, arp spoofing works great. In switched networks, it can hose things up, even cause systems to become unresponsive, but for most cases, should still work. If any adapters are setup with static settings, arp spoofing can fail fail though, depending on the implementation.

Retrace your steps, try different arp poisoning tools, ettercap, bettercap, arpspoof, etc. make sure ip forwarding is enabled as well.

 

Try Iron Geek's excellent notes, see if that helps.

https://www.irongeek.com/i.php?page=security/arpspoof

[trogne]

 

Let's forget about arpspoof for a second.

What's weird is that, on the remote physical machine, "arp -a" shows that the guest vm mac address is the same as the hosts mac address.

It was not like this before.

What's missing so that the guest vm mac address is the right one ? 

Clearing out the arp didn't helped.

 

[trogne]

It works if I changed the virtualbox adapter, used by Kali vm, to the ethernet adapter instead of the wireless one.

Any idea why it's not working anymore with the wireless adapter ?  It was working before ?

 

[trogne]

(it was working before.,   not "before ?")

[digip]

Was this uses only in VBox before, or was it Vmware? Vmware will pass the physical adapter mac. 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. 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. 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. 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). 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. All else fails, use native hardware, or try VMware to see if you can get around the issue for the wifi adapter. 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. Virtual machines are great, they just don't do everything 100% as expected. and they vary by virtual product, ie: vbox, vs vmware, vs qemu, etc.

[trogne]

It's the same for both on virtualbox and vmware.   At least it works on my physical kali (an old pc) with the included wireless adapter.

Note that I'm not talking about the extra wireless usb adapter (like alfa). I'm talking about the pc's wireless adapter used as a bridged adapter for the VMs. That adapter's MAC is no more showing on arp command from another physical pc on same network. Instead it shows the the host pc's MAC address.

To sum up :

Host PC on 192.168.1.10, mac ending with 68

Guest Kali VM on 192.168.1.11 (running on host .10), mac ending with 52

"arp -a" command on physical pc on 192.168.1.123 : Both .10 and .11 have the same MAC (ending with 68).

[digip]

Ah, k. That makes more sense now.

Internal wifi cards are treated like a wired card more or less and you lose all attack functionality for most things(especially in VBox). This is as old as time when it comes to virtual machines, for the most part. Even if you install the VBox extension pack, unless it sees the card itself as a full fledged wifi card, you will need to use a USB card, and more than likely, switch to VMware, you'll have better results with the USB cards.

So thing to note, internal wifi, not good for this kind of stuff. You HAVE to use a USB adapter for wifi attacks like deauths, injection, monitor mode, when using a VM, or they only work for connectivity, and in my experience, only Vmware supports this properly with certain USB cards, where VBox, tends to do what you are already experiencing for the most part even with USB adapters.

 

[Dave-ee Jones]

On 9/22/2017 at 11:40 AM, digip said:

Ah, k. That makes more sense now.

Internal wifi cards are treated like a wired card more or less and you lose all attack functionality for most things(especially in VBox). This is as old as time when it comes to virtual machines, for the most part. Even if you install the VBox extension pack, unless it sees the card itself as a full fledged wifi card, you will need to use a USB card, and more than likely, switch to VMware, you'll have better results with the USB cards.

So thing to note, internal wifi, not good for this kind of stuff. You HAVE to use a USB adapter for wifi attacks like deauths, injection, monitor mode, when using a VM, or they only work for connectivity, and in my experience, only Vmware supports this properly with certain USB cards, where VBox, tends to do what you are already experiencing for the most part even with USB adapters.

 

By internal WiFi you mean an onboard WiFi NIC, not an attached one?

[trogne]

I think digip does not understand.

I mean the onboard wifi.  And it's not the attacking wireless interface, it's just the one used for bridging.

Forget about arpspoof or any attack.

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

 

 

[digip]

5 hours ago, trogne said:

I think digip does not understand.

I mean the onboard wifi.  And it's not the attacking wireless interface, it's just the one used for bridging.

Forget about arpspoof or any attack.

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

 

 

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. Then ping each machine, and check the arp tables again. They should reset to what they are expected. 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. 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.

Once you get your MAC addresses sorted out, and when trying the attack again with the arpspoof, see what happens.

Might help to post a diagram of the machines, how they are connected. Can show the IP addresses as well and your commands, along with what is physically connected to the network. We don't really need to know the MAC addresses, but just understand that ARP attacks happen at layer two by poisoning the ARP table contents with the IP and MAC impersonating the gateway and victims, and the attacker, will appear as both the gateway and victim. If these didn't clear from when you reverted the machine in testing previously, your VM might have a host MAC address and just need to be reset/rebooted. You can open wireshark before doing the attack, and then see how it happens to get a better understanding of what is going on though. I don't know the topology of the network and what is what, so helps when you can see what goes where with what settings and connectivity. Might figure it out on your own just in drawing it out so you can see what you expect, and know what to fix.

[trogne]

No. The problem in simpler. Look :

For any VMs (linux/windows/mac, on vmware/vbox) using the wireless interface for connectivity (in bridged mode)  :

Doing "arp -a" on a physical machine on the same network (but NOT the vmware/vbox host) :

this shows the VM mac address equals to the vmware/vbox host VM .

 

Edited September 27, 2017 by trogne

[digip]

And something in the VM is not right, so reset the adapter's MAC manually on the VM when not booted, then try again, or change it in the VM, and then bring the adapter down and back up to renew your lease and try again.

I'm assuming the HOST's wifi is connected to an AP before the VM is even in the loop, and on the VM, the NIC is set to bridged, which is using the HOSTS already connected wifi connection? Because this is how I have to use my own internal WiFi card just to use it in the VM, which again, only works for connectivity and is shared by the host. If so, your VM is not using wifi directly nor independently, and has no real control over the network card, nor can it properly even do DHCP. It's only sharing the hosts connection, and when it sees it, it's passed back and forth to the host as a bridged adapter. It should still have it's own MAC address though, and independent IP of the HOST machine.

I have mine up now to test, using my internal Intel card to connect to the network over wifi, and passing it to the VM as a bridged adapter, it can't physically get onto the network unless I have the connection from the host started first. My wired NIC however, can, and the VM creates an additional "virtual" adapter in my HOST machines network manager and shows an extra adapter for the virtual NIC. It doesn't however do this for the wifi with the same kind of control to use it independently, which is a limitation of virtual machines and internal wireless cards to begin with.

In any case, using a USB wifi adapter, should resolve this issue and allow the VM, to have it's own physical network card to connect to the home AP and subnet, and from there, you can do whatever you need, whether it be surfing the web or trying arp spoofing attacks.

Only other thing I would say to try, is run arp -d on the other machines against the IP of the VM, ie: "arp -d x.x.x.x" where x.x.x.x is the IP address of the VM. then ping the VM's Ip and check the arp table again, which should show whatever it believes this device's MAC to be. If it still shows the same as the HOST machine, then get a USB wifi card, and you should have no issues.

Edited September 27, 2017 by digip

[trogne]

Nothing wrong in the VM, since all VMs react the same.  I already tried changing the MAC.

As you say, it's a "limitation of virtual machines and internal wireless cards".   When connecting using USB wifi adapter, MACs are good.

I begin to think that EVERYONE have my problem.

 

 

Edited September 27, 2017 by trogne

[digip]

50 minutes ago, trogne said:

Nothing wrong in the VM, since all VMs react the same.  I already tried changing the MAC.

As you say, it's a "limitation of virtual machines and internal wireless cards".   When connecting using USB wifi adapter, MACs are good.

I begin to think that EVERYONE have my problem.

 

 

Think of this logically. Your VM, is inside the HOST. The host connects to the AP using it's wireless card. Then the VM connects to the rest of the network, through the hosts adapter. The rest of the network, if they need to reach the VM, they need to know where it is. It's "inside" the HOST. The HOST machine, is your VM's border to machines "outside" the host.

This would be the same as if you bridged two wifi routers together. Everything connected to router A, would have router A's MAC address when people on router B tried to ping any of the other machines on router A. People on router A pinging each other, will see all the correct MAC addresses, as where people on router B will see the same MAC for all of the devices connected behind router A.

To work around this, and if you need to use the wireless network for more than just connectivity, you would use a USB wifi adapter so everyone can see it as a physical machine on the same segment, instead of something behind a bridge(which is why other machines outside the host, see the MAC as the same as the HOST). It will still work for just normal connection to the internet and such the way you have it now, which is doing a forward of the VM to the main network segment. 

 

Below you can see the same thing, on my own network.

 

Edited September 27, 2017 by digip