In a Man-in-the-Middle (MitM) attack, an attacker inserts himself between two network nodes. For example, in a successful attack, if Bob sends a packet to Alice, the packet passes through the attacker Eve first and Eve decides to forward it to Alice with or without any modifications; when Alice receives the packet, she thinks it comes from Bob. The attack is bidirectional, so the same scenario applies when Alice sends a packet to Bob. Initially developed to attack public key encryption systems, this attack has expanded to include any form of eavesdropping in which the attacker acts as a proxy and controls the packets exchanged by the two target nodes.   

Follow these steps to test for MitM bugs:

  • Step 1: Understand attack scenarios
  • Step 2: Analyze causes and countermeasures
  • Step 3: Start testing and exploring
  • Step 4: Execute additional testing

Step 1: Understand Attack Scenarios

First, it is necessary to understand the basic attack scenario related to MitM attacks:

  • Public-key encryption MitM attack
  • Network MitM attack

Public-key encryption MitM attack

The first scenario relates to public-key cryptography and  key exchanges. An attacker needs to get the public key of one of the two victims in order to start the attack. For instance, eavesdropper Eve gets Alice’s public key when she is sending it to Bob. Now Eve constructs a malicious message that says she is Alice, includes Eve’s public key, and sends it to Bob. When Bob receives this message, he replies by sending Alice a message that is encrypted with Eve’s key. Since Eve is intercepting the conversation, she gets the message from Bob and  deciphers it (using her [Eve’s] key) and enciphers it again (using Alice’s public key that she initially intercepted) before sending it back to Alice. In this way, neither of the attacked parties, Alice or Bob, realize that there is an attacker altering the messages they are exchanging.

In detail:

  1. Attacker (Eve) intercepts a conversation between two users (Alice and Bob).
  2. Attacker reads Alice’s public key.
  3. Attacker crafts a message claiming that it comes from Alice, but using Eve’s key.
  4. Attacker sends message to Bob.
  5. Bob receives message, and sends reply encrypted with attacker’s key (Eve’s key).
  6. Attacker receives the message from Bob and decrypts it.
  7. Attacker uses Alice’s key (intercepted in step 2) and encrypts the message with that key.
  8. Attacker forwards encrypted message to Alice.

Network MitM attack

MitM attacks are not limited to cryptographic system; they include any network attack in which the attacker makes independent connections with two victims and starts relaying messages between the two victims without their knowledge. In other words, the attacker becomes an invisible proxy between the two victims. Common ways to execute network MitM attacks include:

  • ARP poisoning
  • DHCP spoofing
  • DNS poisoning

ARP poisoning

One way for an attacker to execute a network MitM attack is to send gratuitous Address Resolution Protocol (ARP) packets (unsolicited ARP replies) to each victim node, thereby attempting to poison their ARP cache. The attacker specifically wants to replace the MAC address of the remote victim’s IP address with the attacker’s MAC address.  

In a common MitM attack, one of the target nodes is in the attacker’s LAN, while other is in the Internet, such as when attacking computers in a wireless network. In order to execute the attack on the two victims, the attacker sends gratuitous ARP packets to the local victim and the local gateway, to ARP poison these two caches. The ARP cache of the local victim must have the attacker’s MAC address for the gateway’s IP address, and the ARP cache of the gateway must have the attacker’s MAC address for the local target’s IP address. This way, all communication from the target node to the Internet (via the gateway) passes through the attacker.

Note that ARP poisoning attacks are bidirectional: the attacker can insert himself between the Internet server and the victim host. While the attack is in progress, the victim host in the LAN thinks that it’s talking to the Internet server directly, while the Internet server thinks that it’s talking to the LAN host directly -- when in reality an attacker is intercepting the network traffic.

ARP poisoning in detail:

  1. Attacker selects two target nodes on the same local subnet (for example, a client and the gateway).
  2. Attacker sends gratuitous ARP packets to the local node with the IP address of the default gateway but the attacker’s MAC address.
  3. Attacker sends gratuitous ARP packets to the default gateway with the IP address of the client node but the attacker’s MAC address.
  4. Attacker starts filtering IP packets so that only those coming from the local client node and local gateway targets are intercepted; this is necessary so that the attacker can differentiate traffic from the victim and other Internet-bound traffic.

DHCP spoofing

A DHCP server provides IP information such as the default gateway IP address to network nodes that join a local network. An attacker can pose as a DHCP server and send forged DHCP acknowledgments to any connecting nodes. If the connecting node receives the DHCP acknowledgment from the attacker before the real DHCP server, it uses the information provided by the attacker to resolve its IP configuration. The attacker can supply its own IP address for the default gateway address in forged DHCP requests in order to execute MitM attacks between the connecting node and either a local network node or a remote one.  

This attack is unidirectional: Packets sent from the victim node to the Internet victim will be intercepted, but packets sent back to the local victim will not be intercepted.

In detail (victim A is local and victim B is remote):

  1. Attacker starts DHCP server that sends the attacker’s IP address for the default gateway IP address.
  2. Victim A connects to the network (note that the victim must obtain their IP information via DHCP).
  3. Attacker beats race condition against the real DHCP server and sends a forged DHCP acknowledgment to victim A.
  4. Victim A receives the attacker’s IP as the default gateway in the DHCP response message.
  5. Attacker starts intercepting IP packets sent from victim A to victim B, as the attacker is now the gateway for victim A.

DNS Poisoning

A DNS server provides the IP address associated with a given domain/host name. It is possible for an attacker to replace a valid domain name’s IP with an attacker-controlled IP address. By doing so, any victim that resolves the given domain/host name will receive a response that includes the attacker’s address.  Attackers can use this technique to execute MitM attacks on any of the DNS server’s clients. Thus, this technique can be used to execute MitM attacks on different users simultaneously to, for example, execute phishing attacks.

In detail:

  1. Attacker finds the DNS server of one of the victim clients.
  2. Attacker sets up a malicious DNS server that sends malicious IP address information for a valid domain/host name (DN).
  3. Attacker tricks any of the clients of the DNS server found in step 1 to make a request to their malicious DNS server.
  4. Attacker waits until server client makes a request to their malicious DNS server.
  5. Attacker responds with a DNS response that indicates that domain name DN corresponds to an attacker’s IP address.
  6. Attacker waits until victim client connects to the domain name DN. If the attack succeeds, the attacker is able to intercept this connection, because the victim is actually connecting to the attacker-controlled server.

Step 2: Analyze Causes and Countermeasures

The next step in testing for MitM vulnerabilities is to understand what causes them and how to defend against them.

Trusting Keys and Certificates

Let’s go back to the first scenario  above. The reason  that attacker Eve can can execute the MitM attack is because Bob accepts Eve’s key as if it were Alice’s. The problem arises because Bob is  too trustful of the key. The same problem applies to PKI (Public Key Infrastructure), but with certificates instead of keys. For instance, a client that wants to connect to an application site starts using the certificate sent by the site. An attacker can intercept the conversation and send the client a fake certificate, claiming that it comes from the application site. If the client trusts the fake certificate, the MitM attack becomes possible.

The solution to this problem is to use a trusted Certificate Authority (CA) to verify that the certificate, digital signature, or key belongs to the person using it. By adding strong authentication on PKI systems, any certificate coming from a non-trusted CA will be revoked, including the attacker’s fake certificate.

It is important to note that common methods used to sign and encrypt Internet communications (SSL/TSL/SSH) can be vulnerable to MitM attacks as they implement PKI. An attacker that intercepts traffic between a victim browser and an application site using SSL can create a fake SSL certificate and send it to the victim as described above. Most browsers will show a warning indicating that the connection requires a new, and in most cases unverified, certificate. If the Internet user accepts the certificate, the MitM attack can begin. Furthermore, vulnerabilities in past versions of Internet Explorer and other popular browsers  can allow for transparent MitM SSL attacks in which  this warning is not shown  if the fake certificate is trusted by any certificate authority. [i]

Allowing Malicious Network Packets

Network MitM attacks exist because attackers can send arbitrary packets over computer networks such as wireless LANs to execute attacks such as ARP poisoning or DHCP spoofing. Network administrators can help to mitigate the risk of such attacks by properly configuring networks and deploying the appropriate tools.

For instance, administrators can protect computers against both DHCP spoofing and ARP poisoning using the DHCP snooping functionality built into some network switches [ii]. To protect against DHCP spoofing, this functionality differentiates network ports that are allowed to make DHCPs requests and acknowledgments from those that are only allowed to make DHCP requests. This means that it denies any possible forged DHCP acknowledgements sent by an attacker posing as a DHCP server. In addition, DHCP snooping monitors ARP packets and checks if they are legitimate by comparing them to a MAC-to-IP table built during DHCP snooping. Other tools to protect against ARP poisoning include the Unix-based Arpwatch and Windows-based XArp.

To defend against DNS poisoning, it is necessary to add the appropriate network protection at the DNS server and to be less trustful of DNS responses. A solution is to use a secure version of DNS called DNSSEC that uses cryptographic certificates to validate the authenticity of DNS messages.   After deploying DNSSEC, any fake DNS server will not be able to impersonate ownership over a domain that it does not rightfully control.

It is important to note that defenses against MitM attacks are constantly revised and updated. Readers are encouraged to update to the latest MitM defense methods.

Step 3: Start Testing and Exploring

Now that common MitM attack scenarios and  their causes and countermeasures have been reviewed, it is necessary to start using available network security tools to test for the presence of MitM vulnerabilities in your environment.

Test for MitM through ARP poisoning

Follow these steps to test for susceptibility to MitM attacks via ARP poisoning:

  1. Download and install Cain and Wireshark on the attacker’s box.
  2. Run Cain.
  3. Click Configure in the menu and select the network interface (it can be a wireless interface).
  4. Click the Sniffer tab and then the Hosts sub-tab.
  5. Start the sniffer and click the plus (+) sign.
  6. Select a range of IPs to scan their MAC addresses (include the target box in the range), and then click OK. Both the gateway’s and the victim’s IPs (and their MACs) should appear in the hosts list.
  7. Click the ARP poisoning sub-tab.
  8. Click on the plus (+) sign and add an ARP route from the victim to the gateway.
  9. Start the ARP poisoning attack by pressing the ARP button. As soon as the victim becomes active, its status changes from “idle” to “poisoning.” The lower pane will begin to show the packets being intercepted (see Figure 1).
  10. Start Wireshark and start capturing network traffic from the same interface selected in Cain.

Expected results: The first check you can conduct to see if the ARP poisoning attack was successful is to run the arp -a command on the victim’s box (Windows or UNIX). After executing the attack, the entry for the gateway should be that of the attacker’s box, rather than the real MAC of the gateway. For instance, in Windows running arp -a before the attack gives this:

C:\>arp -a
Interface: --- 0x8
Internet Address IP Address Type 00-13-49-5c-e3-de dynamic ff-ff-ff-ff-ff-ff static 01-00-5e-00-00-16 static

After a successful attack, the gateway entry in the victim’s ARP cache will be different; it will equal to the attacker’s MAC:

C:\>arp -a

Interface: --- 0x8
Internet Address IP Address Type 00-1b-77-b2-73-f2 dynamic ff-ff-ff-ff-ff-ff static 01-00-5e-00-00-16 static

A successful ARP poisoning attack will be visible both in Cain and Wireshark. In Cain, the lower pane of the Sniffer->ARP tab shows the packets being sniffed. You can use Wireshark to see the actual contents of the packets (see Figure 2).

Figure 1 - Using Cain to ARP poison a connection between a victim and a gateway
Figure 2 - Using Wireshark to read the contents of the sniffed packets

Note: For more information about ARP poisoning, refer to the How to Test for ARP Poisoning article.

Test for MitM through DHCP spoofing

Follow these steps  to test susceptibility to MitM attacks via DHCP spoofing (tested from a UNIX system):

  1. On the attacker’s system, run the ifconfig command and note the current IP address and network mask. Take note of the system’s DNS resolver IP as well. (On UNIX systems, DNS server information generally resides in the file /etc/resolv.conf.)
  2. Download and install Ettercap on the attacker’s system.
  3. Run Ettercap with the GUI option for simplicity: ettercap -G.
  4. Remove any targets from Ettercap (this is required for DHCP spoofing).
  5. Use the main menu to navigate to Mitm->DHCP Spoofing.
  6. Fill in DHCP spoofing server information, providing an IP pool with a range of 15 IPs, as shown in Figure 3.
  7. Click OK to start the attack.
  8. On the victim’s computer (Windows), use ipconfig /release to release the current DHCP lease.
  9. Execute ipconfig /renew to request a lease from the DHCP server; this triggers the attack.
  10. On the victim’s computer, attempt to connect to an FTP server and supply login credentials.

Expected result: The MitM attack succeeds if executing the ipconfig /renew command in step 8 sets the default gateway on the victim’s machine to the attacker’s IP address. In addition, if the attack succeeds, Ettercap (or other tools on the attacker’s machine) can capture the username and password provided in step 9, as well as any other IP traffic destined for the Internet or networks other than the local subnet.

Figure 3 - Using Ettercap to execute DHCP Spoofing attack

Test for MitM through DNS spoofing

Follow these steps to test susceptibility to MitM attacks via DNS server spoofing, thus poisoning the client’s resolver:

  1. Select the target DNS server.
  2. Set up a client to use the target DNS server.
  3. Set up an attacker-controlled DNS server to send specially crafted responses (see step 6).
  4. Set up an attacker-controlled web server.
  5. Set up a trigger that starts a DNS lookup query from within the target DNS server to the attacker DNS sever.
  6. Use the attacker DNS server to reply to the query with extra information in the DNS packets. Set the Answers, Authoritative nameservers, and Additional records fields of the DNS packets to direct all futures requests to a .COM domain to resolve to the IP address of the attacker web server (from step 4).
  7. Open the web browser from step 2 and navigate to any .COM domain.

Expected result: The MitM attack succeeds if the web browser displays the content from the attacker-controlled web server.

Note: For more information about DNS poisoning, refer to the How to Test for DNS Poisoning article.

Sniffing an HTTPS connection

SSL and SSH MitM tests can also be run using Ettercap and Cain. Both programs automatically create a fake certificate on the fly to substitute for the real certificate.

In Ettercap, follow these instructions to sniff an HTTPS connection:

  1. Download and install Ettercap on the attacker’s box (UNIX/Linux).
  2. Open /usr/local/etc/etter.conf configuration file in text editor.
  3. Uncomment both redir commands (as shown in the table below).
  4. Execute MitM attack using ARP poisoning. Select the victim’s IP and the default gateway’s IP in the Ettercap hosts.
  5. Execute the ARP poisoning attack.
  6. On the victim’s computer, log into Gmail, which uses HTTPS for logins, or any SSL host.
  7. Click OK when prompted by any certificate warning boxes (see Figure 4).
  8. Enter a user name and password and submit the login form.
#redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
#redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

Figure 4 - victim receives certificate warning during HTTPS MitM attack 

Expected result: The MitM attack succeeds if Ettercap captures the victim’s username and password. Examining the SSL certificate that the web browser prompted you to accept can also reveal if the attack succeeded.

Step 4: Execute Additional Testing

As the final step in testing for MitM attacks, it is necessary to cover additional attack methods and decide what to do after the attack has succeeded.

Use Different Attack Methods

This article has covered three popular forms of network MitM attacks: ARP poisoning, DNS spoofing (made more effective by employing DNS cache poisoning techniques), and DHCP spoofing. Make sure to address any additional MitM attacks, such as port stealing. Port stealing consists of flooding a network switch with gratuitous ARP packets, flooding the switch’s CAM table so that the switch forwards packets destined to the victim to all computers on the switch (thus effectively turning the switch in toa hub). It is possible to execute port-stealing attacks using Ettercap, and another utility called macoff. Other attacks include ICMP redirection, route mangling, traffic tunneling, and IP spoofing [i].

What to do After Attack Succeeds

Once you successfully execute an MitM attack and are between the two victim nodes, there are different attacks that you can try, including network sniffing, hijacking, packet injection, and packet filtering. Ettercap provides a set of filters that can be used for different attacks, such as dropping packets from certain users and executing Denial of Service attacks, or downgrading SSH versions in order to use a less-secure connection. For more information, view Full Disclosure’s video about MitM attacks in Ettercap [ii].


Man-in-the-Middle attacks are generally network-related attacks used to sniff network connections or to act as a proxy and hijack a network connection without either of the victims being aware of this. To test for the presence of this vulnerability in a computer network, it is first necessary to understand the common attack scenarios involved. Then, learn the causes of and the defenses against MitM attacks. Network MitM tools such as Cain and Ettercap should be used to execute the different attack scenarios, including sniffing HTTPS communications. Once positioned between two hosts, an attacker can use appropriate tools to execute multiple attack types, such as sniffing, hijacking, and command injection.

[i] Man-in-the-Middle Attacks. Alberto Ornaghi and Marco Valleri. Blackhat Europe 2003,