Using ARP Poisoning to Fake Router Interfaces and Steal Login Credentials

Photo by insecure.in team on insecure.in

Overview

In this blog, we will use arp poisoning to trick a target computer to thinking that we are the router. In doing so, when the target machine tries to login to the router admin page, they will actually be using our fake web page where we are able to see their password attempts.

This is not a MiTM attack as we are not forwarding or relaying the information to the router as the data passes through as we are not targeting the router to think that we are the target machine as well. This is simply an impersonation attack, where we pretend to be the router to directly capture credentials without maintaining a full man-in-the-middle connection.

And to learn about ARP Security, I recommend this post: https://www.networkacademy.io/ccna/ethernet/arp-security

Setup

Windows 10 - Target virtual machine
Kali Linux - Attack virtual machine
- Both are on bridge mode, so they have real IP addresses from my router (like 192.168.0.x).
Optional (but recommended):
- Isolated router & switch (can break and mess around with easily without messing up main network)

Step 1 - Recon

Goal:

Find the IP address of the target machine and router

Using arp-scan we are able to scan machines on the network we are connected to.
- arp-scan works by sending out arp requests to all IPs on the subnet ("Who has ? Tell <attack_machine_ip>")
- You can actually see it via Wireshark if you are a device connected on the network:

Here we have 3 machines that we can see that responded to the arp request
We can tell that 192.168.0.1 is the router as it points to a TP-Link device and the target machine for this scenario will be a Dell computer which will be 192.168.0.106

After identifying devices with arp-scan, we perform more targeted scans to confirm the OS and device type.

Running OS discovery via namp
- nmap -O 192.168.0.106
- Results:
Simply pinging the target IP to see if its a windows machine by its TTL response
- If the TTL is 128 then its probably a windows machine
- Results:

So now we know that its a Dell Windows 10 machine.

Step 2 - Poisoning phase

Goal:

Act like the TP-Link router and trick the target machine to login to the router login page and steal the password.

Now let's start acting like the router

We will use a tool arpspoof via the dsniff library
- arpspoof allows us to send fake arp requests to the target machine and the machine we are trying to mimic.
arpspoof -i eth0 -t 192.168.0.106 192.168.0.1
- Result:
  - Our attack machine is sending out arp requests to the 192.168.0.106 telling it that 192.168.0.1 points to our MAC address
  - When the target machine gets this request it will update its arp table to match the new information
- Here is arp table of the target machine before running the arpspoof command:
- And here it is after:
  We can see that the MAC address of the router has been changed to the MAC address of the attack machine

It's important to remember that on real-world networks, ARP spoofing can sometimes trigger detection systems, but in home networks, it's usually undetected.

Now that all traffic from target machine to the router is going to us, lets host a fake router login page to trick the target into logging in and stealing their password.

We will be creating a very simple API in python using the FastAPI library that will accept a POST request from the login page and then save that password in a text file.
Then we will host this fake login page using nginx on port 80. So when the target machine visits the "routers" IP address it will be directed to this fake login page where anything they submit in the password field will be sent to our API endpoint and log their password.

Before we do that though, we need our Kali machine to be able to accept requests coming to our MAC address but at a different IP address (192.168.0.1), because whenever we receive a packet, our operating system will look at the MAC header and the IP header to see if they match to our system. If they both don't it will drop the packet. Since when the target machine will go to http://192.168.0.1 it will be directed to us but since we don't have the routers IP on our network card, Kali will drop the packet completely.

Fix:
Add the IP address to our network interface: ip addr add 192.168.0.1/24 dev eth0

We are able to do a post request via the /cgi-bin/login endpoint
Then save the result to a text file

The 192.168.0.1 address is actually pointing to our attack machine

Next, we will setup nginx to host this login page
We also need to accept incoming packets with port 80 to forward them to our nginx service running port 80:

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 80
We are saying: ANY packet that hits port 80, redirect it to the local machine’s port 80 server.

We also need to forward port 8000 to our fastapi:

sudo iptables -t nat -A PREROUTING -p tcp --dport 8000 -j REDIRECT --to-port 8000

It's very similar to the real page shown at the start

After submitting a password, the page will always display a login error, encouraging the user to retry multiple times
This isn't always the best way to do it but for this simple example it will do just fine

Interesting Detail

Why we need to also add the IP of target machine

After setting up spoofing and the web page, the victim going to the "poisoned IP" like for example the admin page of the router (if we are acting like the router), doing so will not automatically go straight to our web page that we are hosting. Why? Well this is because whenever we do an HTTP request for example to the poisoned IP (192.168.0.1), it will first:

The victim machine is sending HTTP request to poisoned IP
1. It looks at the arp table and sees that that IP address belongs to the spoofed MAC
2. Sends the packet with the IP address and the spoofed MAC
The attacker machine receives the HTTP request from the target machine
1. The network card looks at the IP of the HTTP packet, showing that it's not the IP address of itself (packet shows that it's meant for 192.168.0.1, but our (attack) machine is 192.168.0.103) so the network card drops the packet.
2. This is where ip addr add 192.168.0.1/24 dev eth0 command comes in.
  1. Its an extra step when to do to be able to accept not only ICMP packets but other Layer 3 and above

Why ICMP “just works” but HTTP doesn’t

ICMP Echo (ping) is handled entirely in the kernel’s networking stack. As long as the ARP-poisoned frame reaches your NIC, you’ll see a ping at the raw‐socket level and can reply manually or with a simple script.
TCP (HTTP) connections, however, require an application (Nginx, FastAPI, etc.) to be listening on that exact IP:port. If the kernel doesn’t recognize the IP as local, it never hands the packet up to your server.

Conclusion

In this blog, we explored the process of performing an ARP spoofing attack in a controlled environment, demonstrating how an attacker can intercept and manipulate network traffic by impersonating a router to capture login credentials through a fake login page. We highlighted the technical steps involved, including reconnaissance, poisoning the ARP cache, and hosting a deceptive web page using Nginx & FastAPI.

This is just a simple example of what can be done with ARP spoofing—there's much more we can do, including advanced man-in-the-middle attacks, packet manipulation, and network sniffing. By understanding these concepts, we gain valuable insight into network vulnerabilities and the importance of securing communication channels to prevent such attacks in real-world scenarios.