UNC6426 usou comprometimento do pacote npm nx para escalar até administrador na AWS

Token de desenvolvedor roubado após a execução de pacote trojanizado permitiu abuso de confiança OIDC entre GitHub e AWS, exfiltração em S3 e destruição de recursos de produção em menos de 72 horas.

Componente	Pacote npm nx, plugin Nx Console, ambiente GitHub da vítima, federação GitHub-to-AWS via OIDC, funções IAM e recursos AWS S3, EC2 e RDS.
Vetor	Execução de script postinstall em versão trojanizada do pacote, acionada por atualização relacionada ao Nx Console em um editor de código, seguida de uso de token GitHub roubado e abuso de função OIDC permissiva.
Impacto	Escalação de um token de desenvolvedor para permissões administrativas na AWS, exfiltração de arquivos em buckets S3, encerramento de instâncias EC2 e RDS de produção, descriptografia de chaves de aplicação e exposição de repositórios internos.
Prioridade	Conter tokens GitHub e credenciais de CI/CD, revisar relações OIDC GitHub-AWS, remover permissões permanentes para criação de papéis administrativos, auditar atividade IAM anômala e bloquear execução não controlada de scripts de instalação.
Artefatos	QUIETVAULT, GITHUB_TOKEN, GitHub PATs, ferramenta Nord Stream, parâmetro --aws-role, função Actions-CloudFormation e política AdministratorAccess.
Mitigação	Aplicar menor privilégio a contas de serviço e funções ligadas a OIDC, exigir PATs granulares com validade curta, restringir ações CloudFormation capazes de criar IAM e monitorar automações de desenvolvimento que tenham acesso a arquivos e credenciais.

Resumo técnico

UNC6426 encadeou um comprometimento de cadeia de suprimentos no ecossistema npm com uma falha de governança de identidade em nuvem para assumir controle administrativo de um ambiente AWS. O ponto inicial foi uma versão trojanizada do pacote nx, distribuída após abuso de um fluxo pull_request_target vulnerável em um cenário conhecido como Pwn Request. A etapa de cadeia de suprimentos permitiu que versões adulteradas chegassem ao registro npm com um script postinstall capaz de executar um ladrão de credenciais em endpoints de desenvolvimento.

O caso é relevante porque o impacto não ficou limitado ao endpoint do desenvolvedor nem ao registro de pacotes. Um funcionário executava um editor de código com o plugin Nx Console, e o processo de atualização resultou na execução do componente malicioso QUIETVAULT. A partir daí, o operador obteve um token GitHub, fez reconhecimento no ambiente de código, encontrou credenciais de uma conta de serviço e explorou a relação de confiança OIDC entre GitHub e AWS para emitir tokens temporários e criar um novo papel com permissões administrativas. A cadeia completa levou menos de 72 horas entre o roubo inicial e o domínio administrativo da conta em nuvem.

O impacto confirmado inclui acesso e enumeração de objetos em buckets S3, exfiltração de arquivos, encerramento de instâncias EC2 e RDS de produção, descriptografia de chaves de aplicação e alteração destrutiva de repositórios internos no GitHub, que foram renomeados e tornados públicos. A sequência mostra que tokens de desenvolvimento, contas de serviço de CI/CD e papéis OIDC com permissões amplas devem ser tratados como caminho direto para controle de nuvem, não apenas como credenciais auxiliares de automação.

Fluxo técnico

A cadeia começou no comprometimento do pacote nx em agosto de 2025. O fluxo vulnerável pull_request_target concedeu aos invasores uma superfície de execução com privilégio elevado, permitindo acesso a dados sensíveis, incluindo GITHUB_TOKEN, e viabilizando a publicação de versões adulteradas no npm. Essas versões continham um script postinstall, mecanismo que roda automaticamente em determinados fluxos de instalação ou atualização de dependências. Em vez de depender de uma exploração interativa, o ataque se aproveitou da confiança rotineira depositada em pacotes de desenvolvimento e integrações de editor.

O QUIETVAULT coletava variáveis de ambiente, informações do sistema e tokens valiosos, incluindo GitHub Personal Access Tokens. Um detalhe importante foi o uso de uma ferramenta de LLM já instalada no endpoint para procurar informações sensíveis no sistema. Isso desloca parte da lógica de descoberta para uma ferramenta autenticada e com acesso local, reduzindo a necessidade de endpoints de rede explícitos ou indicadores estáticos tradicionais. O material capturado foi enviado para um repositório público no GitHub identificado como /s1ngularity-repository-1, o que também indica abuso de infraestrutura legítima para armazenar resultados do roubo de credenciais.

Dois dias depois do comprometimento inicial, UNC6426 usou o PAT roubado para reconhecimento no ambiente GitHub da organização. A atividade incluiu o uso da ferramenta open source Nord Stream para extrair segredos de ambientes de CI/CD, o que expôs credenciais de uma conta de serviço do GitHub. Com essa conta, o operador usou o parâmetro --aws-role para gerar tokens temporários do AWS Security Token Service destinados à função Actions-CloudFormation. Essa etapa foi decisiva porque transformou uma credencial de repositório em uma sessão válida no ambiente AWS por meio da confiança OIDC já configurada.

A função Actions-CloudFormation estava excessivamente permissiva. Com ela, UNC6426 implantou uma pilha AWS com capacidades CAPABILITY_NAMED_IAM e CAPABILITY_IAM, suficientes para criar recursos IAM nomeados. A pilha tinha finalidade restrita: criar um novo papel IAM e anexar a política gerenciada AdministratorAccess. Depois disso, o invasor deixou de depender do token GitHub original e passou a operar com privilégios administrativos na nuvem. Essa mudança de plano de controle explica a velocidade do comprometimento: o ambiente de desenvolvimento forneceu a credencial inicial, a automação CI/CD forneceu a ponte e o IAM permissivo entregou persistência e autoridade administrativa.

Superfície afetada

A superfície exposta envolve estáções de desenvolvimento que instalam ou atualizam pacotes npm, extensões de editor que acionam atualizações de dependências, repositórios GitHub com PATs ou contas de serviço e ambientes AWS que confiam em identidades OIDC originadas de GitHub Actions. O risco aumenta quando a mesma cadeia de automação consegue acessar código, ler segredos, assumir papéis na nuvem e criar recursos IAM. Em ambientes assim, um comprometimento de pacote deixa de ser apenas evento de endpoint e passa a ser uma rota de escalação entre desenvolvimento, CI/CD e plano de controle cloud.

O ponto fraco de maior impacto foi a combinação entre credenciais reutilizáveis e permissões amplas. PATs sem escopo restrito ou com validade longa ampliam a janela de abuso após a coleta. Contas de serviço do GitHub que acessam múltiplos repositórios ou segredos de pipeline reduzem a segmentação. Papéis OIDC que permitem CloudFormation com capacidade de criar IAM tornam possível a criação de papéis administrativos mesmo quando o invasor começa com uma sessão temporária. A presença de ferramentas de IA com acesso ao sistema de arquivos e a credenciais também amplia a superfície, porque consultas em linguagem natural podem ser usadas para localizar material sensível sem uma assinatura binária óbvia.

A exposição final atingiu recursos de produção e ativos de código. Buckets S3 foram enumerados e acessados, arquivos foram exfiltrados, instâncias EC2 e bancos RDS foram encerrados, chaves de aplicação foram descriptografadas e repositórios internos foram renomeados para o padrão /s1ngularity-repository-[caracteres aleatórios] antes de serem tornados públicos. Esses efeitos indicam comprometimento administrativo e capacidade destrutiva, não apenas leitura de código ou vazamento de token isolado.

• Estáções de desenvolvimento com pacote nx trojanizado ou atualização acionada por Nx Console.
• Ambiente GitHub com PATs, contas de serviço e segredos consumidos por CI/CD.
• Relação OIDC GitHub-to-AWS associada à função Actions-CloudFormation.
• Permissões CloudFormation capazes de criar papéis IAM e anexar AdministratorAccess.

Hunting e telemetria

A investigação deve correlacionar eventos de pacote, endpoint, GitHub e AWS em uma linha do tempo única. No endpoint, o foco é identificar execução de scripts de instalação associados ao pacote nx, processos de editor que acionaram atualização, leitura incomum de variáveis de ambiente e acesso de ferramentas de IA a diretórios que contenham credenciais, configurações de nuvem, tokens ou material de CI/CD. A detecção não deve depender apenas de conexões para infraestrutura externa, porque a cadeia descrita usou GitHub como meio de armazenamento e abusou de ferramentas legítimas já presentes no ambiente.

No GitHub, a telemetria deve cobrir uso de PATs fora do padrão do usuário, enumeração acelerada de repositórios, acesso a segredos, atividade de contas de serviço e alterações em visibilidade ou nomes de repositórios. A criação ou renomeação em massa com padrão /s1ngularity-repository- deve ser tratada como sinal de comprometimento. Também é importante revisar quando tokens foram emitidos, quais repositórios foram acessados, quais ações de workflow ocorreram e se houve uso de ferramentas voltadas à extração de segredos em contexto de CI/CD.

Na AWS, os principais sinais estão em CloudTrail, IAM, STS, CloudFormation, S3, EC2, RDS e KMS. Devem ser investigadas chamadas AssumeRoleWithWebIdentity originadas de confiança GitHub, emissão de sessões temporárias para a função Actions-CloudFormation, criação de stacks com capacidades IAM, criação de novos papéis, anexação de AdministratorAccess, enumeração e leitura em S3, ações de parada ou término em EC2 e RDS e operações de descriptografia de chaves de aplicação. A sequência temporal entre token GitHub roubado, emissão STS e criação de papel administrativo é mais forte do que qualquer evento isolado.

• Execução de postinstall vinculada a versões trojanizadas do pacote nx.
• Uso anômalo de GitHub PAT, especialmente a partir de localidade, horário ou cliente não usuais.
• Acesso de conta de serviço a segredos de CI/CD seguido de emissão de tokens STS para AWS.
• CloudFormation com CAPABILITY_NAMED_IAM ou CAPABILITY_IAM criando papéis IAM novos.
• Anexação da política AdministratorAccess a papel recém-criado ou inesperado.
• Enumeração de S3, descriptografia de chaves de aplicação e término de EC2/RDS em janela curta.
• Renomeação e publicação de repositórios internos com padrão /s1ngularity-repository-.

Mitigação

A resposta deve começar pela contenção de identidade. Tokens GitHub associados ao usuário afetado, contas de serviço e pipelines devem ser revogados ou rotacionados, com atenção especial a PATs, GITHUB_TOKEN expostos e credenciais armazenadas em segredos de CI/CD. Em paralelo, as relações OIDC GitHub-AWS precisam ser revisadas para confirmar quais repositórios, ramos, workflows e contas podem assumir papéis na AWS. Qualquer papel usado por automação deve ter escopo mínimo e não deve permitir criação arbitrária de IAM, anexação de políticas administrativas ou implantação de stacks CloudFormation com capacidades de IAM sem controles adicionais.

No plano de dependências, organizações devem reduzir a execução automática de scripts de instalação quando o fluxo de desenvolvimento permitir. Gerenciadores de pacote com bloqueio ou neutralização de scripts postinstall, execução em sandbox e revisão explícita de atualizações reduzem o raio de impacto de pacotes trojanizados. Lockfiles, caches corporativos, espelhos internos e políticas de aprovação para atualizações críticas ajudam a evitar que uma extensão de editor ou rotina automática traga código não verificado diretamente para o endpoint de um desenvolvedor com acesso a tokens.

Para identidade de desenvolvedor, PATs devem ser granulares, com validade curta e permissões específicas por repositório. Contas de serviço precisam ter dono, finalidade documentada, escopo mínimo e rotação periódica. Segredos de CI/CD devem ser separados por ambiente e por finalidade, evitando que uma credencial de build consiga assumir papel de produção ou criar infraestrutura administrativa. A remoção de privilégios permanentes para ações de alto risco, como criar papéis administrativos, é uma medida central: quando essas ações forem necessárias, elas devem passar por aprovação, trilha de auditoria e controles de sessão.

A etapa final é validar o ambiente após a contenção. Isso inclui revisar todos os papéis IAM criados durante a janela do incidente, remover políticas inesperadas, verificar stacks CloudFormation recentes, auditar buckets S3 acessados, confirmar estado de EC2 e RDS, reverter alterações de visibilidade em repositórios e avaliar exposição de chaves de aplicação descriptografadas. Também é necessário tratar o risco de Shadow AI: ferramentas de IA instaladas em estáções de desenvolvimento devem ser inventariadas, controladas e monitoradas, porque qualquer integração capaz de ler arquivos, usar credenciais ou interagir com ferramentas autenticadas herda parte da autoridade operacional do usuário.

• Revogar PATs e credenciais GitHub associados ao usuário, contas de serviço e workflows expostos.
• Restringir OIDC GitHub-AWS por repositório, ramo, workflow e condições de audiência adequadas.
• Remover de papéis CI/CD permissões para criar IAM ou anexar políticas administrativas sem aprovação.
• Bloquear ou isolar scripts postinstall em ambientes de desenvolvimento sensíveis.
• Auditar CloudTrail para criação de papéis, stacks CloudFormation com capacidades IAM e anexação de AdministratorAccess.
• Revisar S3, EC2, RDS, KMS e repositórios GitHub para confirmar exfiltração, destruição e exposição pública.
• Inventariar ferramentas de IA em endpoints de desenvolvimento e limitar acesso a credenciais, diretórios sensíveis e automações autenticadas.