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

La pregunta que separa coleccionar herramientas de hacer inteligencia #

Imagina que una organización te entrega su dominio corporativo:

example.com

Y te formula una pregunta técnica decisiva:

¿Qué puede descubrir un adversario o analista desde Internet sobre nuestra infraestructura tecnológica sin enviarnos un solo paquete de escaneo directo?

Ésa es una cuestión de OSINT de infraestructura inmensamente más rica y profesional que limitarse a preguntar: «¿Qué páginas existen para buscar IPs?».

Cualquier usuario puede abrir una lista con decenas de nombres: Shodan, Censys, urlscan, crt.sh, RDAP, DNS, Passive DNS, GreyNoise, Netlas, LeakIX, FOFA o ZoomEye, y pasar horas saltando de pestaña en pestaña recopilando datos desarticulados. Pero acumular herramientas no proporciona una metodología.

Lo que un analista de ciberseguridad necesita dominar es la cadena de dependencias técnicas que articula la presencia pública en Internet:

DOMINIO ──▶ HOSTNAME ──▶ DNS ──▶ IP ──▶ ASN ──▶ CERTIFICADO TLS ──▶ SERVICIO EXPUESTO ──▶ TECNOLOGÍA ──▶ HISTÓRICO

Comprender ese flujo relacional permite reconstruir la superficie externa de ataque (External Attack Surface) de una corporación utilizando casi exclusivamente información que terceros legítimos ya han observado, analizado e indexado.

El propósito de esta guía es transformar esa masa de datos públicos dispersos en un inventario técnico auditable y verificable, operando siempre sobre infraestructura propia, laboratorios controlados o activos con autorización expresa.

Respuesta rápida: qué herramientas utilizar y para qué pregunta #

Para comenzar no necesitas 250 herramientas. Con este núcleo metodológico estructurado puedes resolver prácticamente cualquier escenario de reconocimiento pasivo:

SCOPE ──▶ DOMINIO ──▶ DNS ──▶ CERTIFICADOS ──▶ IP ──▶ RDAP/ASN ──▶ SHODAN/CENSYS ──▶ URLSCAN ──▶ CORRELACIÓN ──▶ REPORTE

Primero: OSINT pasivo no es lo mismo que reconocimiento activo #

Esta frontera técnica y jurídica es innegociable en ciberseguridad profesional:

Como ya introducimos en nuestra guía pilar de OSINT, la diferencia práctica es evidente: si Shodan muestra que la dirección 203.0.113.10 tiene el puerto 443/TCP abierto con un servidor web Nginx, consultar ese registro en la API de Shodan es observación de terceros (OSINT pasivo). Lanzar un escaneo de puertos directo contra 203.0.113.10 es reconocimiento activo.

A lo largo de este tutorial priorizaremos siempre la observación pasiva para mapear la superficie sin perturbar el entorno auditado.

El modelo de entidades de red que debes dominar #

Antes de lanzar consultas, comprende qué representa cada concepto para evitar confusiones habituales:

• Dominio: Una identidad jerárquica en el Sistema de Nombres de Dominio (ej. example.com).
• Hostname (Nombre de host): Una etiqueta específica dentro de un dominio que identifica un recurso o máquina (ej. vpn.example.com o api.example.com). Un dominio puede albergar miles de hostnames.
• Dirección IP: Un identificador numérico de red (ej. la dirección de documentación 203.0.113.10). Ten presente dos realidades:
  • 1 Hostname ≠ 1 IP (balanceadores de carga y CDNs resuelven a múltiples direcciones).
  • 1 IP ≠ 1 Hostname (el alojamiento virtual permite que miles de webs compartan una única IP).
• ASN (Autonomous System Number): Un número de dos o cuatro bytes asignado a un Sistema Autónomo que gestiona un bloque de enrutamiento BGP propio. Te indica en qué operador o proveedor cloud reside físicamente la red.
• Rango CIDR: Bloque de red continuo (ej. 203.0.113.0/24). Que un servidor de tu cliente esté en ese rango no implica que toda la subred sea de su propiedad; puede tratarse de una subred compartida de AWS, Azure o DigitalOcean.
• Servicio expuesto: Una combinación de puerto y protocolo de transporte (ej. 443/TCP HTTPS, 22/TCP SSH) observado por un crawler en una fecha determinada.
• Certificado TLS: Documento digital criptográfico emitido por una Autoridad de Certificación (CA) que contiene el nombre común (CN) y la lista de nombres alternativos (Subject Alternative Names - SAN).

Paso 1: Delimita el scope y distingue asociación de propiedad #

Nunca comiences introduciendo la marca de una corporación en veinte herramientas de forma indiscriminada. Establece primero tu perímetro formal:

IN-SCOPE:
- example.com
- *.example.com
- Rangos IP propios autorizados (si existen)
- ASN institucional asignado (si existe)

El axioma analítico: «Asociado técnicamente» no significa «Propiedad»

Si descubres que portal.example.com resuelve a 203.0.113.10, no puedes dictaminar que la empresa es dueña de esa IP. La relación técnica real se modela así:

DOMINIO (example.com) ──▶ RESUELVE A ──▶ IP (203.0.113.10) ──▶ PERTENECE REGISTRALMENTE A ──▶ CLOUD PROVIDER X

Por tanto: DOMINIO ASOCIADO ≠ PROPIETARIO DE LA INFRAESTRUCTURA. La organización arrienda o utiliza un servicio sobre una máquina gestionada por un tercero.

Paso 2: Auditoría DNS con utilidades nativas de Linux (dig) #

El DNS es la columna vertebral de cualquier arquitectura en Internet. En lugar de limitarte a ver la IP en un navegador, inspecciona cada familia de registros con la herramienta dig (Domain Information Groper):

# 1. Resolución de direcciones IPv4 (A) e IPv6 (AAAA)
dig example.com A +noall +answer
dig example.com AAAA +noall +answer

# 2. Servidores de correo entrante (MX)
dig example.com MX +noall +answer

# 3. Servidores de nombres autoritativos (NS)
dig example.com NS +noall +answer

# 4. Registros de texto (TXT) para validación de servicios y políticas de correo
dig example.com TXT +noall +answer

# 5. Consulta contra un servidor DNS público específico (ej. Cloudflare 1.1.1.1)
dig @1.1.1.1 vpn.example.com A +noall +answer

Qué revela cada registro para el analista OSINT

• CNAME (Canonical Name): Indica si un hostname es un alias hacia otra infraestructura (ej. tienda.example.com ──▶ cdn.shopify.com o portal.example.com ──▶ elb.amazonaws.com). Revela instantáneamente proveedores SaaS o balanceadores cloud.
• MX (Mail Exchange): Revela la plataforma de correo corporativo (Google Workspace, Microsoft 365, Proofpoint, Mimecast) sin interactuar con sus buzones.
• NS (Name Server): Permite saber si el DNS está delegado en proveedores especializados como Cloudflare, Route 53 o servidores autoritativos on-premise.
• TXT: Contiene políticas SPF (que pueden enumerar rangos IP y servicios autorizados a enviar correos en nombre de la empresa), registros DMARC y tokens de validación de propiedad (Google Site Verification, Atlassian, Microsoft).

Paso 3: RDAP, el estándar moderno que sustituye a WHOIS #

Durante décadas los manuales de ciberseguridad recomendaban ejecutar whois por el puerto 43/TCP. En la actualidad, ese protocolo no estructurado ha sido formalmente reemplazado por RDAP (Registration Data Access Protocol), estandarizado por el IETF y la ICANN.

Ventajas clave de RDAP

• Respuestas normalizadas en formato JSON estructurado legibles por máquina.
• Consultas seguras sobre HTTPS (puerto 443).
• Soporte nativo para internacionalización y redirección federada automatizada entre Registros Regionales de Internet (RIRs: RIPE, ARIN, LACNIC, APNIC, AFRINIC).

Consulta de una dirección IP o ASN mediante RDAP

Puedes consultar el bootstrap de RDAP directamente mediante curl y procesarlo con jq:

# Consultar la información registral de un bloque IP
curl -s "https://rdap.org/ip/203.0.113.10" | jq '{name: .name, handle: .handle, startAddress: .startAddress, endAddress: .endAddress, entities: [.entities[].vcardArray[1][1][3]]}'

# Consultar la información registral de un Sistema Autónomo (ASN)
curl -s "https://rdap.org/autnum/64496" | jq '{name: .name, handle: .handle, type: .type}'

El resultado de RDAP te permite responder de forma contundente: «Esta IP pertenece al rango asignado a DigitalOcean LLC en Ámsterdam, por lo que el servidor está alojado en una instancia VPS de ese proveedor y no en el centro de datos físico de la compañía».

Paso 4: Descubrimiento de subdominios con Certificate Transparency (crt.sh) #

Certificate Transparency (CT) es uno de los mayores tesoros del OSINT moderno. Diseñado como un marco criptográfico abierto para auditar a las Autoridades de Certificación, obliga a registrar en logs públicos de solo adición (append-only) cada certificado TLS emitido en el mundo.

Como las empresas solicitan certificados que agrupan subdominios en el campo Subject Alternative Name (SAN), consultar estos registros permite descubrir activos internos, entornos de staging y servidores olvidados sin enviar una sola solicitud a la empresa.

Consulta de crt.sh mediante interfaz web y terminal

El portal crt.sh mantiene una base de datos indexada de estos registros:

# Consultar crt.sh vía API en formato JSON y extraer subdominios únicos
curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sed 's/\*\.//g' | sort -u

HALLAZGO EN CT ──▶ SUBDOMINIO CANDIDATO ──▶ CONSULTA DNS ACTUAL ──▶ VERIFICACIÓN

Paso 5: Del hostname a la IP: separar lo vigente de lo histórico #

Una vez extraídos los nombres candidatos procedentes de Certificate Transparency y del rastreo DNS, construye tu tabla de resolución directa:

Esta disciplina evita perder tiempo analizando direcciones que ya no tienen ningún servicio asociado en el presente.

Paso 6: Shodan, anatomía de los banners y detección de Shadow IT #

Shodan no es un escáner de puertos interactivo que lanzas bajo demanda: es una base de datos indexada masiva recopilada de forma continua por una red global de crawlers distribuidos.

El Banner: la unidad atómica de Shodan

Cuando un crawler de Shodan se conecta a un puerto abierto, envía una sonda protocolaria básica (un handshake TLS, un comando GET / HTTP o una cabecera SSH) y almacena la respuesta textual devuelta por el servidor. Esa respuesta conforma el banner, acompañado de metadatos como:

• Dirección IP y puerto de escucha.
• Sistema Autónomo (ASN) y país de geolocalización.
• Certificados TLS asociados observados en la conexión.
• Huellas de software y marcas temporales de la observación.

Filtros esenciales en la sintaxis de Shodan

# Filtrar por Sistema Autónomo o nombre de organización
asn:AS64496
org:"Example Corp"

# Filtrar por hostname o bloque de red CIDR
hostname:example.com
net:203.0.113.0/24

# Combinación de filtros técnicos
net:203.0.113.0/24 port:22,443,8080 -country:US

Cuidado con los CVEs asociados en Shodan

Shodan clasifica las vulnerabilidades asociadas a un activo en dos categorías: verificadas (cuando el crawler probó de forma inocua la presencia de la debilidad) y asociadas por versión (basadas en una heurística que lee el número de versión en el banner). Ten siempre presente:

SHODAN DICE CVE-XXXX-YYYY ≠ SISTEMA VULNERABLE COMPROBADO

Una distribución Linux como Debian, Red Hat o Ubuntu realiza con frecuencia backporting de parches de seguridad manteniendo el número de versión del paquete en el banner, lo que genera falsos positivos en herramientas pasivas.

Paso 7: Censys Platform y el nuevo lenguaje CenQL [2026] #

Censys es el gran homólogo de Shodan, pero estructurado bajo una filosofía de modelado de red diferente. En 2026, la plataforma ha completado su transición: la antigua interfaz Legacy Search ha quedado deshabilitada para usuarios gratuitos y el motor opera enteramente bajo la nueva Censys Platform y su lenguaje de consulta estructurado CenQL.

Sintaxis comparada: Censys CenQL frente a consultas clásicas

Paso 8: urlscan.io y la auditoría de dependencias web históricas #

Mientras que Shodan y Censys analizan capas de red y transporte, urlscan.io desciende a la capa de aplicación web. Cuando urlscan procesa un sitio, simula la visita completa de un navegador real sin cabeza (headless), registrando:

• Todas las peticiones HTTP/HTTPS realizadas durante la carga.
• Scripts JavaScript, librerías CSS y recursos externos descargados.
• Direcciones IP y servidores DNS contactados por el cliente.
• Captura visual de pantalla (screenshot) y árbol DOM resultante.

Búsqueda pasiva en el archivo histórico de urlscan

Para mantener un perfil 100% pasivo, consulta primero si el dominio ya fue escaneado por terceros en el pasado utilizando la Search API:

# Buscar scans históricos de un dominio en la API de urlscan
curl -s "https://urlscan.io/api/v1/search/?q=page.domain:example.com" | jq '.results[] | {date: .task.time, url: .page.url, ip: .page.ip, asn: .page.asnname}'

Clasificación de dependencias: First-Party vs. Third-Party

Al auditar los resultados de urlscan, separa con rigor los recursos:

• example.com ──▶ api.example.com: Infraestructura de primer nivel (First-Party) que pertenece a la organización.
• example.com ──▶ cdn.jsdelivr.net o analytics.google.com: Servicios de terceros (Third-Party) consumidos como dependencias externas.

Paso 9: Passive DNS y reconstrucción de la infraestructura en el tiempo #

Una consulta DNS estándar solo te informa del presente inmediato: qué IP responde en este segundo exacto. En cambio, Passive DNS (pDNS) es un mecanismo que captura respuestas DNS reales observadas por sensores distribuidos en servidores recursivos de todo el mundo.

CRONOLOGÍA PASSIVE DNS DE UN HOSTNAME:
├── 2023-01-10: api.example.com ──▶ 198.51.100.22 (Servidor dedicado antiguo)
├── 2024-06-15: api.example.com ──▶ 203.0.113.10  (Migración a AWS)
└── 2026-09-01: api.example.com ──▶ 104.18.25.4   (Activación de Cloudflare)

El Passive DNS es fundamental para detectar servidores antiguos que quedaron desatendidos o identificar direcciones IP de origen (Origin IPs) que quedaron expuestas antes de que la empresa interpusiera una red de entrega de contenidos (CDN).

Paso 10: ASN, arquitecturas Cloud y redes CDN #

En el panorama tecnológico actual, casi ninguna empresa de software aloja sus servidores bajo un Sistema Autónomo propio con servidores físicos en su oficina. La regla general es la adopción masiva de nubes públicas y redes de distribución de contenido:

• CDNs y Proxies Inversos (Cloudflare, Fastly, Akamai): El dominio resuelve a direcciones Anycast compartidas globalmente. Intentar escanear o analizar esa IP no arroja datos de la empresa: analiza la infraestructura de borde de la CDN. Para profundizar en la captura y análisis del tráfico a nivel de paquete, consulta nuestra guía sobre filtros y comandos de Wireshark y nuestra guía técnica de Traceroute y Tracepath en Linux.
• Alojamiento compartido (Shared Hosting): Una misma máquina puede servir simultáneamente 5.000 páginas web de clientes distintos mediante Server Name Indication (SNI) y Virtual Hosts. Nunca atribuyas la reputación de una IP compartida a una sola empresa.
• Bases de redes y conectividad: Para comprender con solvencia el modelo OSI, el enrutamiento IP y los protocolos de transporte, revisa nuestra guía fundamental sobre redes para ciberseguridad.

Paso 11: Tecnologías expuestas, cabeceras y limitaciones heurísticas #

Los motores de inteligencia pasiva analizan múltiples señales para deducir qué componentes de software utiliza un servidor:

• Cabeceras de servidor HTTP (Server: nginx/1.24.0, X-Powered-By: PHP/8.2).
• Estructura de certificados TLS y suites criptográficas soportadas.
• Cookies con nombres reveladores (JSESSIONID para Java, PHPSESSID, csrftoken para Django).
• Títulos de páginas HTML y favicons hasheados con algoritmos como MurmurHash.

Paso 12: Construcción del grafo relacional de infraestructura #

Toda la información recopilada cobra sentido cuando se unifica bajo un modelo de grafo técnico:

                              [ example.com ]
                                     │
         ┌───────────────────────────┼───────────────────────────┐
         ▼                           ▼                           ▼
  www.example.com             api.example.com             mail.example.com
         │                           │                           │
         ▼                           ▼                           ▼
[ CDN Cloudflare ]             203.0.113.10               [ Google Workspace ]
                              (AS64496 - VPS)                (MX Records)
                                     │
                             Puerto 443 (HTTPS)
                             Certificado TLS:
                             SAN: api.example.com
                                  staging.example.com (¡Nuevo candidato!)

Cada arista en este grafo debe contar con tres metadatos indispensables: Fuente de procedencia + Marca temporal (Timestamp) + Nivel de confianza analítica.

Paso 13: Línea base de superficie externa y detección de cambios (EASM) #

La disciplina de External Attack Surface Management (EASM) consiste en pasar de una foto estática a un proceso continuo de supervisión. Establece una línea base (baseline) fechada:

FECHA DE BASELINE: 2026-09-06
- Dominios activos auditados: 2
- Hostnames validados en DNS: 8
- Bloques IP / Direcciones únicas: 5
- Puertos observados globalmente: 80, 443
- Proveedores cloud asociados: AWS, Cloudflare

Paso 14: Dispositivos IoT expuestos vs. auditoría de radio Wi-Fi local #

Es muy importante mantener una separación nítida entre dos conceptos que con frecuencia se confunden en manuales desactualizados:

• Dispositivos IoT conectados a Internet: Cámaras IP, sensores SCADA, pasarelas MQTT y controladores de acceso expuestos directamente a la red con direccionamiento público. Son detectables pasivamente mediante Shodan, Censys o FOFA.
• Auditoría de radiofrecuencia Wi-Fi local: Análisis de identificadores SSID, direcciones BSSID, bandas de 2.4/5/6 GHz y cifrados WPA2/WPA3. Esta disciplina requiere proximidad física de radio y herramientas específicas, tratada en detalle en nuestra guía especializada de Wi-Fi para ciberseguridad.

Caso práctico completo: De un dominio a la superficie de ataque verificada #

Veamos un ejercicio de laboratorio guiado sobre una organización ficticia denominada acme-lab.example:

1. Fase 1 (Scope): Definición del perímetro: acme-lab.example y todos sus subdominios legítimos.
2. Fase 2 (DNS inicial): Se descubren mediante consultas A y MX los hostnames www, api y mail.
3. Fase 3 (Certificate Transparency): La consulta en crt.sh revela tres nombres adicionales en certificados emitidos en los últimos 24 meses: dev, staging y vpn.
4. Fase 4 (Validación DNS): dev devuelve NXDOMAIN (subdominio histórico ya desmantelado). En cambio, staging y vpn resuelven a direcciones IP vigentes (activos candidatos).
5. Fase 5 (RDAP): La dirección de staging pertenece a un bloque registrado a nombre de un proveedor de VPS en Frankfurt (Alemania).
6. Fase 6 (Shodan): Sobre la IP de vpn, Shodan observó el puerto 443/TCP y hace cuatro semanas el puerto 22/TCP (OpenSSH).
7. Fase 7 (Censys): Censys confirma la presencia de un certificado TLS válido que protege a staging.acme-lab.example.
8. Fase 8 (urlscan): Un análisis histórico de staging revela que la aplicación web realizaba llamadas REST hacia api.acme-lab.example.

Resultado final de inteligencia: No hemos acumulado una lista caótica de 200 enlaces. Hemos identificado con precisión 4 activos vigentes en producción y preproducción, 1 activo histórico desmantelado, 1 proveedor de infraestructura identificado y 1 servicio SSH que requiere verificación interna.

Matriz de evidencia técnica y clasificación de confianza #

Plan práctico: 7 laboratorios guiados sobre infraestructura autorizada #

Realiza estos ejercicios utilizando exclusivamente tu propio dominio, un entorno de laboratorio casero o una infraestructura con autorización contractual:

Aplicación en Red Team, Blue Team y Cyber Threat Intelligence #

• Para Blue Team y Defensa Corporativa: Permite confrontar el inventario oficial interno frente a lo que Internet observa desde el exterior, detectando exposiciones no autorizadas de bases de datos o paneles de gestión antes de que sean explotados. Puedes profundizar en este enfoque con nuestra Ruta Blue Team y nuestra guía sobre OSINT en Dark Web y Threat Intelligence.
• Para Red Team y Auditorías Ofensivas: Constituye la fase de reconocimiento pasivo previa a cualquier prueba de intrusión, identificando el perímetro tecnológico del cliente sin activar sus sistemas de detección de intrusos (IDS/IPS). Si deseas formarte en operaciones ofensivas rigurosas, consulta nuestra Ruta Red Team y nuestra recopilación de las 50 mejores herramientas de hacking ético y pentesting.
• Para Cyber Threat Intelligence (CTI): Facilita la correlación de infraestructura maliciosa entre distintas campañas analizando certificados TLS compartidos, proveedores de hosting antibalas (bulletproof) y patrones de nombres de dominio (DGA). Asimismo, si necesitas rastrear identidades humanas o perfiles detrás de un incidente, te recomendamos nuestra guía complementaria sobre OSINT para buscar personas: usernames y verificación de identidad.

10 Errores críticos que debes evitar en OSINT de infraestructura #

Preguntas Frecuentes sobre OSINT de Infraestructura (FAQ) #

Conclusión: El objetivo no es descubrir más IPs, sino comprender la superficie externa con evidencia

Un inventario desarticulado de 250 herramientas no te convierte en analista de ciberseguridad. Lo que aporta valor profesional es ser capaz de responder con rigor:

¿Qué activos son nuestros? ¿Cuáles son históricos? ¿Dónde están alojados físicamente? ¿Qué servicios han sido observados por la comunidad de Internet? ¿Qué cambió respecto al mes pasado? ¿Qué fuentes técnicas lo respaldan?

Por esa razón, un informe de inteligencia de alto nivel no concluye afirmando: «He encontrado 37 IPs en un buscador». Concluye explicando: «Identificamos 11 hostnames en producción, 4 registros históricos desmantelados y 6 direcciones IP activas; 8 servicios están alojados en un proveedor cloud, 2 tras una red CDN y 1 puerto requiere validación interna urgente al no figurar en el inventario oficial de la compañía».

Para dominar las técnicas de reconocimiento pasivo, correlación de inteligencia y auditoría profesional con casos de estudio reales, la Ruta Red Team de Achirou incorpora de forma destacada el Curso COMPLETO de OSINT: De 0 a Avanzado, con Casos Reales, diseñado para transformar la teoría en competencias prácticas para el mundo laboral.