On-path Attacks – CompTIA Security+ SY0-701 – 2.4

An on-path attack allows an attacker to intercept and redirect critical network traffic. In this video, you’ll learn about the processes used to implement an on-path attack.


An on-path attack allows an attacker to sit between two devices and watch all of the traffic go back and forth between those systems. You might have also heard this attack referred to as a man-in-the-middle attack. The attacker in the middle of the conversation is responsible for transferring information from one device to the other. And as it’s passing through, the attacker can look at the information that’s being sent between devices and in some cases modify the information that’s being sent in real time as it’s traversing the network.

What’s perhaps even more concerning, especially for the parties involved, is they have no idea this attack is taking place. The on-path attack is effectively invisible for the victim devices. One type of an on-path attack is ARP poisoning. ARP poisoning occurs on a local IP subnet, so the attacker would need to be on the same subnet as the victim devices. Because ARP doesn’t have any type of security or encryption associated with it, this is a relatively easy attack to implement.

Let’s see how an attacker might use ARP poisoning or ARP spoofing to be able to monitor traffic between two devices. The two devices the attacker would like to monitor is this laptop and this router. The laptop has an IP address of 192.168.1.9 and a Mac address that ends in 38:d5. The router has an IP address of 192.168.1.1, and its Mac address ends in bravo bravo fox echo.

When the laptop first connects to the network it doesn’t know the hardware address of the router. All it has is the IP address of the router. But of course, our devices communicate by Mac address. It’s the address resolution protocol or ARP that allows us to resolve the Mac address from an IP address, so the first thing the laptop will do is send a broadcast across the network asking if any device out there happens to be 192.168.1.1. And if you are this device, please send back your Mac address.

The router will obviously see this broadcast and it will send back a response that says, I am 192.168.1.1 and here is my entire Mac address. And you can see the Mac address here is the same as the Mac address already associated with this router. Once the laptop receives that ARP reply, it saves that reply into a cache on this local device.

This allows the laptop to continue to communicate to the router without having to perform this ARP request over and over again. The ARP cache will normally time out after a number of minutes, at which time the ARP process will occur again. It will be cached again and it will be saved locally for the next interval.

Now we have our attacker. Our attacker is an IP address of 192.168.1.14, and you can see that the Mac address of the attacker ends in echo echo fox fox. This laptop already has the Mac address of the router saved in the cache, and there’s not been a subsequent request to update that ARP information. But the attacker sends an ARP response anyway that says that I am 192.168.1.1, and my Mac address ends with echo echo fox fox. You’ll notice that is identical to the Mac address associated with the attacker.

ARP doesn’t have any type of authentication function or additional security, so when it receives this type of message it will update its cache with this new detail. So you can see the ARP cache has now been overwritten with the 192.168.1.1 and the new Mac address of echo echo fox fox.

This same process will occur to the router, which means now that whenever the router wants to talk to the laptop and the laptop wants to talk to the router, it will send all of that information through the attacker’s device, at which time the attacker can monitor traffic, modify information that’s being sent between these two devices, or effectively turn off the connection between the laptop and the router.

The previous ARP poisoning example involved a number of different devices all communicating over the same network. But what if the attacker could perform this on-path attack on the same device as the victim? This is referred to as an on-path browser attack. With an on-path browser attack, or what you may have heard as a man-in-the-browser attack, malware or Trojan on this device is configured as a proxy that is able to redirect traffic before and after it’s sent to the network.

This means that even if the network traffic was encrypted, this type of attack would still be able to see all of the information in the clear because it’s running on the same device as the victim. And of course, because it’s an on-path attack, everything looks normal to the victim device.

Now the malware waits for you to log into something important like your bank account and captures all of the information that you sent to the bank, including your username, your password, and other credentials. Once you open up your browser and connect to your bank with the username and password, the attacker now has all of the information they need on your device to start other sessions behind the scenes that you as the victim would never see.

These sessions may be transferring data from one account to another, spending your money at an online shopping site or any other location that requires a username and password that is now being captured by the on-path browser attack.