Una videoconsola puede transmitir en directo a un servidor que nunca perteneció a Twitch ni a YouTube, sin que la consola note el cambio: la técnica que lo permite se llama DNS spoofing, y aprovecha que el protocolo de streaming, RTMP, confía ciegamente en lo que le responde el DNS.
Ese punto ciego es la base de una técnica de red que un investigador aplicó para redirigir el streaming nativo de una PlayStation 5 hacia su propio servidor doméstico, sin tocar la consola ni romper ninguna protección de Sony. Este artículo explica cómo funciona RTMP, por qué el DNS es su punto débil y cómo reproducir el mecanismo en un laboratorio propio.
TL;DR
- RTMP envía audio y video en tiempo real sobre TCP, y muchos dispositivos resuelven su servidor por dominio antes de transmitir.- La redirección de DNS cambia esa resolución para que el dispositivo transmita hacia un servidor propio en vez del oficial.- RTMPS con TLS bloquea la interceptación por validación de certificado; el RTMP plano sobre el puerto 1935 no.- dnsmasq reescribe la respuesta y nginx-rtmp recibe el stream como si fuera el servidor original.- Un ataque real contra una PS5 sirvió de laboratorio para entender dónde falla y dónde no la seguridad del streaming.
¿Qué es el DNS spoofing?
DNS spoofing es una técnica de manipulación de red en la que un atacante o administrador falsifica la respuesta del sistema de nombres de dominio para que un dispositivo resuelva un dominio legítimo hacia una dirección IP distinta de la real, redirigiendo así cualquier conexión posterior sin que la aplicación lo note.
La técnica no ataca al protocolo de streaming en sí, sino a la capa anterior: la resolución de nombres. Cualquier dispositivo que descubra un servidor por dominio en lugar de por una IP fija es vulnerable a este tipo de redirección si el resolutor DNS que usa no está protegido. También se la conoce como envenenamiento de DNS o DNS poisoning, y es uno de los vectores de manipulación de tráfico más antiguos de internet.
RTMP corre por defecto sobre el puerto TCP 1935, sin cifrado.
Por qué importa
Esta técnica importa porque buena parte del hardware moderno (consolas, televisores inteligentes, cámaras IP, asistentes de voz) descubre sus servidores en la nube por nombre de dominio, no por dirección fija. Eso simplifica el mantenimiento del lado del proveedor: puede mover, escalar o dar de baja un servidor sin tocar el firmware de millones de dispositivos.
El costo de esa comodidad es que el dispositivo nunca verifica a quién le está hablando más allá de resolver un nombre. Si alguien controla esa resolución (un router comprometido, un punto de acceso Wi-Fi falso, o simplemente el administrador de tu propia red) puede decidir a dónde va el tráfico sin que el usuario note nada raro en la pantalla.
Entender la manipulación de la resolución de nombres sirve para dos cosas opuestas: para un equipo de red team que audita qué tan bien un dispositivo IoT valida sus conexiones, y para cualquier persona que quiera entender por qué existen defensas modernas como DNSSEC o el DNS cifrado.
Cómo funciona el protocolo RTMP
RTMP (Real-Time Messaging Protocol) es el protocolo que Macromedia diseñó a comienzos de los 2000 para el streaming en vivo de Flash, y que Adobe heredó tras comprar Macromedia en 2005. Sigue siendo el estándar de facto para transmitir a Twitch y YouTube desde consolas, cámaras y software como OBS.
RTMP: handshake, chunks y mensajes
Una sesión RTMP arranca con un handshake de tres pasos (C0/C1/C2 del lado del cliente, S0/S1/S2 del servidor) que sincroniza reloj y versión de protocolo antes de mandar un solo byte de video. Superado ese saludo, el video y el audio viajan divididos en chunks, fragmentos pequeños que se intercalan para que el audio no se quede esperando a un fotograma pesado.
Cada chunk pertenece a un mensaje RTMP de un tipo específico: video, audio, metadata o control de la sesión. Es un protocolo binario, sin campos de texto, pensado para baja latencia sobre TCP en el puerto 1935.
flowchart TD
A["Handshake (C0/C1/C2, S0/S1/S2)"] --> B["Division en chunks"]
B --> C["Mensajes RTMP: audio, video, control"]
C --> D[("Servidor de ingesta")]
Así se estructura cualquier transmisión RTMP antes de llegar a un servidor real o falso: el protocolo no cambia según quién esté del otro lado.
El eslabón débil: cómo el dispositivo encuentra su servidor
Antes de transmitir, muchos clientes RTMP no usan una IP fija: primero le preguntan a un endpoint de descubrimiento cuál es el servidor regional más cercano. En el caso de Twitch, el cliente resuelve un dominio de entrada como ingest.global-contribute.live-video.net, y ese dominio, a través del DNS, apunta a un servidor regional concreto según la ubicación.
Ese paso intermedio es exactamente el que se puede secuestrar. Si el resolutor DNS que usa el dispositivo responde con una IP distinta a la real, el cliente jamás lo sabe: para él, sigue hablando con el mismo nombre de dominio de siempre.
sequenceDiagram
participant D as Dispositivo
participant R as Resolutor DNS
participant I as Servidor de ingesta real
D->>R: consulta el dominio de ingesta
R-->>D: responde con la IP oficial
D->>I: conecta y transmite por RTMP
I-->>D: confirma la recepcion del stream
Dónde falla la suplantación: TLS y certificados
La redirección funciona perfecto contra RTMP plano, pero no contra su variante cifrada. RTMPS envuelve la misma conversación en TLS, generalmente sobre el puerto 443, y el cliente valida el certificado del servidor contra una lista de autoridades certificadoras de confianza. Un servidor propio con un certificado autofirmado no pasa esa validación, y en un dispositivo cerrado como una consola no hay forma de instalar una CA personalizada.
Por eso la técnica documentada contra la PS5 apuntó a un endpoint de ingesta que usa RTMP plano en el puerto 1935 en lugar del endpoint HTTPS de descubrimiento. Incluso así hubo un obstáculo adicional: algunos proveedores verifican del lado de su API que el stream efectivamente llegó, y si nunca llega, cortan la transmisión después de un rato corto, aunque el dispositivo siga enviando datos.
sequenceDiagram
participant D as Dispositivo
participant R as Resolutor DNS local
participant A as Servidor propio
D->>R: consulta el mismo dominio de ingesta
R-->>D: responde con la IP del servidor propio
D->>A: conecta pensando que es el proveedor
A-->>D: acepta la conexion RTMP
Note over D,A: el dispositivo nunca detecta el cambio
El resultado es que la suplantación de resolución DNS mueve el destino del stream, pero no cambia ni una línea del firmware ni rompe ningún cifrado. El dispositivo cree que sigue hablando con el proveedor original.
Ejemplos prácticos y cómo empezar
El resto de esta sección arma un laboratorio con dos servicios de código abierto: dnsmasq para la resolución falsa y el módulo nginx-rtmp para recibir el stream. Para no apuntar contra la infraestructura real de ningún proveedor, el ejemplo usa un dominio de prueba propio en lugar de un dominio de Twitch o YouTube: el mecanismo es idéntico, cambia solo el nombre.
Laboratorio propio: reproducir el mecanismo sin tocar servicios de terceros
Necesitás una máquina Linux (funciona en una Raspberry Pi, una VM o tu propia laptop) con permisos de administrador. Instalá dnsmasq como resolutor, nginx con el módulo RTMP como receptor y ffmpeg para generar un stream de prueba sin depender de ningún archivo externo.
sudo apt update
sudo apt install -y dnsmasq nginx libnginx-mod-rtmp ffmpeg
En macOS podés instalar los mismos componentes con Homebrew (brew install dnsmasq nginx-full ffmpeg); en Windows, dnsmasq no tiene un equivalente directo, así que la alternativa más simple es correr este mismo laboratorio dentro de una VM Linux o WSL2.
Configurá dnsmasq para que resuelva un dominio de prueba hacia la propia máquina. La línea server=1.1.1.1 reenvía todo lo demás a Cloudflare, así que el resto de tu red sigue navegando normal:
# /etc/dnsmasq.d/lab-rtmp.conf
server=1.1.1.1
address=/ingest.stream.lab/127.0.0.1
log-queries
log-facility=/var/log/dnsmasq-lab.log
Reiniciá el servicio y agregá el bloque rtmp a la configuración de nginx. Ese bloque va al mismo nivel que http, no adentro:
sudo systemctl restart dnsmasq
# /etc/nginx/nginx.conf (agregar al final del archivo)
rtmp {
server {
listen 1935;
chunk_size 4096;
application live {
live on;
record off;
}
}
}
Reiniciá nginx y confirmá que la resolución falsa está activa antes de transmitir nada:
sudo systemctl restart nginx
$ dig ingest.stream.lab @127.0.0.1 +short
127.0.0.1
Con la respuesta apuntando a la propia máquina, generá un stream sintético con ffmpeg. No hace falta ningún video real, lavfi genera uno:
ffmpeg -re -f lavfi -i testsrc=size=640x480:rate=25 -f lavfi -i sine=frequency=1000 -c:v libx264 -c:a aac -f flv rtmp://ingest.stream.lab/live/test
Para verificar que nginx-rtmp recibe el stream, activá el panel de estadísticas del módulo agregando esta ubicación dentro del bloque http / server de nginx:
location /stat {
rtmp_stat all;
}
Recargá nginx y, mientras ffmpeg sigue corriendo, consultá el estado:
sudo systemctl reload nginx
$ curl -s http://127.0.0.1/stat | grep -o '[0-9]*'
1
Ese 1 confirma que el servidor recibió una conexión activa en la aplicación live. Apagá ffmpeg con Ctrl+C y el número vuelve a cero: esa es toda la comprobación que necesitás para saber que el mecanismo de redirección funciona de punta a punta.
Casos de uso reales
El caso documentado que popularizó esta técnica en 2026 fue el de un desarrollador que quería compartir la pantalla de su PlayStation 5 en Discord sin comprar una capturadora de video. Como describió en su blog, primero intentó suplantar directamente ingest.twitch.tv, pero ese dominio es solo un endpoint de descubrimiento HTTPS: la consola lo consulta para preguntar qué servidor regional usar, y la respuesta llega protegida por TLS.
Revisando los registros de dnsmasq mientras transmitía, encontró que la consola terminaba resolviendo ingest.global-contribute.live-video.net, que a su vez apuntaba a un servidor concreto como aps30.contribute.live-video.net. Suplantar el dominio padre contribute.live-video.net cubre todos esos subdominios regionales de una sola vez, y ese servidor sí acepta RTMP plano por el puerto 1935.
El último paso fue dirigir solo el tráfico de la consola, no el de toda la red doméstica: usando un router con OpenWRT, configuró la opción de DHCP número 6 (el servidor DNS) para que se aplicara únicamente al lease de la dirección MAC de la PS5, vía una etiqueta definida en la configuración del DHCP.
El envenenamiento de DNS es uno de los vectores de manipulación de tráfico más antiguos de internet.
La misma primitiva se usa, en sentido inverso, para filtrar tráfico en vez de robarlo: herramientas como Pi-hole aplican esta misma redirección de DNS, pero como bloqueo deliberado, para que los dominios de publicidad resuelvan a una dirección nula. En auditorías de seguridad autorizadas es, además, una de las primeras pruebas que se corre contra un dispositivo IoT nuevo: si el fabricante no valida certificados, la redirección revela ese fallo en minutos.
Errores comunes y buenas prácticas
-
Confundir el endpoint de descubrimiento con el servidor real: apuntar directamente a un dominio HTTPS de discovery, como
ingest.twitch.tv, no sirve, porque ahí la validación de certificado corta la conexión antes de que viaje un solo byte de video.- Redirigir toda la red en vez de un solo dispositivo: si el dnsmasq falso atiende a toda la LAN, cualquier otro equipo pierde acceso al resto de internet. Limitá el alcance por MAC o por lease de DHCP.- Olvidar el servidor upstream: sin una líneaserver=apuntando a un resolutor real, el dnsmasq de prueba deja sin resolver todo lo que no sea el dominio falso.- Ignorar el chequeo de stream en vivo del proveedor: algunas plataformas confirman contra su propia API que el stream llegó, y si nunca llega, cortan la transmisión a los pocos segundos aunque el dispositivo siga enviando datos.- Probar contra infraestructura ajena sin autorización: lo que en un laboratorio propio es una prueba técnica, contra la red de otra persona o el servicio de un tercero es acceso no autorizado.
⚠️ Ojo: aplicar esta técnica contra una red, un dispositivo o un servicio que no es tuyo, o sin autorización explícita por escrito, es ilegal en la mayoría de las jurisdicciones aunque la intención sea inofensiva.
Comparativa con alternativas
TécnicaCapa de redCuándo usarlaLimitaciónEnvenenamiento de DNS (spoofing)Aplicación (resolución de nombres)El dispositivo descubre su servidor por dominio, no por IP fijaNo funciona si el cliente valida certificado (RTMPS) o usa DNS cifradoARP spoofingEnlace (LAN local)Interceptar cualquier tráfico dentro del mismo segmento de redSolo funciona en la misma LAN y es fácil de detectar con herramientas como arpwatchRogue DHCPEnlace / RedControlar qué servidor DNS y gateway recibe un dispositivo nuevoNecesita ganarle la respuesta al servidor DHCP legítimo de la redProxy transparente (mitmproxy)Aplicación (HTTP/HTTPS)Inspeccionar y modificar tráfico HTTP ya interceptadoNo procesa RTMP binario sin un plugin o proxy específico para ese protocolo
Profundizando
El truco de suplantar contribute.live-video.net en lugar de un subdominio puntual funciona porque dnsmasq resuelve por sufijo: la directiva address=/dominio/ip cubre automáticamente cualquier subdominio que cuelgue de ese nombre. Es la misma lógica que usan los CDN para el geo-enrutamiento: el dominio raíz no cambia, pero la respuesta varía según qué servidor de borde conviene según la ubicación.
La defensa técnica real contra la manipulación de la resolución de nombres tiene dos capas. DNSSEC firma criptográficamente cada respuesta DNS para que un resolutor pueda verificar que no fue alterada en tránsito, pero requiere que tanto el dominio como el cliente lo validen, y buena parte del hardware de consumo simplemente no lo hace. La segunda capa, DNS sobre HTTPS o sobre TLS, cifra la consulta completa hacia un resolutor específico, por ejemplo 1.1.1.1 u 8.8.8.8 vía HTTPS: si el dispositivo usa DoH hacia un servidor fijo en internet, un dnsmasq local en la misma red ya no puede interceptar ni modificar esa consulta.
💡 Tip: forzar DNS over HTTPS hacia un resolutor externo en cualquier dispositivo bajo tu control anula por completo este tipo de redirección local, porque la consulta deja de pasar por el DNS de la red.
En la práctica, casi ningún dispositivo de streaming de consumo implementa DoH de forma nativa todavía, lo que explica por qué la técnica documentada contra la PS5 siguió funcionando en 2026 sin ningún ajuste adicional. Aun así, el patrón se repite en el resto del ecosistema de streaming: cualquier cliente que resuelva su servidor por dominio, sin fijar la IP y sin validar un certificado, es candidato a esta misma clase de redirección.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: montá el laboratorio de esta guía con tu propio dominio de prueba y corré tcpdump -i any port 1935 mientras el ffmpeg de ejemplo transmite, para ver en vivo los chunks RTMP llegando a tu servidor falso.
Preguntas frecuentes
¿En qué se diferencia el envenenamiento de DNS de un ataque ARP spoofing?
El envenenamiento de DNS engaña al dispositivo a nivel de nombre de dominio, sin necesidad de estar en la misma red local. ARP spoofing, en cambio, falsifica direcciones físicas dentro de una LAN y exige que el atacante comparta el mismo segmento de red que la víctima.
¿Por qué RTMPS no se puede interceptar con la misma suplantación de resolución DNS?
RTMPS cifra la conexión con TLS y valida el certificado del servidor contra una lista de autoridades confiables. Un servidor propio con certificado autofirmado no pasa esa validación, así que la suplantación de resolución DNS solo cambia el destino, pero el dispositivo corta la conexión al detectar que el certificado no es de confianza.
¿Es legal el DNS spoofing en mi propia red?
Depende del alcance. Aplicar DNS spoofing contra tus propios dispositivos, en tu propia red y con fines de prueba, no infringe ninguna ley en la mayoría de los países. Hacerlo contra una red, un dispositivo o un servicio ajeno sin autorización es acceso no autorizado, un delito en prácticamente todas las jurisdicciones.
¿Qué es DNS over HTTPS y cómo afecta al DNS poisoning?
DNS over HTTPS cifra la consulta de resolución de nombres dentro de una conexión HTTPS hacia un resolutor específico, en lugar de mandarla en texto plano al servidor DNS de la red local. Eso hace que el DNS poisoning tradicional, el que depende de interceptar una consulta en la LAN, deje de funcionar contra ese dispositivo.
¿Se puede usar la redirección de DNS para acceder a streaming de pago sin autorización?
Técnicamente es posible intentar usar la redirección de DNS para eludir un control de acceso, pero es un uso no autorizado que viola los términos de servicio de cualquier plataforma y puede constituir un delito, además de que los servicios cifrados con RTMPS bloquean la interceptación por validación de certificado.
Referencias
- Hijacking the PS5's RTMP Stream: el artículo original que documenta el caso de la PlayStation 5 usado como ejemplo práctico.- nginx-rtmp-module en GitHub: documentación y código fuente del módulo usado para montar el servidor RTMP del laboratorio.- Documentación oficial de dnsmasq: referencia completa de las directivas de configuración, incluidas address= y server=.- Real-Time Messaging Protocol en Wikipedia: historia y especificación general del protocolo RTMP.- DNS spoofing en Wikipedia: explicación general de la técnica de manipulación de DNS y sus variantes.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)