Ataque ao Trivy: Como uma invasão ao scanner de vulnerabilidades causou um efeito dominó
Uma série de ataques em cascata na cadeia de suprimentos, começando com a invasão do scanner de vulnerabilidades Trivy e da Aqua Security. Atingiu npm, PyPI, Checkmarx, Telnyx e dezenas de milhares de pipelines CI/CD em todo o mundo. O ataque explorou uma configuração perigosa em um dos fluxos de trabalho do projeto, resultando em um efeito dominó.
MundiX News·13 de maio de 2026·15 min de leitura·👁 6 views
Ataque ao Trivy: Como uma invasão ao scanner de vulnerabilidades causou um efeito dominó
Em março de 2026, o grupo de hackers TeamPCP lançou uma série de ataques em cascata na cadeia de suprimentos. Tudo começou com a comprometimento do scanner de vulnerabilidades Trivy e da empresa Aqua Security, e então o ataque atingiu npm, PyPI, Checkmarx, Telnyx e dezenas de milhares de pipelines CI/CD em todo o mundo. Entre os afetados estavam Cisco, Comissão Europeia, a startup de IA Mercor e centenas de outras organizações. De acordo com a empresa Mandiant, o número total de SaaS comprometidos ultrapassou 1.000 e continua a crescer.
O mais desagradável desta história não foi nem a escala dos ataques, mas o fato de que a base de tudo não era uma vulnerabilidade zero-day, mas a invasão de uma única conta. Isso foi suficiente para provocar um verdadeiro efeito dominó.
O que é Trivy
Trivy é um conhecido scanner de vulnerabilidades de código aberto desenvolvido pela Aqua Security. A ferramenta ajuda a identificar problemas de segurança e segredos codificados em contêineres, clusters Kubernetes, repositórios e infraestrutura de nuvem. O projeto tem mais de 33 mil estrelas no GitHub, e as GitHub Actions associadas são usadas em dezenas de milhares de fluxos de trabalho CI/CD em todo o mundo. O paradoxo da situação é que Trivy é uma ferramenta de segurança. É ele que as organizações executam para garantir que não haja malware e vazamentos de segredos em suas compilações. Portanto, a confiança nele é alta, e ele recebe as permissões apropriadas. Para os hackers, comprometer essa ferramenta é muito mais lucrativo do que uma dependência comum.
Prelúdio de fevereiro
Esta história começou em fevereiro de 2026. Naquela época, um bot autônomo hackerbot-claw, registrado no GitHub uma semana antes do início dos ataques, abriu um pull request para o repositório Trivy. O PR explorou uma configuração perigosa pull_request_target em um dos fluxos de trabalho do projeto - um padrão em que o GitHub Actions executa código de um fork, mas o faz com os direitos e segredos do repositório principal. Curiosamente, em novembro de 2025 (três meses antes da exploração do hackerbot-claw), essa configuração perigosa foi descoberta e marcada por um analisador automático, mas os desenvolvedores da Aqua Security ignoraram o aviso. Não se sabe se o hackerbot-claw foi controlado pelo grupo TeamPCP ou se foi uma entidade separada, cujo acesso os hackers usaram posteriormente. De qualquer forma, através dessa brecha, os invasores despejaram da memória do processo o Personal Access Token (PAT) da conta de serviço aqua-bot - esse token tinha direitos de repo para toda a organização aquasecurity. Depois disso, os criminosos excluíram todas as 178 versões do Trivy (de 0.27.0 a 0.69.1), tornaram o repositório privado por um curto período e publicaram uma extensão maliciosa Aqua Trivy para VS Code no OpenVSX.
Especialistas da Aqua Security notaram rapidamente o incidente, relataram-no publicamente em 1º de março e alteraram os tokens comprometidos. No entanto, como se viu mais tarde, parte dos artefatos (chaves de API, certificados, senhas) permaneceu acessível aos invasores. Isso foi suficiente para que, 20 dias depois, os hackers voltassem.
19 de março: o segundo ataque ao Trivy
Em 19 de março de 2026, quando grande parte da comunidade de segurança da informação estava deixando o BSidesSF e se preparando para a RSA Conference, os membros da TeamPCP iniciaram a fase principal de sua operação. Usando as credenciais roubadas em fevereiro, os invasores publicaram a tag maliciosa 0.69.4 no repositório principal do Trivy através da conta de serviço aqua-bot e iniciaram o pipeline de lançamento automático. Paralelamente, eles executaram um force push de 75 das 76 tags no repositório aquasecurity/trivy-action e substituíram todas as sete tags em aquasecurity/setup-trivy. Como resultado, as tags não apontavam mais para commits legítimos, mas para maliciosos. Entre os comprometidos estavam as versões @0.34.2, @0.33 e @0.18.0, e a única não afetada foi @0.35.0. Os invasores não criaram um novo commit ou criaram um lançamento - isso seria refletido no histórico e provocaria o aparecimento de notificações para os mantenedores. Em vez disso, os hackers redirecionaram as tags existentes para commits maliciosos, clonando cuidadosamente os metadados dos originais: nome do autor, e-mail, carimbos de data/hora e até mesmo o texto da mensagem com o número do PR. Qualquer fluxo de trabalho que se referisse a essa tag puxaria automaticamente o código malicioso. Os rastros que, no final, ajudaram a desvendar esse ataque foram descobertos apenas por meio de análise retrospectiva. O force push de tags, em princípio, não gera eventos CreateEvent ou DeleteEvent na API pública do GitHub, ou seja, para sistemas de monitoramento baseados nesses eventos, o ataque foi invisível. Os commits falsos não foram assinados com GPG, enquanto os originais foram. As falsificações afetaram apenas entrypoint.sh, enquanto as originais afetaram vários arquivos. Os commits pai datam de março de 2026, enquanto os próprios commits fingiam ser lançamentos de 2021-2022. Paralelamente às tags, a TeamPCP publicou binários infectados do Trivy v0.69.4 via GitHub Releases, Docker Hub, GHCR, AWS ECR e repositórios DEB e RPM. A versão maliciosa esteve disponível por cerca de três horas, e as tags infectadas do GitHub Actions permaneceram ativas por cerca de doze horas.
TeamPCP Cloud Stealer
O malware que a TeamPCP implantou no Trivy foi chamado de TeamPCP Cloud Stealer. Em GitHub-runners, o malware elevou os privilégios para o nível root via passwordless sudo, encontrou os processos Runner.Worker e escaneou suas regiões de memória /proc/pid/mem em busca de strings JSON com segredos que o GitHub Actions usa para mascarar dados confidenciais nos logs. Além disso, o stealer coletou variáveis de ambiente e procurou credenciais no sistema de arquivos: chaves SSH, configurações AWS, GCP, Azure, Kubernetes, Docker, arquivos .env, senhas de banco de dados, tokens Slack e Discord, chaves TLS, configurações VPN e dados de carteiras de criptomoedas. Tudo o que foi coletado foi criptografado com AES-256-CBC com uma chave gerada aleatoriamente, e a própria chave foi codificada com uma chave pública RSA-4096. O arquivo resultante com o nome tpcp.tar.gz foi enviado por uma solicitação POST para o domínio de typosquatting scan.aquasecurtiy[.]org (observe - as letras na palavra security foram trocadas). Se a exfiltração falhasse, o malware usaria um canal de backup: criaria um repositório público tpcp-docs na conta do GitHub da vítima e carregaria os dados roubados lá como um release asset. Nas máquinas dos desenvolvedores (o malware as determinava pela ausência da variável GITHUB_ACTIONS=true), o comportamento mudava. O malware não apenas coletava segredos, mas também instalava um backdoor Python no host no caminho ~/.config/systemd/user/sysmon.py, que era registrado como um serviço systemd e periodicamente consultava o servidor de controle para novas cargas úteis. Se houvesse um cluster Kubernetes, o malware formava a configuração de um pod privilegiado com securityContext.privileged=true, montava o sistema de arquivos raiz do nó via hostPath e, assim, ia além dos limites do contêiner para o nível do host. De acordo com o "Laboratório Kaspersky", foi essa combinação com o Kubernetes que tornou o malware particularmente perigoso: ele não se limitou a roubar arquivos e tentou obter segredos de tempo de execução que a AWS emite para contêineres via Instance Metadata Service no endereço 169.254.169.254 e Amazon ECS via 169.254.170.2. Ou seja, a TeamPCP estava caçando não apenas segredos estáticos, mas também tokens IAM temporários que, no momento da infecção, abriam acesso direto aos recursos da AWS. No final, o mantenedor do Trivy, Itay Shakury, confirmou o comprometimento e associou o incidente ao ataque de fevereiro. Ele escreveu: Se você suspeitar que usou uma versão comprometida, considere que todos os segredos do seu pipeline foram comprometidos e altere-os imediatamente. O incidente recebeu o identificador CVE-2026-33634 com uma pontuação de 9,4 na escala CVSS.
22 de março: ataque à organização interna da Aqua Security
Três dias após o ataque principal, descobriu-se que a rotação incompleta de segredos trouxe outra surpresa desagradável. Em 22 de março, imagens maliciosas do Trivy versões 0.69.5 e 0.69.6 apareceram no Docker Hub - sem os lançamentos correspondentes no GitHub. Ambos continham o mesmo TeamPCP Cloud Stealer. A última versão "limpa" desde então é considerada 0.69.3. No mesmo dia, o grupo TeamPCP chegou à organização aquasec-com do GitHub, onde a Aqua Security armazena código proprietário: código-fonte do Tracee, forks internos do Trivy, pipelines CI/CD, operadores Kubernetes e bases de conhecimento internas. De acordo com pesquisadores do OpenSourceMalware, o ponto de entrada foi a conta de serviço Argon-DevOps-Mgt - um bot com direitos de administrador simultaneamente na organização pública aquasecurity e na aquasec-com interna. Ele foi autorizado via PAT, e não via GitHub App, e seu token estava no CI-runner do Trivy, onde o stealer o encontrou. Primeiro, os invasores realizaram um teste: criaram e excluíram imediatamente um branch de teste update-plugin-links-v0.218.2 no repositório aquasecurity/trivy-plugin-aqua. Não havia nenhum lançamento com esse nome, nenhum fluxo de trabalho foi iniciado - este foi um teste do token roubado. Sete horas depois, o grupo renomeou automaticamente todos os 44 repositórios em aquasec-com, adicionando o prefixo tpcp-docs- aos nomes e alterando as descrições para TeamPCP Owns Aqua Security. Toda a operação levou menos de dois minutos.
Efeito dominó: npm, LiteLLM, Checkmarx
Paralelamente ao deface da Aqua Security, o grupo TeamPCP passou para a fase em cascata dos ataques, onde cada link subsequente da cadeia foi alimentado por segredos roubados na etapa anterior. Primeiro, o ecossistema npm foi afetado. Os tokens de publicação dos mantenedores, cujos pipelines incluíam a execução do scanner, vazaram dos CI-runners do Trivy. Com base nesses tokens, a TeamPCP lançou o CanisterWorm, um verme de autorreplicação que publicava automaticamente atualizações maliciosas em todos os pacotes aos quais o token tinha acesso. O CanisterWorm merece uma menção separada. Em vez de um servidor de controle comum, o verme usa um canister na rede Internet Computer Protocol, o que torna a infraestrutura resistente ao bloqueio: para remover um canister, é necessária uma votação dos membros da rede. Para mascaramento, o verme se instala no sistema como pgmon.service, fingindo ser um serviço de monitoramento PostgreSQL, e periodicamente consulta o nó ICP em busca de novas cargas úteis. Ele também tinha um "interruptor" que reagia à string youtube.com no URL recebido - caso os operadores precisassem desligar a botnet com urgência. A próxima vítima do comprometimento foi o pacote PyPI LiteLLM - uma biblioteca popular que fornece um gateway para vários provedores de LLM. LiteLLM tem mais de 90 milhões de downloads por mês, e seus usuários incluem empresas que precisam de uma única API para OpenAI, Anthropic, AWS Bedrock e Google Vertex AI ao mesmo tempo. Infelizmente, o pipeline CI da BerriAI (a empresa que desenvolve o LiteLLM) executou o Trivy como uma etapa de compilação e, ao mesmo tempo, não fixou uma versão específica da ferramenta. Como resultado, o stealer despejou o token PYPI_PUBLISH e o GitHub PAT do cofundador do projeto, Krrish Dholakia. Em 24 de março, a TeamPCP publicou versões maliciosas do LiteLLM no PyPI - 1.82.7 e 1.82.8. Não houve commits ou tags correspondentes no repositório Git do projeto: os pacotes foram montados localmente e, usando as credenciais legítimas do mantenedor, carregados no GitHub, contornando o pipeline de lançamento padrão. Assim, os hackers conseguiram contornar as verificações de integridade, incluindo a verificação de hashes no pip: o código malicioso foi corretamente escrito nos metadados do pacote com os hashes corretos e o hash correspondia. A assinatura era válida, mas o conteúdo não. Na versão 1.82.7, o stealer foi embutido no arquivo proxy_server.py na linha 128, inserindo-o cuidadosamente entre dois blocos de código legítimos, e ele foi acionado na importação litellm.proxy. Especialistas da Endor Labs descobriram três iterações de payload nesta versão, o que indicou o desenvolvimento ativo do malware durante o ataque. Na versão 1.82.8, os invasores foram mais longe e adicionaram litellm_init.pth - um tipo especial de arquivo que o módulo Python site executa toda vez que o interpretador é iniciado, sem qualquer importação. Bastava executar qualquer coisa em Python (pip, plug-in IDE, qualquer sub-processo), e o stealer começava a trabalhar. Analistas do "Laboratório Kaspersky" em sua análise notaram um detalhe notável: o payload malicioso foi decodificado do Base64 e executado na memória, e sua saída foi criptografada com AES-256-CBC com uma chave aleatória, que, por sua vez, foi criptografada com uma chave RSA pública. Essa mesma chave RSA foi então descoberta em outras fases da campanha, tornando-se um dos principais indicadores. Paralelamente, especialistas da Sysdig descobriram o mesmo stealer em duas GitHub Actions da empresa de segurança da informação Checkmarx - ast-github-action e kics-github-action. Inicialmente, foi presumido que uma ou duas tags foram afetadas no ast-github-action, mas mais tarde descobriu-se que a TeamPCP reescreveu todas as tags publicadas do repositório (91 tags), fabricando individualmente um commit separado para cada versão. Os dados roubados nesta fase do ataque foram transferidos para o domínio de typosquatting checkmarx[.]zone. Além disso, através da conta Checkmarx comprometida no OpenVSX, os hackers publicaram versões maliciosas das extensões ast-results 2.53.0 e cx-dev-assist 1.7.0. As versões no principal VS Code Marketplace não foram afetadas, e representantes da Checkmarx disseram que não encontraram sinais de vazamento de dados do cliente.
27 de março: Telnyx e esteganografia em arquivos WAV
Em 27 de março, a TeamPCP adicionou o pacote Python Telnyx - o SDK oficial para integração de VoIP, mensagens e serviços de IoT - à lista de vítimas. Duas versões maliciosas (4.87.1 e 4.87.2) apareceram no PyPI, e o código malicioso foi inserido no arquivo client.py para que ele fosse acionado automaticamente na importação do pacote, sem interferir no funcionamento das funções legítimas do SDK. De acordo com a Endor Labs, o token para publicação no PyPI provavelmente vazou como resultado do hack LiteLLM: qualquer desenvolvedor ou pipeline CI que tivesse o LiteLLM instalado e, ao mesmo tempo, tivesse um token PyPI Telnyx no ambiente, poderia dar esse token ao stealer. O mais interessante nesta fase do ataque foi a técnica de entrega do payload final: em vez de hospedar um binário pronto ou um blob codificado, a TeamPCP aplicou esteganografia em arquivos de áudio. No Linux e macOS, o pacote infectado baixou o arquivo ringtone.wav do servidor de controle, extraiu o script-assembler criptografado XOR dos dados de áudio e o executou na memória. Depois disso, o stealer coletou chaves SSH, variáveis de ambiente, tokens de nuvem, dados de carteiras de criptomoedas e segredos de clusters Kubernetes, embalou-os em tpcp.tar.gz e os enviou para o servidor de controle, após o que destruiu todos os rastros. No Windows, o ataque teve uma aparência diferente: o pacote baixou o arquivo hangup.wav, extraiu o arquivo executável dele e o salvou na pasta de inicialização como msbuild.exe. Ou seja, nas máquinas Windows, a TeamPCP se esforçou para se fixar no sistema, ao contrário do Linux e macOS. Curiosamente, a técnica de esteganografia em arquivos WAV foi usada pela TeamPCP antes - por exemplo, no wiper Kamikaze (sobre o qual falaremos mais tarde). Mas se no Kamikaze o payload foi embutido diretamente no áudio na forma de Base64, então para o Telnyx ele foi carregado de um servidor remoto na forma XORed.
Wiper Kamikaze
No âmbito da mesma campanha, a TeamPCP usou um componente que não combina bem com o retrato usual de um grupo financeiramente motivado: um payload destrutivo chamado Kamikaze, direcionado exclusivamente a sistemas iranianos. O wiper foi entregue via CanisterWorm e, às vezes, via instâncias Docker não protegidas. Antes de iniciar, o payload verificou vários indicadores: o fuso horário de Teerã, a localidade iraniana, o sinal fa_IR. Se nada disso fosse descoberto, apenas o backdoor CanisterWorm seria implantado na máquina. Em clusters Kubernetes no fuso horário iraniano, o Kamikaze implantou um DaemonSet privilegiado chamado host-provisioner-iran e um contêiner kamikaze em cada nó, incluindo o plano de controle, após o qual iniciou a limpeza forçada dos sistemas de arquivos e a reinicialização. Em hosts Linux comuns, se o processo fosse executado como root, o comando rm -rf / --no-preserve-root seria executado. Caso contrário, os invasores tentaram elevar os privilégios via passwordless sudo. Charlie Eriksen, da Aikido, que rastreou a evolução do payload em tempo real, contou seis iterações do Kamikaze apenas em 22 de março. As primeiras versões se concentraram em escapar do Kubernetes, e as versões posteriores adicionaram a propagação via SSH, a exploração da API Docker via porta 2375 e a esteganografia em WAV. De acordo com Eriksen, não há confirmação de danos reais dos ataques do wiper, mas a própria combinação de uma campanha financeiramente motivada com malware destrutivo georreferenciado não tem explicação. Os pesquisadores admitem que esta pode ter sido uma operação com objetivos mistos, ou o módulo destrutivo foi encomendado por alguém em paralelo com a campanha principal, ou foi uma tentativa dos hackers de atrair atenção para si mesmos, e o grupo estava intencionalmente aumentando a "visibilidade da mídia".
Cisco, Comissão Europeia, Mercor e outros
Em seguida, a escala do problema começou a aparecer e as primeiras vítimas downstream apareceram. Uma das primeiras vítimas publicamente registradas dessa cascata foi a Cisco. Os invasores usaram as credenciais roubadas durante o comprometimento do Trivy e entraram no ambiente interno de compilação e desenvolvimento da empresa. Como resultado, chaves AWS, que foram então usadas para ações não autorizadas nas contas de nuvem da empresa, vazaram de dezenas de máquinas, incluindo estações de trabalho de desenvolvedores. De acordo com a mídia, os invasores clonaram mais de 300 repositórios do GitHub, incluindo o código-fonte dos produtos de IA da Cisco (incluindo AI Assistants, AI Defense e soluções ainda não lançadas). Pior ainda, parte dos repositórios roubados pode ter pertencido a clientes corporativos da empresa, incluindo bancos, empresas de BPO e agências governamentais americanas. A segunda grande vítima foi a Comissão Europeia. Em 24 de março de 2026, a CE alertou sobre o comprometimento de sua infraestrutura de nuvem, que atende a plataforma Europa.eu, e a responsabilidade pelo ataque foi inicialmente assumida pelo grupo de ransomware ShinyHunters. Como explicaram os especialistas da CERT-EU, o ponto de entrada dos criminosos foi a chave de API da AWS, comprometida em 19 de março durante o ataque ao Trivy. A Comissão Europeia usou uma versão infectada do scanner, sem suspeitar disso: a ferramenta veio pelos canais de atualização regulares. Tendo recebido a chave comprometida, os invasores criaram e anexaram uma nova chave de acesso à conta e começaram a reconhecimento. TruffleHog entrou em ação - uma ferramenta de código aberto para pesquisar segredos e validar credenciais da AWS via Security Token Service. Como resultado, o vazamento afetou os dados de 71 clientes de hospedagem Europa.eu - 42 divisões internas da Comissão Europeia e pelo menos 29 outras estruturas da UE. O volume total de dados roubados em forma não compactada foi de 340 GB, incluindo nomes, endereços de e-mail e logins. Cerca de 2,22 GB (51.992 arquivos) foram para notificações automáticas de falha na entrega, incluindo mensagens com conteúdo original do usuário. Ou seja, eles também podem conter dados pessoais. Outra vítima publicamente confirmada foi a startup de IA Mercor, especializada em recrutamento via IA. Representantes da empresa escreveram nas redes sociais: Recentemente, descobrimos que fomos uma das milhares de empresas afetadas pelo ataque à cadeia de suprimentos LiteLLM. Ao mesmo tempo, o grupo de ransomware Lapsus$ afirmou que roubou 4 TB de dados da startup, incluindo 939 GB de código-fonte, e colocou esse dump à venda. Outra grande vítima desses ataques foi a empresa suíça Sportradar - fornecedora de dados esportivos e análises para a NBA, ESPN, Nike, IMG Arena, Bet365 e FIBA. Em 25 de março, os grupos TeamPCP e o grupo de ransomware Vect realizaram um ataque conjunto contra a Sportradar, usando credenciais comprometidas via Trivy. Como resultado, o vazamento afetou cerca de 26 mil registros de usuários, perfis de 23.169 atletas, oito senhas do banco de dados RDS de produção, bem como 328 pares de chaves de API que conectam a Sportradar a 161 organizações clientes. O dump roubado da empresa foi colocado à venda por US$ 50 mil.
TruffleHog e AWS
Se as primeiras etapas da campanha pareciam um ataque clássico à cadeia de suprimentos, a fase de pós-exploração, que foi estudada por analistas da Wiz, parecia mais uma invasão em grande escala de ambientes de nuvem. De acordo com os pesquisadores, a TeamPCP não perdeu tempo e passou imediatamente a validar as credenciais roubadas. TruffleHog, que foi notado no incidente com o hack da Comissão Europeia, foi usado para verificar se as chaves AWS roubadas, os segredos dos aplicativos Azure e os tokens SaaS ainda estavam funcionando e ativos. Dentro de 24 horas após a validação, o grupo passou a reconhecimento nos ambientes AWS comprometidos: listou serviços com foco em contêineres, estudou clusters e definições de tarefas, chegou ao AWS Secrets Manager. Em seguida, os fluxos de trabalho do GitHub entraram em ação para executar código no ambiente da vítima e ECS Exec para executar comandos bash e scripts Python diretamente nos contêineres AWS. O código-fonte, arquivos de configuração e segredos vazaram dos repositórios do GitHub. Do AWS-infrastructure - o conteúdo dos buckets S3, Secrets Manager e bancos de dados. A atividade de pós-exploração da TeamPCP se concentrou em comprometer segredos adicionais e exfiltrar grandes volumes de dados de repositórios e recursos de nuvem, - relatou Wiz. - Os dados e segredos roubados provavelmente são transferidos para outros grupos para operações adicionais.
Conexão com Lapsus$
Paralelamente aos próprios ataques, a TeamPCP começou a se gabar abertamente de seus sucessos no Telegram e anunciou planos para "roubar terabytes de segredos comerciais junto com novos parceiros". Embora esses parceiros não sejam nomeados diretamente, quase simultaneamente no canal Telegram do grupo Lapsus$ apareceram postagens sobre o próximo ataque à cadeia de suprimentos associada à TeamPCP. Na conferência RSAC 2026, o diretor técnico da Mandiant Consulting, Charles Carmakal, confirmou a conexão entre os grupos. Segundo ele, mais de mil ambientes SaaS comprometidos eram conhecidos naquele momento, e esse número poderia aumentar significativamente. Carmakal enfatizou separadamente que os participantes dos ataques são baseados principalmente nos EUA, Grã-Bretanha, Canadá e Europa Ocidental e "são conhecidos por sua agressividade excepcional em questões de extorsão". De acordo com analistas da Palo Alto Networks, além do Lapsus$, a TeamPCP coopera com os operadores do criptografador CipherForce e o grupo de ransomware iniciante Vect. Representantes deste último até postaram uma declaração aberta de parceria com a TeamPCP em um dos fóruns de hackers. Henrik Plate, chefe do departamento de pesquisa da Endor Labs, explicou a lógica dessa aliança da seguinte forma: O grupo supostamente coletou uma grande quantidade de credenciais durante os ataques recentes, e a cooperação [com os extorsionários] permite dimensionar seu uso até que as vítimas concluam a atualização de segredos. Por sua vez, especialistas da Wiz enfatizaram que a disseminação horizontal do malware pelo ecossistema cria um "efeito bola de neve" e a campanha provavelmente continuará a se expandir: Estamos observando uma convergência perigosa de grupos que atacam cadeias de suprimentos com o conhecido
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Ataque ao Trivy: Como uma invasão ao scanner de vulnerabilidades causou um efeito dominó
Em março de 2026, o grupo de hackers TeamPCP lançou uma série de ataques em cascata na cadeia de suprimentos. Tudo começou com a comprometimento do scanner de vulnerabilidades Trivy e da empresa Aqua Security, e então o ataque atingiu npm, PyPI, Checkmarx, Telnyx e dezenas de milhares de pipelines CI/CD em todo o mundo. Entre os afetados estavam Cisco, Comissão Europeia, a startup de IA Mercor e centenas de outras organizações. De acordo com a empresa Mandiant, o número total de SaaS comprometidos ultrapassou 1.000 e continua a crescer.
O mais desagradável desta história não foi nem a escala dos ataques, mas o fato de que a base de tudo não era uma vulnerabilidade zero-day, mas a invasão de uma única conta. Isso foi suficiente para provocar um verdadeiro efeito dominó.
O que é Trivy
Trivy é um conhecido scanner de vulnerabilidades de código aberto desenvolvido pela Aqua Security. A ferramenta ajuda a identificar problemas de segurança e segredos codificados em contêineres, clusters Kubernetes, repositórios e infraestrutura de nuvem. O projeto tem mais de 33 mil estrelas no GitHub, e as GitHub Actions associadas são usadas em dezenas de milhares de fluxos de trabalho CI/CD em todo o mundo. O paradoxo da situação é que Trivy é uma ferramenta de segurança. É ele que as organizações executam para garantir que não haja malware e vazamentos de segredos em suas compilações. Portanto, a confiança nele é alta, e ele recebe as permissões apropriadas. Para os hackers, comprometer essa ferramenta é muito mais lucrativo do que uma dependência comum.
Prelúdio de fevereiro
Esta história começou em fevereiro de 2026. Naquela época, um bot autônomo hackerbot-claw, registrado no GitHub uma semana antes do início dos ataques, abriu um pull request para o repositório Trivy. O PR explorou uma configuração perigosa pull_request_target em um dos fluxos de trabalho do projeto - um padrão em que o GitHub Actions executa código de um fork, mas o faz com os direitos e segredos do repositório principal. Curiosamente, em novembro de 2025 (três meses antes da exploração do hackerbot-claw), essa configuração perigosa foi descoberta e marcada por um analisador automático, mas os desenvolvedores da Aqua Security ignoraram o aviso. Não se sabe se o hackerbot-claw foi controlado pelo grupo TeamPCP ou se foi uma entidade separada, cujo acesso os hackers usaram posteriormente. De qualquer forma, através dessa brecha, os invasores despejaram da memória do processo o Personal Access Token (PAT) da conta de serviço aqua-bot - esse token tinha direitos de repo para toda a organização aquasecurity. Depois disso, os criminosos excluíram todas as 178 versões do Trivy (de 0.27.0 a 0.69.1), tornaram o repositório privado por um curto período e publicaram uma extensão maliciosa Aqua Trivy para VS Code no OpenVSX.
Especialistas da Aqua Security notaram rapidamente o incidente, relataram-no publicamente em 1º de março e alteraram os tokens comprometidos. No entanto, como se viu mais tarde, parte dos artefatos (chaves de API, certificados, senhas) permaneceu acessível aos invasores. Isso foi suficiente para que, 20 dias depois, os hackers voltassem.
19 de março: o segundo ataque ao Trivy
Em 19 de março de 2026, quando grande parte da comunidade de segurança da informação estava deixando o BSidesSF e se preparando para a RSA Conference, os membros da TeamPCP iniciaram a fase principal de sua operação. Usando as credenciais roubadas em fevereiro, os invasores publicaram a tag maliciosa 0.69.4 no repositório principal do Trivy através da conta de serviço aqua-bot e iniciaram o pipeline de lançamento automático. Paralelamente, eles executaram um force push de 75 das 76 tags no repositório aquasecurity/trivy-action e substituíram todas as sete tags em aquasecurity/setup-trivy. Como resultado, as tags não apontavam mais para commits legítimos, mas para maliciosos. Entre os comprometidos estavam as versões @0.34.2, @0.33 e @0.18.0, e a única não afetada foi @0.35.0. Os invasores não criaram um novo commit ou criaram um lançamento - isso seria refletido no histórico e provocaria o aparecimento de notificações para os mantenedores. Em vez disso, os hackers redirecionaram as tags existentes para commits maliciosos, clonando cuidadosamente os metadados dos originais: nome do autor, e-mail, carimbos de data/hora e até mesmo o texto da mensagem com o número do PR. Qualquer fluxo de trabalho que se referisse a essa tag puxaria automaticamente o código malicioso. Os rastros que, no final, ajudaram a desvendar esse ataque foram descobertos apenas por meio de análise retrospectiva. O force push de tags, em princípio, não gera eventos CreateEvent ou DeleteEvent na API pública do GitHub, ou seja, para sistemas de monitoramento baseados nesses eventos, o ataque foi invisível. Os commits falsos não foram assinados com GPG, enquanto os originais foram. As falsificações afetaram apenas entrypoint.sh, enquanto as originais afetaram vários arquivos. Os commits pai datam de março de 2026, enquanto os próprios commits fingiam ser lançamentos de 2021-2022. Paralelamente às tags, a TeamPCP publicou binários infectados do Trivy v0.69.4 via GitHub Releases, Docker Hub, GHCR, AWS ECR e repositórios DEB e RPM. A versão maliciosa esteve disponível por cerca de três horas, e as tags infectadas do GitHub Actions permaneceram ativas por cerca de doze horas.
TeamPCP Cloud Stealer
O malware que a TeamPCP implantou no Trivy foi chamado de TeamPCP Cloud Stealer. Em GitHub-runners, o malware elevou os privilégios para o nível root via passwordless sudo, encontrou os processos Runner.Worker e escaneou suas regiões de memória /proc/pid/mem em busca de strings JSON com segredos que o GitHub Actions usa para mascarar dados confidenciais nos logs. Além disso, o stealer coletou variáveis de ambiente e procurou credenciais no sistema de arquivos: chaves SSH, configurações AWS, GCP, Azure, Kubernetes, Docker, arquivos .env, senhas de banco de dados, tokens Slack e Discord, chaves TLS, configurações VPN e dados de carteiras de criptomoedas. Tudo o que foi coletado foi criptografado com AES-256-CBC com uma chave gerada aleatoriamente, e a própria chave foi codificada com uma chave pública RSA-4096. O arquivo resultante com o nome tpcp.tar.gz foi enviado por uma solicitação POST para o domínio de typosquatting scan.aquasecurtiy[.]org (observe - as letras na palavra security foram trocadas). Se a exfiltração falhasse, o malware usaria um canal de backup: criaria um repositório público tpcp-docs na conta do GitHub da vítima e carregaria os dados roubados lá como um release asset. Nas máquinas dos desenvolvedores (o malware as determinava pela ausência da variável GITHUB_ACTIONS=true), o comportamento mudava. O malware não apenas coletava segredos, mas também instalava um backdoor Python no host no caminho ~/.config/systemd/user/sysmon.py, que era registrado como um serviço systemd e periodicamente consultava o servidor de controle para novas cargas úteis. Se houvesse um cluster Kubernetes, o malware formava a configuração de um pod privilegiado com securityContext.privileged=true, montava o sistema de arquivos raiz do nó via hostPath e, assim, ia além dos limites do contêiner para o nível do host. De acordo com o "Laboratório Kaspersky", foi essa combinação com o Kubernetes que tornou o malware particularmente perigoso: ele não se limitou a roubar arquivos e tentou obter segredos de tempo de execução que a AWS emite para contêineres via Instance Metadata Service no endereço 169.254.169.254 e Amazon ECS via 169.254.170.2. Ou seja, a TeamPCP estava caçando não apenas segredos estáticos, mas também tokens IAM temporários que, no momento da infecção, abriam acesso direto aos recursos da AWS. No final, o mantenedor do Trivy, Itay Shakury, confirmou o comprometimento e associou o incidente ao ataque de fevereiro. Ele escreveu: Se você suspeitar que usou uma versão comprometida, considere que todos os segredos do seu pipeline foram comprometidos e altere-os imediatamente. O incidente recebeu o identificador CVE-2026-33634 com uma pontuação de 9,4 na escala CVSS.
22 de março: ataque à organização interna da Aqua Security
Três dias após o ataque principal, descobriu-se que a rotação incompleta de segredos trouxe outra surpresa desagradável. Em 22 de março, imagens maliciosas do Trivy versões 0.69.5 e 0.69.6 apareceram no Docker Hub - sem os lançamentos correspondentes no GitHub. Ambos continham o mesmo TeamPCP Cloud Stealer. A última versão "limpa" desde então é considerada 0.69.3. No mesmo dia, o grupo TeamPCP chegou à organização aquasec-com do GitHub, onde a Aqua Security armazena código proprietário: código-fonte do Tracee, forks internos do Trivy, pipelines CI/CD, operadores Kubernetes e bases de conhecimento internas. De acordo com pesquisadores do OpenSourceMalware, o ponto de entrada foi a conta de serviço Argon-DevOps-Mgt - um bot com direitos de administrador simultaneamente na organização pública aquasecurity e na aquasec-com interna. Ele foi autorizado via PAT, e não via GitHub App, e seu token estava no CI-runner do Trivy, onde o stealer o encontrou. Primeiro, os invasores realizaram um teste: criaram e excluíram imediatamente um branch de teste update-plugin-links-v0.218.2 no repositório aquasecurity/trivy-plugin-aqua. Não havia nenhum lançamento com esse nome, nenhum fluxo de trabalho foi iniciado - este foi um teste do token roubado. Sete horas depois, o grupo renomeou automaticamente todos os 44 repositórios em aquasec-com, adicionando o prefixo tpcp-docs- aos nomes e alterando as descrições para TeamPCP Owns Aqua Security. Toda a operação levou menos de dois minutos.
Efeito dominó: npm, LiteLLM, Checkmarx
Paralelamente ao deface da Aqua Security, o grupo TeamPCP passou para a fase em cascata dos ataques, onde cada link subsequente da cadeia foi alimentado por segredos roubados na etapa anterior. Primeiro, o ecossistema npm foi afetado. Os tokens de publicação dos mantenedores, cujos pipelines incluíam a execução do scanner, vazaram dos CI-runners do Trivy. Com base nesses tokens, a TeamPCP lançou o CanisterWorm, um verme de autorreplicação que publicava automaticamente atualizações maliciosas em todos os pacotes aos quais o token tinha acesso. O CanisterWorm merece uma menção separada. Em vez de um servidor de controle comum, o verme usa um canister na rede Internet Computer Protocol, o que torna a infraestrutura resistente ao bloqueio: para remover um canister, é necessária uma votação dos membros da rede. Para mascaramento, o verme se instala no sistema como pgmon.service, fingindo ser um serviço de monitoramento PostgreSQL, e periodicamente consulta o nó ICP em busca de novas cargas úteis. Ele também tinha um "interruptor" que reagia à string youtube.com no URL recebido - caso os operadores precisassem desligar a botnet com urgência. A próxima vítima do comprometimento foi o pacote PyPI LiteLLM - uma biblioteca popular que fornece um gateway para vários provedores de LLM. LiteLLM tem mais de 90 milhões de downloads por mês, e seus usuários incluem empresas que precisam de uma única API para OpenAI, Anthropic, AWS Bedrock e Google Vertex AI ao mesmo tempo. Infelizmente, o pipeline CI da BerriAI (a empresa que desenvolve o LiteLLM) executou o Trivy como uma etapa de compilação e, ao mesmo tempo, não fixou uma versão específica da ferramenta. Como resultado, o stealer despejou o token PYPI_PUBLISH e o GitHub PAT do cofundador do projeto, Krrish Dholakia. Em 24 de março, a TeamPCP publicou versões maliciosas do LiteLLM no PyPI - 1.82.7 e 1.82.8. Não houve commits ou tags correspondentes no repositório Git do projeto: os pacotes foram montados localmente e, usando as credenciais legítimas do mantenedor, carregados no GitHub, contornando o pipeline de lançamento padrão. Assim, os hackers conseguiram contornar as verificações de integridade, incluindo a verificação de hashes no pip: o código malicioso foi corretamente escrito nos metadados do pacote com os hashes corretos e o hash correspondia. A assinatura era válida, mas o conteúdo não. Na versão 1.82.7, o stealer foi embutido no arquivo proxy_server.py na linha 128, inserindo-o cuidadosamente entre dois blocos de código legítimos, e ele foi acionado na importação litellm.proxy. Especialistas da Endor Labs descobriram três iterações de payload nesta versão, o que indicou o desenvolvimento ativo do malware durante o ataque. Na versão 1.82.8, os invasores foram mais longe e adicionaram litellm_init.pth - um tipo especial de arquivo que o módulo Python site executa toda vez que o interpretador é iniciado, sem qualquer importação. Bastava executar qualquer coisa em Python (pip, plug-in IDE, qualquer sub-processo), e o stealer começava a trabalhar. Analistas do "Laboratório Kaspersky" em sua análise notaram um detalhe notável: o payload malicioso foi decodificado do Base64 e executado na memória, e sua saída foi criptografada com AES-256-CBC com uma chave aleatória, que, por sua vez, foi criptografada com uma chave RSA pública. Essa mesma chave RSA foi então descoberta em outras fases da campanha, tornando-se um dos principais indicadores. Paralelamente, especialistas da Sysdig descobriram o mesmo stealer em duas GitHub Actions da empresa de segurança da informação Checkmarx - ast-github-action e kics-github-action. Inicialmente, foi presumido que uma ou duas tags foram afetadas no ast-github-action, mas mais tarde descobriu-se que a TeamPCP reescreveu todas as tags publicadas do repositório (91 tags), fabricando individualmente um commit separado para cada versão. Os dados roubados nesta fase do ataque foram transferidos para o domínio de typosquatting checkmarx[.]zone. Além disso, através da conta Checkmarx comprometida no OpenVSX, os hackers publicaram versões maliciosas das extensões ast-results 2.53.0 e cx-dev-assist 1.7.0. As versões no principal VS Code Marketplace não foram afetadas, e representantes da Checkmarx disseram que não encontraram sinais de vazamento de dados do cliente.
27 de março: Telnyx e esteganografia em arquivos WAV
Em 27 de março, a TeamPCP adicionou o pacote Python Telnyx - o SDK oficial para integração de VoIP, mensagens e serviços de IoT - à lista de vítimas. Duas versões maliciosas (4.87.1 e 4.87.2) apareceram no PyPI, e o código malicioso foi inserido no arquivo client.py para que ele fosse acionado automaticamente na importação do pacote, sem interferir no funcionamento das funções legítimas do SDK. De acordo com a Endor Labs, o token para publicação no PyPI provavelmente vazou como resultado do hack LiteLLM: qualquer desenvolvedor ou pipeline CI que tivesse o LiteLLM instalado e, ao mesmo tempo, tivesse um token PyPI Telnyx no ambiente, poderia dar esse token ao stealer. O mais interessante nesta fase do ataque foi a técnica de entrega do payload final: em vez de hospedar um binário pronto ou um blob codificado, a TeamPCP aplicou esteganografia em arquivos de áudio. No Linux e macOS, o pacote infectado baixou o arquivo ringtone.wav do servidor de controle, extraiu o script-assembler criptografado XOR dos dados de áudio e o executou na memória. Depois disso, o stealer coletou chaves SSH, variáveis de ambiente, tokens de nuvem, dados de carteiras de criptomoedas e segredos de clusters Kubernetes, embalou-os em tpcp.tar.gz e os enviou para o servidor de controle, após o que destruiu todos os rastros. No Windows, o ataque teve uma aparência diferente: o pacote baixou o arquivo hangup.wav, extraiu o arquivo executável dele e o salvou na pasta de inicialização como msbuild.exe. Ou seja, nas máquinas Windows, a TeamPCP se esforçou para se fixar no sistema, ao contrário do Linux e macOS. Curiosamente, a técnica de esteganografia em arquivos WAV foi usada pela TeamPCP antes - por exemplo, no wiper Kamikaze (sobre o qual falaremos mais tarde). Mas se no Kamikaze o payload foi embutido diretamente no áudio na forma de Base64, então para o Telnyx ele foi carregado de um servidor remoto na forma XORed.
Wiper Kamikaze
No âmbito da mesma campanha, a TeamPCP usou um componente que não combina bem com o retrato usual de um grupo financeiramente motivado: um payload destrutivo chamado Kamikaze, direcionado exclusivamente a sistemas iranianos. O wiper foi entregue via CanisterWorm e, às vezes, via instâncias Docker não protegidas. Antes de iniciar, o payload verificou vários indicadores: o fuso horário de Teerã, a localidade iraniana, o sinal fa_IR. Se nada disso fosse descoberto, apenas o backdoor CanisterWorm seria implantado na máquina. Em clusters Kubernetes no fuso horário iraniano, o Kamikaze implantou um DaemonSet privilegiado chamado host-provisioner-iran e um contêiner kamikaze em cada nó, incluindo o plano de controle, após o qual iniciou a limpeza forçada dos sistemas de arquivos e a reinicialização. Em hosts Linux comuns, se o processo fosse executado como root, o comando rm -rf / --no-preserve-root seria executado. Caso contrário, os invasores tentaram elevar os privilégios via passwordless sudo. Charlie Eriksen, da Aikido, que rastreou a evolução do payload em tempo real, contou seis iterações do Kamikaze apenas em 22 de março. As primeiras versões se concentraram em escapar do Kubernetes, e as versões posteriores adicionaram a propagação via SSH, a exploração da API Docker via porta 2375 e a esteganografia em WAV. De acordo com Eriksen, não há confirmação de danos reais dos ataques do wiper, mas a própria combinação de uma campanha financeiramente motivada com malware destrutivo georreferenciado não tem explicação. Os pesquisadores admitem que esta pode ter sido uma operação com objetivos mistos, ou o módulo destrutivo foi encomendado por alguém em paralelo com a campanha principal, ou foi uma tentativa dos hackers de atrair atenção para si mesmos, e o grupo estava intencionalmente aumentando a "visibilidade da mídia".
Cisco, Comissão Europeia, Mercor e outros
Em seguida, a escala do problema começou a aparecer e as primeiras vítimas downstream apareceram. Uma das primeiras vítimas publicamente registradas dessa cascata foi a Cisco. Os invasores usaram as credenciais roubadas durante o comprometimento do Trivy e entraram no ambiente interno de compilação e desenvolvimento da empresa. Como resultado, chaves AWS, que foram então usadas para ações não autorizadas nas contas de nuvem da empresa, vazaram de dezenas de máquinas, incluindo estações de trabalho de desenvolvedores. De acordo com a mídia, os invasores clonaram mais de 300 repositórios do GitHub, incluindo o código-fonte dos produtos de IA da Cisco (incluindo AI Assistants, AI Defense e soluções ainda não lançadas). Pior ainda, parte dos repositórios roubados pode ter pertencido a clientes corporativos da empresa, incluindo bancos, empresas de BPO e agências governamentais americanas. A segunda grande vítima foi a Comissão Europeia. Em 24 de março de 2026, a CE alertou sobre o comprometimento de sua infraestrutura de nuvem, que atende a plataforma Europa.eu, e a responsabilidade pelo ataque foi inicialmente assumida pelo grupo de ransomware ShinyHunters. Como explicaram os especialistas da CERT-EU, o ponto de entrada dos criminosos foi a chave de API da AWS, comprometida em 19 de março durante o ataque ao Trivy. A Comissão Europeia usou uma versão infectada do scanner, sem suspeitar disso: a ferramenta veio pelos canais de atualização regulares. Tendo recebido a chave comprometida, os invasores criaram e anexaram uma nova chave de acesso à conta e começaram a reconhecimento. TruffleHog entrou em ação - uma ferramenta de código aberto para pesquisar segredos e validar credenciais da AWS via Security Token Service. Como resultado, o vazamento afetou os dados de 71 clientes de hospedagem Europa.eu - 42 divisões internas da Comissão Europeia e pelo menos 29 outras estruturas da UE. O volume total de dados roubados em forma não compactada foi de 340 GB, incluindo nomes, endereços de e-mail e logins. Cerca de 2,22 GB (51.992 arquivos) foram para notificações automáticas de falha na entrega, incluindo mensagens com conteúdo original do usuário. Ou seja, eles também podem conter dados pessoais. Outra vítima publicamente confirmada foi a startup de IA Mercor, especializada em recrutamento via IA. Representantes da empresa escreveram nas redes sociais: Recentemente, descobrimos que fomos uma das milhares de empresas afetadas pelo ataque à cadeia de suprimentos LiteLLM. Ao mesmo tempo, o grupo de ransomware Lapsus$ afirmou que roubou 4 TB de dados da startup, incluindo 939 GB de código-fonte, e colocou esse dump à venda. Outra grande vítima desses ataques foi a empresa suíça Sportradar - fornecedora de dados esportivos e análises para a NBA, ESPN, Nike, IMG Arena, Bet365 e FIBA. Em 25 de março, os grupos TeamPCP e o grupo de ransomware Vect realizaram um ataque conjunto contra a Sportradar, usando credenciais comprometidas via Trivy. Como resultado, o vazamento afetou cerca de 26 mil registros de usuários, perfis de 23.169 atletas, oito senhas do banco de dados RDS de produção, bem como 328 pares de chaves de API que conectam a Sportradar a 161 organizações clientes. O dump roubado da empresa foi colocado à venda por US$ 50 mil.
TruffleHog e AWS
Se as primeiras etapas da campanha pareciam um ataque clássico à cadeia de suprimentos, a fase de pós-exploração, que foi estudada por analistas da Wiz, parecia mais uma invasão em grande escala de ambientes de nuvem. De acordo com os pesquisadores, a TeamPCP não perdeu tempo e passou imediatamente a validar as credenciais roubadas. TruffleHog, que foi notado no incidente com o hack da Comissão Europeia, foi usado para verificar se as chaves AWS roubadas, os segredos dos aplicativos Azure e os tokens SaaS ainda estavam funcionando e ativos. Dentro de 24 horas após a validação, o grupo passou a reconhecimento nos ambientes AWS comprometidos: listou serviços com foco em contêineres, estudou clusters e definições de tarefas, chegou ao AWS Secrets Manager. Em seguida, os fluxos de trabalho do GitHub entraram em ação para executar código no ambiente da vítima e ECS Exec para executar comandos bash e scripts Python diretamente nos contêineres AWS. O código-fonte, arquivos de configuração e segredos vazaram dos repositórios do GitHub. Do AWS-infrastructure - o conteúdo dos buckets S3, Secrets Manager e bancos de dados. A atividade de pós-exploração da TeamPCP se concentrou em comprometer segredos adicionais e exfiltrar grandes volumes de dados de repositórios e recursos de nuvem, - relatou Wiz. - Os dados e segredos roubados provavelmente são transferidos para outros grupos para operações adicionais.
Conexão com Lapsus$
Paralelamente aos próprios ataques, a TeamPCP começou a se gabar abertamente de seus sucessos no Telegram e anunciou planos para "roubar terabytes de segredos comerciais junto com novos parceiros". Embora esses parceiros não sejam nomeados diretamente, quase simultaneamente no canal Telegram do grupo Lapsus$ apareceram postagens sobre o próximo ataque à cadeia de suprimentos associada à TeamPCP. Na conferência RSAC 2026, o diretor técnico da Mandiant Consulting, Charles Carmakal, confirmou a conexão entre os grupos. Segundo ele, mais de mil ambientes SaaS comprometidos eram conhecidos naquele momento, e esse número poderia aumentar significativamente. Carmakal enfatizou separadamente que os participantes dos ataques são baseados principalmente nos EUA, Grã-Bretanha, Canadá e Europa Ocidental e "são conhecidos por sua agressividade excepcional em questões de extorsão". De acordo com analistas da Palo Alto Networks, além do Lapsus$, a TeamPCP coopera com os operadores do criptografador CipherForce e o grupo de ransomware iniciante Vect. Representantes deste último até postaram uma declaração aberta de parceria com a TeamPCP em um dos fóruns de hackers. Henrik Plate, chefe do departamento de pesquisa da Endor Labs, explicou a lógica dessa aliança da seguinte forma: O grupo supostamente coletou uma grande quantidade de credenciais durante os ataques recentes, e a cooperação [com os extorsionários] permite dimensionar seu uso até que as vítimas concluam a atualização de segredos. Por sua vez, especialistas da Wiz enfatizaram que a disseminação horizontal do malware pelo ecossistema cria um "efeito bola de neve" e a campanha provavelmente continuará a se expandir: Estamos observando uma convergência perigosa de grupos que atacam cadeias de suprimentos com o conhecido
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
