Inheriting a surveilled internet, with outdated protocols and low authentication rigor, is perhaps one of the biggest causes of cybersecurity vulnerabilities today.
Several network protocols have weak security rules, performing little or no verification of the legitimacy of a given communication.
This fragile trust is the main attack surface for man-in-the-middle (MITM) cyberattacks. MITM is a technique in which an attacker intercepts and/or alters communication packets without the parties involved in the communication noticing.
By exploiting the different OSI Layer protocols1, MITM is a cyberattack as old as the internet itself. It is still widely used today, targeting victims ranging from local networks (LAN/Wi-Fi) to DNS servers and HTTPS connections.
In this article, we will explore the main network vulnerabilities that enable a MITM attack, some tech tools for penetration and defense, as well as famous cases.
About the authors
Pedro Sydenstricker
Community Writer
Pedro is a member of the Nym community and co-founder of the TupiNymQuim squad. A software developer and digital privacy activist, he writes about technology, privacy, and society.
Formatting, encryption, and encoding (TLS/SSL, compression, data representation).
Use of weak TLS versions, lack of secure configuration, absence of session/signature validation.
Use of weak TLS versions, lack of secure configuration, absence of session/signature validation
SSL/TLS downgrade, SSL stripping (remove/force HTTP), exploitation of weak ciphers to decrypt traffic
Session
Establishment, maintenance, and termination of sessions (cookie/session tokens, dialog control).
Predictable tokens or tokens not linked to the client, cookies without security flags (HttpOnly, Secure).
Session hijacking/sidejacking (theft of cookies/tokens), session hijacking after credential capture
Transport
End-to-end transport (TCP/UDP): segmentation, flow control, ports, and connections
No encryption at the transport level, predictable sequence numbers, possibility of injection/RST
DNS spoofing/cache poisoning for redirection, DHCP spoofing to provide malicious gateway/DNS; rogue gateway insertion
wifi.recon
Discovers APs and clients, maps the wireless environment to plan rogue AP/eavesdropping
Allows inventory of Wi‑Fi networks and detection of suspicious APs; useful in wireless audits
wifi.ap
Creates rogue AP / evil‑twin to lure clients and capture traffic (lab)
Used to test connection policies, captive portals and rogue AP detection; validates endpoint controls
sniffer (pcap)
Captures packets/streams for analysis of credentials, headers, and unencrypted payloads
Enables incident reconstruction and validation that sensitive traffic is encrypted; IDS/monitoring testing
arp.spoof
Poisons ARP caches to position MITM on the LAN and redirect traffic
Used to validate detection of ARP poisoning, DHCP/ARP spoof protection policies, and network segmentation
net.recon / net.probe
Discovers hosts, associates IP↔MAC, and maps local topology to choose targets
Allows attack surface assessment, asset inventory, and verification of VLAN isolation
dns.spoof
Redirects DNS resolution to controlled servers (phishing, clone sites)
Tests robustness of DNSSEC, resolver monitoring, and unexpected responses; validates DNS filtering policies
http.proxy
Interposes HTTP/S requests (in lab with TLS inspection) to view/modify traffic and demonstrate SSL‑stripping
Assesses robustness of TLS, HSTS, certificate pinning; tests application protection against injection and header validation
http.server
Serves test pages or cloned pages for phishing/controlled campaigns
Allows creation of test environments for education, phishing detection, and simulation of malicious pages without real harm
tls (handshake inspection)
Inspects TLS handshakes to identify weak versions/ciphers and insecure negotiations
Helps audit TLS configurations of services, verify support for modern TLS, and measure exposure to downgrade attacks
tcp.proxy
Intercepts/manipulates TCP flows to demonstrate injection or alteration of payloads in unencrypted protocols
Used to test anomaly detection in transport layers and validate integrity of critical flows
events.stream
Real‑time event and log stream to monitor intercepted cookies/tokens/hosts
Useful to create exfiltration proof‑of‑concepts and to validate SIEM/IDS alerts from real events
mac (changer)
Changes the attacker's host MAC to mimic other devices and avoid MAC‑based detection
Tests MAC‑based access control policies and link‑layer authentication mechanisms
arp.spoof + ip_forward (host OS)
Combination to redirect traffic via attacker with forwarding enabled (full man-in-the-middle)
Allows you to simulate malicious forwarding and test forwarding/iptables rules, routers, and egress policies
net.probe (passive)
Passive scanning to map ports/services without generating active noise
Important for non-invasive assessments and for measuring visibility that IDS/IPS have in passive mode
What is a man-in-the-middle attack?
In practical terms, a man-in-the-middle attack exploits the lack of or weak authentication at certain points in the network to intercept packets and establish the attacker between two communication points. By doing this, the attacker creates two channels: one between the attacker and the client, and another between the attacker and a server.
The main purposes of MITM attacks are:
Espionage
Credential theft
Script injections
Redirection to fake websites
Message manipulation
Session hijacking
This is a very common attack, accounting for around 35% of current cyberattacks online.2
The case of MITM and ARP
For example, in the case of the Address Resolution Protocol (ARP), which was created to translate IP addresses into MAC addresses, there is a central vulnerability: ARP believes that any response it receives is legitimate, without need of verification.
Therefore, ARP seeks to connect layers 2 and 3 of the OSI model — which we will detail shortly — which have different address records. Layer 2, specific to LANs and switches, comprises MAC addresses, but layer 3, specific to routers, understands IP addresses.
Thus, deceiving communications between different network protocols and exploiting the vulnerability of this connection is at the heart of a man-in-the-middle attacks.
Understanding vectors of MITM attacks
Low-level attacks and local network (Layers 1, 2, and 3)
At the base of the OSI model are the layers that deal with the physical medium and local delivery of frames: cables, fibers, radio signals, network cards, switches, and routers.
Layer 1 (Physical)
At this level, the risk is eminently physical: any access to the medium (an exposed cable, an installed TAP, a rogue device connected to the infrastructure) allows direct capture of signals converted into bits.
In wireless environments, the broadcast nature of the medium makes the physical layer even more vulnerable: clients and devices can be lured to a fake access point (evil twin) and have all their traffic made available to the attacker.
Furthermore, it is possible to perform cable tapping3 directly on the connection cables of that network.
Layer 2 (Link/MAC)
Here, ARP and Ethernet dominate local communication. The aforementioned Address Resolution Protocol (ARP) translates IP addresses into MAC addresses without any authentication mechanism. As already pointed out, this flaw is the root cause of classic ARP spoofing/cache poisoning in which a malicious host sends fake ARP replies to convince victims to associate the gateway IP with the attacker's MAC.
The practical result is that local traffic passes through the attacker, who can simply spy on, manipulate, or inject content.
In the context of Layer 2 wireless, the evil twin works on the same principle: getting the client to connect to a point controlled by the attacker.
Layer 3 (Network/IP)
Finally, this later deals with routing and forwarding between subnets. Its main vulnerabilities are:
IP spoofing: a technique in which the attacker falsifies the source IP address in packets sent over the network, making them appear to come from another machine. In MITM, this technique can be used to deceive routing tables or to impersonate a legitimate host, facilitating redirects or forged responses that divert traffic through the attacker.
Unauthenticated routing and traffic redirection (DNS spoofing/cache poisoning): the absence of mechanisms that verify the authenticity of routes and resolution service responses. In routers/services without authentication, an attacker can inject false routes (or manipulate DNS caches) so that names or prefixes are resolved by paths controlled by them. The practical effect is the same as ARP spoofing, but at the network level: traffic is rerouted to malicious points, allowing inspection, alteration, or blocking.
High-level attacks (Layers 4, 5, 6, and 7)
Moving up the OSI stack, Layers 4–7 deal with transport, session state, presentation/encryption, and application logic — vectors that have their protocol, configuration, and design weaknesses exploited, often without the need for direct physical access to the network.
Layer 4 (Transport)
This layer's role is to ensure end-to-end transport via TCP or connectionless delivery via UDP, relevant vulnerabilities occur when the flow is not protected by higher layers. The absence of encryption at the transport level (or above) leaves payloads and headers readable to any interceptor along the route, facilitating credential capture and data exfiltration.
In addition, the design of TCP allows for injection techniques and forged packets: an attacker who can predict or manipulate sequence numbers can insert segments, force resets (RST), or cause reconnection conditions that enable session hijacking or alteration. In practice, these attacks are used to interrupt legitimate connections, force insecure reconnections, or insert payloads into unencrypted streams.
Layer 5 (Session)
This focuses on maintaining dialogue between client and server: cookies, tokens, session identifiers, and keep-alive mechanisms. Typical flaws — cookies without Secure/HttpOnly flags, tokens transmitted in plain text, or sessions not tied to the client — open the door to sidejacking and replay attacks: an attacker who captures a valid cookie or token can reuse it on another host and take over the user's session without needing credentials.
In MITM scenarios, this is often the next step after intercepting traffic: capturing a token at Layer 4 and using it at Layer 5 for unauthorized access.
Layer 6 (Presentation/TLS)
This should be the defense layer: this is where TLS/SSL encrypts data before it is delivered to the transport. However, weak configurations, poorly managed certificates, or the absence of mechanisms such as HSTS4 allow downgrade5 and SSL-stripping6 attacks.
In these attacks, the attacker, often in a MITM position, forces the client to negotiate an insecure connection (HTTP) or takes advantage of the lack of certificate validation to insert a proxy that sees the traffic in clear text. The result is that the protection expected by the application disappears exactly where it should exist.
Layer 7 (Application)
This is the final stage: protocols and services (HTTP/S, REST APIs, SMTP, FTP, DNS in its resolution role) offer rich surfaces for exploitation — credential theft, content injection (XSS), endpoint exposure, and authentication/authorization failures. When lower layers (especially TLS) fail, the application layer is fully exposed: a user redirected to a cloned website (via DNS spoofing) or connecting via HTTP may have their credentials, cookies, and tokens exfiltrated or manipulated.
Hands-on tests combine DNS manipulation, proxies, and fake servers to demonstrate phishing, HTTPS spoofing, and exfiltration through poorly protected APIs.
Attack and defense tools
A well-known tool for performing MITM tests is Bettercap7, a modular tool written in Go, developed as an evolution of Ettercap8 and the old MITMf9. This tool allows you to discover local networks, rogue APs, ARP spoofing, DNS/HTTP proxies, TLS inspection, and packet capture in a single lightweight framework. It is important to note that it requires elevated privileges and should only be used in controlled environments or with explicit authorization.
Some of its main modules and utilities are described in this table. For more information, see the official documentation.10.
Famous cases of MITM
Tesla account phishing & MITM (2024)
Attack used: Using a phishing-based MITM, attackers phished Tesla users and interposed themselves in the auth/registration flow (e.g., tricking users into registering a new “phone key”), enabling credential/session capture and remote vehicle control (unlock/start) via the mobile-app path.11
Vulnerability/weakness exploited: Social engineering & weaknesses in the authentication/registration flows were exposed via HTTP(S) interactions (user tricked into revealing one-time codes or authorizing device links) and the ability to intercept or proxy the relevant mobile app/web traffic during the registration flow.
Attack used: Active man-in-the-middle and denial-of-service scenario where a malicious host impersonated a legitimate SSH server to a client that relies on DNS-host-key verification.12
Vulnerability/weakness exploited: A logic/verification bug in OpenSSH’s handling of VerifyHostKeyDNS (how hostkey verification and error codes are handled), allowing the attacker to spoof DNS responses (or otherwise manipulate verification) and trick clients into accepting a forged hostkey.
Salt Typhoon and U.S. telecom breach (2024–2025)
Attack used: Compromise of carrier management infrastructure followed by router reconfiguration (creation of GRE/IP-in-IP tunnels, policy routes and traffic mirroring) and deployment of persistent implants — effectively turning provider routers into transparent interception points for signaling and media (carrier-scale MITM).13
Vulnerability/weakness exploited: Chained device-level flaws and operational weaknesses: exploitation of Cisco IOS/XE web-UI and privilege-escalation CVEs (to gain root on routers) combined with credential compromise and misuse of management interfaces, allowing attackers to modify routing/forwarding state and establish covert tunnels for traffic interception.
Conclusion
Man-in-the-middle attacks persist because they exploit both technological gaps and misplaced trust in the network. From large-scale intrusions like Salt Typhoon to targeted phishing campaigns such as the Tesla case, these incidents reveal how attackers continue to bypass weak encryption practices, poor authentication, and outdated routing protocols.
Mitigation depends on layered defense: encrypting all traffic with strong TLS configurations, enforcing HSTS and certificate pinning, securing routers and DNS with authenticated mechanisms, and constantly monitoring for anomalies.
Ultimately, protecting against MITM means eliminating blind trust. Their persistence and repercussions also indicate that we should question the systems left behind by internet designers — systems built for openness and interoperability, not for adversarial resilience. The future of secure communication depends on rebuilding that trust layer by layer, ensuring that every interaction, from local packets to global routing, is verifiable, encrypted, and beyond manipulation.
And it is logical that all technology, no matter how robust, will always have vulnerabilities.
But sometimes it just seems too easy, don't you think?
