If you already got bored with psychology-based hacking tactics like Phishing Attack or Supply-Chain Attack, here are something more technical that might interest you: Man-In-The-Middle Attack.
As mentioned in this Fake BTS Attack post, Man-In-The-Middle Attack (MITM) was used by hackers to intercept connection between user’s mobile phone and telecom provider to eavesdrop conversations or steal passwords. MITM does not exploit user’s psychology layer, it exploits signal’s physical attributes. This type of attack is not limited to BTS networks. Wi-Fi Networks, Local Area Networks (LANs), and IoT Networks can also be vulnerable to MITM attacks.
1. What is Man-In-The-Middle Attack ?
Man-In-The-Middle Attack is when hackers try to sit between a victim’s device and whatever victim’s device want to connect to such as a website, a server, or a wifi router. This is achievable in multiple ways, depends on how devices connect to each others. After successfully deployed, MITM Attack can intercept every packets travel between user’s device and counterpart systems, enable hackers to eavesdrop, steal or impersonate depends on hackers’s purpose. Below is a few scenarios that demonstrate MITM concept:
1.1. In a Wifi Network
We might already familiar with Wifi routers in daily basis. Technically, these routers are also a small computers configured to operate as a Wireless Access Point (AP). Any Linux computer with a compatible Wi-Fi adapter can be configured to operate as a Wireless Access Point (AP) too. This allows these Linux computers to advertise a wireless network that nearby devices, such as mobile phones or other laptops, can see and potentially connect to. The basic process is like so:
- The attacker prepares a Linux laptop and a Wi-Fi adapter that supports Access Point mode.
A USB adapter such as the Alfa AWUS036ACM can be used because it supports AP mode on Linux with the appropriate driver. The built-in Wi-Fi adapter may also work if it supports the required mode. - The attacker installs software to turn the Linux laptop into a Wi-Fi Access Point.
On Linux, tools such as hostapd can configure the wireless adapter to operate as an AP. The attacker can then define the network name (SSID) and other wireless parameters. - The attacker configures the AP with a network name that looks legitimate.
For example, they might name itCoffeeShop_WiFito imitate a nearby legitimate network. The purpose is to make the rogue AP appear familiar to people looking for Wi-Fi. - The Linux laptop provides network connectivity to connected devices.
The attacker can configure the machine to act as a gateway, forwarding traffic between connected clients and another network. This creates the possibility of placing the attacker between the victim and the Internet. - A victim connects to the rogue network.
Once the victim’s phone or laptop connects, its network traffic may pass through the attacker’s Linux machine before reaching its destination. - The attacker is now positioned to attempt a MITM attack.
The attacker may inspect traffic that is not encrypted or properly protected. However, properly configured HTTPS/TLS connections still provide strong protection against simply reading or modifying the encrypted application data.
1.2. In a Local Area Network
Similar to Wi-Fi, a MITM attack can happen inside a Local Area Network as well but with more sophisticated attacks. For example:
1.2.1. CAM Table Flooding
Every device, from laptops and phones to routers and smart TVs, can be identified by its MAC address. A MAC address is a unique identifier assigned to a device’s network interface, for example, A4:5E:60:12:3B:9F. In a Local Area Network (LAN), the switch that handles communication between devices also keeps a table mapping MAC addresses to ports, so it knows where each device is connected and can send traffic to the right place. This table is known as the CAM table. A CAM table might look something like this:
MAC Address Port------------------ ----A4:5E:60:12:3B:9F 17C:8B:CA:45:21:10 2D8:3A:DD:91:7F:42 3B0:35:9F:AA:12:67 4
For example, the switch has learned that:
A4:5E:60:12:3B:9F→ Port 1 (laptop)7C:8B:CA:45:21:10→ Port 2 (phone)D8:3A:DD:91:7F:42→ Port 3 (printer)B0:35:9F:AA:12:67→ Port 4 (smart TV)
So when the switch receives data destined for D8:3A:DD:91:7F:42, it looks up the address and sends the data through Port 3.
In older switches without port security, an attacker can take advantage of the CAM table by sending a large number of fake MAC addresses to the switch. As the table fills up, the switch may no longer know where a device is connected and start flooding traffic to multiple ports. This can give the attacker an opportunity to see traffic that normally would not be sent to their device, turning a simple network switch into something closer to a hub. This attack can happen like so:
- The attacker connects a Linux laptop to the same LAN as the target switch.
A normal Ethernet connection is enough for the attacker to participate in the local network. - The attacker uses a CAM-table flooding tool to generate many Ethernet frames with different source MAC addresses.
Tools such as macof, which is part of the dsniff toolkit, can be used to generate large numbers of frames with spoofed MAC addresses. The purpose is to fill the switch’s CAM table. - The switch starts encountering unknown destination MAC addresses.
When the switch cannot find a destination MAC address in its CAM table, it may flood the corresponding frames through multiple ports within the VLAN. - The attacker’s network interface receives some of the flooded traffic.
The attacker can put the interface into an appropriate packet-capture mode and receive frames that reach that port. - The attacker uses Wireshark or tcpdump to capture and inspect the traffic.
Wireshark provides a graphical interface for examining individual packets, while tcpdump provides a command-line way to capture and filter network traffic. - The attacker examines what information is exposed.
Packet captures can reveal metadata such as MAC/IP addresses, ports, protocols, packet sizes, and timing. If the application uses unencrypted protocols, the actual contents may also be visible. Properly configured HTTPS/TLS, however, keeps the application data encrypted.
CAM flooding does not guarantee that all traffic becomes visible. Modern switches can use protections such as port security, MAC limits, VLAN segmentation, and storm-control mechanisms to mitigate this technique.
1.2.2. ARP Table Attack
Alongside CAM tables, devices also maintain another table to help map an IP address to a MAC address so that they can communicate with the right device on the local network. This table is known as the ARP table. It keeps track of which MAC address belongs to each IP address that a device has recently communicated with. An example ARP table might look like this:
IP Address MAC Address--------------- -----------------192.168.1.1 A4:5E:60:12:3B:9F192.168.1.10 7C:8B:CA:45:21:10192.168.1.20 D8:3A:DD:91:7F:42
Similar to the CAM table, an attacker can abuse this by sending fake ARP messages to make a device associate the attacker’s MAC address with another device’s IP address, such as the network gateway. This can place the attacker in the middle of the communication, allowing them to potentially observe or manipulate traffic. This attack can happen like so:
- The attacker connects a Linux laptop to the same LAN as the victim.
The attacker needs to be on the same local network because ARP operates within the local network segment. - The attacker sends forged ARP messages to the victim.
Tools such as Ettercap, Bettercap, or arpspoof can be used in a controlled lab environment. The attacker sends ARP information that falsely associates the attacker’s MAC address with the network gateway’s IP address. - The victim updates its ARP cache with the forged information.
The victim now believes that the attacker’s MAC address belongs to the gateway. As a result, traffic intended for the gateway can be sent to the attacker’s computer. - The attacker also poisons the gateway’s ARP cache.
The attacker can send forged ARP information to the gateway so that the gateway associates the victim’s IP address with the attacker’s MAC address as well. - The attacker forwards the traffic instead of simply dropping it.
The Linux machine forwards packets between the victim and the real gateway. This allows the victim’s Internet connection to continue working while the attacker remains in the middle. - The attacker captures the traffic passing through the machine.
Tools such as Wireshark or tcpdump can be used to capture and inspect the packets that pass through the attacker’s interface. - The attacker examines the captured traffic.
Unencrypted protocols may expose their contents, while HTTPS/TLS normally keeps application data encrypted. The attacker can still observe metadata such as IP addresses, ports, protocols, packet sizes, and timing.
1.2.3. DHCP Poisoning
Most devices today are assigned an IP address from a DHCP server. DHCP (Dynamic Host Configuration Protocol) is a service that automatically gives devices the network settings they need to communicate, such as an IP address, gateway, and DNS server. A DHCP server usually runs on a router or dedicated network server. The DHCP server assigns these settings to devices through a protocol named DHCP, using a simple exchange of messages between the device and the server.
The process is often described as DORA:
Device DHCP Server │ │ │── DHCP Discover ──────────►│ "Is there a DHCP server?" │◄─ DHCP Offer ──────────────│ "I can give you this IP." │── DHCP Request ───────────►│ "I'll take that IP." │◄─ DHCP ACK ────────────────│ "It's yours." │ │
In a normal network, the device receives its IP address and other settings from the legitimate DHCP server. The problem is that DHCP was designed with a level of trust: a device generally has no built-in way to know whether a DHCP response came from the legitimate server or a rogue one. An attacker on the same LAN can take advantage of this by running a rogue DHCP server and responding to requests before the legitimate server does. The attacker could then provide a malicious gateway or DNS server, potentially putting themselves in a position to observe or redirect the victim’s traffic. This technique is commonly known as DHCP poisoning. This attack can happen like so:
- The attacker connects their Linux computer to the LAN.
The attacker first needs to be on the same network as the victim, because DHCP requests are normally exchanged within the local network. - The attacker runs a rogue DHCP server.
Instead of waiting for the legitimate DHCP server to respond, the attacker’s computer also listens for DHCP requests. Tools such as Bettercap can be used to demonstrate this behavior in a controlled lab environment. - The victim requests network configuration.
When the victim’s device joins the network, renews its lease, or otherwise requests a DHCP configuration, it broadcasts a DHCP request looking for a DHCP server. - The attacker responds with malicious network settings.
The rogue DHCP server attempts to respond to the victim and provide network configuration controlled by the attacker. For example, the attacker may advertise their own computer as the default gateway or provide a DNS server controlled by the attacker. - The victim starts using the attacker’s settings.
If the rogue response is accepted, the victim may begin sending Internet traffic through the attacker’s computer. The attacker has effectively placed their machine between the victim and the legitimate gateway. - The attacker forwards the traffic to keep the connection working.
To avoid immediately revealing the attack, the attacker can forward the victim’s traffic to the legitimate gateway. From the victim’s perspective, the Internet may continue to work normally. - The attacker can inspect the traffic passing through their computer.
Tools such as Wireshark or tcpdump can be used to observe the traffic. Unencrypted protocols such as HTTP may expose their contents, while properly configured HTTPS/TLS protects the application data from being read or modified by the attacker.
The important idea is that DHCP Poisoning does not directly break encryption. Instead, it attacks the process that tells a device where to send its traffic. By supplying a malicious gateway or DNS configuration, the attacker attempts to make the victim send traffic through infrastructure controlled by the attacker.
1.2.4. DNS Spoofing
Another option beside DHCP is DNS. DNS (Domain Name System) is the system that translates human-friendly domain names, such as google.com, into IP addresses that devices can use to connect to the right server. Every device typically consults a DNS server when it needs to find the IP address behind a domain name. Communication between a device and a DNS server is usually handled through the DNS protocol, commonly using UDP port 53, although DNS can also use TCP and encrypted protocols such as DoH and DoT.
The basic process is like this:
Device DNS Server │ │ │── "What is google.com?" ──►│ │ │ │◄── "142.250.x.x" ──────────│ │ │ │──── Connect to that IP ───►│
Once the device receives the IP address, it can connect to the corresponding server. This also creates an opportunity for an attacker on the network: if they can interfere with DNS responses or trick the device into using a malicious DNS server, they may redirect a domain name to an IP address controlled by them. This technique is commonly known as DNS spoofing or DNS poisoning. This attack can happen like so:
- The attacker connects their Linux computer to the LAN.
The attacker needs to be on the same local network so they can interfere with the victim’s DNS requests. - The attacker positions themselves where they can observe DNS traffic.
This can be achieved through techniques such as ARP spoofing or DHCP poisoning, which can cause the victim’s DNS requests to pass through the attacker’s computer. - The victim asks a DNS server for an IP address.
For example, the victim wants to visitexample.com, so their device sends a DNS query asking which IP address belongs to that domain. - The attacker sends a forged DNS response.
Instead of allowing the victim to receive the legitimate answer, the attacker attempts to provide a fake DNS response that associatesexample.comwith an IP address controlled by the attacker. - The victim connects to the wrong server.
If the forged response is accepted, the victim’s browser may connect to the attacker’s server instead of the legitimate server. The attacker could use this to redirect the victim to a fake website, phishing page, or other attacker-controlled service. - The attacker may try to make the fake website look legitimate.
For example, the attacker could create a website that visually resembles a familiar login page. This is where DNS spoofing can become particularly dangerous: the victim may believe they are visiting the correct domain even though their connection has been redirected. - HTTPS can make the attack much harder.
DNS spoofing alone does not allow an attacker to impersonate a legitimate HTTPS website. If the victim connects to the attacker’s server but the server cannot provide a certificate valid for the requested domain, a properly configured browser should display a certificate warning rather than silently trusting the connection.
The key idea is that DNS Spoofing attacks the process of translating a domain name into an IP address. Instead of breaking HTTPS directly, the attacker attempts to make the victim go to the wrong IP address in the first place.
This is also why modern security mechanisms such as HTTPS/TLS, certificate validation, DNSSEC, and encrypted DNS can significantly reduce the effectiveness of traditional DNS spoofing attacks.
1.3. In a IoT Network
IoT, or Internet of Things, is actually a combination of LAN, Wi-Fi, and Internet-connected services. It means that many of the tricks that work against LAN and Wi-Fi networks can also be used against IoT devices. A smart camera, smart TV, or smart plug still needs to connect to a network, receive an IP address, find other devices, and communicate with online services. If an attacker can get into the same network, techniques such as CAM table flooding, ARP spoofing, DHCP poisoning, or rogue access points can potentially be used against these devices as well. The difference is that an IoT device may control something in the physical world, making a network attack potentially more than just a data-security problem. This attack can happen like so:
- The attacker joins the same network as the IoT device.
The attacker first needs access to the same LAN or Wi-Fi network. This could be a home network, office network, or an IoT-specific network. - The attacker attempts to place their computer between the IoT device and its gateway.
Techniques such as ARP spoofing, DHCP poisoning, or a rogue Wi-Fi access point can potentially redirect the IoT device’s traffic through the attacker’s computer. - The IoT device continues communicating normally.
The attacker forwards the traffic to the legitimate gateway so that the device can continue communicating with its cloud service or other systems. Because the connection still appears to work, the attack may not be immediately obvious. - The attacker captures the IoT traffic.
Tools such as Wireshark or tcpdump can be used to inspect packets passing through the attacker’s computer. The attacker may learn information such as the destination servers, protocols, IP addresses, timing, and other network metadata. - Unencrypted communication may expose sensitive information.
If the IoT device uses an unencrypted protocol such as HTTP, an attacker may be able to read or modify the transmitted data. Depending on the device, this could potentially include commands, sensor data, or other information. - Encrypted communication provides an important layer of protection.
If the IoT device properly uses HTTPS/TLS or another authenticated encryption protocol, the attacker may still be able to observe network metadata, but should not be able to read or modify the protected application data. - Weak IoT security can make the situation worse.
Some IoT devices have outdated firmware, weak certificate validation, insecure protocols, or poorly protected local management interfaces. These weaknesses can give an attacker more opportunities to interfere with communications.
2. Real World Incidents
1. Firesheep – Public Wi-Fi Session Hijacking (2010)
In 2010, a security researcher released Firesheep, a Firefox extension that demonstrated how dangerous insecure public Wi-Fi could be. The tool could capture unencrypted session cookies from other users on the same Wi-Fi network and use them to access their existing web sessions.
The demonstration became widely discussed because many websites encrypted the initial login with HTTPS but continued to send session cookies over unencrypted HTTP afterward. Someone sharing the same Wi-Fi network could therefore potentially hijack another user’s authenticated session.
Firesheep was not itself a sophisticated MITM implementation, but it made the underlying problem very visible: an attacker who can observe traffic on a shared network may be able to steal information that applications failed to protect with encryption.
2. Kasa Cameras – Hardcoded RSA private key
TP-Link is a networking and smart-home device manufacturer, and Kasa is its smart-home product line, including devices such as cameras, plugs, and switches. In 2026, researchers discovered that the firmware of some Kasa EC70 and EC71 cameras contained a hardcoded RSA private key that was shared across affected devices. TP-Link later confirmed that the vulnerability could allow an attacker on the local network to compromise the confidentiality of communications with the device’s web management interface and potentially perform a Man-in-the-Middle (MITM) attack.
This opens an interesting attack scenario. Imagine an attacker gets a Kasa device to connect through a Rogue Access Point controlled by a Linux laptop. The laptop now sits between the Kasa device and the rest of the network, allowing the attacker to intercept its traffic. If the attacker also has access to the exposed cryptographic key, encrypted communications that should normally be protected may become vulnerable to interception or MITM manipulation.
The attack could conceptually look like this:
Kasa Camera │ │ Wi-Fi ▼Linux Laptop Rogue AP │ ├── Intercept traffic ├── Forward legitimate traffic └── Potentially modify responses │ ▼ Kasa Service / Device
For example, a Kasa device may send a request and expect an authenticated response. Instead of simply forwarding the legitimate response, an attacker who can successfully perform a MITM attack could potentially replace it with a crafted response. If the device accepts that response without properly verifying its authenticity and integrity, the attacker could influence how the device behaves.
The important point is that the Rogue AP itself does not magically break the encryption. It gives the attacker a position from which to intercept the communication. The cryptographic weakness is what can turn that position into a much more powerful MITM attack.
3. Yi Home Camera – Unencrypted Control Protocol
Yi Camera is another example that demonstrates how a weakness in an IoT communication protocol can turn a Wi-Fi network into an attack surface. Yi Camera is a Wi-Fi security camera that communicates with the Yi Home mobile app to provide camera control and other functions. The problem is that its p2p_tnp protocol uses UDP without encryption for a significant portion of its communication.
This means that if an attacker successfully deploys a Rogue AP and gets the camera or phone to connect through it, the attacker can intercept the communication between them. Instead of seeing protected encrypted data, the attacker may be able to read the actual messages exchanged between the camera and the app.
The attacker could then capture authentication information or replay and modify some of the messages. In its research, Cisco Talos found that captured authentication tokens could be reused and that some camera commands could be manipulated. This means a simple position inside the Wi-Fi communication path could potentially become a way to access or control the camera.
Yi Camera │ │ Wi-Fi ▼Rogue AP(Attacker) │ ▼Yi Home App │ └── Intercept / replay / modify traffic
3. How to know someone is deploying a Man In The Middle Attack ?
3.1. In Wifi environment
The most concerned security risk in a Wi-Fi environment is whether someone has introduced a Rogue Access Point (Rogue AP). A Rogue AP is an unauthorized wireless access point that appears on the network, either intentionally deployed by an attacker or accidentally introduced by someone inside the organization.
A useful open-source tool for detecting Rogue APs is Kismet. It passively monitors nearby Wi-Fi networks and records information such as SSIDs, BSSIDs, channels, signal strength, and encryption types. This can help identify suspicious situations, such as an unknown AP using the same SSID as a legitimate company network.
For example, suppose the legitimate network is:
SSID: Company-WiFiBSSID: AA:BB:CC:11:22:33Channel: 6
An attacker could deploy another AP using the same Company-WiFi SSID:
SSID: Company-WiFiBSSID: DE:AD:BE:EF:12:34Channel: 11
A wireless monitoring system can notice that the same SSID is now being advertised by an unexpected BSSID. This does not automatically prove that the second AP is malicious, but it is a strong reason to investigate.
In larger environments, organizations commonly use Wireless Intrusion Detection/Prevention Systems (WIDS/WIPS) to continuously monitor the wireless spectrum and compare detected access points against known, authorized infrastructure. Tools such as Kismet are useful for investigation and monitoring, while WIDS/WIPS can provide centralized detection and alerting across an enterprise.
The key idea is simple: before looking for sophisticated MITM behavior, first ask whether an unauthorized device has appeared in the Wi-Fi environment. A Rogue AP can be the first visible sign that someone is trying to position themselves between users and the network.
3.2. In Local Area Network environment
On a wired LAN, detecting a Man-in-the-Middle attack usually means looking for abnormal changes in how devices communicate with each other. One of the most useful things to monitor is ARP traffic. If the same IP address suddenly appears to be associated with different MAC addresses, or a device receives an unusual number of unsolicited ARP replies, it could indicate ARP spoofing.
Tools such as Wireshark can be used to inspect ARP packets and identify these unusual changes. arpwatch can continuously monitor IP-to-MAC mappings and alert when a mapping changes unexpectedly, while Zeek can provide broader network monitoring and help identify suspicious traffic patterns.
DHCP is another area worth monitoring. A normal LAN usually has a known DHCP server, so a new device suddenly responding to DHCP requests can be a sign of a Rogue DHCP server. Network monitoring tools can detect multiple DHCP servers or unexpected DHCP responses and alert the administrator.
LAN
│
┌───────┴────────┐
│ │
ARP Monitor DHCP Monitor
│ │
Wireshark Zeek
arpwatch IDS/IPS
│ │
└───────┬────────┘
↓
Detect anomalies
↓
Investigate MITM
The important point is that a MITM attack does not always announce itself directly. Instead, it often leaves small traces at the network layer—such as unexpected ARP mappings, rogue DHCP responses, or unusual traffic patterns. Monitoring these changes can help detect an attacker before the attack becomes a larger security incident.