La llamada venía desde dentro del helpdesk

El 24 de abril, BleepingComputer informó sobre un clúster con motivación financiera al que la Unit 42 de Palo Alto rastrea como CL-CRI-1116, también conocido como BlackFile, también conocido como UNC6671, y al que CrowdStrike (por separado, pero probablemente la misma gente, o al menos primos) llama Cordial Spider. La taxonomía es un lío. La conducta no.

Aquí va la conducta, en el orden en que te ocurre:

1. Recibes una llamada. El identificador de llamadas dice que es IT interno, o algo cercano — VoIP suplantado, o un CNAM fraudulento (el nombre legible para humanos que la red telefónica muestra junto a un número y que, resulta, no está particularmente bien autenticado). La persona al teléfono es amable y un poco apenada. Lamenta mucho molestarte. Hay un pequeño problema con tu cuenta.
2. Para arreglar el pequeño problema con tu cuenta, le gustaría que inicies sesión en una página corporativa cuyo enlace te enviará por SMS, o a veces simplemente te guía hasta ella. La página luce correcta. Tiene el logo de la empresa. Tiene la redacción adecuada. No es la página correcta.
3. Tipeas tu contraseña. La página te pide tu código de un solo uso de tu app autenticadora. Lo tipeas también.
4. La página te dice gracias y posiblemente muestra un spinner. Cuelgas.
5. El atacante, en su propia laptop, en otro lugar, toma tu contraseña recién tipeada y tu código de seis dígitos recién tipeado, inicia sesión en tu portal real de SSO en los próximos noventa segundos y — y esta es la parte elegante — registra su propio dispositivo MFA en tu cuenta.
6. Ahora son tú. Tienen un segundo factor permanente que llevan en el bolsillo. Tu segundo factor también sigue funcionando, por lo que nadie se da cuenta.
7. Van a Salesforce, van a SharePoint, buscan archivos con las palabras "confidential" o "SSN" en ellos, descargan todo lo que pueden, y una semana después tu CEO recibe un correo de rescate de siete cifras desde una dirección de Gmail. A veces, según el informe de BleepingComputer, los empleados también reciben amenazas de swatting, lo que es un nivel de servicio al cliente que la mayoría de las bandas de extorsión no se molestan en ofrecer.

En fin.

Dónde, exactamente, ocurre el ataque

Vale la pena ser preciso sobre qué parte de esta cadena corre dónde, porque la cadena no está toda en el mismo lugar.

La llamada corre por el teléfono. La llamada tiene forma de teléfono. Ningún navegador, ninguna laptop, ningún sistema operativo que puedas parchear puede hacer nada respecto a la llamada en sí, porque la llamada no está en la laptop. (Puedes capacitar al personal, puedes poner carteles en la sala de descanso, puedes hacer que el helpdesk real envíe un correo de seguimiento después de cada llamada legítima, y todo eso ayuda, pero la llamada es, como dicen en el sector, un problema con forma de persona.)

La página de inicio de sesión falsa corre en un navegador. Específicamente, corre en cualquier navegador que la empleada tenga abierto en su laptop de trabajo, en cualquier perfil que estuviera usando por última vez, con cualesquiera sesiones, cookies y contraseñas guardadas para autocompletar que casualmente lleve consigo. Esta parte es un problema con forma de computadora.

El registro de MFA en la cuenta real corre en la laptop del atacante, en su navegador, contra el portal SSO legítimo. Esto no es un problema en el navegador del usuario en absoluto; es un problema con cómo el portal SSO maneja la inscripción de MFA cuando alguien conoce la contraseña y un OTP actual. Tu IdP (el proveedor de identidad que opera SSO — Okta, Entra ID, Google Workspace, el que haya decidido que tu contraseña es correcta) trata "tengo la contraseña y un OTP fresco" como prueba suficiente para añadir otro factor. Esa es una decisión de política, y es la política con la que la mayoría de las empresas arrancan por defecto, porque la alternativa es que los usuarios se queden sin acceso cuando reemplacen su teléfono.

La exfiltración en Salesforce y SharePoint también corre en la laptop del atacante, contra tu SaaS real, con su segundo factor recién acuñado. Esta parte es, en sentido estricto, no "un ataque al navegador de la empleada". Es el atacante iniciando sesión como una persona normal, porque a estas alturas es una persona normal. El navegador de tu empleada se quedó al margen de los últimos tres pasos.

Así que si estás buscando una sola palanca tecnológica que puedas mover para prevenir BlackFile de extremo a extremo, no la hay. El ataque está repartido entre un teléfono, una página falsa, una política de IdP y la laptop de un atacante.

Lo que hay — y esta es la única parte de la cadena sobre la que un fabricante de navegador puede decir algo creíble — es el segundo paso, la página de inicio de sesión falsa. La página tiene que renderizarse en algún sitio. Donde quiera que se renderice, la empleada tipea credenciales reales y un OTP real en ella. Así que la pregunta es solo: ¿en qué tipo de contenedor quieres que ocurra ese evento en particular?

La página tiene que renderizarse en alguna parte

Bien. Así que la página se renderiza en un navegador. ¿En cuál?

Si no haces nada, se renderiza en cualquiera que la empleada estuviera usando — Chrome en una laptop personal, Edge en una laptop corporativa, Safari en el iPad que tenía cerca. Sea cual sea el navegador, lleva un tiempo en uso. Tiene un perfil que lleva un tiempo en uso. Ese perfil probablemente ya tenga cookies para el portal SSO corporativo real, porque la empleada inicia sesión en el trabajo todas las mañanas. Tiene contraseñas guardadas. Tiene una sugerencia de autocompletado que es, servicialmente, la contraseña corporativa real — salvo que el autocompletado correctamente no se dispara en un dominio de phishing (los navegadores son buenos en esto), así que la usuaria la tipea manualmente, lo que también hace bien, porque la ha tipeado diez mil veces.

La página falsa no necesita ninguna de esas cookies. La página falsa solo necesita que los dedos del usuario sigan haciendo lo que los dedos hacen cuando una página pide una contraseña. La página falsa recoge la contraseña. La página falsa recoge el OTP. La página falsa ha terminado.

Pero aquí está la pregunta que me ronda. ¿Por qué el navegador personal de la empleada, con su perfil de larga vida y su colección de cada sitio en el que alguna vez ha iniciado sesión, fue el lugar donde la página falsa de inicio de sesión corporativo se renderizó en primer lugar? La página dice ser corporativa. La usuaria está en el trabajo. La usuaria está, en lo que a ella respecta, haciendo cosas del trabajo. ¿Por qué «la página de login corporativa» se renderiza en el mismo entorno de software que «el enlace compartido de Spotify de la prima» y «una cuenta de Etsy de 2018»?

Esa es, creo, la pregunta.

El argumento del navegador gestionado, hecho pequeño

Aquí va la versión pequeña, estrecha y honesta del argumento de Bromure para este ataque.

Un departamento de IT puede desplegar Bromure como el navegador corporativo autorizado. No el único navegador en la laptop — la usuaria todavía puede tener Chrome y Safari para navegación personal — pero sí el único navegador que está configurado, inscrito y marcado visiblemente como el lugar donde se supone que vive el SaaS corporativo. Bromure tiene una pestaña Enterprise en los ajustes cuya única tarea es exactamente esta: un campo de proxy HTTP y una ranura para certificados raíz internos. Dos ajustes. Es todo lo que hace, y es intencionalmente todo lo que hace. Una organización configura esas dos cosas una vez, entrega a los empleados un perfil de Bromure preconfigurado para confiar en la CA corporativa y enrutar a través del proxy corporativo, y deja que el perfil sea visiblemente el lugar donde vive el SaaS corporativo.

(No estamos afirmando que la pestaña Enterprise sea un plano completo de control de MDM. Son dos cuadros de texto. Dos cuadros de texto bien elegidos a veces son suficientes.)

Dentro de Bromure, cada pestaña es su propia VM Linux desechable con su propio perfil efímero. Así que cuando la pestaña corporativa de Salesforce se abre, se abre en una VM gestionada que conoce el proxy corporativo y confía en la CA corporativa. Cuando la empleada abre, por separado, el enlace compartido de Spotify de su prima, eso se abre en una VM diferente con un perfil diferente que no tiene nada de eso.

Ahora bien, la llamada telefónica todavía ocurre exactamente de la misma manera. La usuaria todavía es guiada hasta un enlace. Esto es lo que cambia:

• El enlace, cuando se hace clic, se abre en alguna VM de Bromure. No, por defecto, en la misma VM que la sesión real de Salesforce de la empleada. (Los perfiles en Bromure no se fusionan en silencio. La página que se carga en un perfil de «enlace desechable» no puede leer cookies del perfil de «Salesforce corporativo», porque viven en VMs distintas con stacks de red distintos y discos distintos.)
• La usuaria, posiblemente, tipea de todas formas credenciales corporativas reales y un OTP real en la página. Bromure no detiene el tipeo. Esa es la parte honesta.
• El token de sesión (o, dependiendo del kit, a veces solo las cookies) que la página captura vive dentro de un perfil que la usuaria está a punto de cerrar, en una VM que está a punto de borrarse, sin ninguna relación privilegiada con nada corporativo. El token capturado es, en este sentido, de baja calidad — es un recuerdo de una pestaña.

Con este último punto quiero ser cuidadoso, porque es exactamente el tipo de cosa donde es fácil exagerar.

En la cadena de BlackFile tal como está documentada, el token capturado no se utiliza en realidad para iniciar sesión en el Salesforce real — el atacante usa las credenciales y el OTP para iniciar sesión en el portal SSO real desde su propia laptop, y registra su propio dispositivo MFA. Las cookies capturadas nunca iban a ser reproducidas contra la sesión corporativa real de todos modos, porque son cookies para un dominio de phishing, no para el dominio real. Donde el aislamiento por VM de Bromure importa es en el tramo detrás de la página falsa: cualquier travesura del lado de la pestaña (exfiltración de tokens a un endpoint del atacante, scripts de seguimiento que intentan leer otras cookies, cadenas de redirección que dejan caer payloads adicionales) está contenida dentro de una VM cuyo sistema de archivos, red y árbol de procesos están sellados respecto al resto de la laptop y a la sesión real del navegador corporativo. La página falsa es una página falsa. Solo tiene que ser una página falsa dentro de una caja.

La pista visible, en particular, está haciendo mucho trabajo en este diagrama, y vale la pena decirlo en voz alta. Un despliegue de navegador gestionado cuya única función es «la pestaña corporativa de Salesforce / SharePoint / Workday se ve visiblemente diferente de la pestaña de un enlace cualquiera» es, por sí sola, una defensa nada trivial, porque la víctima canónica de BlackFile es una persona cansada que recibió una llamada a las 4:45 PM de un jueves. La distinción visible no es un floreo de UI; es el partido entero.

Lo que esto no arregla

Quiero seguir siendo honesto al respecto, porque el modo de fallo aquí es un proveedor que explica cómo su producto habría prevenido un ataque y que, cuando lo lees con atención, describe un ataque diferente.

No detiene la llamada. La llamada está en el teléfono. Bromure no corre en el teléfono, no ve el teléfono, no tiene opinión sobre el teléfono. Si la usuaria atiende y queda convencida por una voz amable de que hay un pequeño problema con su cuenta, la usuaria va a mirar una página falsa de inicio de sesión. Podemos cambiar en qué navegador se renderiza la página. No podemos cambiar si la usuaria la mira.

No detiene el tipeo. Si la usuaria tipea credenciales reales y un OTP real en la página falsa, esas credenciales y ese OTP están ahora en posesión del atacante, sin importar dónde se haya renderizado la página. El hecho de que la página esté en una VM desechable no deshace lo que la usuaria acaba de tipear.

No detiene la inscripción de MFA. El tramo de inscripción de MFA ocurre en la laptop del atacante, contra el IdP legítimo. Bromure no corre en la laptop del atacante, y Bromure no es el IdP. La mitigación aquí está en el lado del IdP, y es la aburrida: activa «requerir autenticación elevada para nueva inscripción de MFA», restringe las inscripciones a la red corporativa o a un dispositivo gestionado, alerta sobre el registro de nuevos factores, y acepta que la alternativa es que los usuarios se queden sin acceso cuando cambien de teléfono. Esta es una decisión de configuración que cualquier admin de Okta y Entra ID puede tomar hoy, y muchos no lo han hecho, y eso es — para decirlo con suavidad — la parte de esta historia que debería quitarles el sueño a los CISOs más que la parte del navegador.

No detiene, en sentido estricto, un ataque de proxy AiTM en tiempo real. Una clase distinta de kit de phishing (Evilginx, Modlishka, Caffeine, los alquileres de AiTM-as-a-service a 2.500 USD por unidad que se han vuelto el patrón dominante de ataque a Microsoft 365) hace relay en tiempo real: la usuaria tipea en una página que actúa de proxy, en tiempo real, hacia el IdP legítimo. La cookie de sesión que el IdP emite va al proxy; el proxy se la pasa al atacante. Si te imaginas una llamada estilo BlackFile dirigiendo a la usuaria a ese tipo de página — que no es lo que se describe que BlackFile hace actualmente, pero es hacia donde va la categoría — entonces la cookie capturada es una cookie de sesión real para el IdP legítimo, y la pregunta pasa a ser si puede reproducirse desde otro lugar. Eso es otro post, y uno más difícil, y la respuesta honesta involucra controles de vinculación de sesión (DBSC, tokens vinculados con mTLS) que son sobre todo trabajo del IdP y solo en parte del navegador. No vamos a agitar una varita mágica sobre eso.

Lo que Bromure gestionado hace, de forma estrecha: hace que la página falsa se renderice en un lugar no gestionado, efímero y visiblemente distinto del entorno corporativo gestionado. Restringe el radio de explosión de cualquier truco posterior a la página que el kit pueda intentar (instalación de extensiones, escrituras al sistema de archivos del host, persistencia) a una VM que va a desaparecer. Y, en la cadena de BlackFile tal como se describe, no impide por sí mismo que el atacante luego registre su propio dispositivo MFA — eso es trabajo del IdP. Estamos mitigando una de las cuatro máquinas en la cadena, que es la única en la que corremos.

Por qué este es, eventualmente, el único camino

En fin. Mira. Da un paso atrás.

La cuestión sobre BlackFile es que es un negocio notablemente eficiente. Eligieron retail y hostelería porque el retail y la hostelería tienen muchísimos empleados, turnos distribuidos, horarios fuera de oficina, equipos de helpdesk de IT reales que llaman legítimamente a empleados, y una nómina de personas muy estresadas que realmente no quieren ser la razón por la que las cajas registradoras están caídas. Eligieron vishing porque el vishing escala (una persona al teléfono puede llamar a una docena de objetivos en una hora, y la tasa de éxito es, según los estándares de esta industria, increíble) y porque la llamada es la parte de la cadena que no puedes parchear. Cosechan credenciales y OTPs porque las credenciales y los OTPs son la parte de la cadena que, en 2026, sigue siendo la puerta principal de la mayoría de las empresas, a pesar de una década de presentaciones explicando que no debería serlo.

La parte de la cadena en la que un navegador puede influir es pequeña. Es una de cuatro máquinas. No deberías comprar un navegador porque afirme derrotar a BlackFile de extremo a extremo. Deberías comprar un navegador porque hace bien la única cosa que puede hacer bien — mantener la sesión corporativa en un lugar gestionado e identificable, y mantener la sesión de enlace cualquiera en un lugar que deja de existir cuando la cierras — y luego deberías combinarlo con los controles aburridos y poco glamurosos del lado del IdP que cierran el lazo de verdad.

El teléfono va a seguir sonando. La página va a seguir cargando. La pregunta es solo dónde, exactamente, carga, y qué hay alrededor cuando lo hace. Resulta que eso sí se puede cambiar.

Fuentes:

• BleepingComputer — New BlackFile extortion gang targets retail and hospitality orgs (2026-04-24)
• CrowdStrike — Cordial Spider adversary profile
• Help Net Security — Attackers use AiTM phishing kit, typosquatted domains to hijack AWS accounts (2026-03-10) (referenciado por el contexto más amplio del mercado de AiTM-as-a-service, no específicamente para BlackFile)