Hacking

Man-in-the-middle attack: Real-life example and video walkthrough [Updated 2021]

April 26, 2021 by Jeff Peters

Is your web browsing private, or is a man in the middle looking at everything you do? Learn what a man-in-the-middle (MITM) attack is, how to set up and execute one, and why they are so dangerous in this walkthrough from Infosec Skills author Keatron Evans.

Man-in-the-middle attack example

In this episode of Cyber Work Applied, Keatron demonstrates a man-in-the-middle attack real-life example: an innocent victim joins the same Wi-Fi network as a malicious attacker. Once the victim joins, it only takes a few steps for Keatron to completely compromise the machine using MITM attack tools.

Watch the full breakdown below of how the attack works below:

How to set up a man in the middle attack | Free Cyber Work Applied series

New episodes of Cyber Work Applied are released every other week. Check out the full collection of free Cyber Work Applied training videos.

More Free Training Videos

Man-in-the-middle attack walkthrough

The edited transcript of the MITM attack is provide below, separated into each step Keatron goes through in the video.

How does man-in-the-middle attack work?

(0:00–1:02) Hi, this is Keatron Evans, and I’m going to show you how to do a man-in-the-middle attack. What we see on the screen is one of the victims that we’re going to be doing a man-in-the-middle attack against. Now, one of the things we need to remember is any time you visit a website, you do so by going out to a router or a gateway or something to get you to the internet. You primarily find the websites you’re trying to visit by doing something called a DNS query, which is when you tell your DNS server to go to the IP address of wherever you’re trying to visit.

We’re going to be interrupting that process — putting ourselves in the middle — so that when the victim requests Facebook or whatever it is they’re trying to get to, we can lie to them and tell them Facebook is somewhere we want it to be. Essentially, we can point them to our site that we control instead of them getting to the real Facebook.

ARP spoofing man-in-the-middle attack

(1:03–3:10) Let’s dive right into it. The first thing we have to do is tell the victim, which is this machine, that we’re the gateway, which is .2. That way it will pass all those requests through us. The easy way to do that is something called ARP poisoning. So let me ARP poison.

I’m going to specifically tell the gateway, which is .2, that I am the victim, which is 100. Now, remember you’re in the middle, or you’re trying to get in the middle, so you can’t just ARP poison one side of that equation. You have the ARP poison both. So simultaneously I’m going to ARP poison and tell the gateway that I am the gateway, which if you’re at home or at Starbucks would essentially be your Wi-Fi router we’re spoofing here.

So first ARP spoof, I’m telling the gateway that I’m the victim. The second ARP spoof, I’m telling the victim that I’m the gateway. This is part of what puts me in the middle. Both sides will now think I’m the other side. So I start my ARP poison and right away you can see the ARP going out and it’s doing a reply, which is telling the 100 machine that I’m the gateway. And it’s also telling the gateway that I’m the 100 machine. So that’s the ARP poisoning in motion. And it’s going every second. The reason it’s going every second is because in a real network, every once in awhile, the real machines would respond and say, wait a minute, I’ve got that IP address. So having this ARP happen every second guarantees that even if the real device responds, you immediately overwrite that response with your more recent response — because in the land of ARP the most recent reply is considered to be the truth.

Turn on IP forwarding to complete the setup

(3:11–5:09) The last step, once we’ve got the ARP poison going, is we have to make sure we turn on something called IP forwarding. The reason for that is by default your machine will simply drop packets. Now, in my case, my machine has the IP forwarding turned off, which means it’s going to follow that behavior.

What I want to do is change that behavior because I am going to be getting packets that are intended for our victim here. Since those packets aren’t actually intended for me, my default behavior is to simply drop those packets. But I don’t want to drop them. I want to go ahead and take them and pass them on. So I’m going to change this IP forward from a value of zero to — guess what? If zero is off, what do you think I need to change it to in order to turn it on? Exactly. One.

So I’m simply going to write the number one into this file, and this will actually turn on IP forwarding. To prove this is working, I’m not going to write this yet. I’m going to show you that currently 100, which is this victim, has trouble pinging .2, That’s because the ping packet is never making it to the actual gateway. It’s coming to my machine, and since my default behavior is to drop packets not meant for me, and I’m clearly not .2, that packet’s getting dropped.

But the minute I turn on IP forwarding — let’s go ahead and turn that on — now you’re going to see those pings are going to end up being a 100 percent successful. That’s because now the ping is making it to the other side, but it’s only making it there by coming through my interface first. So that means I’ve made myself a proxy or now I’ve completed and put myself in the middle.

Stealing victim images using Kali Linux driftnet tool

(5:10–6:26) How do we prove that we’re in the middle? How can we do things? Well, there are a couple of tools I want to show you. The first one is a special purpose sniffer called Driftnet. The Kali Linux driftnet tool is unique in that it grabs only images out of a victim’s traffic. So if I run Driftnet and tell it to listen on interface six here, you’ll see them in this little black window whenever the victim visits websites.

Let’s go do that. The victim goes out. It goes to MSN and some other places. Well, in that traffic are images, and guess what the attacker just grabbed? All of the images that were in that traffic have now been sniffed off by this attacker in the middle. So any images you would have viewed during your browser session, the attacker is able to see those images now. Not only see them, but if I found one that I wanted to keep like this image here with this nice pie, I click that and it actually saves a local copy of that image so I can view it later. Now, if that’s not creepy enough, let me show you how this really gets deep.

Setting up DNS cache poisoning

(6:27–8:27) On top of the man in the middle and on top of the ARP poisoning, I’m going to do one more thing called DNS cache poisoning. Whenever you go to a website such as Facebook, the first thing that happens is your machine sends a query to your DNS server saying, where is Facebook? What’s Facebook’s IP? Your DNS server responds back and says, here’s the IP address for Facebook.

Now, since I’m already in the middle, I’m going to see that request. I’m going to respond on behalf of the actual DNS server and lie to you and tell you that Facebook is at my machine. Let’s look at how easy that is. First I’m going to create a file. We’ll just call this MITM FB, and I’m going to say in there that Facebook is at my IP, which is 204. I’ll save that little text file. Now, I’m going to run the tool dnsspoof and point to that file that we just created. What’s happening is any time this tool sees a query for Facebook, it’s going to respond to that machine that’s asking for Facebook and lie to it and tell it that Facebook is at my IP.

Let’s go check the victim and see what happens. So victim says let’s ping facebook.com, and it gets pings. But look at where it says the pings are coming from: 204. So we’ve successfully poisoned the ARP cache. We’ve successfully DNS cache poisoned them. They can’t even DNS lookup Facebook without blindly trusting what we’re telling it Facebook is.

Use Social Engineering Toolkit to clone website

(8:28–11:53) For the last step, I’m going to use the Kali Social Engineering Toolkit on Facebook. I need to make sure I have a nice clean copy of Facebook that looks just like Facebook, but actually has malicious code in it that will give me control of that victim’s machine if they browse it. This is also known as a client-side attack against a browser that we’re going to use to do the actual exploit. It sounds complex, but let me show you how simple it actually is.

I’m going to load up a tool that’s been around for a lot of years, written by Dave Kennedy. Let me show you how to use the Social Engineering Toolkit in Kali Linux. I’m going to pick one for social engineering, two for website attack vectors, and two, again, for browser exploit method. Then I’m going to go to site cloner and say no to natting. For IP, I wanted to come back to that. It’s going to be mine.

Who do I want to clone? Let’s just say Facebook. And then I’m going to use browser autopwn because these hundreds of exploits here are basically depending on me knowing which browser victim’s use. It could be different browser and OS combinations, so I’m going to pick autopwn, which means that when the victim hits my fake Facebook server, the server is going to look at that victim’s get request and decipher what the browser and OS is, and then send the appropriate exploit based on that. Alright, I’m going to pick Meterpreter as my payload. In other words, if I’m able to export the machine, what do you want to get as your loot? I want a Meterpreter session so that I can take over the machine. Let the port stay 443, and now it’s off to the races. It’s going out.

It’s going to the default Facebook login page. As you can see there, it’s cloning that, which means it’s copying it down. Now it’s putting the malicious code that I’ve crafted inside that fake Facebook copy. And now it’s standing up a version of the exploit for every possible browser and operating system combination and storing them at a slightly different URL on my server. So when your browser hits this server, it’s going to look at your browser version, look at your OS version, and then simply send the appropriate exploit based on that, which we’re loading them all right here.

Once this is finished, the only thing we have left to do is go play victim and see what happens when the victim simply does what the victim does everyday — tries to go to Facebook. So we go to the victim. We open our browser. We load facebook.com in their browser, and at that point right there, it’s game over. Let’s go back and look. What you see happening on the attacker side is the attacker now has a session. We connect to that session as the attacker, and take our obligatory screenshot here to prove that we have it.

At that point we own that machine. It belongs to us completely. It’s no longer that victim’s. It is ours. We can drop into a shell, and it’s game over at that point. And that folks is what a man-in-the-middle-attack looks like. Now you can see the actual devastation that can come from that.

More free training videos

If you want more free training from Keatron and other Infosec instructors, check out the Cyber Work Applied training series, where you’ll learn:

  • How to carry out a watering hole attack, SQL injection and cross-site scripting
  • How Zoom and AI is being exploited for phishing attacks
  • 5 ways to prevent APT ransomware attacks
  • How major major data breaches occurred, such as Capital One and Equifax
  • What it’s like to respond to an ongoing DDoS extortion attack
  • How to create a port scanner, break into cybersecurity and more!

More Free Training Videos

Posted: April 26, 2021
Articles Author
Jeff Peters
View Profile

Jeff Peters is a communications professional with eight years of experience creating cybersecurity-related content. As the Director of Content Marketing at Infosec, he focuses on developing materials to help cybersecurity professionals improve their skills and advance their careers. He oversees the Infosec Resources website, the Cyber Work series (Cyber Work Podcast, Cyber Work Applied and Cyber Work Live) and a variety of other Infosec content.


Notice: Undefined index: visitor_id12882 in /www/resourcesinfosecinstitute_601/public/wp-content/plugins/infosec-user-info/infosec-user-info.php on line 117