El 10 de abril de 2026, la policía finlandesa detuvo a un joven de 19 años cuando intentaba embarcar en un vuelo con destino a Japón. Llevaba consigo dos discos duros de dos terabytes cada uno. Según una denuncia penal modificada y hecha pública en el Distrito Norte de Illinois, ese viajero es Peter Stokes, ciudadano con doble nacionalidad estadounidense y estonia, y los discos duros eran solo la punta del iceberg. El FBI alega que es miembro de Scattered Spider, el grupo al que Microsoft denomina «Octo Tempest», y que ayudó a llevar a cabo intrusiones que el Gobierno relaciona con más de 100 ataques a redes y más de 100 millones de dólares en pagos de rescates.
He leído la denuncia en su totalidad. Tiene 35 páginas y es el relato de primera mano más claro que he visto públicamente sobre un ataque Scattered Spider . La mayor parte de lo que sabemos sobre este grupo procede de blogs de proveedores y resúmenes de incidentes redactados a posteriori. Esto es diferente. Se trata de una declaración jurada federal que describe el ataque paso a paso, nombra las herramientas y cita los registros.
Dos aclaraciones antes de seguir adelante. Una denuncia es una acusación, no una condena, y el Gobierno no ha demostrado nada de esto ante los tribunales. Además, se ha preservado el anonimato de las víctimas, por lo que no voy a especular sobre quién es la «Empresa F». Lo que importa aquí son las técnicas de trabajo, y estas están documentadas.
El ataque, en el orden en que ocurrió
El caso central es una intrusión ocurrida en mayo de 2025 en la empresa F, descrita en la declaración jurada como una cadena minorista de artículos de lujo valorada en varios miles de millones de dólares. A continuación se muestra la cadena de eventos, extraída directamente de los registros de red que cita el FBI.
Todo empezó con unas llamadas telefónicas. Alrededor del 12 de mayo de 2025, unos atacantes llamaron al servicio de asistencia informática de la empresa F desde dos números de Google Voice, haciéndose pasar por empleados, y solicitaron restablecer sus credenciales, incluida la contraseña y el dispositivo móvil utilizado para la autenticación multifactorial. En unas dos o tres horas, habían comprometido tres cuentas de usuario. Sin exploits. Sin malware. Una llamada telefónica y un restablecimiento.
Dos de esas tres cuentas pertenecían a administradores de TI. Los atacantes utilizaron las cuentas estándar que acababan de robar para obtener las credenciales de alto nivel de los administradores y, con ellas, accedieron a las plataformas que controlan los servidores virtuales y cloud de la empresa F.
A partir de ahí, necesitaban perseverancia y una vía de escape. Instalaron ngrok en un servidor de la empresa F, una herramienta legítima para desarrolladores que abre un túnel seguro desde el interior de una red privada hacia Internet, una forma limpia de eludir las defensas perimetrales sin activarlas. A continuación, utilizaron Teleport.sh, otra utilidad legítima de acceso remoto, junto con el almacenamiento de Amazon S3, para sacar los datos. En tres días, sustrajeron al menos 77 gigabytes.
Intentaron rematar la faena con un ransomware. El equipo de seguridad de la empresa F detuvo esa parte y, finalmente, los expulsó. Pero para entonces los datos ya se habían perdido. El 15 de mayo, los atacantes enviaron una nota de rescate desde un buzón de correo que habían comprometido, con el asunto «IMPORTANTE: HEMOS ROBADO LOS DATOS, PÓNGASE EN CONTACTO INMEDIATAMENTE [sic]». Las negociaciones a través de un tercero dieron lugar a una demanda: «8 millones de dólares parece un buen precio». La empresa F no pagó. Las pérdidas declaradas por la interrupción de la actividad y las medidas de mitigación ascendieron a unos 2 millones de dólares.
La denuncia también sitúa al grupo dentro de la economía del «ransomware como servicio» (RaaS). En un servidor vinculado a Stokes, los investigadores encontraron chats en una ventana denominada «DragonForce», una marca de RaaS, entre los que figuraba el de un afiliado quejándose de que le hubieran cobrado 500 dólares por un nuevo nombre de usuario «después de que os hayamos hecho ganar más de un millón». DragonForce no es un grupo fijo, sino un código y una infraestructura que los afiliados alquilan, basada en el mismo Black Basta de Conti y Black Basta que seguí en «De Conti a Black Basta DevMan: el interminable cambio de marca del ransomware».
La marca que aparece en la nota de rescate cambia. El comportamiento, no.
Por qué la prevención no detectó nada
Repasa esa cadena de eventos y fíjate en lo que nunca ocurrió . No hubo ningún intento fallido de inicio de sesión. No se detectó ninguna malware . No se produjo ningún ataque contra un servicio sin parches. Cada puerta que se abrió, se abrió con una llave válida.
El atacante llama haciéndose pasar por el empleado y el servicio de asistencia restablece las credenciales, de modo que el siguiente inicio de sesión lo realiza un usuario real con una contraseña real y un dispositivo de autenticación multifactorial (MFA) real. La autenticación se realiza con éxito. La escalada de privilegios utiliza la propia ruta legítima de la cuenta para obtener una contraseña temporal, por lo que el sistema de identidad registra una elevación autorizada. El túnel de salida discurre a través de ngrok y Teleport, herramientas que un desarrollador podría utilizar cualquier martes. Los datos llegan a Amazon S3, un punto final con el que se comunican millones de empresas a lo largo del día. Esta es la Brecha 2: la autenticación se realiza con éxito, pasando directamente a la Brecha 3, donde el movimiento no es visible. El registro de auditoría les dio vía libre, y la exfiltración se ocultó dentro de un tráfico que parecía normal.
Esta es la parte en la que quiero que se fijen los responsables de seguridad. El equipo de la empresa F no estaba dormido. Detectaron la fase del ransomware y obligaron a los atacantes a retirarse. La prevención y los controles de los terminales cumplieron su función en la fase para la que estaban diseñados. La pérdida se produjo antes, en el intervalo entre un restablecimiento correcto por parte del servicio de asistencia técnica y el momento en que finalizó la subida de 77 gigabytes. Ese intervalo tiene que ver con el comportamiento. Tanto una identidad robada como una auténtica se autentican. Lo único que las diferencia es lo que hacen a continuación: una cuenta de administrador que accede a sistemas a los que nunca suele acceder, un túnel ngrok sin precedentes desde un servidor de producción, una subida repentina a S3 de decenas de gigabytes. Nada de eso es una firma. Todo ello es un patrón.
El manual de medidas de seguridad de 2024 sigue siendo válido, pero ya no cubre esta vía de acceso. La autenticación multifactorial (MFA) Phishing es fundamental. Sin embargo, un restablecimiento realizado por el servicio de asistencia técnica proporciona al atacante un registro de MFA nuevo y legítimo, por lo que el control que debería haber impedido el uso de una contraseña robada se vuelve a emitir a la persona equivocada tras su solicitud. Ya he escrito anteriormente sobre por qué los restablecimientos de la MFA y los códigos SMS son el punto débil de una estructura de identidades que, por lo demás, está bien protegida.
La vulnerabilidad no es el MFA. La vulnerabilidad es el reinicio y todo lo que hace el atacante una vez que el reinicio se ha llevado a cabo con éxito.
Todas las herramientas eran legítimas
En esta historia no hay ningún implante personalizado. Ngrok, Teleport.sh y Amazon S3 son herramientas creadas para ingenieros, y precisamente por eso resultan útiles para los atacantes. No hay nada que analizar, nada en una lista de bloqueo, nada que delate la presencia malware.
Haz un seguimiento del comportamiento, no de la marca.
La cuestión no es si ngrok es malicioso, porque no lo es. La cuestión es si la apertura de un túnel desde el interior de tu centro de datos hacia la Internet pública, desde un servidor que nunca antes lo había hecho, es algo que detectarías y cuestionarías a tiempo.
Cómo pillaron a un adolescente
La otra mitad de la denuncia se centra en la investigación, y merece la pena leerla por sí misma, ya que el método utilizado por el FBI refleja el método que necesitan los defensores.
Según la declaración jurada, Stokes no se andaba con rodeos en lo que respecta al dinero. Unas imágenes de Snapchat y Facebook lo situaban en París, Nueva York, Bangkok y Dubái entre los 17 y los 18 años, alojándose en hoteles de lujo, con fajos de billetes y relojes en la mano, y luciendo una cadena de diamantes en la que se leía «HACK THE PLANET». El día de su cumpleaños envió un mensaje sobre una base de datos que acababa de obtener y que contenía datos de transferencias bancarias destinadas a plataformas de criptoactivos, y la fecha de ese mensaje coincidía con su fecha de nacimiento según los registros del Departamento de Estado. Fotografió una comisaría de policía estonia con un pie de foto en el que se comparaba con un personaje que se entrega al FBI.
Estos son los errores de seguridad operativa que proporcionan pistas a los defensores, el mismo patrón que identifiqué en los fallos de OPSEC: cómo los errores de los actores maliciosos ayudan a los defensores.
Pero lo interesante es la atribución técnica. La cuenta que configuró el ngrok utilizado en el ataque a la empresa F estaba vinculada a un «Microsoft Global Device ID», un identificador persistente de una instalación de Windows. El FBI correlacionó la actividad de la IP de ese dispositivo, a lo largo del tiempo, con las direcciones IP utilizadas para iniciar sesión en cuentas que ya habían relacionado con Stokes: Snapchat, Apple y Facebook.
Las mismas direcciones en Tallin, en Nueva York y en Tailandia, en las mismas fechas, a veces con apenas unas horas de diferencia. Utilizó un proxy VPN para la infraestructura del ataque. Pero eso no importó, porque la correlación se estableció a partir de toda su vida digital, no de una sola conexión.
El detalle que más llama la atención: el 8 de enero de 2025, ese dispositivo se conectó al juego en línea Growtopia a través de una cuenta de Ubisoft desde una dirección IP de Tallin, y el día anterior, esa misma dirección IP había accedido a una de sus cuentas de Apple y a esa cuenta de Ubisoft con dos minutos de diferencia.
Una dirección IP es solo ruido. Una VPN oculta una conexión. Lo que delata, según la lógica del investigador, es el patrón formado por numerosas señales correlacionadas entre distintos planos y a lo largo del tiempo. Esa es la misma lógica que distingue una identidad robada de una real dentro de una red.
El FBI hizo con Stokes exactamente lo que una buena estrategia de investigación hace con un intruso: dejó de buscar una única prueba irrefutable y empezó a establecer relaciones entre los distintos comportamientos.
No se trata de una amenaza lejana
Hay otra cosa que la denuncia deja clara: Scattered Spider noScattered Spider un programa estatal lejano. Stokes tiene 19 años. El cómplice mencionado junto a él en la denuncia era un menor que residía en Estados Unidos en el momento de los hechos y que fue procesado a nivel local. Otro miembro al que se hace referencia en la denuncia, Noah Urban, conocido como «Sosa» y «King Bob», fue condenado a 120 meses de prisión por una estafa de suplantación de tarjetas SIM.
Se trata de jóvenes nativos de inglés que se expresan muy bien por teléfono y se manejan con total soltura en los sistemas que están atacando. Eso es lo que hace que el vector del servicio de asistencia técnica sea tan eficaz. La persona que llama a tu servicio de asistencia técnica suena exactamente igual que el empleado al que está suplantando.
Y Stokes no es el último de ellos. En abril de 2026, Tyler «Tylerb» Buchanan se declaró culpable dephishing perpetrada por el grupo en 2022. En junio de 2026, Thalha Jubair y Owen Flowers se declararon culpables en Londres el primer día de su juicio, por el ataque de agosto de 2024 que paralizó Transport for London. Jubair, quien según la fiscalía codirigía un canal de «intercambio de tarjetas SIM por encargo» llamado Star Chat que suplantaba las credenciales de los empleados de operadores de telefonía móvil, está acusado por separado en Nueva Jersey de más de 120 intrusiones en 47 empresas estadounidenses y de al menos 115 millones de dólares en pagos de rescates. La misma marca, muchos operadores, un mismo método: burlar a un humano y luego utilizar un acceso válido.
He escrito sobre el ecosistema más amplio en el que se mueven estos actores, «The Com», y sobre por qué este perdura más allá de cualquier detención concreta, en el artículo Hunters Scattered Lapsus$ Hunters que van a desaparecer, pero la amenaza persiste».
Qué hay que comprobar
Si gestionas un programa de seguridad, la denuncia de Stokes es un ejercicio de simulación gratuito. He aquí algunas preguntas que conviene plantearse en relación con tu propio entorno:
- Si alguien, mediante técnicas de ingeniería social, lograra que tu servicio de asistencia técnica restableciera hoy la contraseña y la autenticación multifactorial (MFA) de un empleado, ¿qué sistema de alerta se activaría, teniendo en cuenta que el siguiente inicio de sesión se autentica sin problemas?
- ¿Dispones de un patrón de referencia de comportamiento por cada identidad, de modo que resulte sospechoso que un usuario estándar obtenga credenciales con privilegios y, a continuación, acceda a nuevos sistemas?
- ¿Aparecería como algo que hubiera que investigar antes de que finalizara la subida el hecho de crear por primera vez un túnel con ngrok o Teleport desde un servidor de producción, o una transferencia saliente de gran volumen a S3?
Se trata del mismo patrón posterior a la autenticación que he observado en las campañas de ShinyHunters, tal y como se explica en «ShinyHunters no es un grupo. Es un patrón»: actor diferente, punto de entrada diferente, pero la misma secuencia de acceso, persistencia, exploración y exfiltración una vez que se ha iniciado sesión con éxito. La denuncia de Stokes es un dato más que respalda esa misma tesis, esta vez declarada bajo juramento.
En Vectra AI, este es el ámbito en el que nos centramos: el comportamiento que se produce tras un inicio de sesión correcto, tanto en el ámbito de la identidad como en el del SaaS y cloud, donde las firmas y la prevención ya no pueden detectar nada.
Si quieres conocer todos los detalles de una Scattered Spider » y saber dónde aparecen las primeras señales de comportamiento, consulta el capítulo 2 de *Mind Your Attack Gaps*, dedicado a la brecha n.º 2: «la autenticación se realiza con éxito».