Jump to content


Global Moderators
  • Content Count

  • Joined

  • Last visited

  • Days Won


About digininja

  • Rank

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
    Sheffield, UK
  • Interests
    Hacking, Coding, Climbing

Recent Profile Visitors

19,386 profile views
  1. This is the process I'd go through to debug all of this. I'm going to define client and server as the two victims, you take them as whatever devices you have. Start a ping going from client to server. Run tcpdump on both devices and make sure you can see the ICMP traffic on both sides. On the client, set a static ARP entry for the server. Restart ping and tcpdump and check you can still see traffic. Reboot On the server, set a static ARP entry for the server. Restart ping and tcpdump and check you can still see traffic. Those steps confirm that you can monitor traffic and that you are using the arp command correctly to set entries. The reboot clears down anything to stop things interfering. On the client, set an invalid ARP entry for the server. Start the ping. Watching the dump, you should see ICMP traffic leave the client but not arrive at the server. Reboot On the server, set an invalid ARP entry for the client. Start the ping. Watching the dump, you should see ICMP traffic leave the client, arrive at the server, leave the server, but not arrive back at the client. That shows what it looks like when the routing is messed up. It also shows whether the server is honouring the OS ARP table or not. If traffic does flow, then the invalid ARP is being ignored Reboot On both boxes, set ARP entries that go through the attacking box. Start tcpdump on all three boxes. Start the ping. You should see ICMP leave the client, pass through the attacker, arrive at the server, leave the server, come back through the attacker, and arrive back at the client. If you don't, then you know the attacker box is not setup correctly. Debug here till it all works. Take a screenshot of what the ARP entries look like on client and server as this is now a working poisoned state. Reboot Run arpspoof as you expect it to be ran. Check the ARP tables and see if they match what you previous had, they should with. Start tcpdump everywhere and start the ping. You should see traffic flowing correctly through the attacker. When you get here, you have successfully poisoned the network. Don't be tempted to miss steps out, each one is there for a reason. The reboots are needed to clear things out so that you are definitely running on just the setup you are making, not on top of junk from the previous experiment. You can also take screenshots of the ARP table at each step so you can compare things and get used to how it looks. All pings are done purely from client to server, not to an outside entity, that removes anything else from potentially messing with traffic. You can also test pinging from server back to client at each step, that would give a bit of extra confirmation.
  2. For the pings, I meant from the victim ping the target, that way there are no additional hops and you should be able to see the request and response on all three machines. But glad you got it working to at least some degree.
  3. It is some dodgy criminal asking for stuff they realised they won't get on this forum so have ran off.
  4. For testing, I'd use ping as you can start a ping and leave it going while you look for traffic. It's hit a point of hard to debug without access, I'm running out of things to suggest. How about setting static fake ARP entries on the devices and see how that looks? That way you can remove the arpsooof stuff from the picture.
  5. If you are going to go wired through the kali box, you need to do this: Mac -> Kali -> router As far as the Mac is concerned, the Kali box is the default gateway and so the next network hop. In Wireshark, you are looking for ARP messages, so filter on those.
  6. Why not do it the easy way then and just install Wireshark on your Mac? Or use tcpdump/tshark to capture the traffic and then load it into Wireshark later? Or wire the Mac to you Kali box, set that as the default gateway, then enable IP forwarding.
  7. You don't need to poison a router, you can poison two devices. Attack your Mac and phone or two phones. And watch the ARP traffic, make you you are sending out what you expect to send out.
  8. The command you are running is telling the router ( the target specified by -t) that the MAC address of the victim ( - don't know where the -r came from) is now your MAC address which is what you are seeing when the ARP table on the router changes. If you only run the one arpspoof command, then the ARP table on the victim should not update as you aren't targeting that. There are no fake ARP messages going out to tell the victim that the MAC for the IP .1 is now you. The duplicate warnings are because you have two IP addresses using the same MAC address which is allowed, but only in odd situations. If you are going to sniff packets, look for ARP traffic, you'll then see your host sending out traffic to tell the other devices that IPs are moving around. Have a look at this guide, you are probably doing most of it already, but it steps through things so may help pick up something you've missed. https://ourcodeworld.com/articles/read/422/how-to-perform-a-man-in-the-middle-mitm-attack-with-kali-linux
  9. You need to explain what all the devices you are using are, their IP addresses, MAC address, and who is talking to who. Without this, I can't tell which devices you are trying to poison and which devices you are then trying to access. If you want to obscure things give us the first three octets, assuming they are all unique. If not, give us 2-4 as they will be unique.
  10. That is a list of your manually signed IP addresses based on MAC address. That is a static list that says what IP address your DHCP server will give out when that device asks for an address. That won't update as a result of spoofing.
  11. You posted them all within 45 minutes of each other. How fast were you expecting replies?
  12. Assuming it is a Linux based operating system, it should use what it says in the ARP table you get from the command line. Tell us the players, their IPs, and what you are running to try to do all this.
  13. So what you are saying is that the GUI view does not match the command line results?
  14. You need to do some reading on what ARP spoofing actually does. It doesn't change the MAC address of a device, it changes the ARP tables of the devices you are poisoning.
  15. I've removed all the duplicates. @Whippersnapper666 give us some more information that shows that what you are asking about isn't going to be used for illegal purposes, and that you actually know what you are asking for, otherwise this one will be removed as well
  • Create New...