Key takeaway
Validate suspicious ARP changes, separate user and management segments, and allow only required traffic between them.
Spoofing appears at different layers
Spoofing imitates a trusted source to deceive a person or system. Email From fields and display names, source IPs, DNS answers, caller IDs and MAC addresses on a local network are different targets with different mechanics. A forged source IP can hide an attack’s origin or direct a service’s replies to a victim’s address; by itself it does not create a two-way session. BEC can use a lookalike domain or a compromised legitimate mailbox. A familiar display name or IP allowlist alone does not establish identity.
Layer 2: ARP/MAC
Can affect IP-to-MAC mappings between devices in the same broadcast domain.
Layer 3: IP
A source IP can be forged; it should not replace separate authentication.
Applications and people
DNS, website, email or caller-ID imitation calls for source verification.
ARP poisoning: a false map on the local network
On an IPv4 LAN, ARP helps map an IP address to a MAC address on the local link. An attacker can send forged ARP replies, for example mapping the gateway IP to the attacker’s MAC. If traffic then passes through the attacker’s device, it may be observed, altered or blocked. This attack is limited to a local Layer 2/broadcast domain; it cannot be launched directly against an arbitrary internet address. HTTPS/TLS helps protect encrypted session content, while traffic can still be blocked, metadata exposed or users redirected to a false endpoint.
MITM scenarios and useful indicators
In a MITM attack, an adversary positions themselves between the communicating parties and can read or alter data. Scenarios include rogue Wi-Fi, ARP poisoning, DNS cache manipulation and a user bypassing a TLS warning; intercepted session cookies can enable session hijacking. A missing padlock or slow connection alone does not prove an attack. A certificate warning, unexpected domain or certificate change, multiple ARP replies for one IP, or a sudden change in the gateway MAC merits investigation. On public Wi-Fi, use an approved VPN, never bypass TLS warnings, use MFA and phishing-resistant authentication, patch software and correlate events with host logs.
Observe
Collect ARP/DNS changes, certificate warnings and unexpected routes.
Validate
Compare the registered MAC, switch port, DHCP binding and trusted certificate chain.
Contain
Isolate the suspect port or device and inspect gateway, DNS, session and account activity.
Make segmentation boundaries enforce policy
VLANs or separate switches group devices, but they do not by themselves define who may reach a resource. Use rules enforced by routers, firewalls, host firewalls or another policy point to allow only business-required flows between guest Wi-Fi, IoT, users, servers, management and payment systems. Give each rule an owner, purpose, source, destination, protocol and review date. Separate RDP, SNMP, switch management and backup consoles from user segments. A compromised guest or IoT device should not automatically reach other zones.
Define
Map critical systems, device owners and required communications.
Restrict
Move toward default deny; allow management from dedicated admin hosts.
Test and review
Verify allowed and denied flows, then remove obsolete rules.
ARP defenses and switch-feature limits
Static ARP entries can help in a small, stable lab, but are difficult to maintain in a changing network and do not cover IPv6 Neighbor Discovery. On a managed switch, Dynamic ARP Inspection (DAI) can validate ARP packets against the DHCP snooping binding database. For devices with static addresses, configure the ARP access lists or other static-binding mechanism supported by the switch. Packets arriving on DAI-trusted ports may bypass inspection, so incorrect port trust or incomplete DHCP snooping can weaken protection. DAI does not stop every MITM method. When investigating, check port/MAC changes, DHCP bindings and ARP observations, restrict a confirmed malicious port and preserve incident logs.