Do pacote nx comprometido a controle administrativo na nuvem em 72 horas

Em agosto de 2025, uma lacuna na cadeia de fornecimento de software voltou a demonstrar que o elo mais fraco pode estar no fluxo de trabalho do desenvolvedor. Uma versão comprometida do pacote nx publicada no npm incluiu um programa de pós-instalação malicioso que terminou sendo a porta de entrada para um ataque que escalou na nuvem até se tornar controle administrativo total em menos de três dias.

O mecanismo inicial não foi sofisticado em seu conceito: a exploração de um fluxo de trabalho do GitHub Actions baseado empull_ request_target, uma classe de ataque que a comunidade conhece como Pwn Request. Pesquisas sobre este tipo de abuso e como afetam repositórios e workflows podem ser consultadas em análise técnica como os de Praetorian, Endor Labs e SonarSource. Esse tipo de fluxo permite que um ator com acesso a um pedido de extração obtenha privilégios elevados e extraiga segredos que depois se reutilizam para comprometer ambientes mais sensíveis.

Neste caso, o pacote troceado incluía um ladrão de credenciais em JavaScript batizado QUIETVAULT, cuja detecção pode ser consultada em fontes de análise de malware como Vírus total. O código procurava variáveis de ambiente, metadados do sistema e tokens valiosos - incluindo tokens pessoais do GitHub (PAT) - e subia as informações coletadas a um repositório público. O vetor de execução foi, paradoxalmente, uma atualização disparada por uma extensão de desenvolvimento (Nx Console) quando um empregado abriu seu editor e permitiu que o postinstall fosse executado em sua máquina.

Com os tokens em mão, o grupo identificado pelo Google como UNC6426 iniciou manobras de reconhecimento dentro do ambiente GitHub da vítima e utilizou uma ferramenta legítima de extração de segredos chamada Nord Stream Para localizar credenciais adicionais, incluindo as de uma conta de serviço do GitHub. A partir daí, o atacante aproveitou a relação de confiança entre o GitHub Actions e a Amazon Web Services (a integração OIDC) para solicitar tokens temporários da AWS STS e acessar papéis com capacidade de implantação de infraestrutura.

O problema chave na nuvem foi a permissividade de um papel ligado ao GitHub Actions que permitia operações da CloudFormation com faculdades para criar identidades e anexar políticas. Com essa janela, os agressores lançaram uma pilha cujo único objetivo era criar uma nova identidade com a política de AdministratorAccess anexo. De acordo com a análise publicada pelo Google em seu Cloud Threat Horizons Report H1 2026, este encadeamento permitiu passar de um token roubado a licenças administrativas completas na AWS em menos de 72 horas.

Com o controle administrativo absoluto, os atacantes fizeram o que qualquer operador malicioso com esse nível poderia: enumeraram e exfiltraram objetos de buckets S3, terminaram instâncias de produção em EC2 e RDS e desencriptaram chaves de aplicações que protegiam outros ativos. Em uma fase final de humilhação operacional, coincidiram mudanças no ecossistema de desenvolvimento: renomearam repositórios internos e os fizeram públicos, deixando evidência do compromisso e ampliando o dano reputacional e operacional.

Há uma camada adicional relevante neste incidente: a intervenção de agentes de inteligência artificial como ferramenta operacional. O ladrão QUIETVAULT, além de coletar segredos, aproveitou um assistente LLM presente nos endpoints para localizar credenciais e dados com instruções em linguagem natural, o que evidencia uma nova modalidade de abuso da cadeia de fornecimento onde a execução de ações maliciosas se expressa como prompts e não como callbacks codificados. Assinaturas especializadas, como Socket, alertaram sobre como os assistentes integrados no fluxo do desenvolvedor ampliam o perímetro de ataque e complicam a detecção tradicional.

As recomendações técnicas que emergem da pesquisa apontam a medidas tanto na fase de desenvolvimento quanto na gestão de identidades e acessos na nuvem. É crítico limitar programas de pós-instalação ou executar pacotes em ambientes isolados, aplicar estritamente o princípio de menor privilégio em contas e papéis que interagem com CI/CD, e evitar privilégios permanentes para tarefas que não os requerem, como a criação de papéis administrativos. Também é conveniente utilizar PATs mais granulares e de curta duração, monitorizar padrões invulgares na actividade de IAM e reforçar a supervisão para detectar indícios de agentes de IA a agir sobre sistemas de desenvolvimento.

Para além das medidas pontuais, o caso ilustra uma lição estrutural: as cadeias de abastecimento modernas são um vetor multiplicador. Um pacote popular com uma atualização maliciosa pode transformar um exploit local em uma intrusão em grande escala se as relações de confiança entre ferramentas (editores, extensões, registries, pipelines e nuvens) não estiverem corretamente acotadas. As organizações devem repensar não só as políticas de segurança na nuvem, mas como se integram e confiam as ferramentas de desenvolvimento em ambientes distribuídos.

Para aqueles que desejam aprofundar os detalhes técnicos e mitigações, os relatórios e análises citados oferecem guias e contexto adicional: o relatório do Google sobre ameaças na nuvem citadas acima, os ensaios técnicos sobre Pwn Request Praetorian e SonarSource, e trabalhos sobre execução de agentes AI e riscos em extensões por parte de Socket. A vigilância em ambas as frentes — sequência de fornecimento e controle de identidades na nuvem — é hoje uma prioridade operacional e de governança para qualquer organização que dependa de software de terceiros e pipelines automatizados.