Executing A Man-In-The-Middle Attack

Executing a man-in-the-middle attack about:reader?url=https://www.coengoedegebur...
coengoedegebure.com
Executing a man-in-
the-middle attack
Coen Goedegebure
23-29 minutos
One of my favorite parts of the

security awareness demonstration I
give for companies, is the man-in-
the-middle (MiTM) attack. In this, I
explain the factors that make it
possible for me to become a man-in-
the-middle, what the attack looks
like from the attacker and victim's
perspective and what can be done
1 de 55 6/4/21 5:12
to prevent this.
During this attack I'm able to see a
victim's network traffic and browsing
behavior. Weaponizing this
possibility I then steal the victim's
cookies, take over his web session
and change his profile picture on the
website he's visiting to demonstrate
the privileges I gained.
The reason I like this demonstration
so much, is that it really helps
convey the importance of security
awareness on the audience's
personal level. Moreover, the MiTM
attack is a great container for
introducing several interesting
techniques, concepts and tools and
executing the attack brings these all
2 de 55 6/4/21 5:12
together.
This is why I decided to put this
knowledge in the article you are
reading now.
Contents
During a man-in-the-middle attack

an attacker places himself between
two otherwise inter-connected
devices. By doing this, the network
traffic of both devices flows through
the attacker's machine, allowing him
to intercept, read and modify the
contents.
Since we're exploiting the ARP
protocol to achieve this, the first
chapter describes how this protocol
3 de 55 6/4/21 5:12
works. Then we'll dive into the

scenario and theory of this exploit,
followed by a practical breakdown of
the entire attack from both the
attacker and the victim's
perspective. The last chapter
describes how this attack can be
prevented on a network level, in the
website configuration and what you
can do as a client to avoid becoming
a victim of this attack. Shortcuts to
the chapters are included below for
quick reference:
The ARP protocol
ARP network traffic
ARP spoofing
Man-in-the-middle attack
4 de 55 6/4/21 5:12
HTTPS to the rescue?

The attack in practice
Attack setup
SSLStrip
Attack with Ettercap
The attack from the victim's
perspective
The attack from the attacker's
perspective
Prevention
The way the ARP protocol works, is
the reason it is open for an MiTM
attack. So, in order to understand
the attack, a basic understanding of
this protocol is required.
ARP stands for Address
5 de 55 6/4/21 5:12
Resolution Protocol, which helps a

network host make a translation
from the IP-address to the MAC-
address. This is required in order for
data to pass from the OSI model's
Network Layer (layer 3) to the Data
Link layer (layer 2) and vice-versa.
Suppose Machine A needs to
transfer data to Machine B. Zooming
in to the lower levels of the OSI
model, it would need to pass through
the Network layer, the Data Link
layer and the Physical layer (layer 1).
For Machine A to be able to address
Machine B, Machine A would need
to know the IP address of Machine
B; information that is known in the
Network layer.
6 de 55 6/4/21 5:12
The Data Link layer communicates

using MAC addresses. So, a
conversion needs to take place from
the IP address to the MAC address
of Machine B (and vice-versa on the
recipient machine). This is illustrated
in the image below:
OSI Model layers 1-3

The conversion from, or rather
resolution of, the IP address into
MAC address (and the other way
around) is where the ARP protocol
7 de 55 6/4/21 5:12
comes into play. Both machines will

have an ARP table where the IP-
and corresponding MAC-addresses
of all known machines are stored.
Then how does Machine A get the
MAC-address corresponding to the
IP Address of Machine B?
Machine A will just ask for it.
A simplification of the ARP protocol
is depicted in the animation below:
ARP protocol
Let's briefly go over the 3 steps in
the animation:
8 de 55 6/4/21 5:12
1. In the first step of the ARP protocol,

Machine A sends out an ARP
request. This is a broadcast to the
network with the question "Who has
the MAC-address for the IP-address
of Machine B?".
2. The machine that has this
knowledge (usually Machine B
itself), will send an ARP reponse
stating "MAC-address B is the MAC-
address of Machine B".
3. Machine A receives the ARP
response and writes (or updates) the
entry in his ARP table.
The last step is exactly where the
problem with this protocol lies.
However, before we dive into its
9 de 55 6/4/21 5:12
issues, we'll take a look at the ARP

packets being transmitted over the
network.
ARP Network traffic
The image below displays a part of a

network capture made with
Wireshark.
ARP network capture

We can clearly see two packets with
numbers 7 and 8 respectively.
Packet 7 contains the ARP request
from a machine with MAC address
10 de 55 6/4/21 5:12
ending with 56:e7 (source). Its

destination has MAC address
ff:ff:ff:ff:ff:ff, which indicates it does
not have a specific destination; it's a
broadcasted message. The packet is
summarized by Wireshark as "Who
has 192.168.1.2? Tell
192.168.1.130".
Packet 8 is the ARP response from
a machine with MAC address ending
with 01:e7. The destination had the
MAC address of the originator
(source) of packet 7. Wireshark
summarizes its info as "192.168.1.2
is at 00:50:56:ea:01:e7", which is
actually the same MAC-address of
the source of this message. This
11 de 55 6/4/21 5:12
means it was the machine itself

responding to the request. Note that
this ARP response is aimed directly
at the originator (source) of the ARP
request (MAC-address 56:e7).
The lower section of the image
shows the details of packet 7. Here
we can clearly see the sender is on
IP-address 192.168.1.130 and that
machine is looking for the MAC-
address of 192.168.1.2.
Now let's check out the issue with
this protocol.
ARP Spoofing
The fact that Machine A updates its

ARP table with the info from an ARP
12 de 55 6/4/21 5:12
response without any question

about the validity of this
information, opens the door for
ARP spoofing (also known as ARP
poisoning).
An attacker might send a malicious
ARP response, without any
preceding request, containing his
own MAC address and the IP
address of another machine. The
machine to which the response was
directed will update its ARP table
unquestioningly.
13 de 55 6/4/21 5:12
ARP spoofing
The image above depicts the same
scenario as before. However, a
hacker has now joined Machine A
and B on the network. The hacker
has done his work in the
reconnaissance and scanning
phases, knows Machine A and B
exist in the network and what IP
addresses they have.
In this example, the hacker himself
has IP-address H and MAC-address
mac-H. He sends his malicious ARP
response directed at Machine A with
the message "mac-H is the MAC-
address of IP-address B". Machine
A updates its ARP table and IP-
14 de 55 6/4/21 5:12
address B is now linked to MAC-

address H.
From now on, every time Machine A
wants to send a message to
Machine B, it will translate the IP
address of Machine B into MAC-
address H and be sent to the hacker
instead of Machine B.
We've seen how an attacker can
make a machine send its data to him
instead of the intended destination
by sending a malicious ARP
response. Now let's see how this
technique can be weaponized to
become a man in the middle of two
machines.
Consider the following scenario:
15 de 55 6/4/21 5:12
ARP spoofing scenario

In this scenario we see 3 actors: A
Gateway, Adam and a Hacker.
1. At first we see Adam connected to
the Internet via a Gateway. In this
step, the hacker will be doing
reconnaissance and scanning on
the network to find out who else is
present and what their IP- and MAC-
addresses are.
2. The hacker then sends a malicious
ARP response to both the Gateway
and Adam. Basically, the hacker tells
16 de 55 6/4/21 5:12
the Gateway that he is Adam and

simultaneously tells Adam that he is
the Gateway.
3. Both Gateway and Adam will update
their ARP tables with their new
information. From then on, these
nodes will start to send their data to
the hacker instead of each other.
ARP spoof completed!
The hacker will need to take some
measures before he can properly
start intercepting data, but we'll
discuss those in a moment.
HTTPS to the rescue ... ?
Consider the scenario of the

previous chapter where the hacker is
17 de 55 6/4/21 5:12
in between the Gateway and Adam.

The hacker would be able to see all
traffic of both parties. For example, if
Adam browses to a website, the
hacker may see all data sent to and
received from the websites he's
contacting.
What about HTTPS? That's HTTP
over TLS (or HTTP over SSL). It
would mean that all data over the
line would be encrypted right? True,
and real-time decryption still is not
even remotely feasible. So, the
hacker would not be able to see the
encrypted contents of HTTPS-traffic.
The solution: force the victim to
communicate via HTTP, which is
unencrypted plain text, instead of
18 de 55 6/4/21 5:12
HTTPS.
Before I explain how this can be
done, let's take a look at how an
HTTPS-session is setup when you
browse to www.google.com (for
example):
HTTPS session setup
Typing www.google.com in a web

browser's address bar will have the
browser make an HTTP-connection
(on port 80) to www.google.com.
Since google.com will only allow
HTTPS-connections, the site will
19 de 55 6/4/21 5:12
request the user to make an HTTPS-

connection instead. The client will
then reconnect using HTTPS on port
443. This succeeds and google.com
returns its certificate.
Forcing HTTP communication
Consider the scenario where a

hacker is somewhere in between the
communication of web server and
the client. The hacker would be able
to read the contents of the web
traffic until the moment the client
sets up the HTTPS-connection. After
this all data will be encrypted and no
longer readable by the hacker.
Earlier we stated that this might be
circumvented by forcing the client to
20 de 55 6/4/21 5:12
keep communicating via HTTP.

SSLStrip is the tool we will use to
achieve this.
SSLStrip, created by Moxie
Marlinspike, will transparently hijack
HTTP traffic on a network, watch for
HTTPS links and redirects, then map
those links into either look-alike
HTTP links or homograph-similar
HTTPS links. Let's take a look at the
HTTPS session setup when the
hacker uses SSLStrip in between
the client and the web server.
SSLStrip
21 de 55 6/4/21 5:12
Like before, the client types

www.google.com in the
webbrowser, which will attempt to
setup an HTTP connection with the
website. Now with SSLStrip in the
middle, this connection is forwarded
to the intended destination.
However, instead of the entire
HTTPS-redirect-dance to be
performed on the client's side,
SSLStrip takes care of this on the
hacker's machine. After the HTTPS-
connection was setup, SSLStrip will
return an HTTP-OK to the client.
The client's browser thinks this is
acceptable since it never saw the
HTTPS-redirect and will continue to
communicate via HTTP; a format the
22 de 55 6/4/21 5:12
hacker can read effortlessly.
HTTP strict transport Security
Having HTTP strict transport

security (HSTS) enabled for your
website will inform the browser to
always communicate using HTTPS.
It does this via a special HSTS
response header. Simply put, the
browser maintains a list of websites
from which it received this header.
For these websites, the browser will
immediately make an HTTPS-
connection regardless of how the
user attempted to connect. Typing
www.google.com will not result in
the HTTP-HTTPS-redirect-dance,
23 de 55 6/4/21 5:12
but immediately call

https://www.google.com. This
will prevent users from making the
HTTP-connection in the first place,
avoiding SSLStrip to perform this
trick. That is, if your browser
supports it.
The first ever visit of a client to a
website may still be done via HTTP
and an attacker can strip the HSTS
header from the response. This is
why most modern browsers have a
pre-loaded list of HSTS sites. More
on prevention in the final chapter.
In this chapter I will demonstrate
what a man-in-the-middle attack
looks like from both hacker and
24 de 55 6/4/21 5:12
victim's perspectives. Let it be clear

that using this technique on
networks / setups for which you
don't have explicit permission, may
land you in loads of trouble. This
explanation is for educational
purposes only.
Setup
My lab is setup as follows:
Lab setup
25 de 55 6/4/21 5:12
These are the configurations of the 3

components in this setup:
The attacker will be running Kali
Linux with IP-address 192.168.1.134
The victim is running Windows 7 on
a machine with IP-address
192.168.1.130
Both machines are connected via a
gateway with IP-address
192.168.1.2
Attack setup
From the attacker's perspective,

when we just joined the network, we
don't know anything about the
network or the nodes that are
connected to it. Let's do some
26 de 55 6/4/21 5:12
reconnaissance first.
Reconnaissance
We first want to know the details of

our own network interface via the
ifconfig command:
ifconfig
Here we see that our own IP-
address is 192.168.1.134 and
our MAC-address is
00:0c:29:a0:08:88.
Then we should find out the IP-
address of the gateway by running
the route -n command:
27 de 55 6/4/21 5:12
route -n
We can see the gateway's IP-
address is 192.168.1.2. Now we'll
attempt to discover who's on the
network in our 192.168.1.xxx
subnet, by running the command
netdiscover -r
192.168.1.0/24. This will attempt
to discover all nodes in the range
192.168.1.0 to 192.168.1.255:
netdiscover -r 192.168.1.0/24
Besides the gateway, we found
another node: the victim on
192.168.1.130. Notice the line above
28 de 55 6/4/21 5:12
the table in the figure above. It states

that it captured 4 ARP
requests/responses. Netdiscover
sniffs the ARP traffic to discover
who's on the network. With the
parameters we supplied, netdiscover
actively requested around for node
information, quite a loud operation. If
we would have provided the -p-
parameter, it would have passively
listened to the ARP-traffic; a bit
stealthier.
SSLStrip setup
Now we know the IP-addresses of

the machines we want to be in
between of, we are almost ready to
perform the ARP-poisoning. Before
29 de 55 6/4/21 5:12
we do that however, there are a few

things we need to do to setup
SSLStrip in preparation of the attack.
IPv4 forwarding
Make sure all IPv4 traffic is
forwarded. If we wouldn't do this, all
IPv4 traffic would stop at our hacker
machine in the middle of both
nodes. This would result in a Denial-
of-Service attack to our victim, who
would no longer able to
communicate to the Gateway.
In Linux, we enable IPv4 forwarding
by executing the following
command:
echo 1 > /proc/sys/net/ipv4

/ip_forward
30 de 55 6/4/21 5:12
Redirecting HTTP to SSLStrip

We also need to make sure all
HTTP-traffic is redirected to
SSLStrip. When running, SSLStrip
listens on port 10000 by default.
Redirecting incoming HTTP-traffic
(TCP on port 80) to port 10000 on
our own machine, requires a
modification in the linux firewall
tables via the iptables command:
iptables -t nat -A
PREROUTING -p tcp
--destination-port 80 -j
REDIRECT --to-port 10000
Running SSLStrip
Since sslstrip is included in Kali
Linux, running this program is as
31 de 55 6/4/21 5:12
easy as executing the command

sslstrip.
SSLStrip preparation and execution
Attack with Ettercap
Now SSLStrip is running and all

preparations are in place, we can
start the attack. In order to send the
malicious ARP-reponses we could
craft our own packets with scapy or
use Cain & Abel. Very useful tools
and worth articles on their own.
However, for this purpose I'll be
using Ettercap, a powerful man-in-
the-middle toolset that comes pre-
installed with Kali Linux.
32 de 55 6/4/21 5:12
After fireing up Ettercap's GUI with

the command ettercap -G, in the
menu choose Sniff - Unified
sniffing...:
A popup will show where we can

choose which network interface to
use. I chose the default eth0:
In the extended menu, choose

Hosts - Hosts list. This will
33 de 55 6/4/21 5:12
display a list of known hosts on the

network. If no hosts are shown, you
can scan for hosts via the menu
Hosts - Scan for hosts.
As we can see, both the gateway

and the victim are present. In the
hostlist, select the gateway
(192.168.1.2) and press the button
Add to Target 1. We do the
same for the victim (192.168.1.130)
and press Add to Target 2. This
way, we may add multiple addresses
34 de 55 6/4/21 5:12
to either Target groups, enabling us

to be man-in-the-middle of many
different machines at the same time.
After having set the targets, in the
menu choose MiTM - ARP
poisoning..., which will display
the following popup:
Choose Sniff remote

connections and press OK. The
other option would allow us to only
send the malicious ARP response to
one of the targets, leaving the other
one unmodified.
Now both sides are poisoned via
35 de 55 6/4/21 5:12
ARP spoofing, Ettercap will

summarize the details of the affected
target groups in its log:
ARP responses - Network traffic
When taking a look at a part of the

network traffic captured during the
ARP poisoning, we see that the ARP
requests were sent out to the
gateway and the victim:
36 de 55 6/4/21 5:12
Both messages are sent form our

hacker machine (MAC
00:0c:29:a0:08:88). Checking
out the details of the first message,
we see its target is the gateway (IP-
address 192.168.1.2). Wireshark
detected a potential problem with
this message and notes that the
hacker's MAC-address has been
seen linked to another machine's IP
address as well.
Victim's side
Let's switch to the victim's side of

this attack and what it looks like from
his perspective.
ARP table
37 de 55 6/4/21 5:12
We'll start out by checking the

victim's ARP table via the arp -a
command in Windows. Before the
poisoning, the victim's ARP-table
looked like this:
We see that the gateway and

victim's IP addresses have different
MAC-addresses (called physical
address in the table). After the ARP
poisoning, both IP-addresses should
refer to our (the hacker's) MAC-
address 00:0c:29:a0:08:88.
Indeed, we can see this is exactly
what happened if we run the arp
38 de 55 6/4/21 5:12
-a command after the ARP

poisoning:
Just browsing
As a victim, we open Internet

Explorer and browse to
www.gmail.com. I was in Spain
when I performed this hack, so this
is what the Spanish Gmail front-
page looks like:
39 de 55 6/4/21 5:12
As a victim of this attack, we may

notice a few things wrong with the
front-page:
1. The address in the address-bar
shows HTTP instead of HTTPS,
while we know Gmail would usually
be served over HTTPS.
2. More important, we see no
indication we're using a secure
connection, like a lock-symbol,
'Secure' text, or the name of a
company.
Note that this is an older version of
40 de 55 6/4/21 5:12
Internet Explorer without HSTS for

the purpose of this demonstration.
Just for comparison, this is what a
'safe' address bar would look like in
this version of Internet Explorer:
Notice the HTTPS and presence of a

lock-symbol on the right side of the
address. Most modern browsers will
have better notifications for secure
connections. The most recent
versions of Firefox and Chrome
(version 62+) actively notify the user
of insecure connections. It's great to
see the browser companies are
shifting to security-by-default, in
which you're not notified when
41 de 55 6/4/21 5:12
something is secure, but rather

when things are not secure. Troy
Hunt has written a great blog post
about this.
Check whynohttps.com (by Scott
Helme and Troy Hunt) to see the
world's most popular sites that don't
use HTTPS. In September 2018 a
few of these were bbc.com,
espn.com, alibaba.com and
baidu.com). This is what an insecure
website looks like in the modern
version of Chrome:
42 de 55 6/4/21 5:12
Anyways, back to our Gmail

browsing. On the HTTP Gmail
website, I'll enter my email address
and a fake password 12345:
This obviously didn't work, since that

isn't my real password and Gmail
returned an error stating invalid
credentials. However, for what I'm
demonstrating here, this is enough.
43 de 55 6/4/21 5:12
Switching back to the attacker's

side, let's see what we can see of
the user's browsing actions. Ettercap
monitors the network traffic and logs
interesting parts of the
communication to the screen. As we
can see from the image below,
Ettercap saw the HTTP-POST
request with the login details sent to
the Gmail server:
I highlighted my email address and
44 de 55 6/4/21 5:12
the entered password 12345 as

well. Ettercap supports many
protocols besides HTTP so this log
would be interesting to follow.
However, running Wireshark as an
attacker would allow us to see the
contents of all network traffic. In the
image below I highlighted the
username and password from the
HTTP-POST request:
The highlighted Wireshark packet

clearly shows the victim's IP address
as the source. I filtered the network
45 de 55 6/4/21 5:12
capture to display only HTTP-traffic,

but being man-in-the-middle we
would be able to see traffic from all
protocols. We're able to see the is
because the client sends his data
over HTTP, as forced by SSLStrip. If
the client would communicate via
HTTPS, we would see nothing but
encrypted data like in the image
below:
Cookie stealing
When I give a live demonstration of
ARP spoofing, I always take it a little
further after the attack succeeded.
Using the information from the
Wireshark network capture I can
46 de 55 6/4/21 5:12
steal the victim's cookie when he's

browsing a website. Using this
cookie I then take over the victim's
session and perform actions only he
is allowed to do on that site, like
changing his profile picture and
description. If that user would have
been a website administrator, a
hacker may do a lot more damage.
ARP Spoofing is one way to perform
a man-in-the-middle attack.
However, there are a few security
countermeasures to protect you
against this. I've divided the
preventive measures into 3
categories: the network, the website
and the user.
47 de 55 6/4/21 5:12
Network / infrastructure
From a network perspective there

are a few things that can be done to
prevent ARP spoofing:
ARP is a protocol that relies on IPv4.
In IPv6 ARP has been replaced by
the Neighbor Discovery Protocol
(NDP), however the adoption rate of
IPv6 is still relatively low. The
security extension of this protocol
(Secure Neighbor Discovery or
SEND) uses cryptography to ensure
that the claimed source of an NDP
message is the owner of the claimed
address.
Most modern switches come with
an ARP spoofing protection feature
48 de 55 6/4/21 5:12
that can be enabled to prevent this

attack.
Creating a static ARP entry in your
server can help reduce the risk of
spoofing. If you have two hosts that
regularly communicate with one
another, setting up a static ARP
entry creates a permanent entry in
your ARP cache that can help add a
layer of protection from spoofing.
Website
When you're hosting a website,

there are a few things you can do to
protect your site and your
customers. These make it harder for
a hacker to perform a man-in-the-
middle attack.
49 de 55 6/4/21 5:12
Use HTTPS
The reason why we needed

SSLStrip in the first place, was to
force HTTP on our victim browsing
an HTTPS website. If you're not
even serving your website via
HTTPS, you are making it too easy
for hackers to attack your site and
your customers. Basically, in 2018
there is no good reason not to use
HTTPS for your website; yes, also
for your static website.
If you think HTTPS is lowering the
performance of your website, you're
wrong. Check out istlsfastyet.com for
more information or test it yourself
with this great comparison
50 de 55 6/4/21 5:12
benchmark between HTTP and

HTTPS.
My blog is setup to use HTTPS via
Cloudflare, very easy to setup and
does way more than just HTTPS;
highly recommended!
Troy Hunt also has written quite a
few great posts about migrating to
HTTPS, like the 6 step happy path to
HTTPS or HTTPS is easy.
Add HTTP Strict Transport

Security (HSTS)
As we've seen earlier, we were able

to hijack the HTTPS-session setup
with SSLStrip if the victim's browser
started out with an HTTP connection
51 de 55 6/4/21 5:12
to the website. HSTS informs the

browser that the connection to the
site should always be HTTPS. Its
policy is communicated by the
server to the client via a response
header field named "Strict-Transport-
Security". The HSTS header can be
stripped by an attacker on the user's
first visit, which is why most modern
browsers maintain a pre-loaded list
of HSTS-sites.
HSTS Policy specifies a period of
time during which the client should
only access the server in a secure
fashion. Because of this time limit,
HSTS is sensitive to attacks
involving shifting the victim's
computer time (e.g. using false NTP
52 de 55 6/4/21 5:12
packets), but that's a different story.

Troy Hunt has written a great guide
on HSTS and how to set it up, so I
won't repeat that here. Be careful
though, HSTS requires you to
commit to HTTPS for the long term:
Be aware that inclusion in the

preload list cannot easily be undone.
Domains can be removed, but it
takes months for a change to reach
users with a Chrome update and we
cannot make guarantees about
other browsers. Don't request
inclusion unless you're sure that you
can support HTTPS for your entire
site and all its subdomains the long
term (from hstspreload.org).
53 de 55 6/4/21 5:12
The user
As a user of a network or website,

you are usually at the mercy of the
administrators doing a secure job.
When you're browsing a website or
communicating over a network you
don't control and you don't know
who might be eavesdropping, using
a Virtual Private Network (VPN) is a
great option to protect your privacy,
data and communications.
A VPN will allow you to do online
activities through an encrypted
tunnel. Not only is the mode of
transmission encrypted but also the
data that goes through it. Even if
your network is targeted by ARP
54 de 55 6/4/21 5:12
spoofing, your network traffic will

remain secure because the attacker
won't be able to decrypt the data
flowing through the tunnel.
Awareness
Most of the prevention from a user's
perspective comes down to
awareness. This is the reason I
made this post in the first place.
When you are browsing a website
and you're aware of the signs that
something is not right about the
website or your connection, think
twice before entering sensitive data.
It almost goes without saying that it's
always a good idea to keep your
browser up-to-date.
Cover photo by John Barkiple
55 de 55 6/4/21 5:12

Executing A Man-In-The-Middle Attack

Uploaded by

Copyright:

Available Formats

You might also like

Executing A Man-In-The-Middle Attack

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Executing A Man-In-The-Middle Attack

Uploaded by

Copyright:

Available Formats

Executing a man-in-the-middle attack about:reader?url=https://www.coengoedegebur...

One of my favorite parts of the

During a man-in-the-middle attack

works. Then we'll dive into the

HTTPS to the rescue?

Resolution Protocol, which helps a

The Data Link layer communicates

OSI Model layers 1-3

comes into play. Both machines will

1. In the ﬁrst step of the ARP protocol,

issues, we'll take a look at the ARP

ARP Network traﬃc

The image below displays a part of a

ARP network capture

ending with 56:e7 (source). Its

means it was the machine itself

The fact that Machine A updates its

response without any question

address B is now linked to MAC-

ARP spooﬁng scenario

the Gateway that he is Adam and

HTTPS to the rescue ... ?

Consider the scenario of the

in between the Gateway and Adam.

HTTPS session setup

Typing www.google.com in a web

request the user to make an HTTPS-

Forcing HTTP communication

Consider the scenario where a

keep communicating via HTTP.

Like before, the client types

hacker can read eﬀortlessly.

HTTP strict transport Security

Having HTTP strict transport

but immediately call

victim's perspectives. Let it be clear

My lab is setup as follows:

These are the conﬁgurations of the 3

From the attacker's perspective,

We ﬁrst want to know the details of

the table in the ﬁgure above. It states

Now we know the IP-addresses of

we do that however, there are a few

echo 1 > /proc/sys/net/ipv4

Redirecting HTTP to SSLStrip

easy as executing the command

SSLStrip preparation and execution

Attack with Ettercap

Now SSLStrip is running and all

After ﬁreing up Ettercap's GUI with

A popup will show where we can

In the extended menu, choose

display a list of known hosts on the

As we can see, both the gateway

to either Target groups, enabling us

Choose Sniff remote

ARP spooﬁng, Ettercap will