Starkiller se encuadra en una categoría de phishing que ya no intenta “imitar” una página de acceso: se coloca en medio y proxy la página legítima en tiempo real. El usuario ve un login “normal”, introduce credenciales y completa MFA, y aun así el atacante puede quedarse con el estado autenticado (cookies/tokens) y reutilizarlo. El resultado es una intrusión que, desde el punto de vista de muchos controles tradicionales, se parece demasiado a un inicio de sesión válido.
En operaciones corporativas esto cambia el foco: no basta con “tener MFA” o con entrenar a la gente para detectar logos mal puestos. La defensa útil pasa por entender qué está interceptando el proxy (la sesión), cómo viaja esa sesión hacia el atacante, y cómo instrumentar señales que te permitan detectarlo y cortar el acceso antes de que el atacante convierta esa sesión en persistencia.
Qué salió mal: MFA completado y sesión robada igualmente
El fallo típico no es que el usuario “metiera la contraseña en cualquier sitio” sin pensar; es que el flujo se ve legítimo porque el servicio de phishing carga la página real a través de un proxy. En muchos casos el dominio fraudulento sirve el contenido del proveedor (IdP/SSO) y el usuario completa el proceso sin fricción. Lo que el atacante busca no es solo la contraseña, sino el artefacto que prueba “ya estoy autenticado”: la cookie de sesión o el token emitido tras el MFA.
En términos de impacto, esto se traduce en accesos a correo, herramientas de colaboración o consolas cloud sin necesidad de volver a teclear credenciales. En la práctica, el primer movimiento suele ser cambiar reglas de reenvío de correo, registrar un nuevo factor, crear una app OAuth “legítima” o descargar datos. El equipo de seguridad recibe alertas que parecen “un usuario iniciando sesión correctamente”, y el tiempo de reacción se reduce.
Cómo funciona Starkiller cuando actúa como proxy en tiempo real
La idea operativa es sencilla: el atacante controla un dominio y un servidor que se comporta como intermediario. El navegador del usuario no habla directamente con el IdP, sino con el proxy; el proxy a su vez habla con el IdP real. El usuario ve pantallas auténticas porque, en gran medida, lo son: se renderizan a través del intermediario.
En ese tránsito, el proxy puede capturar credenciales y, lo más crítico, capturar/inyectar cookies y tokens. Si el proveedor emite una cookie de sesión tras el MFA, esa cookie puede quedar expuesta al intermediario y reutilizarse desde otra máquina. En empresa esto se nota porque el atacante no “rompe” MFA: lo reusa en la ventana de tiempo en la que la sesión es válida.
- Intercepción de la sesión (cookie/token)
Cuando el objetivo es la cookie, el indicador más doloroso es que cambiar la contraseña después no corta inmediatamente la sesión robada si no hay invalidación global o si hay sesiones persistentes. En entornos con aplicaciones legacy o integraciones, esto es frecuente: se rota la contraseña, pero la sesión sigue viva lo suficiente para que el atacante cree persistencia.
- Reutilización desde otro host/ASN
Operativamente se observa como un “salto”: el mismo usuario pasa de un login interactivo a actividad desde otra ubicación/red sin un nuevo desafío de MFA. Si el IdP no liga la sesión al dispositivo o no fuerza reautenticación ante cambios de contexto, el atacante puede operar hasta que expire la sesión o alguien la revoque.
Señales tempranas en logs: lo que realmente delata un proxy de phishing
La detección efectiva rara vez viene de “URL sospechosa” en un correo (aunque ayuda). Lo que suele delatar un proxy en tiempo real son anomalías de flujo: secuencias de eventos, cambios bruscos de IP/UA, o patrones de acceso que no encajan con el dispositivo habitual. En un SOC corporativo, lo valioso es correlacionar telemetría del IdP, del endpoint y del SaaS destino.
Ejemplo realista: un usuario completa MFA en el IdP desde su portátil corporativo (telemetría EDR presente), y a los pocos minutos aparece actividad en el correo desde un user-agent distinto y sin huella del dispositivo gestionado. Si además el atacante crea reglas de inbox o autoriza una app OAuth, ese “segundo paso” suele ser más determinista que el propio login.
- Cambio de contexto sin reautenticación
Busca sesiones que cambian de IP/ASN o de user-agent en una ventana corta, especialmente si no hay un nuevo evento de MFA o “step-up”. En proveedores que registran “token refresh” o “session issued”, correlaciónalo con el primer acceso a recursos sensibles (correo, drive, consola).
- Acciones de persistencia en SaaS
Reglas de reenvío, delegaciones, dispositivos registrados, claves de aplicación o apps OAuth nuevas suelen ser el siguiente movimiento. Es más útil alertar por “creación de forwarding rule” o “consent granted” tras un inicio de sesión anómalo que intentar bloquear cada email de phishing.
Cómo hacerlo en la práctica: guardrails que sí cortan el robo de sesión
La defensa contra phishing con proxy no es una sola pieza; es una combinación de controles de sesión y políticas de acceso condicionado. La meta es que, aunque el usuario complete MFA en un flujo intermediado, la sesión no sea reutilizable desde el entorno del atacante o quede rápidamente invalidada al cambiar el contexto.
En empresa, lo más efectivo suele ser endurecer el plano de identidad: exigir autenticación resistente al phishing cuando sea posible (métodos basados en origen/clave, no códigos), y forzar “step-up” o bloqueo cuando el dispositivo no es gestionado o cuando el origen de red no cumple. Si tu organización depende de BYOD o acceso externo, hay que aterrizarlo con excepciones bien gobernadas; si no, el bypass operacional lo hace la propia empresa.
- Configurar acceso condicionado por dispositivo y riesgo
Acción concreta: define políticas que requieran dispositivo gestionado/compliant para aplicaciones críticas (correo, almacenamiento, paneles admin). Verificación: valida en el IdP que un login desde un navegador no gestionado fuerza un método más fuerte, limita la sesión o directamente bloquea. En pruebas internas, simula el acceso desde un dispositivo sin posture y confirma que no obtienes una sesión reutilizable.
- Reducir vida y alcance de sesión
Acción concreta: ajusta timeouts de sesión y revocación. A nivel operativo, asegúrate de que el procedimiento de respuesta (reset de contraseña) incluye revocar sesiones activas y revocar tokens en el IdP/SaaS. Verificación: tras revocar, comprueba que una sesión previamente activa deja de acceder (no solo que falle el siguiente login).
- Bloquear persistencia típica post-phishing
Acción concreta: crea alertas y, si tu plataforma lo soporta, reglas de auto-remediación para: creación de reglas de reenvío, concesión de consentimientos OAuth, alta de factores nuevos y cambios de métodos de recuperación. Verificación: ejecuta un ejercicio controlado (cuenta señuelo) y confirma que el evento dispara alerta y que el playbook revoca sesión y revierte el cambio.
Recomendaciones para entornos corporativos
Starkiller representa un phishing donde el objetivo real es la sesión, no el formulario. En ese escenario, completar MFA no garantiza seguridad si el atacante puede intermediar el flujo y reutilizar cookies/tokens emitidos tras el desafío.
En operación, lo que mejor funciona es combinar: detección por secuencias (cambios de contexto sin reautenticación y acciones de persistencia), políticas de acceso condicionado que aten sesiones a dispositivo/riesgo, y procedimientos de respuesta que incluyan revocación efectiva de sesiones y tokens. Si tus controles no fuerzan un “step-up” cuando cambia el contexto, un proxy en tiempo real seguirá pareciendo un login normal.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.