OSINT de IP, dominios e infraestructura: Shodan, Censys y DNS [2026]

La pregunta que separa una búsqueda de una investigación de infraestructura #

La pregunta propietaria de esta URL es: ¿cómo pasar de un dominio, hostname o IP a un mapa temporalmente validado de la infraestructura externa sin confundir observación, propiedad, actividad ni vulnerabilidad? Para la metodología general de fuentes abiertas, el punto de entrada sigue siendo OSINT: qué es, para qué sirve y cómo empezar desde cero.

En infraestructura, casi nunca existe una única fuente que responda todo. DNS puede mostrar cómo resuelve un nombre ahora; Certificate Transparency puede revelar nombres que aparecieron en certificados; RDAP aporta registro administrativo; Shodan y Censys contienen observaciones de servicios; urlscan conserva ejecuciones web; Passive DNS añade historia. El trabajo profesional consiste en correlacionar esas capas sin elevar una relación débil a una conclusión fuerte.

DOMINIO → HOSTNAME → DNS → IP/PREFIJO → ASN → CERTIFICADO → SERVICIO → OBSERVACIÓN → TIMESTAMP

Regla central: “aparece asociado a” no significa “pertenece a”, “está activo ahora” ni “es vulnerable”. Cada salto del grafo necesita fuente, fecha y nivel de confianza.

Esta guía se centra en activos propios, laboratorios y entornos con autorización. Las técnicas de explotación, escaneo directo y validación intrusiva pertenecen a otro nivel de trabajo y deben gestionarse con su scope correspondiente.

Respuesta rápida: qué herramienta responde qué pregunta #

No necesitas una colección infinita de buscadores. Necesitas elegir la fuente que mejor responde una hipótesis concreta y conocer qué no demuestra su resultado.

SCOPE → DNS → RDAP → CT → IP → SHODAN/CENSYS → URLSCAN/PDNS → CORRELACIÓN → VALIDACIÓN → REPORTE

OSINT pasivo, consultas de red y reconocimiento activo: una frontera más precisa #

Etiquetar todo como “pasivo” o “activo” oculta matices importantes. Conviene separar quién envía tráfico al objetivo y si estás consultando una observación previa o provocando una observación nueva.

En un pentest o auditoría profesional, las acciones directas deben estar cubiertas por un scope y autorización explícitos. No conviertas esa práctica contractual en una afirmación legal universal: jurisdicción, términos de servicio y contexto pueden cambiar el análisis jurídico.

El modelo de entidades de red que evita la mayoría de falsas atribuciones #

Antes de utilizar herramientas, separa las entidades. Muchas conclusiones incorrectas nacen de tratar como equivalentes conceptos que pertenecen a capas distintas.

• Dominio: nombre dentro del DNS, como example.com.
• Hostname: nombre específico, como vpn.example.com.
• Dirección IP: identificador de red. Un hostname puede resolver a varias IP y una IP puede servir múltiples hostnames.
• Prefijo/CIDR: conjunto de direcciones en una asignación o anuncio; no implica que cada dirección esté dedicada al mismo cliente.
• ASN: identificador de un Sistema Autónomo usado en routing. IANA asigna bloques de ASN a los RIR, que después los asignan a operadores de red. IANA mantiene el registro.
• Certificado TLS: artefacto criptográfico que puede contener uno o varios nombres; su existencia no demuestra por sí sola que el servicio siga operativo.
• Servicio observado: protocolo/puerto y respuesta vista por una fuente en un momento determinado.
• Proveedor: organización que puede operar red, cloud, CDN, DNS, correo u otra dependencia sin ser propietaria del negocio investigado.

Paso 1: delimita el scope y modela relaciones, no “propiedad” por intuición #

Comienza con un inventario de semillas confirmadas: dominio corporativo, hostnames conocidos, rangos propios, ASN institucionales si existen y proveedores declarados. Después clasifica cada hallazgo.

CONFIRMADO EN SCOPE
↓
ASOCIADO TÉCNICAMENTE
↓
DEPENDENCIA DE TERCERO
↓
HISTÓRICO / INACTIVO
↓
RELACIÓN AÚN NO RESUELTA

El axioma que evita atribuciones falsas

Si portal.example.com resuelve a una IP de un gran proveedor cloud, la evidencia permite afirmar que el hostname utilizó o utiliza esa infraestructura en la observación considerada. No permite afirmar que la organización sea propietaria de la IP, del prefijo completo ni del datacenter.

Paso 2: auditoría DNS con dig sin convertir cada registro en una conclusión #

DNS es una fuente primaria para conocer cómo se publican nombres y servicios. Empieza por consultas reproducibles y guarda respuesta, resolver y timestamp.

# Direcciones
dig example.com A +noall +answer
dig example.com AAAA +noall +answer

# Correo y servidores autoritativos
dig example.com MX +noall +answer
dig example.com NS +noall +answer

# Texto: SPF, verificaciones y otros datos
dig example.com TXT +noall +answer

# Seguir delegación / autoridad
dig example.com SOA +noall +answer

Qué puedes inferir y qué no

• A/AAAA: dirección(es) devueltas en esa consulta. En CDN, anycast o balanceo la respuesta puede variar.
• CNAME: relación de alias. Puede revelar una dependencia SaaS/CDN, pero no prueba que ese proveedor sea el dueño del activo.
• MX: infraestructura publicada para correo entrante; no describe toda la arquitectura de correo.
• NS/SOA: delegación y autoridad DNS, no la ubicación del servicio web.
• TXT: puede contener SPF y tokens de validación. Un token antiguo no demuestra un contrato o integración vigente.

Si necesitas reforzar esta capa antes de entrar en OSINT, revisa qué redes debes aprender para ciberseguridad y en qué orden.

Paso 3: RDAP en 2026 y por qué “reemplazó WHOIS” necesita scope #

RDAP es el protocolo moderno de acceso a datos de registración. El estándar de consulta/respuesta actual está descrito, entre otros documentos, por RFC 9082 y RFC 9083, parte de STD 95.

En el espacio de dominios genéricos, ICANN convirtió RDAP en la fuente definitiva de información de registración desde el 28 de enero de 2025 y eliminó gran parte de las obligaciones de WHOIS, con excepciones contractuales concretas. Consulta la actualización oficial de ICANN. Para IP y ASN, los RIR también ofrecen RDAP.

Qué debes extraer

• handle, nombre y rango registrado;
• entidades asociadas y roles cuando estén publicados;
• eventos/fechas registrales;
• links al servidor autoritativo o recursos relacionados;
• red o ASN administrativo.

RDAP no es geolocalización. Que una IP esté registrada a una organización no prueba dónde se encuentra físicamente un servidor ni qué cliente concreto usa ese recurso. Tampoco toda información de contacto es necesariamente pública: políticas y redacción de datos dependen del tipo de recurso y registro.

Paso 4: Certificate Transparency y crt.sh sin confundir certificado con activo vivo #

Certificate Transparency (CT) publica información sobre certificados TLS en logs auditables. La referencia IETF moderna es RFC 9162 — Certificate Transparency Version 2.0, que obsoleta RFC 6962. Los logs se diseñan como registros auditables y append-only; certificate.transparency.dev mantiene información sobre logs utilizables.

crt.sh, operado por Sectigo, permite buscar certificados registrados en CT. Sectigo lo describe como una herramienta de búsqueda y reporting de CT.

Consulta típica

https://crt.sh/?q=%25.example.com

Los nombres encontrados en certificados son candidatos. Un SAN como vpn.example.com puede corresponder a un servicio activo, a un certificado vencido, a una migración o a un nombre que nunca llegó a publicarse en DNS.

Paso 5: del hostname a la IP sin congelar una arquitectura dinámica #

Una resolución DNS es una observación en un instante. Cloud, CDN, balanceo global, failover y anycast rompen la idea de que hostname → IP sea una relación permanente.

En el informe, separa columnas como first_seen, last_seen, current_dns, source y confidence. La cronología es parte de la evidencia, no un detalle decorativo.

Paso 6: Shodan, banners y el significado real de “servicio expuesto” #

Shodan organiza la información de servicios en objetos denominados banners. Su documentación explica que cada banner puede incluir IP, puerto, organización, ubicación estimada y la respuesta obtenida del servicio. Consulta la documentación de banners y búsquedas.

La API de Shodan también expone un timestamp por observación y permite solicitar histórico para un host cuando la cuenta lo soporta. Referencia oficial de la API.

Consultas útiles dentro de tu scope

hostname:example.com
port:443 hostname:example.com
net:203.0.113.0/24
ssl.cert.subject.cn:"example.com"

Los filtros hostname, net, port y campos de certificado TLS forman parte del catálogo actual de filtros de Shodan.

Qué significa un resultado

• Puerto observado: el crawler obtuvo una respuesta en una fecha concreta.
• Producto/versión: fingerprint o información presentada por el servicio; puede estar ocultada, modificada o ser engañosa.
• Vulnerabilidad sugerida: punto de investigación, no prueba automática de explotabilidad.
• Ubicación: atributo de geolocalización del dataset, no evidencia física suficiente por sí sola.

Paso 7: Censys Platform y CenQL en septiembre de 2026 #

Censys está migrando su experiencia de Legacy Search a Censys Platform. La documentación actual utiliza CenQL (Censys Query Language) para consultar datasets de hosts, certificados y propiedades web. La referencia oficial de CenQL describe búsquedas de texto completo y de campo-valor.

Censys anunció la deprecación de Legacy Search durante septiembre de 2026 y mantiene guías de transición. Por eso, en una guía 2026 conviene enseñar Platform/CenQL y tratar Legacy como interfaz en retirada, no como base de nuevos workflows. Aviso oficial de deprecación.

Ejemplos conceptuales de CenQL

"example.com"
host.location.country="Spain"
web.hostname="example.com"

Los campos exactos dependen del dataset y evolucionan; valida siempre contra las definiciones en la interfaz o documentación actual. Las release notes del 14 de septiembre de 2026 confirman que CenQL y Platform siguen recibiendo cambios.

Paso 8: urlscan.io, históricos y el riesgo de enviar una URL nueva #

urlscan.io registra cómo se comporta una página durante una ejecución: requests, dominios, IP, cabeceras, DOM, screenshot y otros metadatos. Su API permite buscar scans por dominio, IP, ASN y más. Documentación oficial de la API.

• Buscar un scan existente: reutilizas una observación previa.
• Enviar una URL nueva: urlscan realiza una navegación nueva desde su infraestructura.

Visibilidad

urlscan define tres niveles: Public, Unlisted y Private. Public aparece en búsquedas públicas; Unlisted no aparece públicamente pero puede estar disponible a usuarios Pro verificados; Private queda restringido a quien conoce el ID/propietario según su modelo. Revisa las reglas de visibilidad.

Además, desde el 4 de mayo de 2026 ciertos endpoints de resultados/DOM/responses requieren autenticación con API key, según el cambio anunciado por urlscan.

Paso 9: Passive DNS para reconstruir relaciones históricas sin inventar una verdad completa #

Passive DNS (pDNS) agrega resoluciones observadas por sensores o proveedores y permite pivotar entre nombres e IP a lo largo del tiempo.

vpn.example.com → 198.51.100.20  (observado en T1)
vpn.example.com → 203.0.113.40   (observado en T2)
203.0.113.40    → api.example.com (observado en T3)

El valor está en la cronología, pero la cobertura nunca es absoluta. La ausencia de una relación en un proveedor de Passive DNS no demuestra que nunca existiera. Tampoco un registro antiguo demuestra actividad actual.

Conserva proveedor, first/last seen, tipo de registro y la diferencia entre observación histórica y resolución autoritativa actual.

Paso 10: ASN, cloud y CDN — la capa donde más se confunde infraestructura con ownership #

Un ASN identifica un Sistema Autónomo en el plano de routing. Eso es útil para agrupar prefijos y entender operadores, pero no convierte todo lo anunciado por ese ASN en activos del cliente.

• Cloud público: una organización puede utilizar una IP o servicio dentro de infraestructura administrada por el proveedor.
• CDN/WAF: la IP visible puede ser un edge compartido y ocultar el origen.
• Anycast: la misma IP puede anunciarse desde múltiples ubicaciones.
• BYOIP / delegaciones: registro, anuncio y operación pueden pertenecer a entidades diferentes.

Por eso, evita frases como “el servidor está físicamente en X porque la IP pertenece a AS Y”. Mejor: “la IP observada está asociada al prefijo/ASN Y según la fuente Z; la ubicación física del servicio no queda demostrada por ese dato”.

Paso 11: tecnologías expuestas, banners y por qué un fingerprint no confirma un CVE #

Headers HTTP, certificados, banners SSH, títulos web y fingerprints permiten inferir tecnologías. Son útiles para priorizar validaciones, no para emitir un diagnóstico definitivo.

• un Server: nginx/... puede estar modificado o pasar por proxy;
• una distribución puede aplicar backporting de parches sin cambiar la versión mostrada como esperas;
• un WAF/CDN puede responder por el origen;
• un CPE o fingerprint automático puede estar equivocado;
• un CVE asociado a una versión aparente requiere validar producto, build, configuración, parche y exposición.

Cuando quieras pasar de inteligencia pasiva a validación de seguridad, la transición natural está en herramientas de hacking ético y pentesting: qué aprender y para qué sirve cada una.

Paso 12: construye un grafo relacional con relaciones tipadas y tiempo #

El salto profesional consiste en abandonar listas planas y representar relaciones. No basta con nodos; necesitas tipo de relación, fuente y tiempo.

[example.com]
  ├─ has_hostname → [vpn.example.com]
  │    ├─ resolved_to @ T1 → [203.0.113.40]
  │    └─ appeared_in_CT @ T0 → [cert #A]
  ├─ mail_exchange → [mx.provider.example]
  └─ nameserver → [ns.provider.example]

[203.0.113.40]
  ├─ registered_in → [prefix P]
  ├─ announced_by → [ASN Y]
  └─ shodan_observed @ T2 → [443/tcp HTTPS]

Relaciones como resolved_to, appeared_in_certificate, registered_to, announced_by y observed_service expresan propiedades distintas. No las fusiones bajo una etiqueta genérica “pertenece a”.

Paso 13: baseline y EASM — detectar cambios sin confundir cambio con incidente #

La superficie externa es dinámica. Un baseline periódico te permite detectar cambios relevantes:

T0: vpn.example.com → IP_A → 443/tcp observado
T1: vpn.example.com → IP_B → 443/tcp observado
T2: nuevo admin.example.com aparece en CT
T3: Shodan/Censys observan un servicio no inventariado

External Attack Surface Management (EASM) añade procesos y plataformas para descubrir, clasificar y seguir activos externos. Pero ningún proveedor tiene visibilidad perfecta. El baseline debe reconciliarse con inventario interno y owners técnicos.

Paso 14: IoT expuesto en Internet no es lo mismo que auditar una red Wi-Fi local #

Shodan/Censys pueden observar servicios accesibles desde Internet asociados a cámaras, routers, paneles industriales u otros dispositivos. Eso pertenece a la capa IP/servicio externo.

• SSID, BSSID y señal RF pertenecen a la capa inalámbrica local.
• Un dispositivo IoT visible en Internet puede estar detrás de múltiples redes y no revelar su topología Wi-Fi.
• Una red Wi-Fi cercana no implica que sus dispositivos estén expuestos públicamente.

Caso práctico: de un dominio a una superficie externa con estados de evidencia #

Este caso es hipotético y utiliza dominios/direcciones de documentación. El objetivo es mostrar razonamiento, no simular un resultado real.

1. Scope: example.com y hostnames bajo control confirmado.
2. DNS: registrar A/AAAA/MX/NS/TXT con timestamp.
3. CT: descubrir candidatos como vpn.example.com y api.example.com.
4. Validación: comprobar qué candidatos resuelven actualmente.
5. RDAP: identificar quién administra los recursos IP, sin atribuirlos automáticamente al cliente.
6. Shodan/Censys: revisar observaciones y fecha de servicios del conjunto validado.
7. urlscan: buscar primero históricos; si se plantea un scan nuevo, revisar autorización, privacidad y visibilidad.
8. Correlación: clasificar cada relación como confirmada, probable, histórica, tercera parte o no resuelta.
9. Reporte: separar hechos de acciones de validación pendientes.

El resultado no debe ser “encontré 20 IPs”, sino una explicación de qué relaciones están demostradas y cuál es su vigencia.

Matriz de evidencia: cómo evitar que una observación débil se convierta en una afirmación fuerte #

La escala “baja/media/alta” es una convención editorial. En un entorno real define criterios internos para que dos analistas apliquen la confianza de manera consistente.

Plan práctico: 7 laboratorios para aprender OSINT de infraestructura #

Esta ruta es una propuesta pedagógica de Achirou, no un estándar profesional obligatorio.

Cómo encaja en Red Team, Blue Team y Threat Intelligence #

• Blue Team / EASM: comparar inventario interno con activos y servicios observados externamente, priorizando discrepancias.
• Red Team: preparar reconocimiento previo con fuentes de terceros antes de pruebas activas. La transición completa pertenece al Red Team roadmap: ruta para aprender seguridad ofensiva desde cero.
• CTI: pivotar dominios, certificados, IP, ASN y servicios para contextualizar infraestructura sospechosa. Para fuentes de mayor riesgo y filtraciones, deriva a OSINT en Dark Web y Threat Intelligence.

La separación entre roles evita canibalización: este artículo es dueño de infraestructura y relaciones técnicas externas; el hub OSINT cubre metodología general, Dark Web cubre señales de fuentes de riesgo y Red Team cubre operaciones ofensivas autorizadas.

10 errores críticos en OSINT de infraestructura #

Preguntas frecuentes sobre OSINT de IP, dominios e infraestructura #

Conclusión: el objetivo no es encontrar más IPs, sino demostrar relaciones

OSINT de infraestructura aporta valor cuando convierte datos dispersos en una explicación reproducible: qué activo observaste, qué relación existe, en qué fecha, qué fuente la respalda, qué no puedes concluir todavía y qué validación falta.

Un buen informe no dice “Shodan encontró 443 abierto”. Dice: “Shodan observó una respuesta en 443/TCP para esta IP en T2; la IP resolvía desde el hostname autorizado en T1; RDAP la registra dentro de un prefijo operado por un tercero; falta confirmar vigencia y ownership interno”.

Ese cambio de lenguaje evita falsos positivos, mejora la trazabilidad y convierte búsquedas en inteligencia útil para defensa, auditoría y CTI.

Para ampliar la disciplina completa —personas, infraestructura, fuentes de riesgo, verificación y análisis— vuelve al hub de OSINT y utiliza cada deep dive solo para la pregunta que realmente le pertenece.