Man-in-the-Middle

security computer systems networking

A man‑in‑the‑middle (MITM) attack happens when a malicious device inserts itself between two communicating parties and silently relays, inspects, or modifies traffic. The user thinks they are talking to a trusted service. They are not.

To pull it off, an attacker needs a foothold on the network. That can come from:

  • Public networks, secured or not
  • Social engineering into an organization or internal network
  • Wi‑Fi password cracking or guessing with rainbow tables
  • Rogue Wi‑Fi access points that trick devices into auto‑joining

Once a malicious device is in‑path, the attack surface expands quickly:

  • Sniffing authentication or session tokens
  • Address Resolution Protocol (ARP) spoofing
  • Domain Name Service (DNS) spoofing
  • HTTP(S) proxying
  • Network sniffing and probing
  • Routing packet proxying or TCP tunneling
  • Injecting data or code addressed to other hosts
  • Redirecting HTTP traffic
  • Stripping or bypassing TLS when possible

Example

The safest way to simulate a network attack is with virtual machines. You can observe attacks at any level of the TCP/IP stack without touching your real network.

I set up a small github project using vagrant with this virtual environment:

Attacker

A Linux (Arch) VM configured with:

  • kernel IP forwarding enabled
  • bettercap, nmap, and ip tools installed

Victim

A Windows 10 VM with a browser (IE).

Server

Another Linux VM with a web server installed.

The web content is a login form and a landing page accessible in both HTTP and HTTPS.

Scenario

  1. The attacker scans the gateway for IP addresses
  2. The attacker scans a specific IP for targets
  3. The attacker initiates bettercap configured to:
    1. ARP spoof the victim
    2. Start an HTTP proxy to inject a script
    3. Set up SSL stripping where HTTP is available
    4. Sniff network traffic for exposed information like credentials
  4. The victim visits the server via HTTPS
  5. The attacker injects a script
  6. The victim logs in
  7. The attacker strips SSL and reads the credentials

Deeper into the Attack

Using the TCP/IP model we can look at vulnerabilities and mitigations by layer.

Data packets at any layer can be modified in‑stream if an attacker is positioned correctly.

Network Layer

Most vulnerabilities at this layer involve insecure protocols. Manipulating a TCP packet in‑stream is difficult because you have to:

  1. find the packet (possibly decrypt it)
  2. modify the payload
  3. recalculate checksums

IPSec is a secure network protocol suite that protects end‑to‑end inside TCP packets. It is most commonly deployed by Virtual Private Networks (VPNs).

DNSSEC adds authenticity to DNS records to reduce spoofing.

Internet Protocol Version 6

IPv6 improves several vulnerabilities in IPv4 and ICMP with important changes:

  • Replacing ARP with the Neighbor Discovery Protocol (NDP)
  • Introducing a secure extension to network discovery (SEND)
  • Replacing Router Discovery (RDISC) with Multicast Listener/Router Discovery (MLD/MRD)

New IPv6‑specific MITM attacks have been found, such as the Stateless Address Auto Configuration (SLAAC) Attack (which appears to be a Windows configuration issue that allows IPv4‑style vulnerabilities).

Transport Layer

TLS encryption is the main mitigation at this layer. Closing or redirecting HTTP (non‑TLS) ports prevents SSL stripping. Certificate authorities and certificate pinning reduce spoofing, but they are not a silver bullet.

TLS Threat Analysis

TLS protects confidentiality and integrity, but it can still be undermined in real environments:

  • Downgrade opportunities: If HTTP is available, attackers can coerce clients into plaintext unless HSTS is enforced.
  • Certificate trust failures: Users (or enterprise devices) that install new root certificates can be tricked into trusting a malicious proxy.
  • Weak validation logic: Custom TLS implementations often fail to validate hostnames correctly or accept invalid chains.
  • Endpoint compromise: TLS does not help if the client device is rooted, jailbroken, or running malware.

Mitigations that actually matter:

  • Enforce HTTPS everywhere and enable HSTS
  • Validate hostnames and certificate chains correctly
  • Use certificate pinning for high‑risk endpoints
  • Treat rooted or managed devices as higher‑risk

Application Layer

If an attacker reaches the application layer, stolen information can enable further attacks like session hijacking, Cross-site Request Forgery (CSRF), sql injection, denial of service, and unauthorized data access.

Mitigation strategies include:

  • Keep applications and systems up to date and hardened
  • Require strong authentication and authorization on all network access points
  • Use sandboxing (VMs, containers, jails, chroot, file permissions)
  • Follow best practices like least privilege and defense‑in‑depth

Conclusion

MITM attacks work because networks are built on trust and convenience. The hardest part is not intercepting traffic, it is doing so without being noticed. That means the right mindset is not “stop MITM forever” but “make it expensive, visible, and low‑value.”

Threat analysis takeaways:

  • Assume hostile networks, especially on public Wi‑Fi
  • Treat the client as compromisable and validate on the server
  • Use TLS correctly and remove downgrade paths
  • Monitor for anomalies (latency spikes, certificate changes, odd routing)

Detection is difficult. It often comes from tamper detection, latency analysis, or post‑mortem forensics. That is why observability at all levels matters.

The industry still needs to move toward an IPv6‑dominant internet to help address vulnerabilities at the network layer, especially as 5G pushes more IoT and firmware devices online that are not easily updated.

That’s all for now folks.