A velocidade dos ataques cibernéticos modernos aumentou drasticamente. O que antes exigia semanas de exploração e movimentação lateral hoje pode acontecer em poucas horas, principalmente quando cadeias de suprimentos de software são exploradas. Um incidente recente atribuído ao grupo UNC6426 mostrou exatamente isso: um simples token comprometido do npm desencadeou uma invasão que levou ao controle completo de um ambiente na Amazon Web Services em apenas 72 horas.
O ataque começou dentro do ecossistema de desenvolvimento JavaScript, mas rapidamente evoluiu para algo muito maior. Ao comprometer um pacote amplamente utilizado e explorar automações de CI/CD, os invasores conseguiram acessar credenciais sensíveis, assumir papéis privilegiados e dominar recursos críticos na nuvem.
O caso chamou ainda mais atenção da comunidade de segurança porque os invasores utilizaram uma ferramenta baseada em inteligência artificial, chamada QUIETVAULT, capaz de identificar segredos e credenciais escondidas em ambientes de desenvolvimento. Essa combinação de ataque à cadeia de suprimentos, automação DevOps e IA aplicada ao malware mostra como a superfície de ataque dos ambientes modernos se tornou extremamente complexa.
Para desenvolvedores, administradores de sistemas Linux e equipes de segurança, o incidente representa um alerta importante sobre a necessidade de reforçar práticas de DevSecOps e proteger integrações entre plataformas de código e infraestrutura de nuvem.
O incidente do pacote nx: o início da reação em cadeia
O ataque começou no ecossistema do npm, o maior repositório de pacotes JavaScript do mundo. Os invasores conseguiram acesso a um token automatizado utilizado na publicação de pacotes, permitindo que uma nova versão modificada de uma dependência popular fosse distribuída para usuários e pipelines de build.
O pacote afetado fazia parte do ecossistema da ferramenta nx, amplamente utilizada para gerenciar monorepositórios em projetos modernos. Ao inserir código malicioso em uma atualização aparentemente legítima, os atacantes realizaram um clássico ataque à cadeia de suprimentos de software.
Esse tipo de ataque funciona porque muitos ambientes de desenvolvimento utilizam atualizações automáticas de dependências. Quando um pacote comprometido é publicado, ele pode ser instalado automaticamente em:
• pipelines de CI/CD
• ambientes de desenvolvimento locais
• sistemas de build automatizados
Uma vez instalado, o código malicioso executava scripts que buscavam credenciais armazenadas no ambiente de build. Entre os principais alvos estava o GITHUB_TOKEN, uma credencial automática utilizada por pipelines para interagir com repositórios na plataforma GitHub.
Com esse acesso inicial, os invasores passaram a explorar os repositórios comprometidos em busca de novas credenciais, arquivos de configuração e integrações com serviços externos.
Esse foi o ponto de partida para a escalada que levaria à infraestrutura de nuvem.
O papel da IA no roubo de dados: conheça o QUIETVAULT
Um dos elementos mais sofisticados do ataque foi o uso da ferramenta QUIETVAULT, um módulo de malware que incorpora modelos de linguagem locais (LLMs) para ajudar na busca por informações sensíveis.
Tradicionalmente, malwares procuram credenciais utilizando scripts simples que varrem arquivos e variáveis de ambiente. O QUIETVAULT, no entanto, vai além desse modelo tradicional.
A ferramenta utiliza inteligência artificial para interpretar o contexto do projeto e localizar segredos escondidos em diferentes partes do ambiente comprometido.
Entre os alvos analisados estavam arquivos como:
• .env
• arquivos YAML de configuração
• scripts de automação
• arquivos de infraestrutura como código
Em vez de exfiltrar grandes quantidades de dados, o QUIETVAULT utiliza processamento local para extrair apenas informações relevantes, como tokens de acesso, chaves de API e credenciais de serviços.
Essa abordagem reduz significativamente o volume de dados transferidos para os servidores dos invasores, tornando o ataque mais discreto e difícil de detectar.
Especialistas classificam esse tipo de ameaça como parte de uma nova geração de malwares assistidos por IA, capazes de adaptar seu comportamento ao ambiente comprometido.
Na prática, isso significa que o malware consegue analisar estruturas complexas de projetos e encontrar segredos que passariam despercebidos por ferramentas tradicionais de varredura.
Da nuvem ao caos: como a AWS foi dominada em 3 dias
Após coletar credenciais e tokens dentro do ambiente de desenvolvimento, os invasores encontraram um caminho direto para a infraestrutura de nuvem.
O ambiente comprometido utilizava integração entre pipelines hospedados no GitHub e recursos da Amazon Web Services por meio do protocolo OIDC (OpenID Connect).
Esse mecanismo permite que pipelines assumam papéis temporários dentro da nuvem sem armazenar credenciais permanentes. Quando configurado corretamente, ele é considerado seguro. Porém, no ambiente afetado havia permissões excessivas associadas aos pipelines.
Com o acesso ao GITHUB_TOKEN, os invasores conseguiram iniciar workflows que possuíam autorização para assumir papéis privilegiados dentro da AWS.
Isso abriu caminho para uma escalada de privilégios baseada em OIDC.
O processo ocorreu em poucos passos:
• execução de pipelines comprometidos
• obtenção de credenciais temporárias da AWS
• uso dessas credenciais para assumir papéis com permissões ampliadas
Depois de obter acesso a um IAM Role privilegiado, os atacantes passaram a explorar os recursos da conta.
Logs de segurança indicam que o acesso inicial evoluiu rapidamente para controle administrativo completo.
Todo esse processo levou menos de 72 horas.
Esse tipo de escalada demonstra como integrações entre ferramentas de desenvolvimento e infraestrutura de nuvem podem amplificar o impacto de um ataque à cadeia de suprimentos.
Movimentação lateral e destruição de dados
Com acesso administrativo à conta da AWS, os invasores iniciaram a fase final do ataque: movimentação lateral e exfiltração de dados.
Entre as atividades identificadas estavam:
• listagem e acesso a buckets S3
• download de artefatos de build
• coleta de snapshots e backups
• alteração de políticas de acesso
Parte dos dados foi exfiltrada antes de qualquer tentativa de sabotagem.
Depois disso, os atacantes iniciaram ações destinadas a dificultar a resposta ao incidente.
Entre elas:
• renomeação de repositórios internos
• alteração de configurações de pipelines
• remoção de históricos de build
• modificação de metadados de projetos
Esse tipo de comportamento é comum em ataques avançados, pois cria confusão operacional dentro das equipes responsáveis pela resposta ao incidente.
Enquanto as equipes tentam reconstruir o que aconteceu, os invasores já concluíram a extração dos dados mais valiosos.
Lições aprendidas e como proteger seu ambiente DevSecOps
O incidente envolvendo o grupo UNC6426 revela fragilidades importantes na forma como muitas organizações gerenciam dependências e integrações entre plataformas de desenvolvimento e infraestrutura de nuvem.
A primeira medida essencial é aplicar o princípio do privilégio mínimo.
Pipelines de CI/CD não devem possuir permissões administrativas diretas dentro da AWS. Em vez disso, devem utilizar papéis extremamente restritos e temporários.
Outra prática fundamental é o controle rigoroso de dependências externas.
Pacotes instalados a partir do npm devem passar por verificações adicionais, como:
• scanners de segurança de dependências
• verificação de integridade de pacotes
• ambientes de build isolados
Também é importante monitorar continuamente a atividade de pipelines.
Ferramentas de segurança modernas podem detectar:
• execuções anômalas de scripts
• alterações inesperadas em dependências
• uso incomum de credenciais e tokens
Com o surgimento de malwares assistidos por IA, a detecção baseada em comportamento se torna cada vez mais importante.
Esse tipo de monitoramento permite identificar padrões suspeitos, como varreduras inteligentes de arquivos sensíveis ou acessos incomuns a variáveis de ambiente.
Outro ponto crítico é a configuração correta do OIDC.
Políticas de confiança devem restringir:
• quais repositórios podem assumir papéis na AWS
• quais branches podem executar workflows privilegiados
• quais pipelines têm autorização para acessar recursos críticos
Sem essas restrições, qualquer pipeline comprometido pode se transformar em uma porta de entrada para toda a infraestrutura.
Conclusão
O ataque conduzido pelo grupo UNC6426 mostra como cadeias de suprimentos de software se tornaram um dos alvos mais estratégicos da cibersegurança moderna.
Um simples token do npm comprometido foi suficiente para iniciar uma invasão que terminou com o controle completo de um ambiente na Amazon Web Services em apenas três dias.
A presença de ferramentas como o QUIETVAULT, capazes de usar inteligência artificial para localizar credenciais, indica que os ataques estão se tornando mais sofisticados e automatizados.
Para equipes de desenvolvimento e segurança, a lição é clara: proteger dependências, limitar privilégios e monitorar pipelines deixou de ser apenas uma boa prática. Hoje, essas medidas são essenciais para evitar que um pequeno ponto de falha se transforme em um comprometimento total da infraestrutura.
