Trivy

A Cisco foi alvo de um ataque cibernético que resultou no roubo de código-fonte de seus produtos e de clientes, após a exploração de credenciais roubadas em um ataque à cadeia de suprimentos do Trivy. Os atacantes utilizaram um plugin malicioso do GitHub Action, comprometendo o ambiente de desenvolvimento interno da empresa. A violação afetou diversas estações de trabalho e sistemas de desenvolvimento, levando à clonagem de mais de 300 repositórios do GitHub, incluindo códigos de produtos de inteligência artificial. Embora a Cisco tenha contido a violação e isolado os sistemas afetados, a empresa está se preparando para as consequências de ataques subsequentes relacionados ao LiteLLM e Checkmarx. Além disso, chaves da AWS foram roubadas e utilizadas para atividades não autorizadas em algumas contas da Cisco. O ataque está vinculado ao grupo de ameaças TeamPCP, que já havia realizado ataques semelhantes em plataformas de desenvolvimento de código. A Cisco ainda não respondeu a solicitações de comentários sobre o incidente.

Pesquisadores de cibersegurança descobriram artefatos maliciosos distribuídos via Docker Hub após um ataque à cadeia de suprimentos do Trivy, um popular scanner de vulnerabilidades de código aberto mantido pela Aqua Security. As versões comprometidas 0.69.4, 0.69.5 e 0.69.6 foram removidas do repositório, sendo que a última versão limpa conhecida é a 0.69.3. O ataque permitiu que os invasores utilizassem credenciais comprometidas para inserir um ladrão de credenciais em versões trojanizadas do Trivy e em duas ações do GitHub relacionadas. Além disso, os atacantes conseguiram comprometer pacotes npm, distribuindo um worm autossustentável chamado CanisterWorm. O grupo responsável, identificado como TeamPCP, também defaceou repositórios internos da Aqua Security no GitHub, expondo-os publicamente. A análise forense sugere que um token de conta de serviço comprometido foi o vetor do ataque. A crescente sofisticação dos atacantes é evidenciada pela introdução de um novo malware que apaga clusters Kubernetes, especialmente em sistemas iranianos. Diante da gravidade do incidente, é crucial que as organizações revisem o uso do Trivy em seus pipelines de CI/CD e evitem as versões afetadas.

O scanner de vulnerabilidades Trivy, amplamente utilizado por desenvolvedores e equipes de segurança, foi alvo de um ataque supply-chain realizado pelo grupo de ameaças conhecido como TeamPCP. O ataque resultou na distribuição de malware que rouba credenciais através de versões oficiais e ações do GitHub. A vulnerabilidade foi inicialmente divulgada pelo pesquisador de segurança Paul McCarty, que alertou sobre a versão 0.69.4 do Trivy, que havia sido comprometida. Análises posteriores revelaram que quase todas as tags do repositório trivy-action no GitHub foram afetadas, permitindo que o código malicioso fosse executado automaticamente em fluxos de trabalho externos. Os atacantes conseguiram comprometer o processo de construção do GitHub, substituindo scripts legítimos por versões maliciosas. O malware coletou dados sensíveis, incluindo chaves SSH, credenciais de nuvem e arquivos de configuração, armazenando-os em um arquivo que era enviado para um servidor de comando e controle. O ataque, que durou cerca de 12 horas, expôs a necessidade urgente de as organizações que utilizaram as versões afetadas tratarem seus ambientes como totalmente comprometidos, rotacionando todas as credenciais e analisando sistemas para possíveis compromissos.

Um ataque à cadeia de suprimentos visando o popular scanner Trivy resultou na infecção de diversos pacotes npm por um novo malware chamado CanisterWorm. Este worm se propaga automaticamente e utiliza um canister da Internet Computer blockchain como ponto de controle. O ataque foi atribuído ao grupo criminoso TeamPCP, que publicou versões maliciosas do Trivy contendo um ladrão de credenciais. A infecção ocorre através de um hook postinstall que executa um loader, instalando um backdoor em Python que se conecta ao canister para buscar novos payloads. O malware é projetado para ser resiliente, utilizando um serviço systemd que reinicia automaticamente o backdoor. Além disso, uma nova variante do CanisterWorm foi identificada, que se propaga sem intervenção manual, coletando tokens npm do ambiente do desenvolvedor. A situação é crítica, pois cada desenvolvedor que instala pacotes infectados pode se tornar um vetor de propagação, ampliando o alcance do ataque. Este incidente destaca a vulnerabilidade dos sistemas de gerenciamento de pacotes e a necessidade urgente de medidas de segurança mais robustas.