ofensiva
Shodan
OSINT
Censys

Qué es Shodan: búsqueda de dispositivos conectados y uso defensivo

Qué es Shodan, motor búsqueda dispositivos conectados a Internet. Operadores avanzados, casos uso pentesting/threat hunting y alternativas Censys, ZoomEye.

Secra8 de junio de 202614 min de lectura

Shodan es el motor de búsqueda más conocido de dispositivos conectados a Internet, no de páginas web. Mientras Google indexa contenido HTML, Shodan indexa banners de servicios, certificados TLS, cabeceras de protocolos y metadatos de servidores, cámaras IP, controladores industriales, routers, bases de datos expuestas y cualquier cosa con una IP pública abierta. Lo creó John Matherly en 2009 y hoy es referencia tanto para equipos defensivos que quieren conocer su superficie de ataque externa como para equipos ofensivos que arrancan una fase de reconnaissance autorizada.

Esta guía explica qué es Shodan en concreto, cómo funciona técnicamente, los operadores avanzados que conviene dominar, casos reales de uso defensivo y ofensivo, alternativas en el mercado y cómo encaja en una estrategia de attack surface management para una organización seria. Toda la guía asume marco legal y autorización: Shodan habilita visibilidad sobre infraestructura propia o autorizada, no carta blanca para escanear lo ajeno.

Qué es Shodan

Shodan es un buscador especializado en servicios y dispositivos accesibles desde Internet. En lugar de rastrear hipervínculos, mantiene una flota de escáneres distribuidos que continuamente conectan a puertos comunes en el espacio IPv4 global y un subconjunto cada vez mayor de IPv6, capturan el banner que devuelve cada servicio y lo guardan en un índice consultable. Cuando alguien busca, no recibe páginas web, recibe IPs, puertos abiertos, productos identificados y vulnerabilidades conocidas asociadas.

La utilidad práctica nace de invertir la pregunta: en lugar de "qué hay en internet sobre esta empresa", se pregunta "qué servicios y dispositivos de esta empresa están expuestos en internet". Esa segunda pregunta es la que separa un programa de seguridad maduro de uno que se entera de sus exposiciones por noticia de prensa cuando alguien las exploit.

Shodan es una herramienta de doble uso. Los mismos resultados que ayudan a un CISO a auditar shadow IT ayudan a un atacante a localizar paneles de administración mal protegidos. Por eso conviene tratarla como cualquier herramienta dual: documentar alcance, mantener log de consultas y restringir su uso al personal autorizado.

Shodan no descubre lo que no esté ya expuesto. Si una organización aparece con servicios sensibles públicos en Shodan, el problema no es Shodan: el problema es que esos servicios están expuestos.

Cómo funciona técnicamente

Shodan opera una infraestructura propia de escáneres distribuidos en varios países para evitar geo-bloqueos puntuales y obtener fingerprints más fiables. El flujo simplificado:

  1. Generación de targets. Listas de IPs derivadas del espacio IPv4 público y de rangos IPv6 anunciados por BGP. IPv6 se cubre de forma parcial porque escanear todo el espacio IPv6 es computacionalmente inviable; se priorizan rangos activos identificados por DNS pasivo, certificados y respuestas observadas.
  2. Conexión a puertos predefinidos. Listas que crecen con el tiempo: HTTP, HTTPS, SSH, FTP, Telnet, SMB, RDP, MQTT, CoAP, Modbus, S7, BACnet, MongoDB, Elasticsearch, Redis, Memcached, VNC, IPMI, y muchos otros relevantes en IT, IoT y OT.
  3. Banner grabbing. Cuando el puerto responde, Shodan registra exactamente la cabecera o respuesta inicial que devuelve el servicio: versión, banner SSH, cabeceras HTTP, certificado TLS, título de página, mensaje de error y metadatos derivados.
  4. Fingerprinting y enriquecimiento. Reglas internas asocian el banner a un producto, versión, sistema operativo y, cuando aplica, a CVEs conocidos. También se enriquece con geolocalización, hostname inverso, ASN y organización propietaria del bloque.
  5. Indexado. El resultado entra en un índice de búsqueda con filtros estructurados y queda accesible vía web, API REST y CLI.

La frecuencia de re-escaneo varía por puerto y región: rangos densos se reescanean en cuestión de días, regiones marginales en semanas. Por eso Shodan no es tiempo real, es una foto reciente, suficiente para attack surface management estratégico pero no para detección en directo.

Operadores avanzados de Shodan

Los operadores son el verdadero valor diferencial. Cualquier persona puede teclear "webcam" y obtener miles de resultados ruidosos; un analista entrenado combina operadores para acotar a lo accionable.

Los más útiles en trabajo serio:

  • port: filtra por puerto. Ejemplo: port:3389 para localizar RDP expuesto.
  • country: filtra por código ISO de país. Ejemplo: country:ES para España.
  • city: filtra por ciudad. Ejemplo: city:"Madrid".
  • org: filtra por organización del bloque IP según WHOIS. Ejemplo: org:"Mi Empresa SL".
  • hostname: filtra por nombre de host (PTR o cert). Ejemplo: hostname:"miempresa.es".
  • product: filtra por producto detectado. Ejemplo: product:"Apache httpd".
  • version: filtra por versión. Ejemplo: version:"2.4.49" para localizar instancias vulnerables conocidas.
  • vuln: filtra por CVE. Ejemplo: vuln:CVE-2021-44228. Requiere suscripción de pago.
  • ssl.cert.subject.CN: filtra por Common Name del certificado. Ejemplo: ssl.cert.subject.CN:miempresa.es.
  • http.title: filtra por título HTML. Ejemplo: http.title:"Login".
  • net: filtra por bloque CIDR. Ejemplo: net:203.0.113.0/24.
  • asn: filtra por ASN. Ejemplo: asn:AS65000.
  • has_screenshot:true solo resultados con captura web.
  • tag:ics solo dispositivos clasificados como industriales.

Los operadores se combinan con AND implícito y se pueden negar con -. Por ejemplo, para auditar tu propia organización sin ruido de honeypots conocidos:

org:"Mi Empresa SL" country:ES -tag:honeypot

O para localizar servidores TLS con tu CN expuestos en puertos no estándar:

ssl.cert.subject.CN:miempresa.es -port:443 -port:8443

El reto está en aplicar criterio: una query bien pensada devuelve 5 hallazgos accionables; una mal pensada devuelve 50.000 resultados que nadie revisa.

Casos de uso defensivos

El caso por antonomasia es attack surface management. Una organización mediana descubre con un día de trabajo en Shodan más superficie expuesta de la que su CMDB declara: servidores de pruebas olvidados en una nube de marketing, paneles de administración con autenticación básica, instancias de bases de datos NoSQL abiertas, switches gestionables con interfaz web pública, cámaras IP de oficinas remotas, impresoras corporativas con servicios IPP abiertos.

Otros casos defensivos recurrentes:

  • Shadow IT discovery. Departamentos que contratan SaaS o IaaS sin pasar por IT dejan rastro en Shodan vía certificados TLS con el dominio corporativo en CN o SAN.
  • M&A due diligence. Antes de cerrar una adquisición, mapear la exposición externa de la empresa target da una imagen mucho más realista que cualquier cuestionario de seguridad rellenado por el propio target.
  • Third-party monitoring. Vigilar la exposición de proveedores críticos permite anticipar incidentes en la cadena de suministro: un ERP-as-a-service que aparece con vulnerabilidades sin parchear es un riesgo directo para sus clientes.
  • Validación post-incidente. Tras un parche o cambio, verificar en Shodan que el servicio efectivamente ya no es accesible o que el banner ya no expone la versión vulnerable.
  • Compliance y soporte de auditorías. Capturas de Shodan acompañan informes de auditoría como evidencia objetiva de la superficie en un momento dado.

Casos de uso ofensivos

En la fase de pentesting y Red Team, Shodan acelera la fase de reconnaissance pre-engagement cuando hay autorización explícita del cliente:

  • Target identification. Localizar todos los activos públicos del alcance contratado, incluidos los que el cliente no declaró por desconocimiento.
  • Tecnología y versiones. Saber qué software y qué versiones expone cada activo antes de tocar nada, reduciendo el ruido de escaneo activo posterior.
  • Detección de honeypots. Shodan etiqueta muchas instalaciones honeypot conocidas con tag:honeypot, evitando perder horas en sistemas que no son objetivo real.
  • Cross-referencing con vulnerabilidades conocidas. Combinado con un buen catálogo de CVE permite priorizar qué activo merece análisis profundo primero.
  • Soporte a OSINT más amplio. Encaja con Maltego, theHarvester, Amass y demás herramientas de reconnaissance.

El uso ofensivo sin autorización contractual es ilegal y poco profesional. Cualquier pentest serio empieza con un statement of work donde figura explícitamente Shodan dentro de la metodología.

Alternativas comerciales y open

Shodan no es la única opción. La elección depende de cobertura geográfica, profundidad de banner grabbing, modelo de licencia y especialización:

  • Censys. Nace en la Universidad de Michigan. Fortaleza histórica en certificados TLS y mejor cobertura IPv6 que Shodan en algunos rangos. Versión académica gratuita limitada, plataforma comercial para empresa.
  • ZoomEye. Empresa china. Cobertura buena en Asia y en productos chinos que Shodan reconoce peor. Plataforma menos pulida para usuario europeo y consideraciones de jurisdicción al subir queries sensibles.
  • BinaryEdge. Enfoque en empresa y datasets brutos descargables. Útil cuando se quiere ingerir datos en pipelines propios.
  • Fofa. Buscador chino similar a Shodan, con sintaxis propia y cobertura amplia del espacio asiático.
  • Onyphe. Empresa francesa, fuerte en pasive DNS, geolocalización y enriquecimiento con threat intelligence.
  • Spyse (descatalogado pero referenciado en mucha literatura). Datasets relevantes que parte de su funcionalidad ha pasado a otras plataformas.
  • Hunter (no confundir con Hunter.io de emails). Cobertura específica de exposición de servicios.
  • GreyNoise. No es competidor directo: clasifica tráfico de internet ruido frente a tráfico dirigido. Complementa a Shodan en la fase de análisis para priorizar IoCs.

Una stack realista para attack surface management corporativo combina Shodan más Censys más Onyphe o GreyNoise: cada una cubre matices que las otras no llegan a fingerprintear.

Shodan Monitor y alerting

Más allá del buscador, Shodan ofrece Monitor, un módulo donde se definen IPs, rangos CIDR, ASNs o dominios bajo vigilancia. Cuando aparece un nuevo servicio expuesto o cambia el banner de uno existente, envía notificación por email, webhook o vía API.

Setup típico para una organización mediana:

  1. Cargar en Monitor todos los rangos públicos asignados por el ISP.
  2. Añadir bloques cloud asignados por AWS, Azure o GCP a las cuentas corporativas.
  3. Añadir ASN propio si la organización tiene autonomía BGP.
  4. Añadir patrones de hostname y CN de certificado que cubran subdominios corporativos.
  5. Configurar webhook que envíe los eventos a una cola SIEM o a un canal de Slack del equipo de seguridad.
  6. Definir playbook: cada alerta se triagea en menos de 24 horas, se categoriza (esperado, shadow IT, exposición a corregir) y se cierra.

Bien implementado, Monitor cubre el 80% del caso de uso de attack surface management externo sin necesidad de comprar una plataforma ASM dedicada de seis cifras anuales.

ICS y OT específicos

Shodan mantiene una categoría especial de dispositivos de control industrial, accesible vía tag:ics y operadores de producto específicos. Indexa banners de protocolos OT como Modbus TCP, Siemens S7, DNP3, BACnet, EtherNet/IP, Niagara Fox y muchos más. La consecuencia es que PLCs de Siemens, Schneider Modicon, Allen-Bradley RS Logix, HMIs varias y sistemas SCADA expuestos directamente a internet quedan visibles globalmente.

Para responsables de ciberseguridad industrial este dato cambia la prioridad: cualquier activo OT que aparezca en Shodan es un fallo de segmentación de red, no un riesgo aceptable. La regla de oro sigue siendo que OT no debe estar accesible directamente desde Internet, y Shodan se convierte en la auditoría externa que valida esa regla.

Limitaciones honestas

Shodan no es magia y conviene asumir sus limitaciones:

  • No es tiempo real. Hay lag entre el cambio en la infraestructura y su aparición en el índice. Para detección de incidentes en curso hay que combinar con flow logs y EDR propios.
  • No ve detrás de WAF o CDN bien configurados. Si el origen real está oculto detrás de Cloudflare, Akamai o similar, Shodan ve el frontend, no el backend. Aún así, errores de origen filtrado o subdominios sin proteger por CDN suelen revelar el backend con frecuencia.
  • No autenticated visibility. Shodan no se autentica en servicios, solo lee lo que se le devuelve sin credenciales. Vulnerabilidades que requieren post-auth no se mapean.
  • Cobertura desigual de IPv6. Mejora cada año, pero todavía hay rangos IPv6 anunciados que no se barren en profundidad.
  • Honeypots y datos sucios. Muchos resultados son honeypots académicos o sistemas señuelo que añaden ruido si no se filtran con -tag:honeypot.
  • Fingerprinting imperfecto. La inferencia de versión puede fallar cuando el banner está modificado o cuando el servicio devuelve respuestas no estándar.
  • Privacidad y ética. Aunque la información sea pública, hay zonas grises éticas (cámaras domésticas inseguras, dispositivos médicos personales). Una política interna razonable evita explotar visualmente lo que sirve para titulares pero no para mejorar la seguridad del cliente.

Implementación de attack surface management con Shodan

Paso a paso para integrar Shodan en una operación seria:

  1. Definir scope formal. Inventariar rangos IP propios, ASNs, dominios y subdominios. Incluir cloud accounts (AWS, Azure, GCP), SaaS críticos y cualquier outsourcing relevante. Sin este alcance escrito, las queries se vuelven anecdóticas.
  2. Suscripción adecuada. La cuenta gratuita sirve para pruebas; el uso profesional requiere plan Small Business o superior para acceder a vuln:, Monitor con alertas y API extendida.
  3. Catálogo de queries. Construir y versionar un repositorio interno de queries útiles por sector y tipo de hallazgo: paneles admin expuestos, bases de datos abiertas, servicios obsoletos, certificados expirando.
  4. Integración SIEM/SOAR. Eventos del Monitor llegan a una cola del SIEM como cualquier otro feed, con playbook asociado. La integración vía webhook es nativa.
  5. Frecuencia y cadencia. Revisión semanal de hallazgos en Monitor; auditoría mensual completa con queries del catálogo; auditoría trimestral con el equipo de Red Team para validar tendencias.
  6. Métricas internas. Número de exposiciones detectadas por trimestre, tiempo medio hasta cierre, porcentaje de servicios encontrados que no estaban en CMDB. Estas métricas son las que llevan al comité de seguridad.
  7. Disciplina de cierre. Cada hallazgo se cierra retirando exposición, restringiendo IP, moviendo detrás de WAF o aceptando formalmente el riesgo. Sin disciplina de cierre, el ASM se convierte en un cementerio de tickets.

Encaja de forma natural en programas de pentesting de infraestructura externa: el ASM continuo identifica activos, el pentest periódico los valida y profundiza.

Preguntas frecuentes

Sí. Consultar Shodan sobre infraestructura propia o sobre infraestructura para la que existe autorización contractual es legal. Lo que sí infringe la ley es usar Shodan como paso previo a un acceso no autorizado a sistemas ajenos: no es la herramienta, es el uso posterior. Para investigaciones que toquen datos personales, además, aplica el marco general de RGPD y LOPD-GDD.

¿El plan gratuito cubre la exposición de mi empresa?

Para una pyme con pocos rangos y dominios, el plan gratuito permite consultas básicas suficientes para una auditoría puntual. Para una empresa mediana o grande con activos cloud, varios dominios y necesidad de alerting continuo, hace falta plan de pago para acceder a Monitor con alertas, búsquedas vuln: y volumen de API necesario.

¿La búsqueda por CVE es tiempo real?

No. Cuando aparece un CVE nuevo, Shodan tarda entre horas y días en reflejar la asociación entre versión y CVE en el índice. Para inventario propio de activos vulnerables es fiable; para identificar exposición global a un zero-day recién publicado hay siempre lag.

¿Shodan o Censys, cuál es mejor?

No es excluyente. Ambos son complementarios. Shodan tiende a tener cobertura más amplia de banners de protocolos no HTTP y de IoT/OT; Censys destaca en certificados TLS y en algunos rangos IPv6. Un programa serio suscribe ambos y compara hallazgos.

¿Cómo configuro alertas Shodan hacia mi SIEM?

Vía Monitor: defines los assets bajo vigilancia, configuras un webhook que apunta al endpoint de ingesta del SIEM o a un middleware (Logstash, Fluentd, Cribl). El payload llega como JSON con campos estándar (IP, puerto, módulo, producto, vulns), parseable directamente.

¿Es suficiente Shodan como única herramienta ASM?

Para una pyme, sí cubre el caso esencial. Para una organización grande, no: hace falta combinar Shodan con Censys, escaneo activo propio autorizado, descubrimiento de subdominios continuo, monitorización de certificados (CT logs) y, si el contexto lo requiere, una plataforma ASM comercial dedicada. Lo importante es no confundir cobertura con falsa tranquilidad.

Recursos relacionados

Attack surface management con Secra

En Secra integramos Shodan, Censys y descubrimiento activo en cada proyecto de pentesting externo y en programas continuos de attack surface management. Definimos el alcance formal con el cliente (rangos IP, ASNs, dominios, cuentas cloud), configuramos Monitor con alertas hacia SIEM, mantenemos un catálogo de queries propio por sector y entregamos informes con hallazgos accionables priorizados, no listas de IPs sin contexto. Si necesitas auditar la exposición externa real de tu organización o quieres montar un programa ASM con criterio y disciplina de cierre, escríbenos a través de contacto o consulta nuestro servicio de pentesting.

Sobre el autor

Equipo de Secra Solutions

Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.

Compartir artículo