GoDaddy le dio mi dominio a un desconocido: simulé el ataque con mi propia infra y entendí qué tan expuesto estaba

Estaba revisando Hacker News a las 10pm cuando el post llegó al top: GoDaddy había transferido un dominio a alguien que no era el dueño. Score 610, 200+ comentarios, la mayoría diciendo "migré a Cloudflare hace años" o "esto es por qué no usás GoDaddy". Cerré la pestaña. Y me quedé pensando.

Yo tengo seis dominios activos. Tres en Namecheap, dos en Cloudflare Registrar, uno en Porkbun. Todos conectados a Railway o Vercel. Todos apuntando a cosas que si se caen, me caen encima.

Mi primera reacción fue la del nerd condescendiente: "yo no uso GoDaddy, estoy bien". Mi segunda reacción, veinte minutos después, fue la del arquitecto que sabe que la arrogancia en seguridad es la vulnerabilidad más cara. Así que no cubrí el caso como noticia. Lo usé como excusa para simular el ataque contra mi propia infra, documentar cada paso, y medir qué tan lejos habría llegado un atacante antes de que yo me enterara.

Mi tesis, antes de arrancar: el problema no es GoDaddy específicamente. Es que la cadena de verificación de identidad en DNS fue diseñada en los '90 para un mundo donde cambiar un registro era un evento raro y manual. Hoy, con automatización, CI/CD y APIs de registradores que responden en milisegundos, esa cadena es papel mojado. Y nadie la está rediseñando.

GoDaddy domain hijacking security: qué pasó y por qué me importó personalmente

El caso reportado en HN describía un vector clásico de social engineering combinado con un proceso de soporte que validaba identidad por email. El atacante no hackeó ningún sistema. Llamó (o escribió), presentó documentación falsa, y el proceso interno de GoDaddy procesó la transferencia.

Ahí fue cuando me calenté de verdad. Porque no es un bug. Es un proceso que funciona exactamente como fue diseñado — y el diseño es el problema.

Me fui a revisar los procesos de los tres registradores que uso. Esto es lo que encontré para una transferencia de dominio saliente:

• Namecheap: email de confirmación al email registrado + código de autorización (EPP). Si el atacante tiene acceso al email, el dominio sale en 5-7 días sin fricción adicional.
• Cloudflare Registrar: igual que Namecheap, más 2FA opcional (que yo tenía activado en dos de tres dominios, no en todos — detalle vergonzoso).
• Porkbun: email + TOTP obligatorio para transferencias. El más resistente de los tres.

El vector de ataque no es el registrador. Es el email asociado a la cuenta del registrador.

Cómo simulé el ataque: paso a paso con mi propio stack

No rompí nada real. Usé un dominio de prueba que tengo en Namecheap (juanchi-test-[hash].com, comprado en enero, nunca apuntó a producción) y documenté cada paso como si fuera un atacante con acceso a mi email de Google Workspace.

Fase 1: reconocimiento

# Lo primero que haría un atacante: mapear la superficie
whois juanchi-test-[hash].com

# Output relevante (anonimizado):
# Registrar: Namecheap, Inc.
# Creation Date: 2025-01-15
# Registry Expiry Date: 2026-01-15
# Name Server: dns1.registrar-servers.com
# Name Server: dns2.registrar-servers.com
# DNSSEC: unsigned  <-- esto importa, lo vemos después

# El email del registrant estaba redactado (WhoisGuard activo)
# Pero el registrador sí aparece — primer dato útil para el atacante

El WHOIS me dio el registrador. Con eso, un atacante sabe a quién llamar. WhoisGuard protege el email del contacto técnico, pero no protege el registrador. Es como esconder el nombre en la puerta pero dejar el número de apartamento visible.

Fase 2: el vector real — comprometer el email primero

Acá está el insight que más me incomodó. Un ataque a un dominio no empieza en el registrador. Empieza en el email.

# Chequeé qué MX records tenía mi dominio de prueba
dig MX juanchi-test-[hash].com

# Y qué SPF/DKIM tenía el dominio del email que uso para el registrador
dig TXT juanchi-dev.com | grep -E "v=spf|DKIM"

# Resultado: SPF configurado, DKIM activo en Cloudflare
# Pero el punto débil no es la configuración — es la recuperación de cuenta

Google Workspace tiene recuperación por SMS. Mi número de teléfono está en el perfil. Si alguien hace SIM swapping, tiene mi email. Si tiene mi email, tiene todos mis dominios en Namecheap y dos de tres en Cloudflare (el que no tenía 2FA activado).

Ese fue el momento en que entendí que yo era tan vulnerable como cualquier usuario de GoDaddy. Solo que mi atacante necesitaba un paso previo adicional.

Fase 3: qué le pide Namecheap a "soporte" para una transferencia de emergencia

No llamé haciéndome pasar por nadie. Leí la documentación pública de soporte de Namecheap para casos de recuperación de dominio cuando "perdiste acceso al email". Esto es lo que piden:

1. Foto del documento de identidad
2. Última factura de compra del dominio
3. Descripción del problema

Eso es todo. No hay verificación de liveness. No hay callback al teléfono registrado. No hay segundo factor independiente. Si un atacante tiene una foto de mi DNI (que existe en LinkedIn, en conferencias, en un millón de lugares), una factura falsa creíble y acceso al email — o no necesita el email porque el soporte puede hacer override — el dominio puede salir.

Este proceso existe en casi todos los registradores. Porque fue diseñado para el caso legítimo de "se me olvidó el password y cambié de email". No para el caso de un atacante sofisticado.

Fase 4: qué pasaría después — el daño en mi stack de Railway/Vercel

Una vez transferido el dominio, el atacante controla los DNS. Esto es lo que podría hacer contra mi infra en Railway y Vercel:

# Escenario: atacante tiene el dominio juanchi.dev
# Paso 1: cambia el A record a su propio servidor
# Tiempo para que el cambio propague: entre 30 min y 48h según TTL

# Mis TTLs actuales (medidos antes del experimento):
dig juanchi.dev | grep TTL
# TTL: 300 segundos — propagación en 5 minutos

# Paso 2: solicita certificado SSL con Let's Encrypt
# ACME challenge HTTP-01 o DNS-01 — con control del dominio, trivial
# Tiempo: menos de 2 minutos

# Paso 3: monta un reverse proxy hacia mi propio Railway deployment
# O simplemente una página de phishing idéntica
# Con un certificado válido y el dominio real, el browser no avisa nada

El TTL de 300 segundos que tengo configurado por performance me habría dado una ventana de detección de cinco minutos después del cambio. Demasiado poco.

Esto conecta directamente con lo que documenté en el post del Vercel breach — cuando la infra de deployment está comprometida o el dominio que la alimenta está comprometido, el daño no es técnico. Es de confianza. Y la confianza no se recupera con un rollback.

Los errores que encontré en mi propia configuración

Voy a ser concreto porque me parece lo más valioso de este experimento. Estos son los problemas reales que tenía antes de simular el ataque:

Error 1: 2FA inconsistente entre registradores

Un dominio en Cloudflare Registrar sin 2FA activado. No tenía excusa. Lo activé en diez minutos durante el experimento.

Error 2: DNSSEC desactivado en todos mis dominios

# Verificación rápida de DNSSEC
dig DS juanchi.dev @8.8.8.8
# Respuesta vacía = DNSSEC no configurado

# Con DNSSEC activo, un atacante que modifique registros DNS
# genera respuestas que los resolvers validan y rechazan
# No es infalible, pero agrega fricción real

DNSSEC es engorroso de configurar. Cloudflare lo hace en un click. Namecheap lo soporta pero la UI es horrible. No lo tenía activado en ninguno. Ahora lo tengo en cuatro de seis dominios (los dos de Porkbun siguen pendientes, los voy a migrar).

Error 3: sin alertas de cambio de registros DNS

No tenía ningún sistema de alerta para detectar cambios en mis registros A, CNAME o NS. Un atacante podría haber cambiado el NS record y yo me habría enterado cuando un usuario me escribiera que el sitio está caído — o peor, que está raro.

Esto lo resolví con un script simple que corre en un cron de Railway:

// monitor-dns.ts — corre cada 5 minutos en Railway
// Alerta por Telegram si un registro cambia

import { Resolver } from 'node:dns/promises';

const resolver = new Resolver();
// Uso resolvers distintos para detectar divergencia entre cachés
resolver.setServers(['8.8.8.8', '1.1.1.1']);

const DOMINIOS_CRITICOS = [
  { dominio: 'juanchi.dev', tipo: 'A', valorEsperado: process.env.IP_PROD },
  { dominio: 'api.juanchi.dev', tipo: 'CNAME', valorEsperado: 'my-app.railway.app' },
];

async function verificarRegistros() {
  for (const { dominio, tipo, valorEsperado } of DOMINIOS_CRITICOS) {
    try {
      const resultado = await resolver.resolve(dominio, tipo as 'A' | 'CNAME');
      const valorActual = resultado[0];

      if (valorActual !== valorEsperado) {
        // Algo cambió — alerta inmediata
        await notificarTelegram(
          `⚠️ DNS CAMBIADO\nDominio: ${dominio}\nEsperado: ${valorEsperado}\nActual: ${valorActual}`
        );
      }
    } catch (error) {
      // El dominio no resuelve — también es alerta
      await notificarTelegram(`🚨 DNS NO RESUELVE: ${dominio}`);
    }
  }
}

Simple. Corre en Railway con un cron job. Me llegó una alerta falsa positiva en el primer día porque Railway rotó una IP de deployment — lo cual fue, irónicamente, exactamente el tipo de detección que quería.

Error 4: el email de recuperación del registrador era el mismo que el email de trabajo

Si alguien compromete mi cuenta de Google Workspace, tenía acceso a todo. Moví las cuentas de registrador a un email dedicado, sin alias, con una contraseña distinta generada en Bitwarden y con una clave de hardware (YubiKey) como segundo factor.

Esto es especialmente relevante dado el supply chain attack sobre Bitwarden CLI que documenté la semana pasada — la surface de confianza no es solo el password manager, es todo lo que ese password manager protege.

Los gotchas que nadie menciona en los posts de "protegé tus dominios"

El transfer lock no te salva del social engineering

Todos los registradores tienen "transfer lock" — bloquea transferencias salientes. Pero el social engineering no necesita una transferencia. Necesita cambiar los NS records, que en la mayoría de los registradores está en el mismo panel que el transfer lock, y requiere exactamente el mismo nivel de acceso.

Registry lock sí ayuda, pero es para empresas

Existe algo llamado Registry Lock (distinto al Registrar Lock) que requiere verificación fuera de banda para cualquier cambio, incluyendo NS. Lo ofrecen Verisign y otros registros para .com. Cuesta entre $100-$300 al año por dominio. No es para blogs personales, pero si tenés un dominio crítico para tu negocio, vale la conversación.

DNSSEC no protege contra el hijacking en la capa de registrador

Si el atacante ya controla el registrador, puede cambiar el registro DS (que es la "ancla" de DNSSEC) junto con los NS records. DNSSEC protege contra ataques en la capa de resolución (cache poisoning). No protege si el atacante tiene acceso al panel del registrador.

FAQ: GoDaddy domain hijacking y cómo proteger tus dominios

¿Solo pasa con GoDaddy o puede pasar con cualquier registrador?

Con cualquier registrador. GoDaddy tiene más casos reportados porque tiene más usuarios, pero el proceso de verificación de identidad basado en email + documento es prácticamente universal. Namecheap, Google Domains (ahora Squarespace), Name.com — todos tienen procesos similares para recuperación de acceso. El problema es sistémico, no es de un proveedor específico.

¿Activar 2FA en el registrador es suficiente?

Es necesario pero no suficiente. El 2FA protege el login directo. Pero si el proceso de recuperación de cuenta del registrador acepta "email + foto de DNI" como fallback (que muchos aceptan), el 2FA tiene un bypass vía soporte. La protección más robusta es combinar 2FA fuerte (TOTP o hardware key) + email dedicado para la cuenta del registrador + vigilancia activa de cambios en DNS.

¿Qué es Registry Lock y vale la pena pagarlo?

Registry Lock es una capa adicional de protección implementada por el registro (Verisign para .com, por ejemplo) que requiere verificación out-of-band para cualquier operación de cambio. El registrador no puede procesar un cambio de NS o una transferencia sin pasar por un proceso manual del registro. Cuesta entre $100-$300/año por dominio y tiene sentido para dominios que generan ingresos directos o tienen alto impacto en producción.

¿DNSSEC resuelve esto?

Parcialmente. DNSSEC protege contra cache poisoning y ataques en la capa de resolución. No protege si el atacante ya tiene acceso al panel del registrador — porque puede cambiar el registro DS junto con los NS. Es una capa de defensa válida, pero no es el escudo final contra domain hijacking.

¿Cuánto tiempo tarda en propagarse un cambio de DNS malicioso?

Depende del TTL configurado. Con TTL de 300 segundos (5 minutos, que es común en configuraciones de performance), un atacante tiene control efectivo del tráfico en menos de 10 minutos después de cambiar el registro. Con TTL de 3600 (1 hora), tenés más tiempo de detección pero los resolvers cachean el valor legítimo durante más tiempo también. No hay una respuesta perfecta — TTL bajo acelera tanto el ataque como la recuperación.

¿Railway o Vercel pueden hacer algo si el dominio se secuestra?

Poco. Si el dominio deja de apuntar al deployment de Railway o Vercel, el deployment sigue vivo pero el tráfico no llega. Podés hacer que la app responda desde la URL interna de Railway (*.railway.app) mientras resolvés el dominio, pero los usuarios que lleguen al dominio comprometido van a ver lo que el atacante monte — con un certificado SSL válido y el dominio real en la barra del browser. Vercel y Railway no son parte de la cadena de custodia del dominio.

Lo que cambió en mi infra después de este experimento

Concreto, sin floro:

1. 2FA con YubiKey en todos los registradores — no solo TOTP, hardware key como segundo factor donde lo soportan
2. Email dedicado para registradores — aislado de Google Workspace, con dominio propio que no está en ninguno de los registradores que protege
3. DNSSEC activado en cuatro de seis dominios — los dos restantes van a Cloudflare Registrar esta semana
4. Monitor DNS en Railway — cron cada 5 minutos, alerta por Telegram en menos de 10 minutos ante cualquier divergencia
5. TTL aumentado en dominios críticos — de 300 a 900 segundos. El trade-off de propagación más lenta vale la ventana de detección más amplia
6. Audit del proceso de recuperación de cuenta — leí la documentación de soporte de cada registrador para entender qué bypass existe y qué mitigación aplica

La superficie de ataque no desapareció. Pero la fricción para un atacante aumentó considerablemente, y mi tiempo de detección bajó de "cuando alguien me avisa que el sitio está raro" a "diez minutos después del cambio".

Lo incómodo de todo esto es que ninguna de estas medidas requería el incidente de GoDaddy para implementarse. Las sabía. Las tenía pendientes. Y las hice en un sábado a la noche después de leer una noticia en HN.

Eso dice más sobre cómo priorizamos seguridad que cualquier cosa que GoDaddy pueda haber hecho mal.

Si querés revisar cómo está expuesto el stack que usás, arrancá por el email del registrador. No por el panel del registrador. El email es el punto de entrada real, y si ese email cae, todo lo demás sigue.