Kubernetes

Grupo TeamPCP compromete pacote Python litellm com malware

O grupo de ameaças TeamPCP comprometeu o pacote Python litellm, publicando versões maliciosas (1.82.7 e 1.82.8) que contêm um coletor de credenciais, um kit de ferramentas para movimentação lateral no Kubernetes e um backdoor persistente. As versões comprometidas foram removidas do PyPI após a descoberta por empresas de segurança como Endor Labs e JFrog. O ataque é descrito como uma operação em três etapas, começando com a coleta de chaves SSH, credenciais de nuvem e segredos do Kubernetes. O código malicioso é executado automaticamente quando o pacote é importado, e a versão 1.82.8 introduz um vetor mais agressivo que permite a execução em segundo plano. Os dados coletados são enviados para um domínio de comando e controle. A campanha do TeamPCP é uma escalada deliberada de ataques à cadeia de suprimentos, afetando várias ecossistemas, incluindo GitHub Actions e Docker Hub. Especialistas alertam que a situação pode se agravar, com o grupo se comprometendo a continuar suas atividades maliciosas. Usuários são aconselhados a auditar ambientes, isolar hosts afetados e reverter para versões limpas do pacote.

Grupo de hackers TeamPCP ataca clusters Kubernetes com script destrutivo

O grupo de hackers TeamPCP está direcionando ataques a clusters Kubernetes com um script malicioso que apaga todos os dados de máquinas configuradas para o Irã. Este grupo é responsável por um recente ataque à cadeia de suprimentos no scanner de vulnerabilidades Trivy e por uma campanha baseada em NPM chamada ‘CanisterWorm’, que começou em 20 de março. A nova campanha utiliza o mesmo código de comando e controle (C2) e o mesmo caminho de instalação do backdoor que foram observados nos incidentes anteriores do CanisterWorm, mas com uma diferença significativa: um payload destrutivo que visa especificamente sistemas iranianos. O malware é projetado para destruir qualquer máquina que corresponda ao fuso horário e à localidade do Irã, independentemente da presença do Kubernetes. Em sistemas identificados como iranianos, o script apaga todos os diretórios principais do sistema, enquanto em outros locais, ele instala um backdoor. A Aikido, empresa de segurança de aplicações, destaca que a nova versão do malware também utiliza propagação via SSH, buscando credenciais válidas em logs de autenticação. Os pesquisadores identificaram indicadores de atividade maliciosa, como conexões SSH de saída com configurações específicas e conexões ao Docker API. Este cenário representa uma ameaça significativa, especialmente para organizações que operam em ambientes Kubernetes.

Ataque à cadeia de suprimentos compromete versões do Trivy no Docker Hub

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.

Grupo norte-coreano UNC4899 compromete organização de criptomoedas

O grupo de ameaças conhecido como UNC4899, vinculado ao governo da Coreia do Norte, está associado a uma sofisticada campanha de comprometimento em nuvem que visou uma organização de criptomoedas em 2025, resultando no roubo de milhões de dólares em ativos digitais. O ataque começou com engenharia social, onde um desenvolvedor foi enganado a baixar um arquivo malicioso que, ao ser transferido para seu dispositivo corporativo, permitiu que os invasores acessassem o ambiente de nuvem da empresa. Utilizando técnicas de Living-off-the-Cloud (LotC), os atacantes exploraram fluxos de trabalho legítimos de DevOps para coletar credenciais e manipular bancos de dados SQL na nuvem. Através de uma série de etapas, incluindo a modificação de políticas de autenticação multifatorial e a injeção de comandos em recursos do Kubernetes, o grupo conseguiu escalar privilégios e acessar informações sensíveis, culminando em saques significativos de criptomoedas. Este incidente destaca os riscos críticos associados ao uso de métodos de transferência de dados pessoais para corporativos e à gestão inadequada de segredos em ambientes de nuvem. Especialistas recomendam que as organizações adotem estratégias de defesa em profundidade e implementem controles rigorosos para mitigar tais ameaças.

Campanha massiva ataca ambientes nativos de nuvem com infraestrutura maliciosa

Pesquisadores em cibersegurança alertaram sobre uma campanha massiva que tem como alvo ambientes nativos de nuvem, estabelecendo infraestrutura maliciosa para exploração subsequente. Observada em 25 de dezembro de 2025, a atividade, descrita como ‘dirigida por worms’, explorou APIs Docker expostas, clusters Kubernetes, painéis Ray e servidores Redis, além da vulnerabilidade React2Shell (CVE-2025-55182, pontuação CVSS: 10.0). A campanha foi atribuída ao grupo de ameaças conhecido como TeamPCP, ativo desde pelo menos novembro de 2025. O objetivo da operação é construir uma infraestrutura de proxy distribuído e escalável, comprometendo servidores para exfiltração de dados, implantação de ransomware e mineração de criptomoedas. O TeamPCP utiliza técnicas de ataque já conhecidas, aproveitando vulnerabilidades e configurações inadequadas para criar um ecossistema criminoso autossustentável. A exploração bem-sucedida permite a implantação de cargas úteis adicionais, como scripts em shell e Python, que buscam novos alvos. Os ataques são principalmente direcionados a ambientes da Amazon Web Services (AWS) e Microsoft Azure, afetando organizações que operam essa infraestrutura, tornando-as vítimas colaterais. A campanha PCPcat exemplifica um ciclo completo de exploração e monetização, destacando a necessidade de vigilância e mitigação em ambientes de nuvem.

A segurança na nuvem está mudando como proteger sua infraestrutura

A segurança na nuvem enfrenta novos desafios, com atacantes explorando vulnerabilidades em configurações, identidades e códigos, em vez de realizar ataques diretos. Ferramentas de segurança convencionais frequentemente falham em detectar essas ameaças, que se disfarçam como atividades normais. O time Cortex Cloud da Palo Alto Networks realizará um webinar técnico para discutir três vetores de ataque que estão contornando a segurança tradicional: erros de configuração de identidade na AWS, ocultação de arquivos maliciosos em modelos de IA e permissões excessivas em Kubernetes. Durante a sessão, especialistas mostrarão como esses ataques são realizados e como as equipes podem melhorar a visibilidade e a detecção de ameaças. O evento promete fornecer insights práticos sobre como auditar logs de nuvem, corrigir permissões arriscadas e aplicar controles voltados para IA, ajudando as organizações a se protegerem antes que vulnerabilidades sejam exploradas. A participação é essencial para fechar as lacunas de segurança e evitar surpresas desagradáveis em relatórios de violação.

Vulnerabilidade no runc Permite Bypass de Isolamento de Contêineres

Três vulnerabilidades críticas no runc, o runtime de contêineres que suporta Docker e Kubernetes, foram divulgadas por um pesquisador da SUSE em 5 de novembro de 2025. As falhas, identificadas como CVE-2025-31133, CVE-2025-52565 e CVE-2025-52881, permitem que atacantes contornem o isolamento de contêineres e obtenham acesso root aos sistemas host. Essas vulnerabilidades afetam versões conhecidas do runc e exploram fraquezas nas operações de montagem e nas proteções de arquivos durante a criação de contêineres. Os atacantes podem usar condições de corrida e manipulação de links simbólicos para contornar restrições de segurança, permitindo a escrita em arquivos críticos do sistema, o que pode levar a uma fuga de contêineres. É crucial que organizações que utilizam Docker, Kubernetes ou serviços que dependem do runc atualizem imediatamente para versões corrigidas (1.2.8, 1.3.3 ou 1.4.0-rc.3 e posteriores) para evitar compromissos de segurança. Além disso, recomenda-se a auditoria de ambientes implantados e a implementação de políticas rigorosas de escaneamento de imagens para detectar Dockerfiles maliciosos.

Novo rootkit LinkPro compromete infraestrutura da AWS

Uma investigação sobre a violação de uma infraestrutura hospedada na Amazon Web Services (AWS) revelou um novo rootkit para GNU/Linux, denominado LinkPro, conforme relatado pela empresa de cibersegurança Synacktiv. O ataque começou com a exploração de um servidor Jenkins exposto, vulnerável à CVE-2024–23897, que permitiu a implantação de uma imagem Docker maliciosa chamada ‘kvlnt/vv’ em vários clusters Kubernetes. Essa imagem continha um sistema baseado em Kali Linux e arquivos que permitiam a instalação de um servidor VPN e um downloader que se comunicava com um servidor de comando e controle (C2).

Falhas no SUSE Rancher permitem bloqueio de contas administrativas

Uma vulnerabilidade crítica foi identificada no SUSE Rancher Manager, permitindo que atacantes bloqueiem contas administrativas por meio de manipulação de nomes de usuário. Essa falha, resultante de uma validação inadequada no sistema de gerenciamento de usuários, possibilita que usuários mal-intencionados com permissões de atualização alterem nomes de usuários, impedindo o acesso de administradores legítimos. Existem dois vetores principais de ataque: a tomada de conta, onde um usuário pode alterar o nome de outro para ‘admin’, e o bloqueio direto de contas administrativas. A exploração dessa vulnerabilidade pode causar interrupções significativas nas operações de gerenciamento de plataformas, deixando sistemas críticos sem supervisão adequada. A SUSE já disponibilizou correções nas versões v2.12.2, v2.11.6, v2.10.10 e v2.9.12, que implementam validações para impedir a modificação de nomes de usuário após a atribuição inicial. Para organizações que não podem atualizar imediatamente, recomenda-se a implementação de controles de acesso rigorosos. A auditoria regular de permissões e o monitoramento de alterações não autorizadas são essenciais para detectar tentativas de exploração antes que causem danos operacionais.

Vulnerabilidade no Cliente C do Kubernetes Expõe Comunicações a Ataques MiTM

Uma vulnerabilidade de alta severidade foi descoberta na biblioteca cliente C# do Kubernetes, comprometendo a integridade das comunicações com o servidor API e abrindo espaço para ataques do tipo man-in-the-middle (MiTM). Identificada como CVE-2025-9708, a falha resulta de uma validação inadequada de certificados no modo de Autoridade Certificadora (CA) personalizada. O cliente aceita qualquer certificado assinado pela CA fornecida, sem verificar a cadeia de confiança completa. Isso permite que atacantes apresentem certificados falsificados e interceptem ou manipulem o tráfego sensível do plano de controle. A vulnerabilidade afeta todas as versões do cliente C# do Kubernetes até a versão 17.0.13, especialmente em ambientes que utilizam certificados CA personalizados. Embora a falha tenha um escore CVSS de 6.8, indicando uma severidade média, ela representa um risco significativo em ambientes de desenvolvimento e produção. O projeto Kubernetes já lançou uma correção na versão 17.0.14, e recomenda-se que os usuários atualizem imediatamente. Enquanto isso, uma solução temporária é mover os certificados CA personalizados para o armazenamento de confiança do sistema, embora isso amplie a confiança para todos os processos no host. As equipes devem auditar arquivos kubeconfig e monitorar logs para detectar possíveis explorações.

Vulnerabilidades críticas no Chaos Mesh podem comprometer Kubernetes

Pesquisadores de cibersegurança revelaram múltiplas vulnerabilidades críticas no Chaos Mesh, uma plataforma de Engenharia de Caos de código aberto, que podem permitir a tomada de controle de clusters em ambientes Kubernetes. As falhas, coletivamente chamadas de ‘Chaotic Deputy’, incluem a exposição de um servidor de depuração GraphQL sem autenticação, permitindo que atacantes executem comandos arbitrários e causem negação de serviço em todo o cluster. Além disso, três mutações no Chaos Controller Manager são vulneráveis a injeção de comandos do sistema operacional, com pontuações CVSS de até 9.8, indicando um alto nível de severidade. Um atacante com acesso à rede do cluster pode explorar essas vulnerabilidades para executar código remotamente e potencialmente roubar dados sensíveis ou interromper serviços críticos. Após a divulgação responsável em maio de 2025, a equipe do Chaos Mesh lançou uma atualização em agosto para corrigir as falhas. Os usuários são fortemente aconselhados a atualizar suas instalações imediatamente ou restringir o tráfego de rede para o daemon e servidor API do Chaos Mesh.

Transformação da Segurança em Aplicações Nativas da Nuvem

O cenário de segurança para aplicações nativas da nuvem está passando por uma transformação significativa, impulsionada pela adoção crescente de tecnologias como containers, Kubernetes e serverless. Embora essas inovações acelerem a entrega de software, também ampliam a superfície de ataque, tornando os modelos de segurança tradicionais inadequados. Em 2025, a visibilidade em tempo de execução (runtime visibility) se destaca como uma capacidade essencial para as plataformas de proteção de aplicações nativas da nuvem (CNAPPs). Essa abordagem permite que as equipes de segurança identifiquem e priorizem ameaças reais, evitando a armadilha de falsos positivos. A integração da inteligência artificial (IA) nesse contexto também se mostra promissora, ajudando a correlacionar sinais de diferentes domínios e a acelerar a resposta a incidentes. Além disso, a responsabilidade compartilhada entre equipes de segurança e desenvolvimento é crucial para garantir que as vulnerabilidades sejam tratadas de forma eficaz. A consolidação de ferramentas em uma única plataforma CNAPP é vista como inevitável para reduzir a fragmentação e melhorar a visibilidade do risco na nuvem. À medida que o uso de containers cresce, a segurança em tempo real, a assistência impulsionada por IA e plataformas unificadas se tornam essenciais para proteger as aplicações de forma eficaz.

Exploração de DNS do Kubernetes permite roubo de credenciais do Git

Um novo ataque cibernético descoberto permite que usuários autenticados do ArgoCD, uma ferramenta popular de entrega contínua para Kubernetes, roubem credenciais do GitHub. O ataque explora a resolução de DNS do Kubernetes, enganando o servidor de repositório do ArgoCD a se conectar a um serviço controlado pelo atacante em vez do verdadeiro GitHub. Ao implantar um serviço malicioso, o atacante cria um registro DNS que redireciona o domínio github.com para um IP interno do cluster. Quando o ArgoCD busca manifestos via HTTPS, o atacante utiliza um certificado personalizado para inspecionar o cabeçalho de autorização e exfiltrar credenciais, incluindo tokens de autenticação e JWTs do GitHub. Para que o ataque seja bem-sucedido, a conta do ArgoCD comprometida deve ter permissões adequadas. O artigo também sugere medidas de mitigação, como aplicar princípios de menor privilégio e monitorar o tráfego interno. Essa vulnerabilidade é uma preocupação crescente, especialmente em um cenário onde a exfiltração de informações é um tema recorrente na cibersegurança.

Falha crítica na API do Argo CD expõe credenciais de repositórios

Uma vulnerabilidade crítica foi identificada na plataforma Argo CD, amplamente utilizada para entrega contínua em ambientes Kubernetes. Essa falha permite que tokens de API com permissões básicas de projeto acessem credenciais sensíveis de repositórios, incluindo nomes de usuário e senhas. A vulnerabilidade, designada como GHSA-786q-9hcg-v9ff, foi revelada pelo pesquisador de segurança Michael Crenshaw e afeta todas as versões do Argo CD a partir da 2.2.0-rc1.

O problema ocorre no endpoint da API de detalhes do projeto (/api/v1/projects/{project}/detailed), onde tokens com permissões padrão podem recuperar credenciais sem a necessidade de acesso explícito a segredos. Isso representa uma séria escalada de privilégios, pois tokens destinados a operações rotineiras de aplicação obtêm acesso não autorizado a dados de autenticação sensíveis. A falha não se limita apenas a permissões de nível de projeto, mas também se estende a qualquer token com permissões de obtenção de projeto, aumentando o impacto potencial em implementações empresariais do Argo CD.

Vulnerabilidade no SUSE Fleet expõe dados sensíveis sem criptografia

Uma vulnerabilidade crítica foi identificada no sistema de gerenciamento Fleet da SUSE, que expõe dados sensíveis de configuração do Helm devido ao armazenamento não criptografado. O problema está relacionado ao manuseio de informações sensíveis através de recursos BundleDeployment, que são armazenados em formato de texto simples, permitindo que qualquer usuário com permissões de GET ou LIST acesse valores do Helm que contêm credenciais, chaves de API e senhas. Diferente do Helm v3, que utiliza segredos do Kubernetes para proteger esses dados, a implementação do Fleet não adota essas salvaguardas, deixando os valores vulneráveis tanto no nível de armazenamento quanto nas respostas da API. A SUSE já lançou patches que alteram fundamentalmente a forma como o Fleet lida com dados sensíveis, introduzindo capacidades de armazenamento de segredos dedicadas para cada recurso Bundle e BundleDeployment, garantindo criptografia e controles de acesso adequados. Organizações são aconselhadas a revisar suas implementações do Fleet e a implementar políticas de controle de acesso para mitigar os riscos enquanto os patches são aplicados.