Infraestructura fantasma tras una adquisición: cómo descubrir lo que nadie inventarió

El inventario que te entregaron no es el inventario real

Cuando una empresa adquiere una startup, el proceso de due diligence suele centrarse en el negocio: ingresos, contratos, equipo, propiedad intelectual. La infraestructura técnica queda en un segundo plano, y lo que se entrega como inventario de activos suele ser, en el mejor de los casos, una foto parcial de lo que existe realmente.

Semanas o meses después de cerrar la operación, empiezan a aparecer cosas: un dominio con tráfico activo que nadie mencionó, una cuenta AWS vinculada a la tarjeta personal de un fundador que ya no trabaja en la empresa, un bucket S3 con datos de clientes que sigue generando costes. No es negligencia maliciosa — es simplemente cómo crecen las startups. Rápido, sin parar a documentar, con cada desarrollador desplegando lo suyo.

Confiar en la CMDB del equipo adquirido o en lo que te cuenten en una reunión no va a llevarte muy lejos. La metodología que funciona es la contraria: descubrimiento externo primero, reconciliación interna después.

Por qué empezar desde fuera, no desde dentro

La trampa clásica es usar el inventario existente como punto de partida y luego intentar completarlo. El problema es que ese inventario define implícitamente qué existe — y lo que no está en él tiende a quedarse invisible.

La alternativa es tratarlo como un problema de descubrimiento: actuar como si no supieras nada y reconstruir el mapa de la infraestructura desde señales externas verificables. Luego, y solo luego, comparas contra lo que hay en la CMDB, el GRC o cualquier herramienta de compliance que use la empresa. Lo que está en los registros externos pero no en los internos es exactamente donde están los problemas.

Esta inversión del flujo habitual no es teórica. Profesionales con décadas de experiencia en entornos cloud a gran escala coinciden en que es la única forma de evitar que el sesgo del inventario existente contamine toda la auditoría.

Las victorias rápidas: DNS y certificados SSL

El punto de entrada más accesible y con mejor ratio esfuerzo/resultado son los registros DNS. Una enumeración completa de subdominios del dominio principal de la startup adquirida puede revelar decenas de hosts que nadie mencionó: entornos de staging, aplicaciones internas, paneles de administración, instancias de prueba nunca eliminadas.

No es raro encontrar más de setenta u ochenta subdominios activos en un dominio que el equipo adquirido describía como sencillo. La mayoría apuntan a recursos que alguien creó, usó durante un sprint y olvidó.

Complementar esto con los registros de transparencia de certificados SSL es especialmente potente. Servicios como crt.sh registran todos los certificados emitidos para un dominio, incluidos los de subdominios que quizás ya no resuelven pero que existieron. Esto permite reconstruir el historial de infraestructura, no solo el estado actual.

El problema de los dominios pendientes (dangling DNS)

Aquí es donde una auditoría deja de ser solo un ejercicio de inventario y se convierte en una cuestión de seguridad activa.

Un dominio pendiente o dangling DNS es un registro CNAME que apunta a un servicio externo que ya no existe: una aplicación en Heroku eliminada, un bucket S3 dado de baja, un proyecto en Vercel que se borró. El subdominio sigue en el DNS de la empresa, pero el destino está vacío — y en muchos de esos servicios, cualquier tercero puede reclamar ese nombre y empezar a servir contenido bajo el dominio legítimo de la empresa.

El impacto potencial es serio: desde phishing bajo un dominio de confianza hasta robo de cookies de sesión si el subdominio comparte dominio padre con aplicaciones activas.

Herramientas como dnsReaper o nuclei automatizan la detección de estos registros problemáticos y son gratuitas o de bajo coste, dentro del alcance de cualquier equipo técnico sin presupuesto dedicado de ciberseguridad. No es necesario recurrir a plataformas enterprise para hacer esta comprobación.

Facturación cloud: el mapa del dinero que ya se está gastando

Los registros DNS te dicen qué nombres existen. La facturación cloud te dice qué está encendido y costando dinero ahora mismo.

El problema típico en una startup adquirida es que las cuentas cloud no siempre están bajo una organización central. Es frecuente encontrar cuentas AWS o GCP creadas por fundadores o desarrolladores a título personal, vinculadas a tarjetas de crédito ya no disponibles y con servicios activos que nadie supervisa. Hasta que la tarjeta caduca o alguien revisa un extracto, esos recursos siguen corriendo.

Acceder a estos datos requiere trabajo de campo: hablar con los fundadores o desarrolladores históricos para recuperar credenciales, revisar correos corporativos de facturas de cloud, o rastrear direcciones de correo vinculadas a las cuentas. Es laborioso, pero cada cuenta huérfana localizada representa tanto un ahorro de costes inmediato como un vector de acceso potencialmente desprotegido.

La recomendación práctica es empezar siempre por las direcciones MAC e IPs conocidas como línea de base técnica, y desde ahí escalar: DNS, LDAP o Active Directory si existe, escaneos de red, y finalmente comparación contra CMDB y herramientas de compliance. Es una cadena ascendente, no un proceso de arriba abajo.

El factor humano más impredecible: los proyectos paralelos de los desarrolladores

Ningún informe de due diligence menciona esto, pero es consistentemente la fuente más común de infraestructura fantasma en startups: los proyectos que un desarrollador individual desplegó un viernes por la tarde para probar algo, nunca documentó, y que llevan meses o años ejecutándose.

Pueden ser instancias de base de datos con datos reales de producción copiados para pruebas, integraciones con servicios de terceros usando claves API de la empresa, o simplemente herramientas internas que el equipo usaba pero que nunca entraron en ningún inventario porque siempre habían funcionado sin problemas.

El análisis pasivo del tráfico de red ayuda a detectar este tipo de infraestructura: conexiones salientes a destinos desconocidos, patrones de tráfico periódico hacia servicios no documentados, o picos de coste en cuentas cloud sin correlación con releases conocidos. Los registros de transparencia de certificados también son útiles aquí, porque muchos de esos proyectos paralelos tienen su propio certificado.

Herramientas accesibles sin presupuesto enterprise

Una pregunta legítima en cualquier pyme es si este tipo de auditoría requiere invertir en plataformas de seguridad de gran escala. La respuesta corta es no, al menos para el descubrimiento inicial.

• crt.sh: consulta gratuita de registros de transparencia de certificados SSL. Sin instalación, sin coste.
• dnsReaper: herramienta de código abierto para detectar dominios DNS pendientes con riesgo de apropiación.
• nuclei: escáner de vulnerabilidades y misconfigurations con plantillas mantenidas por la comunidad, gratuito para uso interno.
• DNS brute-forcing con diccionarios de subdominios comunes: técnica básica pero efectiva para enumeración inicial.
• Análisis de logs de facturación de AWS, GCP o Azure exportados a formatos tabulares: combinado con herramientas como DuckDB y Parquet, permite procesar grandes volúmenes de datos de coste sin infraestructura adicional.

La combinación de estas herramientas cubre la mayor parte del descubrimiento sin requerir licencias. Lo que sí requieren es tiempo técnico y metodología.

¿Cuánto tiempo lleva realmente?

Una auditoría inicial de DNS, certificados y facturación cloud puede completarse en días si el equipo técnico tiene acceso a las cuentas y los dominios. Pero el proceso completo no es puntual: es incremental.

Durante los primeros meses tras la adquisición, seguirán apareciendo activos a medida que expiren suscripciones, caduquen accesos, o se procesen facturas antiguas. El tiempo entre descubrimiento de un activo y su remediación efectiva — cancelar la cuenta, eliminar el CNAME, revocar credenciales — depende de factores externos: recuperar acceso a cuentas vinculadas a personas que ya no están, gestionar contratos con terceros, o simplemente priorizar dentro de un equipo con más tareas que tiempo.

No hay un número universal, pero la expectativa realista es que una auditoría completa y estabilizada lleva varios meses, no semanas. Quien espera resolver esto en un sprint probablemente está subestimando el problema.

La frontera emergente: agentes de IA para auditorías continuas

Hay un debate activo en la comunidad técnica sobre si los agentes de IA pueden cambiar el modelo de auditoría de infraestructura. La idea es darle a un agente acceso de solo lectura a registros de aplicaciones, conexiones de plataformas como Azure o VMware, y claves API de sistemas de logging, y dejar que construya el mapa de activos de forma autónoma.

En la práctica, algunos equipos ya están explorando esto con modelos de lenguaje avanzados orquestados mediante flujos automatizados, y los resultados en velocidad son llamativos: lo que manualmente lleva días puede analizarse en minutos.

El debate es sobre el coste real. El procesamiento por tokens de grandes volúmenes de logs tiene un precio que, según el caso, puede superar al de sistemas de observabilidad clásicos basados en formatos abiertos como Parquet con DuckDB. No hay una respuesta universal: depende del volumen de datos, la frecuencia de las auditorías y qué tan madura esté la infraestructura de observabilidad existente.

Lo que sí parece claro es que la dirección es hacia auditorías continuas y automatizadas, no hacia revisiones manuales puntuales. Y eso conecta directamente con herramientas de orquestación que permiten programar flujos de descubrimiento recurrentes sobre DNS, cloud y logs sin intervención manual en cada ciclo.

El coste de no hacer esto

Cada dominio pendiente sin resolver es un vector de ataque abierto. Cada cuenta cloud huérfana es dinero saliendo sin control. Cada bucket con datos de clientes activo sin supervisión es una exposición frente al RGPD que puede materializarse en cualquier momento en forma de notificación a la AEPD.

La infraestructura fantasma no es un problema técnico abstracto. Tiene coste financiero directo, tiene riesgo legal concreto, y tiene un impacto reputacional real si algo sale mal con un dominio que el equipo ni siquiera sabía que existía.

La buena noticia es que el punto de entrada — una enumeración DNS y una consulta a crt.sh — está al alcance de cualquier equipo técnico con unas horas disponibles. La pregunta no es si tienes infraestructura que no conoces. Después de una adquisición, la tienes casi con certeza. La pregunta es cuánto tiempo vas a esperar para empezar a buscarla.