Un error de configuración en kits adversary-in-the-middle expone direcciones IP de servidores relay en cookies de sesión — y convierte un único dominio reportado en un mapa completo de la operación.
Un atacante registró un dominio, obtuvo certificado TLS y desplegó una página activa de cosecha de credenciales en menos de 24 minutos — 12 de esos minutos fueron tiempo de espera en la propagación de nameservers. Esa velocidad de reemplazo explica por qué el bloqueo de dominios, la métrica más reportada en programas de defensa contra phishing, tiene impacto operacional limitado: el dominio es el activo más barato y descartable que posee el adversario. Los kits de phishing que dominan el panorama actual no sirven páginas falsas — funcionan como proxies adversary-in-the-middle que relayan tráfico en tiempo real hacia servicios legítimos como Microsoft Sign-in, capturando credenciales y tokens de sesión mientras las víctimas completan prompts de autenticación multifactor genuinos. Microsoft documentó una única campaña de este tipo que alcanzó más de 10,000 organizaciones, y el modelo se ha vuelto cada vez más accesible desde entonces.
El servidor como punto de costo real — y por qué los kits modernos lo ocultan
El dominio cuesta un dólar y se reemplaza en minutos. El servidor, en cambio, requiere inversión de tiempo y dinero, persiste entre campañas porque reconstruirlo es tedioso, y — lo más importante desde una perspectiva de inteligencia de amenazas — es compartido entre múltiples operaciones. Identificar el servidor de origen no entrega un único indicador: entrega el inventario completo de la infraestructura del atacante. Precisamente por eso, los kits modernos están diseñados para impedir que se lo encuentre. Colocar el proxy detrás de una red de distribución de contenido (CDN) hace que las consultas de transparencia de certificados devuelvan el certificado de la CDN, no el del origen. El DNS pasivo muestra que el dominio nunca resolvió a otra dirección. Las plataformas de escaneo masivo de internet devuelven resultados vacíos — no porque no haya nada, sino porque el servidor de origen rechaza cualquier conexión que no presente el hostname exacto esperado, en menos de medio segundo, sin servir un solo byte de datos.
Cómo un cookie de sesión reveló la dirección del atacante
El mecanismo que finalmente expuso el servidor fue un error de configuración en el propio proxy del atacante. Cuando el proxy relaya una solicitud de login hacia Microsoft, el servicio legítimo ve una conexión entrante — pero esa conexión no proviene de la víctima, proviene del proxy, porque el proxy es quien está haciendo la solicitud real. Microsoft, como muchos servicios, establece un cookie que registra la dirección IP desde la cual observó que el cliente se conectó. El proxy transparente, configurado para relayar respuestas sin reescribir headers, devuelve ese cookie a la víctima sin modificarlo. El resultado: el navegador de la víctima recibe un cookie estampado con la dirección IP del servidor relay del atacante. El proxy escribe su propia dirección de retorno en el sobre que entrega a la persona que está robando. El hallazgo surgió al filtrar una captura de tráfico descifrado en busca de cookies establecidos por el sitio de phishing — el valor no era ni la dirección de Microsoft ni la del entorno de análisis, sino la de un pequeño proveedor de hosting reseller que acepta criptomonedas.
Por qué un hallazgo no es una conclusión hasta que se corrobora desde direcciones independientes
El paso siguiente importa más que el hallazgo mismo: no tratarlo como resuelto. Un artefacto es una pista, no una conclusión, y el salto prematuro entre ambos es cómo las investigaciones se retractan y cómo los programas de inteligencia pierden la credibilidad que los hace útiles. La hipótesis alternativa obvia era que el cookie hubiera capturado la dirección de salida del entorno de detonación en lugar de la del atacante. Examinar la dirección IP — un reseller de servidores virtuales económicos, no una ruta que use ningún sandbox comercial — debilitó esa alternativa sin cerrarla. Lo que la cerró fue corroboración desde direcciones que la primera observación no podía haber influenciado, llegando de forma independiente y coincidiendo. Solo entonces el hallazgo se consideró verificado. Si hubieran discrepado, habría permanecido en las notas como no verificado y se habría publicado de esa manera — los resultados no probados siguen siendo resultados, y el siguiente analista obtiene más valor de una incertidumbre declarada que de una suposición presentada con confianza.
De un email reportado a un mapa completo de infraestructura compartida
La dirección del servidor llevó a un segundo dominio que había apuntado silenciosamente a esa IP durante meses sin servir contenido, lo cual llevó a su vez a un registrador que el operador no usaba en ningún otro lugar. Resolver los dominios restantes los agrupó en un puñado de máquinas. Y dos de esas máquinas estaban alojando dominios pertenecientes a tenants de identidad en la nube separados que el operador había trabajado activamente para mantener compartimentados. Esos tenants no tenían relación visible entre sí — enumerar cualquiera de ellos nunca habría revelado al otro. Pero el operador había economizado en hosting, y la infraestructura compartida expuso lo que la identidad compartimentada había ocultado. Un único email de phishing reportado se convirtió en un inventario mapeado de docenas de dominios lookalike suplantando fabricantes reales, agencias de staffing y empresas de gestión de residuos. Este patrón de economización en servidores mientras se mantiene separación en identidad es estructuralmente común en operaciones que buscan escala sin inversión proporcional en infraestructura — y es precisamente el tipo de comportamiento que el bloqueo de dominios individuales no puede detectar ni interrumpir.
Nuestro análisis
El caso documenta una brecha entre dónde invierten recursos los programas de defensa y dónde el adversario tiene costos reales. El dominio — el indicador más bloqueado, reportado y medido — es el activo más barato y reemplazable en la cadena de ataque. El servidor, en cambio, es compartido, persistente y costoso de reconstruir, pero la mayoría de los programas nunca lo ven porque las técnicas de ocultamiento (CDN, gating por hostname, rechazo sub-segundo de conexiones no esperadas) están diseñadas específicamente para impedir que las plataformas de escaneo y los feeds de inteligencia lo alcancen. La exposición accidental de la IP del relay en cookies de sesión — un error de configuración en proxies transparentes que no reescriben headers de respuesta — representa una clase de artefacto forense que no depende de que el servidor responda a escaneos externos ni de que el dominio persista el tiempo suficiente para ser catalogado. Para América Latina, donde la adopción de autenticación multifactor en organizaciones medianas sigue siendo irregular y donde la dependencia de servicios de identidad en la nube de Microsoft es alta (especialmente en sectores financiero, manufactura y gobierno), este tipo de ataques representa una amenaza de evasión directa: el usuario completa un prompt MFA legítimo, ve una página genuina de Microsoft, y el atacante obtiene un token de sesión activo sin que ningún control de autenticación haya fallado. La pregunta que queda abierta es cuántos programas de defensa en la región están equipados para trabajar en la capa del servidor — no solo en la del dominio — cuando el adversario ha invertido en ocultarlo.