Un activo olvidado es un hallazgo hasta la primera CVE: cómo conciliar el perímetro declarado y el real

El mes pasado nos pidieron evaluar el perímetro externo de una empresa logística mediana. El alcance indicaba tres dominios y dos direcciones IP. Dos horas después de empezar, resultó que en una de esas direcciones IP funcionaba un servidor web que no aparece en ninguna documentación del cliente, y que otros dos subdominios resolvían a direcciones públicas que nadie del equipo de soporte conocía.

No es algo excepcional. Es la situación habitual en cualquier auditoría externa: la diferencia entre lo que un cliente considera su perímetro y lo que realmente es accesible desde internet suele ser mayor de lo previsto.

El primer paso de una prueba externa no es buscar vulnerabilidades

Es verificar el perímetro. Antes de lanzar escáneres o probar inyecciones hay que responder a una pregunta simple: ¿qué recursos pertenecen realmente al cliente? Si las pruebas parten de una lista de activos incorrecta, todo lo que venga después queda distorsionado. O se pasa por alto una superficie de ataque crítica, o se invierte tiempo en sistemas que no forman parte de la infraestructura del cliente, por ejemplo una IP reasignada a otro arrendatario después de una migración.

MITRE ATT&CK describe esta etapa como T1590: Gather Victim Network Information. Un atacante siempre empieza por el reconocimiento: reúne información sobre la infraestructura de red del objetivo para averiguar dónde está el punto más débil. El equipo de pruebas hace lo mismo, de forma legal y con fines defensivos. La única diferencia es que el resultado de nuestro reconocimiento debería coincidir con lo que el cliente entiende por su perímetro. Cuando no coincide, hay un problema de visibilidad de activos, y conviene resolverlo antes de pasar a la explotación.

Por qué importan los activos olvidados

Los activos olvidados son la clase de recurso que con más frecuencia se convierte en punto de entrada para un compromiso. Están abandonados, ejecutan versiones antiguas de software, sus contraseñas llevan años sin cambiarse y no pasan por los ciclos regulares de gestión de parches. La Binding Operational Directive 23-01 de CISA señala la mejora de la visibilidad de activos y de la detección de vulnerabilidades como tarea prioritaria, y el motivo es simple: no se puede corregir aquello cuya existencia se desconoce.

Cómo se verifica el perímetro en la práctica

Tomamos la lista de activos acordada con el cliente: dominios, direcciones IP, servicios. Después construimos una evaluación independiente de lo que realmente se ve desde fuera, a través de varios canales en paralelo:

1. Resolución DNS de todos los dominios conocidos y búsqueda de zonas relacionadas.
2. Escaneo de puertos en las direcciones IP indicadas.
3. Revisión de los certificados SSL/TLS: los campos CN y SAN revelan con frecuencia nombres de host adicionales.
4. Análisis de los datos WHOIS y del historial de registro de los dominios.

El punto clave es la comparación de dos listas: la que entregó el cliente y la que encontramos nosotros. Cualquier discrepancia es una señal. Supongamos que el cliente indicó app.example.com con la IP 1.2.3.4. Al escanear vemos que old-api.example.com también resuelve a 1.2.3.4, con el puerto 8080 abierto y un servicio HTTP que devuelve la versión de la aplicación en las cabeceras. Ese recurso no estaba en el alcance. ¿Qué se hace entonces?

Qué ocurre cuando aparece algo fuera del alcance

No tenemos derecho a empezar a explotar ese activo recién encontrado. Lo primero es comunicárselo al cliente. Puede ser un servidor antiguo previsto para apagarse pero todavía activo. Puede ser un entorno de pruebas que quedó accesible públicamente por accidente. Puede ser un microservicio legítimo que sencillamente se quedó fuera del inventario. La decisión se toma junto con el cliente: o se incorpora a la auditoría en curso, o se registra como hallazgo de configuración de seguridad.

Dónde la automatización acorta la primera pasada

Conciliar dos listas a mano es lento y expuesto al error humano, sobre todo cuando hay cientos de dominios de por medio. Para reducir el tiempo de la recopilación inicial de datos utilizamos la función de descubrimiento de activos olvidados de SeguriScan. Genera una lista independiente de dominios, direcciones IP y dispositivos de red accesibles desde fuera a partir de fuentes públicas: DNS, WHOIS, certificados y resultados de escaneo de puertos.

Ese informe automatizado sirve de base para la comparación. En lugar de recopilar datos dominio por dominio, obtenemos una lista estructurada: estas son todas las IP públicas, estos son todos los dominios relacionados, estos son los dispositivos encontrados. A partir de ahí la tarea se reduce a un diff en ambos sentidos. ¿Qué está en el informe y falta en la lista del cliente? Y a la inversa: ¿qué declaró el cliente que no resulta accesible desde fuera, quizá porque un firewall ya lo cerró?

El enfoque resulta especialmente útil para los MSP (Managed Service Providers) que atienden a decenas de clientes. Cada cliente tiene su propio conjunto de activos y mantenerlos todos actualizados de memoria no es viable. Obtener de forma automática una lista independiente del perímetro antes de cada auditoría reduce el riesgo de dejar superficies sin revisar.

Comprobaciones manuales cuando no hay herramientas especializadas

Hay varias comprobaciones que vale la pena hacer incluso sin herramientas dedicadas. No ofrecen la imagen completa que da una recopilación sistemática, pero cada una suele sacar algo a la luz.

DNS inverso contra el inventario

Empiece por una conciliación básica de DNS. Tome la lista de sus direcciones IP públicas y ejecute una resolución inversa (reverse lookup) para cada una. Coteje los nombres de host obtenidos con su inventario interno (CMDB). Un nombre de host que no figure en la base es una señal de alerta: puede ser un servidor olvidado o un registro no autorizado.

Historial de DNS

Revise también el historial de DNS. Servicios como SecurityTrails o ViewDNS.info muestran qué direcciones IP estuvieron asociadas a sus dominios en el pasado. A veces quedan registros antiguos en la caché o en el proveedor de DNS aunque el recurso ya se haya eliminado físicamente. El caso más serio es otro: en ocasiones el recurso no se elimina del todo y parte de su funcionalidad sigue accesible por IP o subdominios antiguos.

Campos SAN de los certificados TLS

Otra comprobación que compensa es el análisis de los certificados TLS. Solicite el certificado de cada uno de sus dominios públicos y revise con atención el campo SAN (Subject Alternative Name). Puede incluir nombres de host que no aparecen en su documentación actual. Si dev.internal.example.com surge de pronto en el campo SAN de un certificado público, significa que ese host estuvo accesible desde fuera en algún momento, o que el certificado se emitió de forma incorrecta e incluye nombres de más. En cualquier caso, conviene investigarlo: puede que un servicio interno haya quedado expuesto hacia fuera.

Convierta la conciliación en algo periódico, no en una tarea previa a la auditoría

La conciliación del perímetro debería formar parte de un ciclo de monitorización regular y no de una tarea puntual antes de una auditoría. Aparecen servicios nuevos, se detienen los antiguos, las direcciones IP cambian con las migraciones a la nube. Si el perímetro solo se revisa antes de la prueba de penetración anual, se corre el riesgo de acumular en un año varios activos «olvidados», cada uno de ellos una posible vía de entrada. Una conciliación periódica, trimestral o incluso mensual, mantiene el inventario al día y reduce la ventana durante la cual uno de esos activos permanece desconocido.