Vazamento na Novo Nordisk: como um token do GitHub expôs a fórmula exata do Ozempic
Publicado pela Pentesty · Vazamento de dados · Indústria farmacêutica · Vazamento de código-fonte
Um grupo que se apresenta como FulcrumSec afirma ter roubado aproximadamente 1.3 TB de dados da Novo Nordisk, a farmacêutica dinamarquesa responsável pelo Ozempic e pelo Wegovy. Depois que a empresa supostamente recusou pagar um resgate de US$ 25 milhões, o grupo começou a publicar uma amostra de 264 GB dos dados. O material vazado supostamente inclui código-fonte, registros de estudos clínicos, dados de funcionários e pacientes e a própria fórmula do Ozempic. Segundo os relatos, a entrada ocorreu por um único token do GitHub que deu aos invasores dois meses de acesso a repositórios internos antes que alguém percebesse.
O que torna esse incidente digno de uma leitura cuidadosa é o quanto a falha foi comum. Não há zero-day, operação de Estado ou técnica inédita. Apenas uma credencial que não deveria permitir uso externo e ninguém monitorando a entrada.
O que a FulcrumSec afirma ter obtido
Segundo declarações do grupo à DataBreaches.Net e reportagem do g1, o conjunto inclui:
- Código-fonte e documentação técnica proprietária de medicamentos lançados e ainda não lançados.
- A fórmula exata do Ozempic, além de material sobre outros medicamentos em desenvolvimento.
- Registros de estudos clínicos de aproximadamente 11,500 pacientes.
- Dados pessoais de milhares de funcionários, médicos e pacientes.
- Detalhes sobre instalações de processamento e modelos internos de IA usados pela empresa.
O grupo diz ter extraído mais de 700,000 arquivos, cerca de 1.3 TB, e divulgado aproximadamente 264 GB até o momento. Também afirmou que, por enquanto, reterá os arquivos de funcionários e pacientes, uma forma comum de pressionar vítimas na extorsão que exige pagamento para evitar a divulgação. Detalhamos esse padrão na nossa análise da metodologia de extorsão da ShinyHunters.
A Novo Nordisk confirmou em 11 de junho que sofreu um incidente de cibersegurança envolvendo acesso não autorizado a um número limitado de sistemas internos e a dados pessoais de alguns participantes de estudos clínicos. A empresa informou à Reuters que está “em contato com as autoridades competentes” e que suas principais plataformas funcionam normalmente.
Como entraram: um token do GitHub, dois meses de acesso
Segundo a FulcrumSec, o acesso começou em março com um token de acesso pessoal do GitHub que permitia clonar repositórios internos. A partir daí, o grupo permaneceu no ambiente por aproximadamente dois meses antes de extrair a maior parte dos dados.
O grupo também fez questão de zombar da empresa, alegando que sistemas críticos eram protegidos por senhas como “novo123”. Seja essa sequência exata ou não, o quadro geral é difícil de contestar. Quando uma credencial de desenvolvedor abre caminho para código-fonte, modelos internos de IA e dados de clientes, grande parte do restante do programa de segurança perde relevância.
Esse formato de ataque tem aparecido durante todo o ano. Um token vazado com permissões excessivas, nenhum alerta sobre acessos incomuns aos repositórios e semanas de permanência até que alguém perceba. A mesma dinâmica aparece em nossa análise de configurações incorretas na nuvem em 2026 e na onda de ataques com IA que agora automatizam a busca por esses pontos de entrada.
Por que o vazamento de uma fórmula de medicamento é diferente
Quando dados de clientes vazam de um aplicativo de entregas ou de uma plataforma de cursos, o dano é real, mas grande parte das consequências aparece depois, na forma de phishing, tomada de contas e fraudes. Um conjunto de propriedade intelectual farmacêutica representa outro tipo de problema.
- Propriedade intelectual não pode ser trocada como uma senha. Uma senha pode ser alterada em uma tarde. Uma fórmula, depois de publicada, continua pública.
- O risco de falsificação aumenta. Documentação detalhada de formulação e processos facilita que fabricantes ilegais produzam medicamentos injetáveis dos quais milhões de pacientes dependem.
- Participantes de estudos ficam em uma posição vulnerável. Dados de estudos clínicos frequentemente associam um nome a uma condição de saúde específica. Essa combinação pode ser usada para chantagem, discriminação por seguradoras e phishing direcionado. O risco posterior é semelhante ao que descrevemos na análise do vazamento do iFood, mas com informações de saúde associadas.
- Modelos internos de IA tornam-se uma segunda superfície de ataque. Pesos de modelos, dados de treinamento e prompts nas mãos erradas oferecem a concorrentes e agentes de ameaça um ponto de partida que a equipe original levou anos para construir.
O que as equipes de engenharia devem aprender com isso
As medidas que teriam evitado esse incidente são conhecidas. Continuam sendo deixadas de lado porque são pouco atraentes e porque nada falha quando você as ignora, até que algo falha de forma grave.
Trate credenciais de código-fonte como ativos essenciais
Tokens de acesso pessoal, chaves de implantação e tokens de CI são credenciais ao portador com permissão de leitura sobre sua propriedade intelectual. Prazos curtos de expiração, permissões restritas, listas de IPs autorizados e contas corporativas integradas ao SSO devem ser o padrão. Faça a rotação com frequência e revogue no mesmo dia do desligamento.
Elimine senhas fracas e compartilhadas na origem
É fácil rir de “novo123”, mas o padrão por trás disso, contas administrativas em sistemas internos com senhas previsíveis ou compartilhadas, aparece em quase todo vazamento que analisamos. Exija um gerenciador de senhas em toda a organização, bloqueie padrões comuns na política de senhas e exija MFA resistente a phishing em tudo que tenha acesso a código, nuvem ou dados. Isso é OWASP A07: falhas de identificação e autenticação em linguagem simples.
Crie alertas para clonagem em massa, não apenas para logins
Um token que clona silenciosamente centenas de repositórios ao longo de semanas é um dos sinais mais evidentes que você pode coletar, desde que alguém esteja acompanhando. Crie alertas para padrões anormais de acesso a repositórios, uso incomum de tokens de API e grandes fluxos de saída de dados. Dois meses de permanência raramente significam que o invasor foi brilhante. Em geral, significam que o defensor não tinha visibilidade.
Verifique seus repositórios como um invasor faria
A busca por segredos, a análise de dependências e a SCA não são opcionais para equipes que entregam código. Se seus repositórios internos contêm credenciais fixas no código, chaves de API ou strings de conexão de bancos de produção, um token roubado basta para comprometer todo o ambiente. Foi exatamente isso que aconteceu aqui.
Pressuponha uma invasão e ensaie a resposta
As empresas que melhor lidam com esses incidentes não são as que os evitam. São as que já praticaram. Da recusa da Rockstar em pagar o resgate ao caso do BTG Pactual, o padrão é o mesmo: uma posição jurídica clara, divulgação rápida e um plano de resposta a incidentes escrito antes de surgir o prazo.
A Novo Nordisk deveria ter pago?
As reportagens indicam que a Novo Nordisk não pagou os US$ 25 milhões exigidos, o que teria desencadeado o vazamento público. De fora, essa parece ter sido a decisão correta. O pagamento nunca garante a exclusão, financia o próximo ataque e, depois que uma fórmula e dados clínicos estão em mãos criminosas, não existe cenário em que a empresa “recompre” o segredo. A mesma lógica ficou evidente quando a Rockstar recusou pagar à ShinyHunters e o vazamento previsto aconteceu mesmo assim. Recusar uma extorsão é doloroso. Pagar tende a ser pior.
A verdadeira falha veio antes, nas condições que transformaram um token do GitHub em uma chave mestra. Uma resposta bem conduzida não equivale a uma boa postura de segurança. Apresentamos o mesmo argumento em Por que seu relatório de pentest está mentindo para você: uma verificação de conformidade não identifica o tipo de caminho de ataque observado aqui.
O que pacientes e participantes de estudos devem fazer
Mesmo que os invasores digam que não publicarão arquivos de pacientes e funcionários, a suposição mais segura é que os dados já estão em mãos adversárias. Se você participou de um estudo clínico da Novo Nordisk ou é um paciente atual, trate como suspeito qualquer contato não solicitado sobre esse assunto.
- Espere phishing direcionado com referências ao seu tratamento, médico ou estudo. Não clique em links nem compartilhe informações por telefone, SMS ou e-mail.
- Verifique qualquer comunicação “oficial” por canais nos quais você já confia, como o consultório do seu médico, o coordenador do estudo ou a página de contato da empresa, digitada manualmente no navegador.
- Acompanhe contas financeiras e benefícios farmacêuticos. Dados sensíveis de saúde podem alimentar fraudes de seguros e golpes com receitas médicas.
- Use senhas exclusivas e MFA em qualquer portal de saúde ou seguro. A reutilização de credenciais transforma um vazamento em vários, como mostramos na análise do vazamento da Udemy.
Como a pentesty.co ajuda empresas a evitar esse cenário
O caso da Novo Nordisk será citado por anos como a história de um token vazado, dois meses de permanência e uma molécula de bilhões de dólares chegando à internet aberta. A verdade mais difícil é que condições semelhantes existem agora em muitas equipes de engenharia. Elas simplesmente ainda não foram testadas.
pentesty.co ajuda equipes a encontrar o caminho que um invasor realmente seguiria antes que isso aconteça. Com testes de intrusão contínuos apoiados por IA, a plataforma pode:
- Mapear sua superfície de ataque externa e encontrar credenciais vazadas, tokens expostos e ativos de desenvolvimento esquecidos.
- Simular como um invasor avançaria de um único ponto de entrada, como um token de acesso pessoal ou uma senha administrativa fraca, para dados de produção e código-fonte.
- Priorizar problemas pelo impacto no negócio para sua equipe fechar caminhos reais de ataque, em vez de percorrer uma lista de CVEs sem priorização.
Uma análise completa de uma aplicação web ou API leva menos de 10 minutos e entrega um PDF pronto para auditoria ao final. Sem fila de consultoria nem semanas de espera por uma apresentação. Nossos serviços de segurança ofensiva seguem a mesma perspectiva de pensar primeiro como o invasor.
Você não escolhe se alguém testará sua segurança. Só escolhe se será um pentester contratado ou um grupo de extorsão com seu código-fonte. Pentesty.co foi criada para tornar a primeira opção rápida o suficiente para que a segunda nunca precise ser o padrão.
Conteúdos relacionados na Pentesty
Por dentro da ShinyHunters: o roteiro da extorsão →
O mesmo modelo de extorsão usado pela FulcrumSec contra a Novo Nordisk, mapeado de ponta a ponta em cinco fases.
A Rockstar Games recusou pagar. Veja o que aconteceu depois →
O argumento público mais claro de por que pagar extorsões quase nunca funciona, e o mesmo cálculo enfrentado pela Novo Nordisk.
Alerta de “megavazamento” do iFood →
Setor diferente, padrão idêntico: extorsão com ameaça de divulgação contra uma marca à qual o público confia dados pessoais.
Configurações incorretas de segurança na nuvem em 2026 →
Por que tokens com permissões excessivas e caminhos de acesso sem monitoramento ainda motivam a maioria dos vazamentos modernos.
OWASP Top 10: o guia do desenvolvedor →
Senhas fracas e tokens vazados correspondem diretamente ao OWASP A07, com exemplos concretos da alternativa mais segura.
Por que seu relatório de pentest está mentindo para você →
Ser aprovado em uma auditoria não identifica um token do GitHub vazado. Testar caminhos reais de ataque, sim.
Resumo
Encontre o token vazado antes que outra pessoa o encontre. Solicite acesso antecipado à Pentesty.