Caster - Intercept

Genre: Offensive
Sources: caster0x00.com
Release Date: 09 January 2026
Language: English
Difficulty: Medium
Length: 4094 Words
Reading Time: 15 Minutes

Performing: Caster (Alter Ego)
Writing: Mahama Bazarov
Artwork: AI (Reworked by Mahama Bazarov)

Intro

MITM attacks are widely used by penetration testers, as they have a significant impact in allowing them to intercept credentials from various services. MITM is also often part of relay attacks, when the attacker performs lateral movement across the infrastructure. However, conducting MITM attacks carries certain risks.
In general, the concept of network spoofing is quite simple: just pretend to be the default gateway or DNS server that end hosts access. But if you make mistakes or lack knowledge of how networks work, you can disrupt the normal operation of the infrastructure. Network administrators, in particular, have never liked such attacks because of the high risk of disruption.

There is a lot of material on MITM attacks online, with examples of how to use various tools. But in this article, I will focus on how to perform MITM correctly. I will also focus on practical MITM attacks that have a tangible impact. The purpose of this article is not to teach MITM attacks from scratch; my goal is to give you a better understanding of the processes that occur during MITM attacks.

Disclaimer

This material is for educational purposes only and is intended for information security professionals. All examples and techniques are provided to demonstrate possible attack vectors and the subsequent development and integration of defense mechanisms. The use of the methods described outside of a legal and agreed-upon context is not permitted. Responsibility for the use of this information lies solely with the reader.

Preparing

First and foremost, before performing a MITM attack, the attacker must assess their risks and ensure that their OS is running smoothly, checking that there are no specific configurations that could interfere with normal traffic flow. In this chapter, I will discuss the best practices.

1. Promiscuous Mode

You need to switch your network adapter to promiscuous mode so that it can capture all network packets passing through the network segment:

:~$ sudo ip link set dev {iface} promisc on

2. Firewall

Check your firewall settings to make sure there aren't any rules that could mess up traffic after MITM:

:~$ sudo iptables -L
:~$ sudo iptables -t nat -L
:~$ sudo iptables -t mangle -L
:~$ sudo iptables -t raw -L

Netfilter is a kernel-level firewall, while iptables is an interface for managing it from userspace.

3. Routing

In Linux distributions, routing is disabled by default. You must enable it yourself. This can be done using the system utility sysctl
If you do not explicitly enable routing, then when performing MITM, traffic from victims to your machine will be looped back to your interface, causing an unintended DoS.

:~$ sudo sysctl -w net.ipv4.ip_forward=1 
:~$ sudo sysctl -w net.ipv6.conf.all.forwarding=1
:~$ sudo ip6tables -A FORWARD -i {iface} -j ACCEPT

However, this method will fail if you reboot your system.

4. NAT

In most MITM scenarios, NAT is not used for the attack itself, but to see the second part of the traffic, which may potentially contain credentials. This is due to asymmetric routing, a phenomenon where traffic goes one way but returns another. Thanks to masquerading, asymmetric routing will not prevent the attacker from seeing traffic going in both directions.

:~$ sudo iptables -t nat -A POSTROUTING -o {iface} -j MASQUERADE

However, it should be understood that including NAT in a MITM scenario effectively changes the network topology at the L3 layer for the target host. For external services, multiple hosts behind the attacker begin to appear as a single source of traffic, which can lead to disruption of services tied to the IP address.

Particularly sensitive to this are:

• monitoring systems;
• protocols with high-duration connections;
• services that use reverse connections or strict ACLs.

In addition, NAT simplifies the detection of MITM presence: sudden traffic aggregation behind a single IP address, identical network parameters, and changes in behavioral patterns can be detected by monitoring and network protection tools. For this reason, NAT should be used consciously and selectively.

5. TTL Manipulation

MITM often adds an extra hop to the route: the packet physically passes through the attacker's host, which means that traceroute may show this host as a separate step. Since traceroute relies on TTL and ICMP responses from intermediate devices, any extra point on the path potentially becomes visible.

Sometimes the attacker tries to compensate for this by artificially changing the TTL of transit packets so that, from the traceroute perspective, the number of hops looks the same as before. The idea is simple: if MITM adds +1 hop, then the adjusted TTL can visually smooth out the added transition in the trace:

:~$ sudo iptables -t mangle -A PREROUTING -i {iface} -j TTL --ttl-inc 1

6. ICMP Redirect

During a MITM attack, your machine may generate ICMP Redirect packets, which may trigger IDS/IPS sensors, so disable ICMP Redirect with sysctl commands:

:~$ sudo sysctl -w net.ipv4.conf.all.send_redirects=0
:~$ sudo sysctl -w net.ipv4.conf.{iface}.send_redirects=0
:~$ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
:~$ sudo sysctl -w net.ipv4.conf.default.accept_redirects=0
:~$ sudo sysctl -w net.ipv6.conf.all.accept_redirects=0
:~$ sudo sysctl -w net.ipv6.conf.default.accept_redirects=0

The same applies to IPv6:

:~$ sudo ip6tables -A INPUT -p ipv6-icmp --icmpv6-type redirect -j DROP
:~$ sudo ip6tables -A OUTPUT -p ipv6-icmp --icmpv6-type redirect -j DROP

7. In-line Traffic Processing (Forwarding)

During inline traffic processing in MITM, the attacker's host effectively becomes part of the data transmission path. In this mode, the load on the system is determined not only by the channel bandwidth, but also by the capabilities of the kernel network stack to process large numbers of packets and their states.

The limitations manifest themselves as follows:

• processing large amounts of traffic;
• network interface queues and delays when they are overloaded;
• an increase in the number of file descriptors;
• load on the stateful connection processing subsystem.

The following parameters are not mandatory and do not constitute a universal recipe. They are provided to help understand which Linux subsystems become bottlenecks during inline traffic processing.

8. File Descriptors

This allows you to increase the global limit for file descriptors. This is generally relevant for systems that process a large number of parallel connections.

:~$ sudo sysctl -w fs.file-max=100000

9. Queue of connections

Sets the max length of the queue of connections waiting to be accepted by the application.

:~$ sudo sysctl -w net.core.somaxconn=65535

10. Packet Queue Size

Controls the packet queue size at the network interface level. This can reduce packet loss during peak loads, but may increase latency.

:~$ sudo sysctl -w net.core.netdev_max_backlog=65536

11. TCP FIN Timeout

Allows you to reduce the connection retention time after FIN, thereby helping to free up resources faster when there are a large number of short-lived TCP sessions.

:~$ sudo sysctl -w net.ipv4.tcp_fin_timeout=15

12. TCP Window Scaling

Controls TCP window scaling. Increasing the TCP window can improve data transfer performance in networks with high latency or high load. In TCP, each side sets the window size. The corresponding number of bytes can be sent without confirmation.

:~$ sudo sysctl -w net.ipv4.tcp_window_scaling=1

In the context of inline traffic processing, such parameters can only partially mitigate the effects of increased load. They do not change the fundamental nature of an inline node, which is to aggregate traffic and the states of multiple hosts at a single point.

Credential Harvesting

One of the main goals of MITM is to intercept credentials transmitted over the network. Once intercepted, the attacker can use them for performing lateral movement. To automate the harvesting of logins and passwords in traffic, you can use the PCredz tool:

:~$ git clone https://github.com/lgandx/PCredz
:~$ sudo ./Pcredz -i {iface} -v
:~$ ./Pcredz -f capture.pcap -v

ARP Spoofing

ARP Spoofing is one of the oldest and most common methods of conducting MITM attacks on local networks. Its effectiveness is due to a fundamental feature of the ARP protocol: the absence of any authentication and a trust model for network interaction within a broadcast domain.

ARP (Address Resolution Protocol) was designed for an environment where each node is considered trusted a priori. Any host in the segment can send an ARP response, reporting the correspondence between the IP and MAC addresses, and this correspondence will be accepted by other nodes without checking the source. This model makes it possible to impose false ARP correspondences and intercept traffic between the victim and the default gateway.

The essence of ARP spoofing is that the attacker sends IS-AT type ARP frames, declaring their MAC address to be the IP address of the gateway (or another host in the segment). As a result:

• the victim begins sending traffic intended for the gateway to the attacker.
• the attacker forwards the traffic, maintaining network connectivity.
• the attacker becomes an inline node and gains the ability to analyze, modify, or redirect traffic.

It is important to understand that ARP spoofing actually changes the hosts' perception of the network topology. As a result of this attack, the attacker becomes a logical participant in the route. ARP spoofing is very simple in terms of mechanics, but dangerous in terms of MITM exploitation. With ARP spoofing, it is important to be able to control traffic, load, and attack time.

Conditions

ARP Spoofing is only possible when the following conditions are met:

• the attacker is in the same L2 segment as the target hosts;
• Dynamic ARP Inspection/IP Source Guard mechanisms are missing or incorrectly configured;
• traffic between the victim and the gateway passes through a broadcast domain;
• the attacker is capable of handling the amount of traffic that will be on its interface.

In segmented networks with small VLANs, the attack often goes unnoticed. In large broadcast domains, it quickly becomes operationally dangerous.

Risks

The more hosts the attacker spoofs, the higher the load on the attacker and the network infrastructure. This manifests itself in the form of:

• a sharp increase in incoming traffic on the attacker's interface;
• network stack queue overflow;
• increased delays and packet loss;
• network speed degradation, which may be noticed by network administrators.

In practice, ARP spoofing does not scale well and becomes increasingly unmanageable as the size of the subnet mask chosen by the attacker increases. Therefore, when performing ARP spoofing, consider the number of hosts you intend to spoof in order to avoid switch port oversaturation and unexpected DoS. Base your decision on the capabilities of your device and the speed of your network interface.

Example: ARP Spoofing on a /20 subnet mask, which can contain up to 4094 (usable IPv4 addresses) hosts. I don't think spoofing several thousand hosts at once is a good idea.

Canceling an Attack

I think one of the most frequently overlooked aspects of ARP spoofing is the correct termination of the attack. The ARP cache on hosts can remain poisoned even after the spoofed ARP frames have stopped being broadcast. If the attacker simply stops spoofing ARP frames, some nodes will continue to consider it a gateway and send traffic to its interface, resulting in an unintended DoS.

For this reason, after completing the attack, it is necessary to restore the ARP table by initiating reverse ARP IS-AT frames. Ignoring this step is one of the most common mistakes when performing this attack.

ARP Spoofing Prevention

ARP Spoofing is prevented at the access layer (L2) switches if the following are present:

• DHCP Snooping;
• IP Source Guard;
• Dynamic ARP Inspection.

In properly designed networks, ARP spoofing is either impossible or quickly leads to the attacker's port being blocked.

ARP Spoofing Tools

Ettercap, Scapy, Loki

IPv6 Attacks

IPv6 remains one of the most underestimated vectors for MITM attacks on internal networks. In many corporate infrastructures, it is not formally used, but it is active by default on workstations and has priority over IPv4. This creates a situation where IPv6 effectively takes on a life of its own, without filtering, monitoring, or proper attention from network engineers.

Unlike IPv4, where MITM is more often built around ARP and DHCP, in IPv6 the attacker affects auto-configuration mechanisms and ICMPv6 service messages. These mechanisms were designed for a trusted environment and do not contain authentication mechanisms, which makes IPv6 an interesting vector for an attacker.

The key feature of IPv6 is that:

• each host must have a link-local address (fe80::/10);
• IPv6 protocols (RA, NDP, DHCPv6) operate via multicast;
• DNS server addresses distributed via RA/DHCPv6 can be link-local on-link.

This means that the attacker does not need to know global IPv6 prefixes or have access to the router. It is sufficient to be in the same L2 segment and send correctly formed service packets.

Conditions

• IPv6 is enabled on target hosts (Windows enables it by default);
• RA Guard/SAVI/DHCPv6 Snooping are absent on access switches;
• there is no strict ICMPv6 filtering.

SLAAC to DHCPv6 Downgrade

IPv6 supports several configuration models, and the choice between them is determined by flags in RA packets:

• M (Managed) - use DHCPv6 for addresses;
• O (Other) - use DHCPv6 for parameters (DNS, etc.)

RA injection with flags M=1 and O=1 set forces hosts to abandon SLAAC and switch to DHCPv6. This is not MITM per se, but rather a switch in the address configuration method on the host. From an attacker's point of view, this is critically important: DHCPv6 provides a more convenient point for imposing DNS and further attacks (NTLM relay, WPAD, credential harvesting), for example, this is achieved using the mitm6 tool.

After successfully injecting an ICMPv6 RA packet with the data flags, the host will begin generating DHCPv6 requests to obtain an address, also known as DHCPv6 Solicit (0x01).

DHCPv6 Spoofing

A DHCPv6 spoofing attack is based on sending a DHCPv6 Advertise packet (0x02), which the attacker uses to impose their host as a DNS server at the IPv6 level. This can often be achieved using the mitm6 tool, whose default script is:

• forced downgrade from SLAAC to DHCPv6 by sending a specific ICMPv6 RA with the M/O flags of the required values;
• spoofing of a DHCPv6 Advertise packet (0x02) with the attacker's address imposed as the DNS server.

In this case, the attacker does not become a router, but gains control over DNS at the IPv6 level. Due to the priority of IPv6, this often completely bypasses ARP attacks and works even in networks that consider themselves “IPv4-only.”

However, mitm6 supports operation without sending a special RA packet for downgrading to DHCPv6. This is useful when RA Guard is used on the network. It is sufficient to use the --no-ra argument when using mitm6. Windows machines with IPv6 enabled periodically generate and send DHCPv6 Solicit packets themselves.

After this attack, the attacker has the following options for advancing:

• WPAD poisoning;
• NTLM relay;
• credentials harvesting.

mitm6 is relatively easy to use, but it is extremely sensitive to scale and timing. Without domain (-d) or time restrictions, the attack can easily cause massive disruptions. It is important to remember that the lease time set by mitm6 is equal to 5 minutes.

IPv6 Attacks Prevention

Effective protection against attacks on IPv6 is based on a combination of the following protective mechanisms:

• RA Guard;
• DHCPv6 Snooping;
• ND Inspection/SAVI;
• ICMPv6 Filtering;
• conscientiously disabling IPv6 where it is not actually used;

IDS/IPS

IDS/IPS and signatures are useful as an additional layer of detection, but without filtering at the switch level, they do not prevent attacks, but only record their occurrence.

IPv6 Attacks Tools

Scapy, mitm6, thc-ipv6

LLMNR/NBT-NS/mDNS Poisoning

Unlike ARP or IPv6 spoofing, attacks on LLMNR, NBT-NS, and mDNS do not change the traffic path and do not make the attacker an inline node. Their main value lies in intercepting credentials, rather than MITM. Furthermore, this attack is not scalable and does not provide control over segment traffic. LLMNR/NBT-NS Spoofing is useful as a point tool for collecting credentials, but not as a full-fledged MITM.

These protocols are designed for name resolution within a local segment and are used in situations where the primary DNS server is unavailable, incorrectly configured, does not contain the required record, or there has been a mistype of the resource name (a famous example: //printserver vs //pintserver)

LLMNR/NBT-NS Poisoning is considered a relatively quiet attack, but that doesn't mean it's invisible:

• behavior is well known and frequently monitored;
• poisoned answers are easily correlated by timing;

The essence of the attack is that the attacker responds to name resolution requests faster than legitimate sources, posing as the requested resource.

A typical scenario looks like this:

• the host attempts to access a resource by name.
• DNS does not respond or does not contain the record.
• the host sends a request via LLMNR, NBT-NS, or mDNS.
• the attacker responds to this request, declaring itself to be the requested node.
• the client establishes a connection with the attacker and transmits credentials.

Although LLMNR/NBT-NS Poisoning is not MITM in itself, it is often used as a preparatory stage for obtaining NetNTLMv2-SSP hashes, NTLM Relay, and for further lateral movement across the network.

Conditions

• the attacker is in the same L2 segment as the target hosts;
• LLMNR and/or NBT-NS are not disabled on the target hosts;

LLMNR/NBT-NS/mDNS Poisoning Prevention

Protection against LLMNR/NBT-NS/mDNS Poisoning is relatively simple and well known:

• Disabling LLMNR and NBT-NS on Windows hosts;
• traffic monitoring at the IDS;

In mature corporate networks, these measures are either already in place or easily implementable. This is why attacks are more often successful in user or poorly managed segments. Despite the long existence of this attack vector, it is still found in infrastructures.

LLMNR/NBT-NS/mDNS Poisoning Tools

Responder, Inveigh

DHCP Server Spoofing

DHCP (Dynamic Host Configuration Protocol) is often used in corporate networks to automatically configure IP addresses for all devices on the network. However, DHCP is also vulnerable to a number of attacks.
Many have already reported DHCP Exhaustion attacks, but they are useless because they actually cause a DoS. It is much more useful to try using DHCP as a spoofing attack vector. The basic concept is that the attacker sets up a fake DHCP server and responds to client DHCP requests faster or with higher priority than the legitimate server. As a result of this attack, the target hosts receive the following from the attacker:

• IP address;
• default gateway address;
• DNS server;
• lease time parameters.

Thus, the attacker does not wedge itself into the existing route, forcing hosts to consider it part of the legitimate infrastructure, since it will effectively be their default gateway or DNS server.

Conditions

• hosts use DHCP to obtain configuration;
• DHCP Snooping is not enabled on access switches;
• the attacker is in the same L2 segment as the victims;

User VLANs, Wi-Fi segments, and temporary segments are particularly vulnerable, as DHCP control is often weakened in these areas.

Risks

DHCP spoofing is a high-impact network attack from an operational standpoint because it can cause:

• mass impact on the segment;
• long-term consequences due to the possible use of a long lease time.

In practical scenarios, DHCP spoofing is either carried out very briefly or used as a demonstration vector rather than as the main method of intercepting traffic. In real-world penetration tests, DHCP spoofing is used less frequently than ARP or IPv6 attacks, but in the absence of basic defenses, it remains one of the most effective and obvious ways to compromise an internal network.

Canceling an Attack

Terminating DHCP spoofing is indeed a very important step in maintaining infrastructure health. You must consider the lease time given to clients when you set up a fake DHCP server. You must also serve host traffic for the entire lease time by leaving forwarding enabled.

DHCP Spoofing Prevention

Protection against DHCP spoofing has been known for a long time and is effectively implemented at the access switch level:

• DHCP snooping (allowing service DHCP packets only from trusted ports, usually connections between switches, trunks, and routers);
• rate limit DHCP requests (DISCOVER) to prevent DHCP exhaustion;
• monitor the DHCP Snooping table, ensure it is fully saturated, and create copies of it.

DHCP Spoofing Tools

Ettercap

FHRP Spoofing

First Hop Redundancy Protocols (FHRP) are used to ensure the failover of the default gateway in corporate networks. Protocols such as HSRP, VRRP, GLBP, and CARP allow multiple physical routers to jointly serve a single virtual IP address, ensuring continuity of communication in the event of a failure of one of the backup routers. Attacks on FHRP go beyond user MITM. In this case, the attacker actually interferes with the infrastructure logic of the segment itself, replacing the role of the default gateway for all hosts in the segment at once.

The essence of FHRP Spoofing is that the attacker sends FHRP protocol packets with a maximum priority of 255, declaring itself to be the active or master device. If the protocol does not use authentication or the priorities are set below 255, legitimate routers yield the role to the attacking host. The result is that:

• the virtual IP of the gateway is tied to the attacker's MAC address;
• all segment traffic is directed to the attacking host.

Conditions

• presence of hello packets from FHRP protocols in the user segment;
• protocol authentication is disabled, or the attacker was able to brute force the password by capturing the hash from the packet (pcap2john & john);
• the priority on the master router is set below 255;
• no filtering ACLs;
• the attacker will need to send a gratuitous ARP after packet injection;
• the attacker will need to assign the FHRP domain VIP address as a secondary address and configure the default gateway through legitimate Master/Standby routers to ensure network connectivity.

Despite the specificity of this attack, similar conditions are still encountered in production environments.

Risks

FHRP Spoofing is an attack with maximum blast radius. This is because spoofing instantly affects the entire segment served by the FHRP domain. And also:

• almost guaranteed detection through log monitoring;
• high probability of network degradation or failure;
• sharp increase in traffic on the attacker host's interface;
• there is also a risk of switch port oversaturation.

Blast radius is a metaphorical term that refers to the potential scale of damage that can be caused by a single attack, error, or network failure.

Any failure in traffic processing, NAT, or routing immediately affects all clients. Even a brief connectivity interruption will be noticed by users and monitoring systems.

From a MITM perspective, this is the cleanest scenario: all traffic for the entire segment goes through the attacker's host without ARP spoofing or client configuration substitution. But this is precisely why FHRP Spoofing is rarely used for long-term attacks.

In my opinion, the value of this attack lies in demonstrating vulnerability and confirming risk, rather than in undetectable exploitation. It shows that in the absence of basic hardening, a single host is capable of taking control of the traffic of an entire segment.

Canceling an attack

Despite the high risks involved in carrying out an attack, the network recovers thanks to the default short timers of FHRP protocols. As soon as you stop sending Hello messages, legitimate routers in the segment will automatically re-perform the Master/Standby role distribution negotiation process using multicast announcements. However, in real networks, this does not always happen instantly and may be accompanied by gateway role flapping.

• for HSRP: 224.0.0.2 (v1), 224.0.0.102 (v2);
• for VRRP: 224.0.0.18
• for GLBP: 224.0.0.102
• for CARP: 224.0.0.18

FHRP Spoofing Protection

The issue of protecting FHRP protocols is not difficult:

• enable authentication using a brute-force resistant password;
• configure an ACL that restricts incoming traffic for FHRP.
• use the maximum priority value of 255. However, for VRRP, it is particularly important to note that the maximum priority is limited to 254, so configuring priorities alone is not sufficient for protection.
• monitor changes in router roles and priorities.

FHRP Spoofing Tools

Loki, Scapy

Outro

MITM attacks are rarely technically complex. Most are based on long-established protocols and mechanisms designed for trusted environments. Their effectiveness stems not from novelty, but from the fact that infrastructure still relies on that trust - often due to a lack of network security hardening.

From a security perspective, most of the attacks described do not require exotic solutions. They can be prevented by basic configuration hygiene: segmentation, filtering of service traffic, disabling unnecessary mechanisms, and conscious use of IPv6. Where these measures are implemented, MITM is either impossible or quickly detected.