Não houve invasão. A credencial estava no site, servida a quem pedisse

Há uma pergunta que aparece em toda reunião pós-incidente: por onde ele entrou? Nestes casos a resposta é constrangedora. Ele entrou pela porta da frente, com a chave que estava pendurada do lado de fora.

O caso da Novo Nordisk merece detalhe porque expõe a mecânica inteira. O ponto inicial foi um token de acesso do GitHub encontrado em março. Com ele, o grupo clonou repositórios internos e extraiu novas credenciais de dentro do código. Em paralelo, encontrou segredos em JavaScript servido ao navegador em dois subdomínios que não tinham relação entre si. Palavras do próprio grupo: duas equipes diferentes, duas aplicações diferentes, o mesmo erro elementar cometido duas vezes.

O grupo afirma ter passado mais de dois meses dentro do ambiente. O que saiu de lá inclui código-fonte, informação sobre medicamentos lançados e não lançados, dados de ensaio clínico, registros de funcionários e pacientes e material sobre modelos internos de IA. A empresa recusou pagar. O conteúdo foi publicado.

O padrão se repete em setores que não têm nada em comum

No Manchester Airports Group, o achado foi uma chave de API da Iterable exposta em JavaScript visível a qualquer visitante do site. Saíram 86 gigabytes. A lista de vítimas segue por consultoria de engenharia, rede internacional de escolas, fintech australiana e provedor de dados jurídicos.

Aeroporto, farmacêutica, escola e escritório de engenharia não compartilham fornecedor, regulação, arquitetura nem maturidade de segurança. Compartilham uma prática de desenvolvimento, e é só disso que o grupo precisa.

Por que a pilha de segurança não vê nada

Convido a leitura desta parte com a sua própria arquitetura em mente, porque o incômodo é o ponto.

• Não há o que o EDR detecte. A sessão usa credencial válida, dentro do fluxo previsto pela aplicação. Não existe binário estranho, processo anômalo nem escalada de privilégio para gerar alerta.
• Não há patch. Correção pressupõe defeito em software de terceiro. Segredo publicado não tem correção de fornecedor, tem rotação e limpeza de histórico.
• Não há perímetro a defender. O atacante lê exatamente o mesmo arquivo que o navegador de qualquer visitante baixa. Bloquear isso significaria bloquear a própria aplicação.
• Não há janela de urgência. Uma chave esquecida em 2022 continua válida em 2026 se ninguém a rotacionou. O tempo joga contra o defensor, e só contra ele.

Essa combinação explica por que o grupo consegue passar meses dentro de organizações grandes e bem financiadas. Não é sofisticação técnica. É exploração de um ponto cego que a maioria dos programas de segurança herdou por construção: o código é território do time de desenvolvimento, e o time de segurança olha para a infraestrutura.

O que costuma dar errado na resposta

Quem descobre um segredo exposto normalmente faz duas coisas: remove a linha do código e publica uma nova versão. Nenhuma das duas resolve.

Remover a linha não apaga o commit anterior. O histórico do repositório continua guardando a chave, e ela permanece válida até que alguém a rotacione no sistema que a emitiu. Publicar nova versão também não ajuda: o bundle antigo já foi baixado, indexado e arquivado por quem se interessou. A única ação que encerra a exposição é invalidar a credencial na origem.

A segunda falha típica é tratar o achado como incidente isolado. Se um segredo vazou por essa via, o processo que permitiu isso continua rodando. A pergunta certa não é qual chave vazou, e sim quantas outras estão pelo mesmo caminho neste momento.

Leitura LATAMSEC

Este é um daqueles riscos em que o trabalho inicial é barato e o adiamento é caro. Quatro movimentos, em ordem.

Um: varrer o que você já publica. Baixe os bundles de JavaScript dos seus domínios públicos e procure por chave de API, endpoint interno, string de conexão e token. É a mesma coisa que o atacante faz e leva uma tarde. Comece pelos subdomínios que nenhuma equipe reivindica, que são onde o achado costuma estar.

Dois: varredura de segredo no histórico, não só no código atual. Ferramenta que olha apenas o estado presente do repositório perde exatamente o caso da Novo Nordisk. O commit de março importa.

Três: prazo de validade em credencial de máquina. Token que nunca expira é token que sobrevive ao funcionário que o criou, ao projeto que o usava e à empresa que foi adquirida. Rotação automática reduz o valor do achado a poucas semanas.

Quatro: incluir o fornecedor na conta. Metade das chaves expostas nesses casos é de serviço de terceiro, do tipo que a área de marketing contrata sem passar por revisão. Uma chave de plataforma de e-mail marketing dá acesso à base inteira de contatos, e isso raramente aparece no mapa de risco.

Para o conselho, a pergunta é direta: quantos segredos válidos existem hoje em código que nós mesmos publicamos, e quem tem a autoridade para revogá-los sem derrubar a operação? Se não houver resposta, a resposta prática é que a organização depende da sorte de ninguém ter procurado ainda.