Un cheat de Roblox, un «Allow all» de OAuth y una fuga de $2M en Vercel
La brecha de Vercel revelada esta semana empezó con un empleado de Context.ai descargando exploits de Roblox en un PC personal, y terminó con un atacante leyendo las variables de entorno de los clientes de Vercel. Bromure Enterprise, lanzado esta semana, está pensado exactamente para esta cadena.
Un empleado busca cheats de Roblox en su portátil personal. Dos meses después, un atacante vende la base de datos de clientes de Vercel por 2 millones de dólares en BreachForums. Entre esos dos eventos hay una cadena de decisiones ordinarias — una máquina personal, un clic en «Allow all» de OAuth, una herramienta de IA de terceros con una cuenta support@ — que todo equipo de TI empresarial debería estar mirando esta semana. Bromure Enterprise, que lanzamos ayer, fue construido precisamente para el medio de esa cadena.
El 20 de abril, Vercel comunicó que un atacante «altamente sofisticado» había vulnerado sus sistemas internos a través de una herramienta de IA de terceros comprometida llamada Context.ai, y había accedido a variables de entorno no sensibles de un subconjunto de proyectos de clientes. El director ejecutivo, Guillermo Rauch, describió a los atacantes como «significativamente acelerados por IA» y pidió a los clientes que rotaran cualquier credencial marcada como no sensible. Un grupo que se hace llamar ShinyHunters intenta ahora vender los datos robados por $2M en BreachForums.
La cifra del rescate es el titular. La cadena de ataque es la lección. Hudson Rock rastreó la infección hasta febrero de 2026, cuando un empleado de Context.ai buscó scripts de «auto-farm» y ejecutores de exploits de juegos para Roblox, descargó uno y se llevó de regalo Lumma Stealer — un infostealer comercial que recolecta cookies del navegador, credenciales guardadas y tokens OAuth. CyberScoop y SpecterOps reconstruyeron después el resto. Lo que Lumma extrajo no fue solo una contraseña de Context.ai; fue el conjunto completo de credenciales corporativas cacheadas en el navegador — sesiones de Google Workspace, claves de Supabase, inicios de sesión de Datadog, tokens de Authkit.
A partir de ahí, el atacante pivotó hacia el entorno de AWS de Context.ai, leyó los tokens OAuth que Context.ai mantenía en nombre de sus clientes, y encontró a un empleado de Vercel que en algún momento se había registrado en la «AI Office Suite» de Context.ai con su cuenta corporativa de Google — y había marcado la casilla de scope «Allow all». Ese único consentimiento, dado meses atrás, fue la única primitiva que el atacante necesitó. Acuñaron una sesión como ese empleado, entraron en el Google Workspace de Vercel y, desde allí, en la API interna de producto de Vercel, donde enumeraron y descifraron cada variable de entorno que un cliente no había marcado explícitamente como sensible.
Hay cuatro cosas de esa cadena que merecen destacarse, porque cada una se corresponde con un control concreto que lanzamos en Bromure Enterprise esta semana. No vamos a pretender que la versión habría detenido la brecha por completo — no lo habría hecho. Lo que sí habría hecho es romper la cadena en cuatro puntos distintos, cualquiera de los cuales basta.
El portátil personal era el eslabón crítico
El detalle más ignorado en los análisis públicos es que la máquina infectada era un dispositivo personal. El empleado de Context.ai estaba buscando exploits de Roblox — no una tarea corporativa típica — y la infección cayó en una máquina que probablemente hacía tanto navegación laboral como personal. A Lumma Stealer no le importa a qué perfil pertenece una cookie; lee cada fichero de credenciales de Chrome y Edge que encuentra, y lo envía todo.
Este es el patrón central de la era BYOD. El host no está gestionado. Las cookies de trabajo están en el mismo tarro que el cheat de Roblox que el usuario acaba de descargar. Puede que haya un agente EDR instalado, o puede que no; en una máquina personal, es muy poco probable. E incluso cuando lo hay, se ha observado rutinariamente que Lumma esquiva los AV comerciales.
La respuesta de Bromure Enterprise es una VM gestionada sobre un host no gestionado. TI entrega un perfil de trabajo Bromure. El empleado instala Bromure en su portátil personal, inicia sesión con el IdP corporativo (Google Workspace, Okta, Entra, Authentik), y el perfil de trabajo arranca como su propia máquina virtual Linux. Esa VM tiene su propio kernel, su propio sistema de ficheros, su propio directorio de perfil de Chromium. Las cookies corporativas, las contraseñas corporativas guardadas y los tokens de refresco OAuth corporativos viven dentro de esa VM. Un stealer que corra en el macOS o Windows anfitrión — entregado a través de una descarga de Roblox o cualquier otra cosa — no puede enumerarlos, leerlos ni exfiltrarlos. No hay un perfil Chrome compartido en disco que robar. El tarro de cookies está dentro de una imagen de VM que el SO anfitrión trata como un fichero de disco opaco.
Esa separación no es teórica. Es el objetivo mismo de la arquitectura. El host puede caer todo el día; el navegador de trabajo está en un ordenador distinto.
El clic en «Allow all» era el verdadero trofeo
Mira de cerca el camino del atacante. El stealer cosechó credenciales de Google Workspace, Supabase, Datadog, Authkit. Fueron útiles para pivotar dentro de Context.ai. Pero lo que llegó hasta Vercel no fue una contraseña robada — fue un token OAuth. Específicamente, el token acuñado cuando un empleado de Vercel se registró en la AI Office Suite de Context.ai, pasó por la pantalla de consentimiento de Google y aprobó el paquete de scopes «Allow all». Ese consentimiento fue hace meses. Nunca se volvió a evaluar. Se quedó ahí, válido, esperando.
Esta es la brecha de visibilidad OAuth que señaló SpecterOps: aristas de confianza creadas por empleados individuales que pulsan pantallas de consentimiento operan por completo fuera del flujo de aprovisionamiento de TI. El camino estaba abierto antes de que nadie supiera que debía buscarlo.
Bromure Enterprise estrecha esa superficie en dos direcciones a la vez.
La lista de SaaS autorizados es el cuello de botella a la entrada. Los admins publican el conjunto de apps de trabajo aprobadas en la página de inicio del perfil de trabajo de cada usuario inscrito. Esos mosaicos son lo que los empleados pulsan para adoptar una nueva herramienta. Context.ai no estaba en esa lista en Vercel — no podía haberlo estado; era un experimento individual del empleado. Sin mosaico, no hay flujo de alta en un clic dentro del perfil de trabajo gestionado. El empleado, por supuesto, puede navegar a Context.ai manualmente; ahí es donde entra en juego el segundo control.
El perfil de trabajo va protegido por SSO y su superficie de consentimientos es visible. Los consentimientos OAuth iniciados desde un perfil de trabajo Bromure gestionado suceden a través del IdP corporativo, bajo política del admin. Un admin que quiera filtrar qué aplicaciones de terceros pueden recibir scopes de Google Workspace — cosa que todo admin de Google Workspace debería estar haciendo, y casi ninguno hace en realidad — tiene su punto de aplicación dentro del motor de políticas de Bromure, no disperso por lo que cada empleado pulsó hace semanas. La casilla «Allow all» deja de ser una sorpresa que aflora dieciocho meses después durante una respuesta a incidentes.
Nada de esto revoca retroactivamente un consentimiento OAuth otorgado antes de que el empleado migrara a Bromure. Pero de aquí en adelante, la categoría de «un empleado dio scopes amplios de Google a una app SaaS cualquiera de la que nunca he oído hablar» es visible, y filtrable.
Después, el registro de auditoría es el único modo de acotar el daño
El boletín público de Vercel es honesto sobre lo que descubrió su investigación: el atacante enumeró y descifró variables de entorno de un subconjunto de proyectos de clientes. El alcance sigue afinándose. La razón por la que sigue afinándose es que reconstruir «¿qué leyó realmente la cuenta del empleado entre finales de marzo y mediados de abril?» a partir de los registros de auditoría de Google Workspace y los logs internos de producto de Vercel es un proyecto forense de reconstrucción, no una consulta.
Esta es la brecha que el registro de auditoría por petición de Bromure Enterprise está diseñado para cerrar. Cada petición HTTP realizada desde cada sesión de trabajo, en cada dispositivo inscrito, se registra de forma centralizada: usuario, URL, verbo, marca temporal. «¿Quién envió credenciales a evil.com entre las 8:00 y las 8:15 de ayer?» es el ejemplo que usamos en el lanzamiento. Un mejor ejemplo esta semana: «Para cada endpoint de variables de entorno de nuestra API de producto de Vercel, quién lo alcanzó, desde dónde y cuándo, en los últimos noventa días». Una consulta, no un proyecto.
Esta es la pieza EDR-meets-registro-web-de-auditoría. El EDR responde la misma pregunta para procesos nativos: ¿qué tocó este proceso? Bromure lo responde para la navegación: ¿qué tocó el navegador de este usuario? En un incidente como el de Vercel, donde la huella del atacante queda enteramente dentro de una sesión de navegador comprometida, la respuesta del EDR está vacía y la respuesta de Bromure es la línea temporal del incidente.
Los controles de exfiltración aquí son estrechos — y eso es honesto
Queremos ser cuidadosos con dónde ayuda Bromure Enterprise y dónde
no. Los controles de copiar y pegar, descarga de archivos, capturas
de pantalla y red local son reales, y son victorias reales para la
exfiltración de datos en general — una pestaña comprometida en un
perfil gestionado no puede arrastrar env vars de clientes a scp
en el host, ni capturarlas por pantalla, ni subirlas a un peer de
la LAN. Para la cadena específica de Vercel, sin embargo, el paso
de exfiltración sucedió íntegramente por la red desde el propio
backend de Vercel hasta un endpoint controlado por el atacante. El
atacante hacía llamadas API autenticadas, no arrastraba ficheros
fuera de una ventana del navegador. Los controles de pegado,
descarga o LAN no habrían atrapado eso.
Lo que sí habría ayudado, y figura en el registro de auditoría por petición anterior, es el registro de las propias llamadas API. Los controles de exfiltración son la segunda línea; la primera línea es asegurarse de que el ataque nunca llegue a acuñar una sesión en un navegador gestionado.
Lo que Bromure Enterprise no hace
Tres límites honestos, porque la historia los merece.
No detiene el malware en un host personal no gestionado. Un cheat de Roblox descargado fuera de la VM de Bromure sigue siendo un cheat de Roblox instalando malware infostealer en el SO personal del usuario. Bromure no limpia eso. Lo que hace es asegurarse de que el botín del malware, para el atacante, sean solo las cookies personales del usuario — no las corporativas.
No deshace retroactivamente concesiones de scopes OAuth. Los consentimientos otorgados meses antes de que la empresa desplegara Bromure Enterprise están en la lista de concesiones de Google Workspace, no en la nuestra. El movimiento operativo correcto tras desplegar Bromure sigue siendo una auditoría de las concesiones existentes a apps de terceros — nosotros te ayudamos a evitar la siguiente, no reescribimos la última.
No sustituye a la disciplina de limitar scopes. El empleado de Vercel pulsó «Allow all». Si un futuro empleado pulsa «Allow all» en un mosaico autorizado, la concesión sigue siendo amplia. Bromure hace la superficie visible y el camino de alta más estrecho; no sustituye a un admin decidiendo qué scopes de Google están permitidos y cuáles no para una categoría dada de app.
El argumento del «navegador primero» no es «no pueden ocurrir ataques». Es que el punto de control de mayor palanca, para la categoría entera de ataques que transitan por la sesión de navegador de un usuario, es el propio navegador — y resulta que el navegador es la única pieza de software empresarial que nunca ha tenido una historia de gestión decente sobre dispositivos no gestionados.
La forma del arreglo
Las brechas de cadena de suministro a través de concesiones OAuth a SaaS son el equivalente moderno de los ataques de credential stuffing contra VPNs de hace diez años. Ambos son consecuencias de una arista de confianza que era barata de crear, difícil de inventariar e imposible de revocar con rapidez cuando la contraparte caía. El boletín de Vercel es cuidadoso y honesto; la cadena que describe no es culpa de Vercel. Es lo que pasa cuando el mismo navegador en el mismo portátil personal alberga la sesión corporativa del empleado, su historial de descargas de Roblox y sus consentimientos acumulados de «Allow all» para cada herramienta de IA con la que experimentó el trimestre pasado.
La respuesta estructural es darle a la sesión de trabajo su propio ordenador. No un segundo portátil — una segunda máquina, materializada sobre el mismo portátil, con su propio kernel, su propio sistema de ficheros, su propio tarro de cookies, su propio motor de políticas, su propio tap de auditoría hacia el registro central. Eso es Bromure Enterprise. Si diriges TI en una empresa cuyos empleados rutinariamente otorgan scopes OAuth a apps SaaS de terceros — es decir, en cualquier empresa — el boletín de Vercel de esta semana es la razón para ponerlo en la lista corta.
Fuentes primarias