Voltar para todas as publicações
Publicado em · por Renaud Deraison

Uma trapaça no Roblox, uma autorização OAuth e um vazamento de US$ 2M na Vercel

A violação da Vercel divulgada nesta semana começou com um funcionário da Context.ai baixando exploits do Roblox em um PC pessoal e terminou com um atacante lendo as variáveis de ambiente de clientes da Vercel. O Bromure Enterprise, lançado nesta semana, foi feito exatamente para essa cadeia.

Um funcionário procura trapaças de Roblox em seu notebook pessoal. Dois meses depois, um atacante está vendendo a base de dados de clientes da Vercel por US$ 2 milhões no BreachForums. Entre esses dois eventos há uma cadeia de decisões comuns — uma máquina pessoal, um clique em «Permitir tudo» em um OAuth, uma ferramenta de IA de terceiros com uma conta support@ — para a qual toda equipe de TI corporativa deveria estar olhando nesta semana. O Bromure Enterprise, que lançamos ontem, foi feito para o meio dessa cadeia.

Em 20 de abril, a Vercel divulgou que um atacante «altamente sofisticado» havia invadido seus sistemas internos por meio de uma ferramenta de IA de terceiros comprometida, chamada Context.ai, e acessado variáveis de ambiente não sensíveis pertencentes a um subconjunto de projetos de clientes. O CEO Guillermo Rauch descreveu os atacantes como «significativamente acelerados por IA» e pediu aos clientes que rotacionassem qualquer credencial marcada como não sensível. Um grupo que se autodenomina ShinyHunters agora tenta vender os dados roubados por US$ 2M no BreachForums.

O valor do resgate é a manchete. A cadeia de ataque é a lição. A Hudson Rock rastreou a infecção até fev. 2026, quando um funcionário da Context.ai pesquisou scripts de «auto-farm» do Roblox e executores de exploits de jogo, baixou um e pegou o Lumma Stealer — um infostealer de commodity que coleta cookies do navegador, credenciais salvas e tokens OAuth. Depois, a CyberScoop e a SpecterOps reconstruíram o resto. O que o Lumma extraiu não foi apenas uma senha da Context.ai; foi o conjunto completo de credenciais corporativas guardadas em cache no navegador — sessões do Google Workspace, chaves do Supabase, logins do Datadog, tokens do Authkit.

A partir daí, o atacante pivotou para o ambiente AWS da Context.ai, leu os tokens OAuth que a Context.ai mantinha em nome de seus clientes e encontrou um funcionário da Vercel que havia, em algum momento, se cadastrado no «AI Office Suite» da Context.ai usando sua conta Google corporativa — e clicado na caixa de escopo «Permitir tudo». Esse único consentimento, dado meses antes, foi a única primitiva de que o atacante precisou. Eles cunharam uma sessão como aquele funcionário, entraram no Google Workspace da Vercel e, a partir dali, na API interna de produto da Vercel, onde enumeraram e decifraram cada variável de ambiente que um cliente não havia marcado explicitamente como sensível.

ETAPA 1 — FEV. 2026Notebook pessoaldownload de trapaça RobloxLumma Stealer caicreds corp. exfiltradasETAPA 2 — MAR. 2026AWS da Context.aiescalada via support@leitura de OAuth de clientestokens extraídosETAPA 3Workspace da Vercel"Permitir tudo" concedidodesde meses antessessão cunhadaETAPA 4API de produto Vercelenumerar projetosdecifrar env varsdados de clientes lidosETAPA 5 — 20 DE ABR.BreachForumsShinyHuntersbase à vendaUS$ 2.000.000ONDE O BROMURE ENTERPRISE TERIA QUEBRADO A CADEIANA ETAPA 1VM gerenciada emhospedeiro não gerenciadoA navegação corporativa ficaem uma VM que o stealer dohospedeiro não consegue ler.NA ETAPA 3Lista de blocos SaaSautorizadosContext.ai nunca esteve nalista de sancionados. Sem bloco,sem cadastro em um clique.NA ETAPA 3Perfil de trabalhoprotegido por SSOSuperfície de consentimentovisível a admins. App OAuthnão sancionado, sem concessão.NA ETAPA 4 (E DEPOIS)Log de auditoria por requisiçãoToda chamada HTTP de todasessão de trabalho, usuário + URL +verbo. "O que a Context.airealmente leu?" — respondível.
A cadeia Vercel / Context.ai, do início ao fim. A infecção em um notebook pessoal na Context.ai coleta o estado do navegador corporativo. O atacante pivota para o AWS da Context.ai, lê os tokens OAuth dos clientes e cavalga um consentimento «Permitir tudo» pré-concedido direto para o Google Workspace da Vercel. De lá: a API de produto da Vercel e as variáveis de ambiente dos clientes.

Quatro coisas sobre essa cadeia merecem destaque, porque cada uma mapeia um controle específico que entregamos no Bromure Enterprise nesta semana. Não vamos afirmar que o lançamento teria impedido a violação por completo — não teria. O que ele teria feito é quebrar a cadeia em quatro pontos distintos, e qualquer um deles já basta.

O notebook pessoal foi estrutural

O detalhe mais subnoticiado nas análises públicas é que a máquina infectada era um dispositivo pessoal. O funcionário da Context.ai estava procurando exploits de Roblox — não é uma tarefa corporativa típica — e a infecção chegou a uma máquina que provavelmente estava sendo usada tanto para trabalho quanto para navegação pessoal. O Lumma Stealer não se importa a qual perfil um cookie pertence; ele lê cada arquivo de credencial do Chrome e do Edge que encontra e envia o lote todo.

Esse é o padrão central da era BYOD. O hospedeiro não é gerenciado. Os cookies de trabalho estão no mesmo pote de cookies que a trapaça de Roblox que o usuário acabou de baixar. Um agente EDR pode ou não estar instalado; em uma máquina pessoal, é muito improvável que esteja. E mesmo quando está, o Lumma é rotineiramente observado driblando antivírus de prateleira.

A resposta do Bromure Enterprise é uma VM gerenciada em um hospedeiro não gerenciado. A TI emite um perfil de trabalho Bromure. O funcionário instala o Bromure em seu notebook pessoal, entra com o IdP corporativo (Google Workspace, Okta, Entra, Authentik) e o perfil de trabalho inicia como sua própria máquina virtual Linux. Essa VM tem seu próprio kernel, seu próprio sistema de arquivos, seu próprio diretório de perfil do Chromium. Cookies corporativos, senhas corporativas salvas e tokens de atualização OAuth corporativos vivem dentro dessa VM. Um stealer rodando no macOS ou Windows hospedeiro — coletado via um download de Roblox ou qualquer outra coisa — não consegue enumerar, ler ou exfiltrar esses dados. Não há um perfil compartilhado do Chrome em disco para ele roubar. O pote de cookies está dentro de uma imagem de VM que o SO hospedeiro trata como um arquivo de disco opaco.

Essa não é uma separação teórica. É o ponto central da arquitetura. O hospedeiro pode ser comprometido o dia inteiro; o navegador de trabalho está em outro computador.

O clique em «Permitir tudo» foi o verdadeiro troféu

Olhe de perto o caminho do atacante. O stealer coletou credenciais do Google Workspace, Supabase, Datadog, Authkit. Elas foram úteis para pivotar dentro da Context.ai. Mas o que chegou até a Vercel não foi uma senha roubada — foi um token OAuth. Especificamente, o token cunhado quando um funcionário da Vercel se cadastrou no AI Office Suite da Context.ai, passou pela tela de consentimento do Google e aprovou o pacote de escopos «Permitir tudo». Esse consentimento estava no passado, com meses de idade. Nunca foi reavaliado. Ficou lá, válido, esperando.

Essa é a lacuna de visibilidade OAuth que a SpecterOps apontou: arestas de confiança criadas por funcionários individuais clicando em telas de consentimento operam inteiramente fora do fluxo de provisionamento da TI. O caminho estava aberto antes que alguém soubesse que devia procurá-lo.

O Bromure Enterprise estreita essa superfície em duas direções ao mesmo tempo.

A lista de blocos de SaaS autorizados é o ponto de estrangulamento na entrada. Os admins publicam o conjunto de apps de trabalho sancionados na página inicial de Trabalho de cada usuário inscrito. Esses blocos são o que os funcionários clicam para começar a usar uma nova ferramenta. A Context.ai não estava nessa lista na Vercel — não poderia estar; era um experimento de um funcionário individual. Sem um bloco, não há fluxo de cadastro em um clique dentro do perfil de trabalho gerenciado. O funcionário pode, claro, ainda navegar manualmente até a Context.ai; é aí que o segundo controle entra em cena.

O perfil de trabalho é protegido por SSO e sua superfície de consentimento é visível. Consentimentos OAuth iniciados a partir de um perfil de trabalho Bromure gerenciado passam pelo IdP corporativo, sob política do admin. Um admin que queira restringir quais apps de terceiros podem receber escopos do Google Workspace — o que todo admin do Google Workspace deveria estar fazendo, e quase nenhum faz na prática — tem seu ponto de aplicação dentro do motor de políticas do Bromure, e não espalhado por tudo o que cada funcionário resolveu clicar semanas atrás. A caixa «Permitir tudo» deixa de ser uma surpresa que aparece dezoito meses depois durante uma resposta a incidentes.

Nada disso revoga retroativamente uma concessão OAuth emitida antes de o funcionário migrar para o Bromure. Mas, daí para frente, a categoria «um funcionário concedeu escopos amplos do Google a um SaaS aleatório do qual nunca ouvi falar» fica visível e passível de controle.

Depois, o log de auditoria é a única forma de dimensionar o estrago

O boletim público da Vercel é honesto sobre o que a investigação encontrou: o atacante enumerou e decifrou variáveis de ambiente de um subconjunto de projetos de clientes. O escopo ainda está sendo refinado. A razão pela qual ainda está sendo refinado é que reconstruir «o que a conta do funcionário de fato leu entre fins de março e meados de abril?» a partir dos logs de auditoria do Google Workspace, mais os logs internos de produto da Vercel, é um projeto de reconstrução forense, não uma consulta.

Essa é a lacuna que o log de auditoria por requisição do Bromure Enterprise foi projetado para fechar. Toda requisição HTTP feita a partir de toda sessão de trabalho, em cada dispositivo inscrito, é registrada centralmente: usuário, URL, verbo, carimbo de tempo. «Quem enviou credenciais para evil.com entre 8h e 8h15 de ontem» é o exemplo que usamos no lançamento. Um exemplo melhor nesta semana: «Para cada endpoint de variável de ambiente em nossa API de produto da Vercel, quem o acessou, de onde e quando, nos últimos noventa dias». Uma consulta, não um projeto.

Essa é a peça do EDR-encontra-log-de-auditoria-web. O EDR responde à mesma pergunta para processos nativos: no que esse processo tocou? O Bromure responde para a navegação: no que o navegador desse usuário tocou? Em um incidente como o da Vercel, no qual a pegada do atacante está inteiramente dentro de uma sessão de navegador comprometida, a resposta do EDR é vazia e a resposta do Bromure é a linha do tempo do incidente.

Os controles de exfiltração são limitados aqui — e isso é honesto

Queremos ser cuidadosos sobre onde o Bromure Enterprise ajuda e onde não. Os controles de copiar-e-colar, download de arquivo, captura de tela e rede local são reais e são ganhos reais para exfiltração de dados em geral — uma aba comprometida num perfil gerenciado não pode arrastar env vars de clientes para scp no hospedeiro, nem capturar a tela, nem fazer upload para um par na LAN. Para a cadeia específica da Vercel, porém, a etapa de exfiltração aconteceu inteiramente pela rede, do próprio backend da Vercel para um endpoint controlado pelo atacante. O atacante estava fazendo chamadas API autenticadas, não arrastando arquivos para fora de uma janela de navegador. Os controles de colar/download/LAN não teriam pegado isso.

O que teria ajudado, e está listado no log de auditoria por requisição acima, é o registro das próprias chamadas API. Os controles de exfiltração são a segunda linha; a primeira linha é garantir que o ataque nunca chegue a cunhar uma sessão em um navegador gerenciado.

O que o Bromure Enterprise não faz

Três limites honestos, porque a história merece.

Não impede malware em um hospedeiro pessoal não gerenciado. Uma trapaça de Roblox baixada fora da VM Bromure continua sendo uma trapaça de Roblox instalando um infostealer no SO pessoal do usuário. O Bromure não limpa isso. O que ele faz é garantir que o rendimento do malware, para o atacante, seja apenas os cookies pessoais do usuário — não os corporativos.

Não revoga retroativamente escopos OAuth. Consentimentos emitidos meses antes de a empresa adotar o Bromure Enterprise estão na lista de concessões do Google Workspace, não na nossa. O passo operacional certo após implantar o Bromure continua sendo uma auditoria das concessões existentes para apps de terceiros — nós ajudamos a prevenir a próxima, mas não reescrevemos a última.

Não substitui a disciplina de escopar. O funcionário da Vercel clicou em «Permitir tudo». Se um futuro funcionário clicar em «Permitir tudo» em um bloco sancionado, a concessão continuará ampla. O Bromure torna a superfície visível e o caminho de inscrição mais estreito; não substitui a decisão de um admin sobre quais escopos do Google são ou não permitidos para uma dada categoria de app.

O argumento centrado no navegador não é «nenhum ataque pode acontecer». É que o ponto de controle de maior alavancagem, para toda a categoria de ataques que passa por uma sessão de navegador do usuário, é o próprio navegador — e o navegador acontece de ser a única peça de software corporativo que nunca teve uma história de gerenciamento adequada em dispositivos não gerenciados.

Hospedeiro pessoal não gerenciadosem EDR corporativo, sem MDMMALWARE NO HOSPEDEIROLumma Stealerlê Chrome/Edge do hospedeiroNAVEGADOR PESSOALChrome / Edgeroblox, e-mail pessoalVM DE TRABALHO BROMURE · ISOLADA POR HIPERVISORPERFIL DE TRABALHO INSCRITO VIA SSOGoogle corp., painel Vercel, blocos sancionadosPOTE DE COOKIES PRÓPRIOsessões corp.dentro do disco da VMCAPTAÇÃO DE AUDITORIAtoda requisição registradano log de frotabloqueado pelohipervisorSaaS & o atacanteSANCIONADOGoogle Workspaceconsentimentos visíveisSANCIONADOPainel da Vercelauditado por requisiçãoTERCEIRO NÃO SANCIONADOContext.ai / SaaS de IA aleatóriosem bloco, sem caminho "Permitir tudo" do perfil de trabalhoATACANTEsó possui cookies do hospedeirosem sessão Workspace corp.sem pivot para a Vercel
Como a cadeia da Vercel se parece com o Bromure Enterprise no meio. O notebook hospedeiro continua não confiável. A VM de trabalho fica sobre ele, isolada pelo hipervisor. O estado do navegador corporativo nunca sai da VM. O consentimento OAuth para apps de terceiros não sancionados ou nunca começa (sem bloco, sem caminho via SSO) ou é visível aos admins. Toda requisição que a sessão faz é registrada centralmente, de modo que dimensionar um incidente vira uma consulta.

O formato da correção

Violações de cadeia de suprimentos via concessões OAuth em SaaS são o equivalente moderno dos ataques de credential stuffing em VPN de dez anos atrás. Ambos são consequências de uma aresta de confiança que era barata de criar, difícil de inventariar e impossível de revogar a tempo quando a contraparte era comprometida. O boletim da Vercel é cuidadoso e honesto; a cadeia que ele descreve não é culpa da Vercel. É o que acontece quando o mesmo navegador, no mesmo notebook pessoal, guarda a sessão corporativa do funcionário, o histórico de downloads de Roblox e os consentimentos «Permitir tudo» acumulados para cada ferramenta de IA com a qual ele experimentou no último trimestre.

A resposta estrutural é dar à sessão de trabalho seu próprio computador. Não um segundo notebook — uma segunda máquina, materializada no mesmo notebook, com seu próprio kernel, seu próprio sistema de arquivos, seu próprio pote de cookies, seu próprio motor de políticas, sua própria captação de auditoria para o log central. É isso que é o Bromure Enterprise. Se você cuida da TI em uma empresa cujos funcionários rotineiramente concedem escopos OAuth a apps SaaS de terceiros — o que equivale a dizer qualquer empresa — o boletim da Vercel desta semana é o motivo para colocá-lo na lista curta.


Fontes primárias