Kadima Cloud · Blog
Três vazamentos em um mês: o que GTA, Vercel e 251 milhões de CPFs têm em comum
Abril de 2026 vai entrar para a história da segurança digital.
Em menos de três semanas, três incidentes de grande repercussão vieram a público: a Rockstar Games teve 78 milhões de registros do GTA Online vazados, a Vercel confirmou acesso não autorizado a sistemas internos e credenciais de clientes, e um banco de dados com 251 milhões de CPFs brasileiros supostamente extraídos do Gov.br apareceu à venda em fóruns criminosos.
Empresas diferentes. Países diferentes. Portes diferentes. Mas um padrão idêntico: nenhuma delas foi atacada diretamente. O atacante entrou pela porta dos fundos, pela cadeia de fornecedores.
O que aconteceu em cada caso
Rockstar / GTA Online
Em 11 de abril, o grupo ShinyHunters publicou no seu site de vazamentos que havia obtido acesso aos servidores da Rockstar Games. A exigência: pagamento de resgate até 14 de abril, ou os dados seriam publicados.
A Rockstar confirmou o incidente, mas com uma ressalva importante: o ataque não veio de dentro. A entrada foi via Anodot, uma plataforma de analytics de terceiros integrada ao ambiente Snowflake da empresa. Os atacantes usaram tokens de autenticação roubados para se passar por serviços legítimos internos e acessar dados de analytics do GTA Online e Red Dead Online, incluindo métricas de receita, padrões de engajamento e dados operacionais.
Nenhuma credencial de jogador foi exposta. Mas 78 milhões de registros de inteligência de negócios estão agora circulando na dark web.
Vercel
No dia 19 de abril, a Vercel publicou um boletim de segurança confirmando acesso não autorizado a sistemas internos. A cadeia de eventos:
- Um funcionário da Vercel instalou o Context AI, uma ferramenta de produtividade com IA, e a conectou à sua conta corporativa Google com permissões amplas (“Allow All”).
- O Context AI havia sido comprometido em março de 2026 por um infostealer que roubou tokens OAuth da ferramenta.
- Com esses tokens, o atacante assumiu a conta Google Workspace do funcionário, sem precisar de senha ou segundo fator, porque tokens OAuth válidos não exigem reautenticação.
- A partir do Google Workspace, o atacante escalou acesso para ambientes internos da Vercel, enumerando variáveis de ambiente marcadas como “não sensíveis”: API keys, tokens de acesso, credenciais de banco de dados.
O dado que assusta: os dados foram colocados à venda no BreachForums por 2 milhões de dólares. A Vercel hospeda o pipeline de deploy de centenas de milhares de times de desenvolvimento no mundo inteiro, incluindo chaves de acesso para AWS, GCP e Azure.
# O que estava em risco nas variáveis "não sensíveis" da Vercel:
# - Cloud access keys (AWS, Azure, GCP)
# - Database credentials
# - GitHub tokens
# - Payment API keys (Stripe, Twilio, SendGrid)
# - Signing keys e tokens internos
251 milhões de CPFs (Gov.br)
Em 18 de abril, um relatório de inteligência de ameaças registrou que um agente criminoso identificado como “Buddha” estaria comercializando um banco de dados batizado de “MORGUE” em fórum especializado. O conjunto de dados conteria 251.720.444 registros — número que supera a população atual do Brasil, porque inclui registros de pessoas falecidas.
O alvo apontado é o portal Gov.br. O vazamento ainda não foi confirmado oficialmente pela ANPD no momento desta publicação, mas o vendedor disponibilizou uma amostra de 20 mil linhas como prova de autenticidade. Especialistas recomendam tratar o incidente como real até prova em contrário.
O padrão por trás dos três
Nenhum dos três ataques explorou uma vulnerabilidade técnica de dia zero. Nenhum precisou quebrar criptografia de ponta ou superar controles de acesso sofisticados.
Os três usaram o mesmo vetor: um fornecedor ou integração de terceiro com acesso privilegiado ao ambiente da vítima.
| Incidente | Vetor de entrada | Tipo de acesso comprometido |
|---|---|---|
| Rockstar / GTA | Anodot (analytics SaaS) via Snowflake | Tokens de autenticação roubados |
| Vercel | Context AI (ferramenta de IA) via OAuth Google | Token OAuth de sessão válido |
| Gov.br (suspeito) | Ainda sob investigação | Acesso a banco de dados |
Essa é a definição de ataque à cadeia de fornecedores (supply chain attack). O atacante não precisa comprometer você. Basta comprometer alguém em quem você confia e que tem acesso ao seu ambiente.
E o problema é estrutural: quanto mais ferramentas SaaS, integrações de IA, plataformas de analytics e conectores de terceiros uma organização usa, maior é a superfície de ataque indireta.
O que sua empresa deveria estar fazendo agora
1. Inventário de integrações OAuth
Cada aplicativo conectado ao seu Google Workspace, Microsoft 365 ou Okta via OAuth é um vetor potencial. A maioria das empresas não tem esse inventário atualizado.
# No Google Admin Console:
# Admin → Segurança → Controles de API → Aplicativos de terceiros
# Filtre por "Acesso a dados corporativos" e revise permissões
Revogar acesso de apps não utilizados, apps com permissões excessivas e apps de fornecedores pequenos sem histórico de segurança.
2. Variáveis de ambiente como segredos, não conveniência
O incidente da Vercel expôs uma prática comum e perigosa: usar variáveis de ambiente “não sensíveis” para armazenar credenciais de produção porque é mais fácil.
A distinção entre “sensível” e “não sensível” deveria ser técnica, não operacional. Se o valor pode ser usado para autenticar contra um sistema de produção, ele é sensível.
3. Rotação regular de credenciais
Tokens e API keys que nunca expiram são uma janela aberta. A maioria dos ataques de supply chain funciona porque o token roubado permanece válido por dias, semanas ou meses.
# Política mínima recomendada:
rotacao_api_keys: 90 dias
rotacao_tokens_servico: 30 dias
rotacao_credenciais_banco: 180 dias
expiracao_tokens_oauth: 24h (com refresh limitado)
4. Avaliação de segurança de fornecedores
Antes de integrar qualquer ferramenta SaaS ao seu ambiente corporativo, especialmente ferramentas de IA que pedem acesso a e-mail, Google Drive ou repositórios, avalie:
- O fornecedor tem SOC 2 Type II ou equivalente?
- Quais permissões OAuth a ferramenta solicita e por quê?
- Existe uma política de resposta a incidentes documentada?
- O contrato inclui cláusulas de notificação de breach?
5. Monitoramento de credenciais expostas
Existem serviços que monitoram em tempo real se credenciais da sua organização aparecem em dumps públicos ou fóruns criminosos. A detecção precoce pode limitar o impacto de um vazamento antes que o atacante aja.
O que esses casos significam para a LGPD
Os três incidentes têm implicações diretas para a conformidade com a Lei Geral de Proteção de Dados.
O artigo 46 da LGPD exige que controladores e operadores adotem medidas técnicas e administrativas para proteger dados pessoais contra acessos não autorizados. Integrações de terceiros sem avaliação de segurança, variáveis de ambiente desprotegidas e ausência de rotação de credenciais são evidências de falha nessa obrigação.
No caso de um incidente confirmado envolvendo dados de titulares brasileiros, a notificação à ANPD deve ocorrer em prazo razoável, e o controlador precisa demonstrar que adotou as medidas cabíveis.
A pergunta que todo CTO e CISO deveria estar respondendo esta semana: se um dos nossos fornecedores for comprometido amanhã, quais sistemas e dados estarão em risco?
Precisa de ajuda?
A Kadima Cloud realiza avaliações de postura de segurança com foco em supply chain risk: inventário de integrações OAuth, revisão de políticas de credenciais, análise de fornecedores críticos e conformidade com LGPD.
Se você ainda não sabe quais ferramentas de terceiros têm acesso ao seu ambiente, esse é o primeiro sinal de alerta.
Entre em contato com a Kadima Cloud e agende uma conversa sem compromisso.