O DarkSword e o Coruna são novas ferramentas utilizadas em ataques invisíveis a dispositivos iOS. Esses ataques não exigem interação do usuário e já estão sendo usados em larga escala por agentes mal-intencionados. Antes do surgimento dessas ameaças, a maioria dos usuários do iPhone não precisava se preocupar com a segurança de dados. Poucos grupos realmente se preocupavam com isso, como políticos, ativistas, diplomatas, executivos de negócios de alto nível e pessoas que lidam com dados extremamente confidenciais, já que eles poderiam vir a ser alvos de agências de inteligência estrangeiras. Já discutimos spywares avançados usados contra esses grupos anteriormente, e observamos como era raro encontrá-los.

No entanto, o DarkSword e o Coruna, descobertos por pesquisadores no início deste ano, são revolucionários. Esses malwares estão sendo usados em infecções em massa de usuários comuns. Nesta postagem, explicamos por que essa mudança ocorreu, os riscos dessas ferramentas e como se proteger.

O que sabemos sobre o DarkSword e como ele pode infectar o seu iPhone

Em meados de março de 2026, três equipes de pesquisa diferentes coordenaram a divulgação das suas descobertas sobre um novo spyware chamado de DarkSword. Essa ferramenta é capaz de invadir silenciosamente dispositivos com o iOS 18, sem que o usuário perceba que algo está errado.

Primeiro, devemos esclarecer uma coisa: o iOS 18 não é tão antigo quanto parece. Embora a versão mais recente seja o iOS 26, a Apple revisou recentemente o sistema de versões, surpreendendo a todos. A empresa decidiu avançar oito versões (da 18 diretamente para a 26) para que o número do sistema operacional correspondesse ao ano atual. Apesar disso, a Apple estima que cerca de um quarto de todos os dispositivos ativos ainda executam o iOS 18 ou uma versão anterior.

Agora que isso já foi esclarecido, vamos voltar a falar sobre o DarkSword. A pesquisa mostra que esse malware infecta as vítimas quando elas visitam sites perfeitamente legítimos que contêm códigos maliciosos. O spyware se instala sem qualquer interação do usuário: basta acessar uma página comprometida. Isso é conhecido como técnica de infecção zero clique. Os pesquisadores relatam que milhares de dispositivos já foram infectados desta forma.

Para comprometer um dispositivo, o DarkSword usa uma cadeia de exploits com seis vulnerabilidades para evitar o sandbox, aumentar privilégios e executar código. Assim que o dispositivo é infectado, o malware consegue coletar dados, incluindo:

• Senhas
• Fotos
• Conversas e dados do iMessage, WhatsApp e Telegram
• Histórico do navegador
• Informações dos aplicativos Calendário, Notas e Saúde da Apple

Além disso, o DarkSword coleta dados de carteiras de criptomoedas, atuando como malware de dupla finalidade para espionagem e roubo de criptoativos.

A única boa notícia é que o spyware não sobrevive a uma reinicialização. O DarkSword é um malware sem arquivo, o que significa que ele vive na RAM do dispositivo e nunca se incorpora ao sistema de arquivos.

Coruna: direcionado às versões mais antigas do iOS

Apenas duas semanas antes da descoberta do DarkSword se tornar pública, os pesquisadores revelaram outra ameaça que tinha o iOS como alvo, chamada de Coruna. Esse malware consegue comprometer dispositivos que executam softwares mais antigos, especificamente as versões 13 a 17.2.1 do iOS. O método utilizado pelo Coruna é exatamente igual ao do DarkSword: as vítimas visitam um site legítimo injetado com código malicioso que, em seguida, infecta o dispositivo delas com o malware. Todo o processo é completamente invisível e não requer interação do usuário.

Uma análise detalhada do código do Coruna revelou que ele explora 23 vulnerabilidades distintas do iOS, várias delas localizadas no WebKit da Apple. Vale lembrar que, de um modo geral (fora da UE), todos os navegadores iOS precisam usar o mecanismo WebKit. Isso significa que essas vulnerabilidades não afetam apenas os usuários do Safari, mas também qualquer pessoa que use outros navegadores no iPhone.

A versão mais recente do Coruna, assim como o DarkSword, inclui modificações projetadas para drenar carteiras de criptomoedas. Ele também coleta fotos e, em alguns casos, informações de e-mails. Ao que tudo indica, roubar criptomoedas parece ser o principal motivo da implementação generalizada do Coruna.

Quem criou o Coruna e o DarkSword, e como eles foram disseminados?

A análise do código de ambas as ferramentas sugere que o Coruna e o DarkSword provavelmente foram desenvolvidos por grupos diferentes. No entanto, ambos são softwares criados por empresas patrocinadas pelo governo, possivelmente dos EUA. Isso se reflete na alta qualidade do código: não são kits montados com partes aleatórias, mas exploits projetados de forma uniforme. Em algum momento, essas ferramentas vazaram e foram parar nas mãos de gangues de cibercriminosos.

Os especialistas da GReAT, da Kaspersky, analisaram todos os componentes do Coruna e confirmaram que o kit de exploração é uma versão atualizada da estrutura usada na Operação Triangulação. Esse ataque anterior tinha como alvo os funcionários da Kaspersky, uma história que abordamos em detalhes neste blog.

Uma teoria sugere que um funcionário da empresa que desenvolveu o Coruna vendeu o malware para hackers. Desde então, ele tem sido usado para drenar carteiras de criptomoedas de usuários na China. Alguns especialistas estimam que pelo menos 42 mil dispositivos foram infectados somente neste país.

Quanto ao DarkSword, os cibercriminosos já o usaram para infectar dispositivos de usuários na Arábia Saudita, Turquia e Malásia. O problema se agrava pelo fato de que os invasores que implementaram o DarkSword deixaram o código-fonte completo nos sites infectados, facilitando a detecção dele por outros grupos criminosos.

O código também inclui comentários detalhados explicado exatamente o que faz cada componente, reforçando a hipótese de que ele surgiu no Ocidente. Essas instruções detalhadas tornam mais fácil para outros hackers adaptarem a ferramenta para interesses próprios.

Como se proteger do Coruna e do DarkSword

Dois malwares poderosos que permitem a infecção em massa de iPhones sem exigir qualquer interação do usuário caíram nas mãos de um grupo essencialmente ilimitado de cibercriminosos. Para ser infectado pelo Coruna ou pelo DarkSword, basta que você visite o site errado na hora errada. Portanto, este é um daqueles casos em que todos os usuários precisam levar a sério a segurança do iOS, não apenas aqueles que pertencem a grupos de alto risco.

A melhor coisa a fazer para se proteger do Coruna e do DarkSword é atualizar assim que possível os dispositivos para a versão mais recente do iOS ou do iPadOS 26. Se isso não for possível (por exemplo, se o dispositivo for mais antigo e não compatível com o iOS 26), ainda assim é recomendado baixar a versão mais recente disponível. Especificamente, procure as versões 15.8.7, 16.7.15 ou 18.7.7. A Apple aplicou correções em vários sistemas operacionais mais antigos, o que é raro.

Para proteger os dispositivos Apple contra malwares semelhantes que provavelmente aparecerão no futuro, recomendamos fazer o seguinte:

• Instale as atualizações em todos os dispositivos da Apple o quanto antes. A empresa lança regularmente versões do SO que corrigem vulnerabilidades conhecidas. Não as ignore.
• Ative a opção Otimização de segurança em segundo plano. Esse recurso permite que o dispositivo receba correções de segurança críticas além das atualizações completas do iOS, reduzindo o risco de exploração de vulnerabilidades pelos hackers. Para ativá-lo, vá para Configurações → Privacidade e segurança → Otimização de segurança em segundo plano e ative a opção Instalar automaticamente.
• Considere usar o Modo de bloqueio. Essa é uma configuração de segurança reforçada que, apesar de limitar alguns recursos do dispositivo, bloqueia ou restringe ataques de forma significativa. Para ativá-lo, vá para Configurações → Privacidade e segurança → Modo de bloqueio → Ativar o Modo de bloqueio.
• Reinicie o dispositivo uma vez por dia (ou mais). Isso interrompe a atuação de malwares sem arquivo, pois essas ameaças não são incorporadas ao sistema e desaparecem após a reinicialização.
• Use o armazenamento criptografado para dados confidenciais. Mantenha chaves de carteiras de criptomoedas, fotos de documentos e dados confidenciais em um local seguro. Kaspersky Password Manager é uma ótima opção para isso, pois gerencia suas senhas, tokens de autenticação de dois fatores e chaves de acesso em todos os dispositivos, mantendo notas, fotos e documentos sincronizados e criptografados.

A ideia de que os dispositivos da Apple são à prova de balas é um mito. Eles são vulneráveis a ataques de zero clique, cavalos de Troia e técnicas de infecção ClickFix. Além disso, aplicativos maliciosos já foram encontrados na App Store mais de uma vez. Leia mais aqui:

• Predador vs. iPhone: a arte da vigilância invisível
• AirBorne: Ataques a dispositivos da Apple através de vulnerabilidades no AirPlay
• Os seus fones de ouvido Bluetooth estão espionando você?
• O trojan para roubo de dados SparkCat penetra na App Store e no Google Play para roubar dados de fotos
• Banshee: um malware de roubo de dados que persegue usuários do macOS

Como já comentamos em uma postagem anterior, o desenvolvimento de produtos de software modernos é praticamente impossível sem o uso de componentes de código aberto. Mas, nos últimos anos, os riscos associados a isso tornaram-se cada vez mais diversos, complexos e numerosos. Devemos considerar que, primeiro, as vulnerabilidades afetam a infraestrutura e o código de uma empresa mais rapidamente do que são corrigidas; segundo, os dados são incompletos e pouco confiáveis; e, terceiro, malware pode estar escondido em componentes populares. Portanto, não basta simplesmente verificar os números de versão e solicitar que a equipe de TI corrija os problemas. O gerenciamento de vulnerabilidades deve ser expandido para abranger políticas de download de software, proteções para assistentes de IA e todo o pipeline de criação de software.

Um conjunto confiável de componentes de código aberto

A principal característica de uma solução é impedir o uso de código vulnerável e malicioso. As seguintes medidas devem ser implementadas:

• Ter um repositório interno de artefatos. A fonte única de componentes para desenvolvimento interno precisa ser um repositório unificado no qual os componentes são admitidos somente após uma série de verificações.
• Fazer uma triagem rigorosa dos componentes. Isso inclui verificações de versões conhecidas do componente, versões vulneráveis e maliciosas conhecidas, data de publicação, histórico de atividades e reputação do pacote e de seus autores. É obrigatório verificar todo o conteúdo do pacote, incluindo instruções de compilação, casos de teste e outros dados auxiliares. Para filtrar o registro durante a ingestão, use verificadores de código aberto especializados ou uma solução de segurança abrangente de carga de trabalho na nuvem.
• Fixar versões de dependências. Os processos de compilação, as ferramentas de IA e os desenvolvedores não devem usar modelos (como “o mais recente”) ao especificar versões. As compilações do projeto precisam ser baseadas em versões verificadas. Ao mesmo tempo, as dependências com versões fixas devem ser atualizadas com frequência para as versões verificadas mais recentes que mantêm a compatibilidade e não contêm vulnerabilidades conhecidas. Isso reduz significativamente o risco de ataques à cadeia de suprimentos por meio do comprometimento de um pacote conhecido.

Aperfeiçoamento dos dados de vulnerabilidades

Para identificar vulnerabilidades com mais eficácia e priorizá-las de forma adequada, uma organização precisa estabelecer vários processos de TI e segurança:

• Enriquecimento de dados de vulnerabilidade. Dependendo das necessidades da organização, isso é necessário para enriquecer as informações combinando dados do NVD, EUVD, BDU, GitHub Advisory Database e osv.dev, ou para comprar um feed de inteligência de vulnerabilidades comercial no qual os dados já estão agregados e enriquecidos. Em ambos os casos, também vale a pena monitorar os feeds de inteligência de ameaças para rastrear tendências de exploração reais e obter um entendimento do perfil dos invasores que visam vulnerabilidades específicas. A Kaspersky fornece um feed de dados especializado especificamente focado em componentes de código aberto.
• Análise detalhada da composição do software. As ferramentas especializadas de análise de composição de software (SCA) permitem o mapeamento correto da cadeia de dependências no código-fonte aberto para realizar o inventário completo das bibliotecas que estão sendo usadas e descobrir componentes desatualizados ou sem suporte. Os dados sobre componentes íntegros também são úteis para enriquecer o registro de artefatos.
• Identificação do abandonware. Mesmo que um componente não apresente vulnerabilidades formais e o encerramento do suporte ainda não tenha sido declarado oficialmente, o processo de verificação deve sinalizar os componentes que não receberam atualizações há mais de um ano. Isso garante uma análise separada e uma possível substituição, assim como ocorre com os componentes em EOL (fim da vida útil).

Proteção do código e dos agentes de IA

As atividades dos sistemas de IA usados na codificação devem ser agrupadas em um conjunto abrangente de medidas de segurança: desde a filtragem de dados de entrada até o treinamento do usuário:

• Restrições de recomendações de dependências. Configure o ambiente de desenvolvimento para garantir que os agentes e assistentes de IA consultem apenas componentes e bibliotecas do registro de artefatos confiável. Se eles não contiverem as ferramentas corretas, o modelo deve acionar uma solicitação para incluir a dependência no registro em vez de extrair algo do PyPI que apenas corresponda à descrição.
• Filtragem das saídas do modelo. Apesar dessas restrições, tudo o que for gerado pelo modelo também deve ser verificado para garantir que o código de IA não contenha dependências desatualizadas, sem suporte, vulneráveis ou inventadas. Essa verificação deve ser integrada diretamente no processo de aceitação do código ou no estágio de preparação da compilação. Ela não substitui o processo de análise estática tradicional: as ferramentas SAST ainda devem ser incorporadas no pipeline de CI/CD.
• Treinamento do desenvolvedor. As equipes de TI e de segurança devem estar extremamente familiarizadas com as características dos sistemas de IA, seus princípios operacionais e erros comuns. Para conseguir isso, os funcionários devem completar um curso de treinamento especializado, adaptados às suas funções específicas.

Remoção sistemática de componentes em EOL

Se os sistemas de uma empresa utilizarem componentes de código aberto desatualizados, deve-se adotar uma abordagem sistemática e consistente para lidar com as vulnerabilidades. Existem três métodos principais para fazer isso:

• Migração. Este é o método mais complexo e caro para uma organização, pois envolve a substituição total de um componente, seguida pela adaptação, reescrita ou substituição dos aplicativos construídos sobre ele. Decidir sobre uma migração é muito mais difícil quando se exige uma revisão geral de todo o código interno. Isso costuma afetar os componentes principais: é impossível migrar facilmente do Node.js 14 ou do Python 2.
• Suporte de longo prazo (LTS). Existe um mercado de serviços de suporte dedicado para projetos legados de larga escala. Às vezes, isso envolve uma bifurcação do sistema legado mantido por desenvolvedores de terceiros; em outros casos, equipes especializadas fazem o backport de patches que corrigem vulnerabilidades específicas em versões mais antigas e sem suporte. A transição para o LTS geralmente exige custos de suporte contínuos, mas, em muitos casos, isso ainda pode ser mais econômico do que uma migração completa.
• Controles compensatórios. Com base nos resultados de análises detalhadas, é possível criar um conjunto de medidas de segurança abrangentes para mitigar o risco de exploração das vulnerabilidades de um produto legado. Tanto a eficácia quanto a viabilidade econômica dessa abordagem dependem da função do software na organização.

Os departamentos de segurança, TI e negócios devem trabalhar juntos para escolher um desses três métodos para cada componente abandonado ou com EOL documentado e refletir a escolha feita nos registros de ativos e SBOMs da empresa.

Gerenciamento de vulnerabilidades de código aberto baseado em risco

Todos os métodos listados acima reduzem o volume de softwares e componentes vulneráveis que entram na organização, o que simplifica a detecção e a correção de falhas. Apesar disso, é impossível eliminar todos os defeitos: o número de aplicativos e componentes está crescendo muito rápido.

Portanto, é essencial priorizar as vulnerabilidades com base nos riscos reais que elas representam. O modelo de avaliação de risco deve ser expandido para considerar as características do código aberto, além de responder às seguintes perguntas:

• A ramificação do código vulnerável é realmente executada no ambiente da organização? Deve-se realizar uma análise de acessibilidade das vulnerabilidades descobertas. Muitos snippets de código defeituosos nunca são realmente executados na implementação específica da organização, fazendo com que seja impossível explorar a vulnerabilidade. Certas soluções de SCA podem realizar esta análise. Esse mesmo processo permite avaliar um cenário alternativo: o que acontece se os procedimentos ou componentes vulneráveis forem removidos completamente do projeto? Às vezes, esse método de remediação é surpreendentemente indolor.
• O defeito está sendo explorado em ataques reais? Há um PoC disponível? As respostas a essas perguntas fazem parte de estruturas de priorização padrão, como EPSS, mas o rastreamento deve ser realizado em um conjunto muito mais amplo de fontes de inteligência.
• A atividade de criminosos cibernéticos foi relatada nesse registro de dependência ou em componentes relacionados e semelhantes? Estes são fatores adicionais para a priorização.

A consideração desses fatores permite que a equipe aloque recursos de forma eficaz e corrija os defeitos mais perigosos primeiro.

A transparência nunca sai de moda

O padrão de segurança para softwares de código aberto só vai continuar subindo. As empresas que desenvolvem aplicativos, mesmo que para uso interno, enfrentarão pressões regulatórias que exigem segurança cibernética documentada e verificável nos seus sistemas. De acordo com as estimativas dos especialistas da Sonatype, 90% das empresas em todo o mundo já se enquadram em um ou mais requisitos que as obrigam a fornecer provas da confiabilidade do software que usam. Portanto, os especialistas consideram a transparência “o pilar fundamental da segurança da cadeia de suprimento de software”.

Ao controlar o uso de componentes e aplicativos de código aberto, enriquecer a inteligência contra ameaças e fazer o monitoramento rigoroso dos sistemas de desenvolvimento orientados por IA, as organizações podem introduzir as inovações que tanto desejam, ao mesmo tempo em que atingem o padrão elevado definido por reguladores e clientes.

Até bem pouco tempo, somente as empresas especializadas em software e as gigantes em tecnologia precisavam se preocupar com as vulnerabilidades de código aberto e os ataques direcionados contra a cadeia de suprimentos. Porém, os tempos mudaram. Hoje, até mesmo as pequenas empresas estão mantendo suas próprias lojas de desenvolvimento, e isso torna o problema significativo para todo mundo. De maneira ininterrupta, as equipes internas de TI das empresas estão ocupadas escrevendo código, configurando integrações e automatizando fluxos de trabalho, mesmo que o negócio principal não tenha absolutamente nada a ver com software. É o que a eficiência empresarial moderna exige. No entanto, como consequência disso, surge uma nova geração de vulnerabilidades de software, o tipo muito mais complicado de corrigir do que apenas instalar a atualização mais recente do Windows.

O desenvolvimento de software moderno é inseparável dos componentes de código aberto. Porém, os riscos associados proliferaram nos últimos anos, além de terem aumentado em variedade e sofisticação. Estamos testemunhado a injeção de código malicioso em repositórios populares, dados de vulnerabilidade fragmentados e com falhas, o uso sistemático de componentes desatualizados e vulneráveis e as cadeias de dependência cada vez mais complexas.

A escassez de dados de vulnerabilidade para código aberto

Mesmo que sua organização tenha um processo de gerenciamento de vulnerabilidades sólido para software comercial de terceiros, é possível constatar que o código aberto requer uma revisão completa desse processo. Os bancos de dados públicos mais usados geralmente são incompletos, imprecisos ou simplesmente lentos para obter atualizações quando se trata de código aberto. Isso transforma a priorização de vulnerabilidades em um jogo de adivinhação. Por mais automação que possa existir, ela será inútil se os dados de referência estiverem cheios de falhas.

De acordo com os dados da Sonatype, cerca de 65% das vulnerabilidades de código aberto atribuídas a um CVE ID não possuem uma pontuação de vulnerabilidade (CVSS) no NVD, a base de conhecimento de vulnerabilidades mais usada. Dessas vulnerabilidades não pontuadas, quase 46% seriam classificadas como alta, se analisadas adequadamente.

Mesmo quando uma pontuação CVSS está disponível, fontes diferentes estão de acordo apenas no que se refere à gravidade em cerca de 55% das vezes. Um banco de dados pode sinalizar uma vulnerabilidade como crítica, enquanto outro recebe uma pontuação média para ela. Metadados mais detalhados, como as versões de pacotes afetadas, também costumam estar repletos de erros e inconsistências. Seus verificadores de vulnerabilidades que comparam versões de software acabam gerando falsos positivos ou fornecendo falsamente um atestado de integridade.

O déficit nos dados de vulnerabilidade está crescendo e o processo de geração de relatórios está ficando mais lento. Nos últimos cinco anos, o número total de CVEs dobrou, mas o número de CVEs sem uma pontuação de gravidade explodiu por um fator de 37. De acordo com a Tenable, até 2025, o código de exploração de prova de conceito (PoC) esteve normalmente disponível dentro de uma semana após a descoberta de uma vulnerabilidade, mas obter a mesma vulnerabilidade listada no NVD levou em média 15 dias. Os processos de aprimoramento, como atribuir uma pontuação CVSS, são ainda mais lentos, a Sonatype no mesmo estudo estima que o tempo médio para atribuir uma pontuação CVSS é de 41 dias, com alguns defeitos permanecendo sem classificação por até um ano.

O problema do código aberto legado

Bibliotecas, aplicativos e serviços que não são mais mantidos, que foram abandonados ou que atingiram seu fim de vida útil (EOL), podem ser encontrados em 5 a 15% dos projetos corporativos, de acordo com a HeroDevs. Em cinco registros populares de código aberto, há pelo menos 81 mil pacotes que contêm vulnerabilidades conhecidas, mas pertencem a versões desatualizadas e sem suporte. Esses pacotes nunca verão os patches oficiais. Essa “bagagem legada” é responsável por cerca de 10% dos pacotes no Maven Central e no PyPI, e impressionantes 25% no npm.

Usar esse tipo de código aberto quebra o ciclo de vida padrão do gerenciamento de patches: não é possível atualizar, automática ou manualmente, uma dependência que não é mais compatível. Além disso, quando as versões EOL são omitidas dos boletins de vulnerabilidades oficiais, os verificadores de segurança podem categorizá-las como “não afetadas” por um defeito e ignorá-las.

Um excelente exemplo disso é o Log4Shell, a vulnerabilidade crítica (CVSS 10) na popular biblioteca Log4j descoberta em 2021. A versão vulnerável foi responsável por 40 milhões dos 300 milhões de downloads do Log4j em 2025. É importante ressaltar que estamos falando de uma das vulnerabilidades mais infames e amplamente relatadas da história, uma que foi ativamente explorada, corrigida pelo desenvolvedor e tratada em todos os principais produtos derivados. A situação para os defeitos menos divulgados é significativamente pior.

Para agravar esse problema, existe a lacuna de visibilidade. Muitas organizações não têm as ferramentas necessárias para mapear uma árvore de dependências completa ou obter visibilidade total dos pacotes e versões específicos integrados em sua pilha de software. Desse modo, os componentes desatualizados geralmente permanecem invisíveis e nunca entram na fila de correção.

Malware em registros de código aberto

Os ataques que envolvem pacotes de código aberto infectados ou inerentemente maliciosos se tornaram uma das ameaças de crescimento mais rápida para a cadeia de fornecimento de software. De acordo com pesquisadores da Kaspersky, aproximadamente 14 mil pacotes maliciosos foram descobertos em registros populares até o final de 2024, um aumento de 48% a cada ano. A Sonatype relatou um aumento ainda mais explosivo ao longo de 2025 e detectou mais de 450 mil pacotes maliciosos.

A motivação por trás desses ataques varia muito: roubo de criptomoedas, coleta de credenciais de desenvolvedor, espionagem industrial, obtenção de acesso à infraestrutura por meio de pipelines de CI/CD ou comprometimento de servidores públicos para hospedar campanhas de spam e phishing. Essas táticas são empregadas tanto por grupos APT de espionagem quanto por criminosos virtuais motivados financeiramente. É cada vez mais comum a violação de um pacote de código aberto ser apenas o primeiro passo de uma violação corporativa em vários estágios.

Cenários de ataque comuns incluem comprometer as credenciais de um mantenedor de pacote de código aberto legítimo, publicar uma biblioteca “útil” com código malicioso integrado ou publicar uma biblioteca maliciosa com um nome quase idêntico a um popular. Uma tendência particularmente alarmante em 2025 foi o aumento de ataques automatizados semelhantes a worms. O exemplo mais notório é a campanha Shai-Hulud. Nesse caso, o código malicioso roubou os tokens do GitHub e npm e continuou infectando novos pacotes, eventualmente se espalhando para mais de 700 pacotes npm e dezenas de milhares de repositórios. Ele vazou segredos de CI/CD e chaves de acesso à nuvem para o domínio público no processo.

Embora esse cenário não esteja tecnicamente relacionado a vulnerabilidades, as ferramentas de segurança e as políticas necessárias para seu gerenciamento são as mesmas usadas para o gerenciamento de vulnerabilidades.

Como os agentes de IA aumentam os riscos do uso de código aberto

A integração apressada e onipresente de agentes de IA no desenvolvimento de software aumenta significativamente a velocidade do desenvolvedor, mas também amplifica qualquer erro. Sem supervisão rigorosa e proteções claramente definidas, o código gerado por IA fica excepcionalmente vulnerável. A pesquisa mostra que 45% do código gerado por IA contém falhas da lista OWASP Top 10, enquanto 20% dos aplicativos orientados por IA implementados abrigam erros de configuração perigosos. Isso acontece porque os modelos de IA são treinados em grandes conjuntos de dados que incluem grandes volumes de código desatualizado, demonstrativo ou puramente educacional. Esses problemas sistêmicos ressurgem quando um modelo de IA decide quais componentes de código aberto devem ser incluídos em um projeto. O modelo costuma não saber quais versões do pacote existem no momento, nem quais foram sinalizadas como vulneráveis. Em vez disso, ele sugere uma versão de dependência extraída de seus dados de treinamento, que, provavelmente, estará obsoleta. Em alguns casos, os modelos tentam chamar versões inexistentes ou bibliotecas totalmente alucinadas. Isso abre a porta para ataques de confusão de dependência.

Em 2025, mesmo os principais LLMs recomendaram versões de dependência incorretas, simplesmente inventando uma resposta, em 27% dos casos.

A IA pode simplesmente corrigir tudo?

É uma ideia simples e tentadora: basta apontar um agente de IA para sua base de código para que ele procure e corrija todas as vulnerabilidades. Infelizmente, a IA não pode resolver totalmente esse problema. Os obstáculos fundamentais que discutimos prejudicam os agentes de IA tanto quanto os desenvolvedores humanos. Se os dados de vulnerabilidade estiverem ausentes ou não forem confiáveis, em vez de encontrar vulnerabilidades conhecidas, será necessário redescobrir tudo do zero. Esse processo consome muitos recursos e requer conhecimento de nicho que permanece fora do alcance da maioria das empresas.

Além disso, se uma vulnerabilidade for descoberta em um componente obsoleto ou sem suporte, um agente de IA não poderá “corrigir automaticamente” a vulnerabilidade. Ainda será preciso desenvolver patches personalizados ou executar uma migração complexa. Se uma falha estiver profundamente oculta em uma cadeia de dependências, é provável que a IA ignore isso completamente.

O que fazer?

Para minimizar os riscos descritos acima, será necessário expandir o processo de gerenciamento de vulnerabilidades para incluir políticas de download de pacotes de código aberto, regras operacionais do assistente de IA e o processo de compilação do software. Isso inclui:

• usar uma solução abrangente de segurança de carga de trabalho na nuvem;
• verificar pacotes de código aberto usados no processo de desenvolvimento de software com feeds de inteligência de ameaças para componentes de código aberto;
• considerar medidas de segurança para proteger o código de IA e os agentes de IA;
• remover sistematicamente os componentes de código aberto obsoletos.

É possível ler mais detalhes sobre o gerenciamento de vulnerabilidades em código aberto em uma postagem de blog dedicada.

Os ataques a cadeias de suprimentos têm sido uma das categorias mais perigosas de incidentes de cibersegurança há anos. Se o ano de 2025 nos ensinou alguma coisa, é que os cibercriminosos estão aumentando sua capacidade de ataque. Nesta análise detalhada, veremos ataques a cadeias de suprimentos realizados em 2025 que, embora não sejam os que causaram maiores prejuízos financeiros, certamente foram os mais incomuns e chamaram a atenção do setor.

Janeiro de 2025: um RAT encontrado no repositório do GitHub do DogWifTools

Como um “aquecimento” após o fim de ano, os cibercriminosos realizaram inúmeros ataques de backdoor a várias versões do DogWifTools. Trata-se de um utilitário projetado para lançar e promover vigorosamente moedas de meme baseadas em Solana no Pump.fun. Depois de comprometer o repositório privado do GitHub para o DogWifTools, os invasores esperaram os desenvolvedores carregarem uma nova versão do utilitário, injetaram um RAT nela e trocaram o programa legítimo por uma versão maliciosa apenas algumas horas depois. De acordo com os desenvolvedores, os agentes de ameaças instalaram com êxito as versões 1.6.3 a 1.6.6 do DogWifTools para Windows.

O golpe final foi dado no fim de janeiro. Depois de usar o RAT para coletar uma grande quantidade de dados dos dispositivos infectados, os invasores esvaziaram as carteiras de criptomoedas das vítimas. As vítimas estimaram o total de mais de USD 10 milhões em criptomoedas, mas os invasores contestaram esse número, embora não tenham revelado exatamente o valor total roubado.

Fevereiro de 2025: roubo de USD 1,5 bilhão do Bybit

Se janeiro foi só o aquecimento, o mês de fevereiro foi um colapso total. A invasão da plataforma de câmbio de criptomoedas Bybit superou completamente os incidentes anteriores, tornando-se o maior roubo de criptomoedas da história. Os invasores conseguiram comprometer o software Safe{Wallet}, a solução de armazenamento a frio de múltiplas assinaturas na qual a empresa confiava para gerenciar os seus ativos.

Os funcionários da Bybit pensaram que estavam assinando uma transação de rotina. Na realidade, eles estavam autorizando um contrato inteligente malicioso. Uma vez executado, ele esvaziou os fundos de uma carteira fria principal e os distribuiu em várias centenas de endereços controlados pelo invasor. A transferência final ultrapassou 400 mil ETH/stETH, com um impressionante valor total de aproximadamente… USD 1,5 bilhão!

Março de 2025: Coinbase é alvo de comprometimento em cascata do GitHub Actions

O ano de 2025 seguiu com um ataque sofisticado que usou o comprometimento de vários GitHub Actions, os padrões de fluxo de trabalho usados para automatizar tarefas de DevOps padrão, como seu principal mecanismo de entrega. Tudo começou com o roubo de um token de acesso pessoal pertencente a um mantenedor da ferramenta de análise SpotBugs. Usando esse ponto de apoio, os invasores publicaram um processo malicioso e conseguiram sequestrar um token de um mantenedor do fluxo de trabalho reviewdog/action-setup, que também estava envolvido no projeto.

A partir daí, eles comprometeram uma dependência, o fluxo de trabalho tj-actions/changed-files, modificando-o para executar um script Python malicioso. Esse script foi projetado para procurar segredos de alto valor, como chaves da AWS, do Azure e do Google Cloud, tokens do GitHub e do NPM, credenciais de banco de dados e chaves privadas do RSA. Por incrível que pareça, o script gravou tudo o que encontrou diretamente nos registros de compilação acessíveis ao público em geral. Isso significa que os dados vazados não estavam disponíveis apenas para os invasores, mas também para qualquer pessoa experiente o suficiente para acessá-los.

O alvo original dessa operação era um repositório pertencente à plataforma de câmbio de criptomoedas Coinbase. Felizmente, os desenvolvedores detectaram a ameaça a tempo e impediram o comprometimento. Ao que tudo indica, depois de perceberem que estavam prestes a perder o controle do pipeline tj-actions/changed-files, os invasores adotaram uma abordagem indiscriminada. Isso colocou 23 mil repositórios em risco de vazamento de segredos. No final, várias centenas desses repositórios realmente tiveram suas credenciais confidenciais expostas ao público.

Abril de 2025: um backdoor em 21 extensões do Magento

Em abril, uma infecção foi descoberta em um amplo conjunto de extensões do Magento, uma das plataformas mais populares para a criação de lojas on-line. O backdoor foi incorporado em 21 módulos desenvolvidos por três fornecedores: Tigren, Meetanshi e MGS. As extensões faziam parte da infraestrutura de várias centenas de empresas de comércio eletrônico, incluindo pelo menos uma corporação multinacional.

De acordo com os pesquisadores que o descobriram, o backdoor na verdade foi implantado em 2019. Em abril de 2025, os invasores o acionaram para comprometer sites e fazer o upload de web shells. Isso foi feito por meio de uma função incorporada nas extensões que executava um código arbitrário extraído de um arquivo de licença.

Por ironia, os módulos infectados incluíam o MGS GDPR e o Meetanshi CookieNotice. Como os nomes sugerem, essas extensões foram projetadas para ajudar os sites a cumprir os regulamentos de privacidade e processamento de dados dos usuários. Por fim, em vez de garantir a privacidade, o uso deles provavelmente levou ao roubo de dados e ativos financeiros do usuário por meio de skimming digital.

Maio de 2025: ransomware distribuído por meio de um MSP comprometido

Em maio, os agentes de ransomware da gangue DragonForce obtiveram acesso à infraestrutura de um provedor de serviços gerenciados (MSP) não identificado e a usaram para distribuir um ransomware e roubar dados das organizações clientes do MSP.

Ao que tudo indica, os invasores exploraram várias vulnerabilidades (incluindo uma falha crítica) no SimpleHelp, a ferramenta de monitoramento e gerenciamento remoto usada pelo MSP. Essas vulnerabilidades foram descobertas em 2024 e divulgadas publicamente e corrigidas em janeiro de 2025. Infelizmente, ficou claro que o MSP optou por não acelerar o processo de atualização, um atraso que a gangue do ransomware ficou mais do que feliz em explorar.

Junho de 2025: um backdoor em mais de uma dúzia de pacotes npm populares

No início do verão, os invasores invadiram a conta de um dos mantenedores da biblioteca Glustack e usaram um token de acesso roubado para injetar backdoors em 17 pacotes npm. O mais popular desses pacotes, @react-native-aria/interactions, ostentava 125 mil downloads semanais, enquanto todos os pacotes comprometidos combinados totalizaram mais de um milhão.

O que é particularmente interessante nesse caso são as etapas que os desenvolvedores do Glustack seguiram após o incidente: primeiro, eles restringiram o acesso ao repositório GitHub para contribuidores secundários; segundo, eles ativaram a autenticação de dois fatores (2FA) para publicar novas versões; e terceiro, eles prometeram implementar práticas de desenvolvimento seguras, como fluxo de trabalho baseado em pull requests, revisões sistemáticas de código, registro de auditorias e assim por diante. Em outras palavras, antes do incidente, um projeto com centenas de milhares de downloads semanais não tinha tais medidas em vigor.

Julho de 2025: pacotes npm populares infectados por meio de um ataque de phishing

Em julho, os pacotes npm foram novamente as estrelas do show, incluindo o pacote amplamente usado chamado “is”, que possui 2,7 milhões de downloads semanais. Essa biblioteca de utilitários JavaScript fornece uma ampla variedade de funções de verificação de tipo e validação de valor. Para realizar um ataque de phishing contra um dos proprietários do projeto, os invasores utilizaram com êxito um truque antigo: o typosquatting (usar o domínio npnjs.com em vez de npmjs.com) e um clone do site oficial do npm.

Em seguida, eles usaram a conta comprometida para publicar várias das suas próprias versões do pacote com um backdoor incorporado. A infecção passou desapercebida por seis horas: tempo suficiente para um grande número de desenvolvedores baixarem os pacotes npm maliciosos.

A mesma tática de phishing foi usada contra outros desenvolvedores. Os invasores aproveitaram várias contas de desenvolvedores comprometidas para distribuir diferentes variantes de sua carga maliciosa. Há também uma forte suspeita de que eles podem ter guardado parte dessa carga para ataques futuros.

Agosto de 2025: o ataque s1ngularity e o vazamento de centenas de segredos dos desenvolvedores

No final de agosto, um incidente apelidado de “s1ngularity” continuou a tendência de atingir desenvolvedores de JavaScript. Os invasores comprometeram o Nx, um sistema de compilação popular e uma ferramenta de otimização de pipeline de CI/CD. O código malicioso injetado nos pacotes pesquisou diversos sistemas dos desenvolvedores infectados, acessando uma grande quantidade de dados confidenciais, como chaves de carteiras de criptomoedas, tokens do npm e do GitHub, chaves SSH, chaves de API e muito mais.

Curiosamente, os invasores usaram ferramentas de IA instaladas localmente, como Claude Code, Gemini CLI e Amazon Q, para detectar os segredos nas máquinas das vítimas. Tudo o que eles encontraram foi publicado nos repositórios públicos do GitHub criados em nome das vítimas, usando os títulos “s1ngularity-repository”, “s1ngularity-repository-0” e “s1ngularity-repository-1”. Como você deve ter adivinhado, é daí que vem o nome do ataque.

Consequentemente, os dados privados de centenas de desenvolvedores acabaram ficando à vista de todos e poderiam ser acessados não apenas pelos invasores, mas por absolutamente qualquer pessoa com uma conexão com a Internet.

Setembro de 2025: um stealer de criptomoedas ataca pacotes npm que têm 2,6 bilhões de downloads semanais

A tendência de comprometimentos de pacotes npm seguiu até setembro. Após uma nova campanha de phishing direcionada a desenvolvedores de JavaScript, os invasores conseguiram injetar código malicioso em algumas dezenas de projetos de alto nível. Alguns deles, especificamente “chalk” e “debug”, tiveram centenas de milhões de downloads semanais; coletivamente, os pacotes infectados estavam acumulando mais de 2,6 bilhões de downloads por semana no momento da violação, e eles se tornaram mais populares desde então.

A carga era um stealer de criptomoedas: um malware projetado para interceptar transações de criptomoeda e redirecioná-las para as carteiras dos invasores. Felizmente, apesar de infectar com sucesso alguns dos projetos mais populares do mundo, os invasores acabaram falhando no estágio final da operação. No final, eles ficaram com míseros USD 925.

Apenas uma semana depois, outro grande incidente ocorreu: a primeira onda do malware autopropagável Shai-Hulud, que infectou cerca de 150 pacotes npm, incluindo projetos da CrowdStrike. No entanto, a segunda onda, que ocorreu vários meses depois, provou ser muito mais destrutiva. Vamos analisar o Great Worm em mais detalhes a seguir.

Outubro de 2025: o GlassWorm infecta o ecossistema do Visual Studio Code

Cerca de um mês após o ataque do Shai-Hulud, um malware autopropagável semelhante denominado GlassWorm começou a infectar extensões do Visual Studio Code no Open VSX Registry e no Microsoft Extension Marketplace. Os invasores estavam procurando contas do GitHub, Git, npm e Open VSX, bem como chaves de carteiras de criptomoedas.

Os criadores do GlassWorm adotaram uma abordagem altamente criativa para sua infraestrutura de comando e controle: eles usaram uma carteira de criptomoedas no blockchain Solana como seu C2 principal, com o Google Agenda servindo como um canal de comunicação de backup.

Além de esvaziar as carteiras de criptomoedas das vítimas e sequestrar suas contas para espalhar o worm ainda mais, os invasores também injetaram um RAT chamado Zombi nos dispositivos infectados, obtendo controle total sobre os sistemas comprometidos.

Novembro de 2025: a campanha IndonesianFoods e 150 mil pacotes de spam no npm

Em novembro, um novo incômodo emergiu do repositório do npm. Uma campanha maliciosa coordenada apelidada de IndonesianFoods fez os invasores inundarem o repositório com dezenas de milhares de pacotes inúteis.

O objetivo principal era jogar com o sistema para inflar as métricas e os tokens de farm no tea.xyz, uma plataforma de blockchain projetada para recompensar os desenvolvedores de código aberto. Para conseguir isso, os invasores construíram uma enorme rede de projetos interdependentes com nomes que fazem referência à culinária indonésia, como zul-tapai9-kyuki e andi-rendang23-breki.

Os criadores da campanha não se deram ao trabalho de invadir contas. Estritamente falando, os pacotes de spam nem sequer continham um contêiner malicioso, a menos que você considere um script projetado para gerar automaticamente novos contêineres a cada sete segundos. No entanto, o incidente serviu como um lembrete de como a infraestrutura npm é vulnerável a campanhas de spam em larga escala.

Dezembro de 2025: Shai-Hulud 2.0 e o vazamento de 400 mil segredos de desenvolvedores

O destaque absoluto do ano, não apenas de ataques a cadeias de suprimentos, mas provavelmente para todo o campo de segurança cibernética, foi o malware autopropagável Shai-Hulud (também conhecido como Sha1-Hulud) contra desenvolvedores.

Esse malware foi a evolução lógica do ataque s1ngularity mencionado anteriormente: ele também vasculhou os sistemas em busca de todos os tipos de segredos e os publicou em repositórios GitHub abertos. No entanto, o Shai-Hulud adicionou um mecanismo de autopropagação à linha de base: o worm infectou projetos controlados por desenvolvedores já comprometidos usando as credenciais roubadas.

A primeira onda do Shai-Hulud ocorreu em setembro, infectando várias centenas de pacotes npm. No final do ano, a segunda onda chegou e foi batizada como Shai-Hulud 2.0.

Dessa vez, o worm foi atualizado com a funcionalidade de wiper. Se o malware não encontrasse tokens npm ou GitHub válidos em um sistema infectado, ele acionava uma carga destrutiva que apagava os arquivos do usuários.

Aproximadamente 400 mil segredos foram vazados no total como resultado do ataque. Vale a pena notar que, assim como no s1ngularity, todos os dados confidenciais acabaram publicados em repositórios públicos, onde poderiam ser baixados não apenas pelos invasores, mas por qualquer outra pessoa. E é altamente provável que as consequências desse ataque ainda sejam sentidas por um longo tempo.

Um dos primeiros casos confirmados de uma exploração usando segredos vazados pelo Shai-Hulud foi um roubo de criptomoeda visando vários milhares de usuários da Trust Wallet. Os invasores usaram esses segredos na véspera de Natal para carregar uma versão maliciosa da extensão Trust Wallet com um drenador de criptomoedas integrado para a Chrome Web Store. No final, eles conseguiram se safar com USD 8,5 milhões em criptomoedas.

Como se proteger contra ataques a cadeias de suprimentos

Ao elaborar uma retrospectiva semelhante para 2024, descobrimos que manter uma estrutura de “um mês, uma ameaça” é bastante fácil. Para 2025, no entanto, o caso foi muito mais grave. Houve tantos ataques maciços a cadeias de suprimentos no ano passado, que não conseguimos encaixá-los em uma visão geral.

O ano de 2026 está se mostrando igualmente intenso, por isso recomendamos verificar nossa postagem sobre a prevenção de ataques a cadeias de suprimentos. Enquanto isso, aqui estão as conclusões mais importantes:

• Avalie minuciosamente seus fornecedores e faça uma auditoria cuidadosa do código que você integra em seus projetos.
• Implemente requisitos de segurança rígidos diretamente em seus contratos de serviço.
• Desenvolva um plano abrangente de resposta a incidentes.
• Monitore atividades suspeitas em sua infraestrutura corporativa usando uma solução de XDR.
• Se a sua equipe de segurança interna estiver sobrecarregada, procure um serviço externo de identificação proativa de ameaças e resposta rápida.

Se quiser saber mais detalhes sobre os ataques a cadeias de suprimentos, confira o nosso relatório analítico Supply chain reaction: securing the global digital ecosystem in an age of interdependence (Reação em cadeia de suprimentos: proteção ao ecossistema digital global em uma era de interdependência). Ele se baseia em insights de especialistas técnicos e revela com que frequência as organizações enfrentam riscos relacionados à cadeia de suprimentos e a relações de confiança, onde ainda existem lacunas de proteção e quais estratégias adotar para aumentar a resiliência contra esse tipo de ameaça.

Milhões de pipelines de desenvolvimento de software automatizados dependem de ferramentas de segurança, como Trivy e Checkmarx AST, integradas ao processo de compilação. E foram essas soluções confiáveis que recentemente se tornaram o ponto de entrada para um dos maiores e mais perigosos ataques contra a cadeia de suprimentos da história moderna. Nesta postagem, discutiremos como auditar os fluxos de trabalho automatizados e como proteger a infraestrutura de nuvem corporativa.

Linha do tempo do ataque e as consequências conhecidas

Em 19 de março, um ataque direcionado e bem-sucedido contra a cadeia de suprimentos foi realizado por meio do Trivy, uma ferramenta de verificação de vulnerabilidades de código aberto amplamente usada em pipelines de CI/CD. Os invasores, um grupo conhecido como TeamPCP, conseguiram injetar malware nos fluxos de trabalho oficiais do GitHub Actions e nas imagens do Docker associadas ao Trivy. Com isso, cada verificação automatizada de pipeline feita acionou um malware que roubou chaves SSH, tokens de acesso à nuvem, carteiras de criptomoedas e outros dados valiosos dos sistemas comprometidos. Dada a natureza crítica do incidente, o identificador CVE-2026-33634 foi atribuído a ele, com uma pontuação CVSS4B, praticamente máxima, de 9,4.

Mais tarde, naquele mesmo dia, a equipe do Trivy detectou o ataque, removeu os artefatos maliciosos dos canais de distribuição e interrompeu aquela fase do ataque. No entanto, os invasores já tinham conseguido acessar os ambientes de muitos usuários do Trivy.

Em 23 de março, um incidente semelhante foi descoberto em outra ferramenta de segurança do aplicativo: um GitHub Action para Checkmarx KICS, e também, para Checkmarx AST. Três horas depois, o código malicioso foi então removido do ambiente. O TeamPCP também conseguiu comprometer as extensões do OpenVSX compatíveis com Checkmarx: cx-dev-assist 1.7.0 e ast-results. Os relatórios que indicam quando ocorreu o momento da resolução dessa parte do incidente variam.

Em 24 de março, um projeto popular que usa a verificação de código do Trivy (o gateway LiteLLM AI, que nada mais é do que uma biblioteca universal para acesso a vários provedores de LLM) foi atacado. As versões 1.82.7 e 1.82.8, carregadas no repositório PyPI, foram comprometidas. Essas versões ficaram disponíveis publicamente por cerca de cinco horas.

Mas o fato do ataque ter durado apenas algumas horas não é motivo para desconsiderar o evento. Dada a popularidade dos projetos afetados, o código malicioso pode ter sido executado milhares de vezes, inclusive dentro da infraestrutura de empresas muito grandes.

Isso permitiu que os invasores não só implementassem backdoors persistentes em clusters do Kubernetes, mas também iniciassem o CanisterWorm autorreplicante no ecossistema npm do JavaScript.

O código dos invasores tem recursos destrutivos que eliminam um cluster Kubernetes, e todos os seus nós, se o fuso horário de Teerã ou o farsi for detectado como idioma principal no sistema comprometido. Em outras regiões, o malware simplesmente rouba dados com o uso do CanisterWorm.

De acordo com especialistas, mais de 20 mil repositórios são considerados suscetíveis a ataques. Os invasores alegam ter roubado centenas de gigabytes de dados e mais de 500 mil contas.

Como o Trivy foi atacado

Para comprometer o Trivy, os invasores usaram as credenciais roubadas em um incidente anterior. O comprometimento anterior do Trivy, ocorrido no final de fevereiro, provavelmente não foi contido de forma plena, e os invasores, ou seja, o mesmo grupo TeamPCP, retornaram com um novo ataque. A Aqua Security, por meio de sua equipe de desenvolvedores do Trivy, especula que, como as credenciais estavam sendo eliminadas gradualmente após o incidente anterior, os invasores conseguiram gerar novos tokens de acesso para si mesmos antes que os antigos comprometidos fossem revogados.

Com isso, os invasores do grupo TeamPCP conseguiram comprometer o GitHub Actions usado em pipelines de CI/CD. Com o uso de credenciais com privilégios de gravação de tags, os invasores forçaram a substituição de 76 das 77 tags de versão no aquasecurity/trivy-action, além de todas as 7 tags no aquasecurity/setup-trivy, e redirecionaram as versões confiáveis existentes para as versões maliciosas. Essa tática de ataque se assemelha com as táticas observadas na campanha Shai-Hulud 2.0. Com isso, os fluxos de trabalho em todo o pipeline começaram a executar o código dos invasores, porém, os metadados da versão não mostravam as alterações visíveis.

Paralelamente a isso, os invasores publicaram um binário Trivy infectado (v0.69.4) nos canais de distribuição oficiais, inclusive com versões do GitHub e registros de contêiner.

Comprometimento da ferramenta LiteLLM

O comprometimento da popular ferramenta de acesso ao modelo de linguagem LiteLLM pode desencadear, por si só, uma grande onda de ataques em toda a cadeia de projetos que utiliza o recurso. O ataque ocorreu em 24 de março de 2026, quando os invasores do TeamPCP publicaram diretamente as versões maliciosas da biblioteca (1.82.7 e 1.82.8) no PyPI. Entre 10:39 UTC e 16:00 UTC, esses pacotes comprometidos continham malware que roubava credenciais. Ele foi integrado no arquivo proxy_server.py, e a versão 1.82.8 também continha um arquivo litellm_init malicioso. Os dados roubados foram exfiltrados para o servidor models.litellm[.]cloud.

Os clientes que usam o LiteLLM Cloud ou a imagem oficial do LiteLLM Proxy Docker não foram afetados devido ao bloqueio estrito da versão, enquanto os desenvolvedores e os projetos de downstream que instalaram as versões não fixadas pelo pip, durante a janela de tempo especificada, foram comprometidos.

Em três horas, os pacotes maliciosos foram removidos do repositório PyPI, e a equipe do LiteLLM suspendeu as novas versões, atualizou as credenciais e envolveu um processo externo de resposta a incidentes. As equipes que usam o LiteLLM em seus projetos são aconselhadas a verificar imediatamente o indicador de comprometimento litellm_init.pth e atualizar rotineiramente todos os segredos que possam estar comprometidos.

Recursos do malware TeamPCP Cloud Stealer

Os invasores adicionaram uma nova lógica ao GitHub Actions, ao executável do Trivy e preservaram a funcionalidade original. Os resultados da verificação de vulnerabilidades por meio do Trivy pareciam normais, mas, ao mesmo tempo, dados valiosos estavam sendo pesquisados e extraídos. O código malicioso atuava da seguinte maneira:

• realizando reconhecimento (coletando dados de rede e variáveis de ambiente);
• procurando tokens e credenciais para acessar ambientes de nuvem AWS e GCP;
• verificando a memória (/proc/*/mem ) para extrair segredos armazenados na memória dos processos Runner.Worker e Runner.Listener;
• extraindo segredos do Kubernetes (/run/secrets/kubernetes.io/serviceaccount);
• coletando dados para conexão com servidores de banco de dados (MySQL, PostgreSQL, MongoDB, Redis, Vault);
• coletando quaisquer outras chaves e segredos de API de arquivos de ambiente e arquivos de configuração de CI/CD (.env, .json, .yml);
• pesquisando webhooks para canais Slack e Discord;
• procurando dados relativos às carteiras de criptomoedas (variáveis relativas ao blockchain Solana, além de dados rpcuser e rpcpassword).

Os dados coletados foram criptografados e carregados em um servidor com um nome semelhante ao dos desenvolvedores do Trivy (scan.aquasecurtiy[.]org). Como se fosse um mecanismo de backup, os invasores forneceram um método para carregar os dados em um repositório denominado docs-tpcp.

O ataque ao CheckMarx e ao LiteLLM usou uma tática semelhante aos outros domínios de typosquatting: models.litellm[.]cloud e checkmarx[.]zone.

Uma análise técnica detalhada do malware, juntamente com indicadores de comprometimento, pode ser encontrada no artigo de nosso especialista no blog Securelist.

Estratégias de resposta e defesa ao CVE-2026-33634

As verificações baseadas em assinatura e as verificações de dependência existentes em registros públicos não são mais suficientes, pois o código malicioso foi injetado diretamente em ações confiáveis e assinadas, o que fez com que a detecção fosse burlada até que o monitoramento comportamental fosse aplicado. Os pipelines de CI/CD se tornaram o “novo perímetro” de segurança.

Ações imediatas. Verifique e confirme se todos os fluxos de trabalho usam versões seguras (Trivy binary 0.69.3, trivy-action 0.35.0 e setup-trivy 0.2.6).

Os administradores de pipeline de CI/CD e as equipes de segurança devem revisar imediatamente as dependências das soluções Checkmarx (kics-github-action e ast-github-action) e Trivy (setup-trivy e trivy-action). Se os fluxos de trabalho fizerem referência a uma tag de versão em vez de um hash SHA específico, revise cuidadosamente os logs de execução do fluxo de trabalho durante o ataque ativo contra a cadeia de suprimentos.

Também é necessário verificar os logs de rede quanto ao tráfego para os domínios scan.aquasecurtiy[.]org, checkmarx[.]zone e models.litellm[.]cloud. A presença desse tráfego indica que os dados confidenciais foram exfiltrados com êxito.

Se um repositório denominado docs-tpcp tiver aparecido no GitHub da organização, isso também poderá indicar uma violação bem-sucedida de dados.

Verifique os hosts e clusters quanto aos sinais de comprometimento, ou seja, a presença de arquivos ~/.config/sysmon/sysmon.py, isto é, pods suspeitos no Kubernetes.

Limpe o cache e realize um inventário dos módulos PyPI: verifique se há módulos maliciosos e reverta para versões limpas.

Em qualquer caso, uma identificação proativa de ameaças deve ser realizada, tendo em vista que os sistemas tenham sido comprometidos com êxito e que os invasores avançaram rapidamente dentro dos sistemas afetados.

É recomendável restaurar os ambientes afetados por meio de backups verificados.

Fixação de dependências e gerenciamento de segredos. Verifique e confirme se as versões de dependência exatas estão fixadas com o uso de hashes criptográficos em todos os pipelines e Dockerfiles. Aconselhamos fazer a transição de tokens de longa duração para credenciais de curta duração com o uso de uma ferramenta de gerenciamento de segredos e fazer a implementação de integrações OIDC onde houver compatibilidade. Minimize a injeção de segredos no ambiente de tempo de execução, faça isso apenas quando for absolutamente necessário. Verifique e confirme se os segredos não estão armazenados em disco ou em arquivos temporários, e se eles não estão sendo reutilizados em processos diferentes.

Atualize todas as credenciais que possam estar comprometidas, ou seja, chaves de API, variáveis de ambiente, chaves SSH, tokens de conta de serviço do Kubernetes e outros segredos.

Outras medidas de segurança. Permita apenas o uso do GitHub Actions originado por uma lista aprovada pela organização e bloqueie os processos novos e não verificados. Configure o GITHUB_TOKEN e outras chaves de acesso de acordo com o princípio do privilégio mínimo. Não conceda permissões de gravação, a menos que seja absolutamente necessário.

Para aumentar a segurança do GitHub Actions, há várias ferramentas de código aberto disponíveis:

• zizmor: uma ferramenta para análise estática e detecção de erros de configuração no GitHub Actions;
• gato e Gato-X: duas versões de uma ferramenta que ajuda a identificar pipelines estruturalmente vulneráveis;
• allstar: um aplicativo do GitHub, desenvolvido pelo OpenSSF, para configurar e aplicar políticas de segurança em organizações e repositórios do GitHub.

Se quiser saber mais detalhes sobre os ataques contra a cadeia de suprimentos, deixamos aqui o nosso convite para consultar o relatório analítico Reação da cadeia de suprimentos: proteção ao ecossistema digital global em uma era de interdependência. Ele é baseado em insights de especialistas técnicos e revela com que frequência as organizações enfrentam os riscos para a cadeia de suprimentos e de relacionamento confiável, onde permanecem as lacunas de proteção e quais são as estratégias que devem ser empregadas para melhorar a resiliência contra esses tipos de ameaças.

Em fevereiro de 2026, a empresa de segurança cibernética Oversecured publicou um relatório que faz com que você queira redefinir o telefone para o padrão de fábrica e se mudar para uma cabana remota na floresta. Os pesquisadores fizeram uma auditoria em 10 aplicativos populares de saúde mental para Android, desde aplicativos de acompanhamento de humor e terapeutas de IA até ferramentas para gerenciar depressão e ansiedade, e descobriram 1.575 vulnerabilidades! Cinquenta e quatro dessas falhas foram classificadas como críticas. Dadas as estatísticas de download desses aplicativos no Google Play, é provável que 15 milhões de pessoas sejam afetadas. Quer saber qual é a ironia? Seis dos dez aplicativos testados fizeram promessas explícitas aos usuários de que seus dados estavam “totalmente criptografados e protegidos”.

Vamos analisar esses escandalosos “vazamentos de dados mentais”: o que exatamente pode vazar, como isso acontece e por que o “anonimato” nesses serviços geralmente não passa de um mito.

O que foi encontrado nos aplicativos

A Oversecured é uma empresa de segurança de aplicativos móveis que usa um verificador especializado para analisar arquivos APK em busca de padrões de vulnerabilidade conhecidos em dezenas de categorias. Em janeiro de 2026, alguns pesquisadores analisaram dez aplicativos de monitoramento de saúde mental do Google Play por meio do verificador, e os resultados foram, digamos, “espetaculares”.

A anatomia das falhas

As vulnerabilidades descobertas são diversas, mas seu propósito é o mesmo: dar aos invasores acesso a dados que deveriam estar trancados a sete chaves.

Para começar, uma das vulnerabilidades permite que um invasor acesse quaisquer atividades internas do aplicativo, inclusive aquelas que deveriam ser sigilosas. Isso permite o sequestro de tokens de autenticação e dados de sessão do usuário. Uma vez que um invasor obtiver essas informações, ele poderá acessar os registros de terapia de um usuário.

Outro problema é o armazenamento de dados local inseguro, com permissões de leitura concedidas a qualquer outro aplicativo no dispositivo. Em outras palavras, aplicativos aleatórios no seu telefone, como a lanterna ou a calculadora, poderiam ler seus registros de terapia cognitivo-comportamental (TCC), notas pessoais e avaliações de humor.

Os pesquisadores também encontraram dados de configuração não criptografados inseridos diretamente nos arquivos de instalação do APK. Isso inclui endpoints da API de back-end e URLs codificadas para bancos de dados do Firebase.

Além disso, foi identificado que vários aplicativos usam a classe java.util.Random, conhecida por ter uma criptografia fraca, para gerar tokens de sessão e chaves de criptografia.

Por fim, a maioria dos aplicativos testados não tinha detecção de root/jailbreak. Em um dispositivo com root, qualquer aplicativo de terceiros com privilégios de root pode obter acesso total a cada bit dos dados médicos armazenados localmente.

É de se espantar que, dos 10 aplicativos analisados, apenas quatro receberam atualizações em fevereiro de 2026. O restante não viu um patch desde novembro de 2025 e há um aplicativo que não foi atualizado desde setembro de 2024. Passar 18 meses sem um patch de segurança é considerado um longo tempo nesse setor, especialmente para um aplicativo que contém diários de humor, transcrições de terapia e horários de ingestão de medicamentos.

Aqui está um rápido lembrete do perigo do uso indevido desse tipo de dados. Em 2024, o mundo da tecnologia foi abalado por um ataque sofisticado ao XZ Utils, um componente crítico encontrado em praticamente todos os sistemas operacionais baseados no kernel Linux. O invasor conseguiu convencer o responsável pelo projeto a entregar as permissões de alteração de códigos, aproveitando-se da sua admissão pública de cansaço extremo e falta de motivação para manter o projeto. Se o ataque tivesse sido concluído, o dano teria sido inimaginável, uma vez que cerca de 80% dos servidores do mundo executam o Linux.

O que pode vazar?

O que esses aplicativos coletam e armazenam? É o tipo de coisa que você provavelmente só compartilharia com um médico de confiança: transcrições de sessões de terapia, registros de humor, horários de medicação, indicadores de automutilação, notas de TCC e várias escalas de avaliação clínica.

Em 2021, registros médicos completos eram vendidos na dark web por US$ 1,000 cada. Para efeito de comparação, um número de cartão de crédito roubado custa entre US$ 5 e US$ 30. Os registros médicos contêm um pacote de identidade completo: nome, endereço, informações do seguro e histórico de diagnóstico. Ao contrário de um cartão de crédito, não há como “reemitir” um histórico médico. Além disso, todos sabem que a fraude médica é difícil de detectar. Embora um banco consiga detectar uma transação suspeita em horas, um pedido de seguro fraudulento para um tratamento inexistente pode passar despercebido por anos.

Já vimos este filme antes

O estudo da Oversecured não é apenas uma história de terror isolada.

Em 2020, Julius Kivimäki invadiu o banco de dados da clínica de psicoterapia finlandesa Vastaamo, acessando os registros de 33 mil pacientes. Quando a clínica se recusou a desembolsar um resgate de 400 mil euros, Kivimäki passou a enviar ameaças diretas aos pacientes: “Pague 200 euros em Bitcoin dentro de 24 horas, ou então seus registros se tornarão públicos.” Por fim, ele acabou vazando todo o banco de dados na dark web. Pelo menos duas pessoas se suicidaram, fazendo com que a clínica fosse forçada a declarar falência. Kivimäki acabou sendo condenado a seis anos e três meses de prisão, tornando este um julgamento recorde na Finlândia devido ao grande número de vítimas envolvidas.

Em 2023, a Comissão Federal de Comércio dos EUA (FTC) aplicou uma multa de US$ 7,8 milhões à BetterHelp, uma empresa gigante de terapia on-line. Apesar de declarar na sua página de inscrição que os dados dos usuários eram estritamente confidenciais, a empresa foi pega repassando suas informações (incluindo respostas a questionários de saúde mental, e-mails e endereços IP) ao Facebook, Snapchat, Criteo e Pinterest para fins de publicidade direcionada. Depois que a poeira baixou, 800 mil usuários afetados receberam um total geral de US$ 10 cada como compensação.

Em 2024, a FTC voltou sua atenção à empresa de telessaúde Cerebral, multando-a em US$ 7 milhões. Por meio de pixels de rastreamento, a Cerebral vazou os dados de 3,2 milhões de usuários para o LinkedIn, Snapchat e TikTok. O vazamento incluía nomes, históricos médicos, prescrições de medicamentos, datas de consultas e informações de seguro. Quer saber o que é pior? A empresa enviou cartões-postais promocionais (sem envelopes) para 6 mil pacientes, revelando que os destinatários estavam em tratamento psiquiátrico.

Em setembro de 2024, o pesquisador de segurança Jeremiah Fowler descobriu que um banco de dados pertencente à Confidant Health, um provedor especializado na recuperação de vícios e serviços de saúde mental, havia sido exposto. O banco de dados continha gravações de áudio e vídeo de sessões de terapia, transcrições, anotações psiquiátricas, resultados de testes de drogas e até cópias de carteiras de motorista. No total, 5,3 terabytes de dados, 126.000 arquivos ou 1,7 milhão de registros podiam ser acessados sem senha.

Por que o anonimato é uma ilusão

Os desenvolvedores adoram a frase: “Nunca compartilhamos seus dados pessoais com ninguém”. Tecnicamente, isso pode ser verdade, já que, em vez disso, eles compartilham “perfis anônimos”. A pegadinha? Hoje é muito mais fácil descobrir a identidade real das pessoas por trás desses perfis. Pesquisas recentes revelaram que o uso de LLMs para eliminar o anonimato se tornou uma realidade rotineira.

Até mesmo o próprio processo de “anonimização” é muitas vezes uma bagunça. Um estudo da Duke University revelou que as corretoras de dados estão divulgando abertamente os dados de saúde mental dos americanos. Das 37 corretoras pesquisadas, 11 concordaram em vender dados vinculados a diagnósticos específicos (como depressão, ansiedade e transtorno bipolar), parâmetros demográficos e, em alguns casos, até nomes e endereços residenciais. Os preços começaram em US$ 275 para 5 mil registros agregados.

De acordo com a Fundação Mozilla, em 2023, 59% dos aplicativos populares de saúde mental falharam em atender até mesmo aos padrões de privacidade mais básicos e 40% se tornaram menos seguros do que no ano anterior. Esses aplicativos permitiam a criação de contas por meio de serviços de terceiros (como Google, Apple e Facebook), apresentavam políticas de privacidade suspeitas e resumidas que citavam de forma leviana as informações sobre a coleta de dados e continham uma pequena brecha inteligente: algumas políticas de privacidade se aplicavam estritamente ao site da empresa, mas não ao aplicativo em si. Em resumo, seus cliques no site estavam “protegidos”, mas suas ações dentro do aplicativo podiam ser monitoradas.

Como se proteger

Abolir totalmente esses aplicativos da sua vida é, obviamente, a opção mais infalível, mas não é a mais realista. Além disso, não há garantia de que você possa realmente destruir os dados já coletados, mesmo se excluir sua conta. Nós já falamos sobre o processo extenuante de remover suas informações dos bancos de dados das corretoras de dados; é possível, mas gera uma enorme dor de cabeça. Então, o que fazer para se manter seguro?

• Verifique as permissões antes de clicar em “Instalar”. No Google Play, vá até Descrição de aplicativos → Sobre este aplicativo → Permissões. Um rastreador de humor não precisa solicitar acesso à sua câmera, microfone, contatos ou localização de GPS precisa. Se isso acontecer, ele não está preocupado com o seu bem-estar, mas sim coletando dados.
• Faça um esforço e leia a política de privacidade. Nós sabemos que ninguém lê esses manifestos de várias páginas. Mas quando um serviço está espiando seus pensamentos mais íntimos, vale a pena dar uma olhada. Procure os sinais de alerta: a empresa compartilha dados com terceiros? Você consegue excluir manualmente seus registros? Está explícito que a política abrange o aplicativo em si ou ela cobre apenas o site? Você sempre pode inserir o texto da política em uma IA e solicitar que ela sinalize qualquer violação de privacidade.
• Verifique a data da última atualização. Um aplicativo que não recebe uma atualização há mais de seis meses provavelmente é um terreno fértil para vulnerabilidades não corrigidas. Lembre-se: seis dos dez aplicativos testados pela Oversecured não eram atualizados há meses.
• Desative tudo o que não é essencial nas configurações de privacidade do telefone. Sempre que solicitado, selecione “pedir para não rastrear”. Quando um aplicativo pede que você ative um tipo específico de acompanhamento alegando que é para fins de “otimização interna”, quase sempre é uma jogada de marketing e não uma necessidade funcional. No fim das contas, se o aplicativo realmente não funcionar sem uma determinada permissão, você sempre poderá ativá-la mais tarde.
• Não use os serviços “Fazer login com…”. A autenticação por meio do Facebook, Apple, Google ou Microsoft cria identificadores adicionais e dá às empresas uma oportunidade de ouro para vincular seus dados em diferentes plataformas.
• Trate tudo o que você digita como se fosse uma postagem em uma rede social. Se você não quer que um estranho aleatório na Internet leia o que você publica, provavelmente não deveria digitar informações em um aplicativo com mais de 150 vulnerabilidades que não recebe um patch desde o ano retrasado.

O que mais você deve saber sobre configurações de privacidade e controle dos seus dados pessoais on-line:

• Corretoras de dados de geolocalização: o que essas empresas fazem e o que acontece quando há vazamentos
• Descubra por que os corretores de dados criam dossiês sobre você e como impedir que eles façam isso
• Como desaparecer da Internet
• Como reduzir sua pegada digital
• Como os smartphones criam um dossiê sobre você

É possível que um computador seja infectado por malware simplesmente ao processar uma foto? Especialmente se esse computador for um Mac, que muitos ainda acreditam, de forma equivocada, ser inerentemente resistente a malware? A resposta é sim. Isso pode ocorrer se você estiver utilizando uma versão vulnerável do ExifTool ou um dos inúmeros aplicativos desenvolvidos com base nele. O ExifTool é uma solução de código aberto amplamente utilizada para ler, gravar e editar metadados de imagens. Trata-se da ferramenta de referência para fotógrafos e arquivistas digitais, sendo também muito empregada em análise de dados, perícia digital e jornalismo investigativo.

Especialistas da nossa equipe GReAT descobriram uma vulnerabilidade crítica, registrada como CVE-2026-3102, que é acionada durante o processamento de arquivos de imagem maliciosos contendo comandos shell incorporados em seus metadados. Quando uma versão vulnerável do ExifTool no macOS processa esse tipo de arquivo, o comando é executado automaticamente. Isso permite que um agente malicioso realize ações não autorizadas no sistema, como baixar e executar um payload a partir de um servidor remoto. Neste post, explicamos em detalhes como esse exploit funciona, apresentamos recomendações práticas de defesa e mostramos como verificar se seu sistema está vulnerável.

O que é o ExifTool?

O ExifTool é um aplicativo gratuito e de código aberto que atende a uma necessidade específica, porém crítica: extrair metadados de arquivos e permitir o processamento tanto desses dados quanto dos próprios arquivos. Metadados são informações incorporadas à maioria dos formatos de arquivo modernos e que descrevem ou complementam o conteúdo principal de um arquivo. Por exemplo, em uma faixa de música, os metadados incluem o nome do artista, o título da música, o gênero, o ano de lançamento, a arte da capa do álbum e assim por diante. Em fotografias, normalmente incluem a data e hora do registro, as coordenadas GPS, as configurações de ISO e a velocidade do obturador, além da marca e do modelo da câmera. Até documentos de escritório armazenam metadados, como o nome do autor, o tempo total de edição e a data original de criação.

O ExifTool é considerado o líder do setor em termos de quantidade de formatos de arquivo compatíveis, além da profundidade, precisão e versatilidade de suas capacidades de processamento. Entre os casos de uso mais comuns estão:

• Ajustar datas se estiverem incorretamente registradas nos arquivos de origem
• Transferir metadados entre diferentes formatos de arquivo (de JPG para PNG, entre outros)
• Extrair miniaturas de pré-visualização de formatos RAW profissionais (como 3FR, ARW ou CR3)
• Recuperar dados de formatos especializados, incluindo imagens térmicas da FLIR, fotos de campo de luz da LYTRO e imagens médicas no formato DICOM
• Renomear arquivos de foto ou vídeo com base no momento real do registro e sincronizar a data e hora de criação do arquivo
• Inserir coordenadas GPS em um arquivo sincronizando-o com um log de trilha GPS armazenado separadamente ou adicionando o nome da localidade habitada mais próxima

E a lista continua. O ExifTool está disponível tanto como aplicativo autônomo de linha de comando quanto como biblioteca de código aberto, o que significa que seu código frequentemente opera nos bastidores de ferramentas mais complexas e multifuncionais. Entre os exemplos estão sistemas de organização de fotos como Exif Photoworker e MetaScope, ou ferramentas de automação de processamento de imagens como ImageIngester. Em grandes bibliotecas digitais, editoras e empresas especializadas em análise de imagens, o ExifTool costuma ser utilizado em modo automatizado, acionado por aplicativos corporativos internos e scripts personalizados.

Como a CVE-2026-3102 funciona

Para explorar essa vulnerabilidade, um invasor precisa criar um arquivo de imagem de uma forma específica. A imagem em si pode ser qualquer uma; o exploit está nos metadados, mais precisamente no campo DateTimeOriginal (data e hora de criação), que precisa estar registrado em um formato inválido. Além da data e da hora, esse campo deve conter comandos shell maliciosos. Devido à forma específica como o ExifTool manipula dados no macOS, esses comandos só serão executados se duas condições forem atendidas:

• O aplicativo ou a biblioteca estiver sendo executado no macOS
• O sinalizador -n (ou –printConv) estiver habilitado. Esse modo gera dados legíveis por máquina, sem processamento adicional. Por exemplo, no modo -n, os dados de orientação da câmera são exibidos simplesmente como “six”, enquanto, com processamento adicional, aparecem na forma mais compreensível “Rotated 90 CW”. Essa conversão para uma forma “legível por humanos” impede a exploração da vulnerabilidade

Um cenário raro, mas de forma alguma impossível, de ataque direcionado poderia ocorrer da seguinte maneira. Um laboratório forense, uma redação de jornal ou uma grande organização que processe documentação jurídica ou médica recebe um arquivo digital de interesse. Pode ser uma fotografia sensacionalista ou uma petição judicial; a isca depende da área de atuação da vítima. Todos os arquivos que entram na organização passam por triagem e catalogação em um sistema de gestão de ativos digitais (DAM). Em grandes empresas, esse processo costuma ser automatizado; profissionais autônomos e pequenas empresas executam o software necessário manualmente. Em ambos os casos, a biblioteca ExifTool precisa estar sendo utilizada nos bastidores desse software. Ao processar a data da fotografia maliciosa, o computador onde o processamento ocorre é infectado por um trojan ou um infostealer, que posteriormente pode roubar todos os dados valiosos armazenados no dispositivo comprometido. Enquanto isso, a vítima pode não perceber absolutamente nada, pois o ataque explora apenas os metadados da imagem, enquanto a própria fotografia pode ser aparentemente inofensiva, legítima e até útil.

Como se proteger da vulnerabilidade do ExifTool

Pesquisadores da equipe GReAT relataram a vulnerabilidade ao autor do ExifTool, que rapidamente lançou a versão 13.50, não suscetível à CVE-2026-3102. As versões 13.49 e anteriores devem ser atualizadas para corrigir a falha.

É fundamental garantir que todos os fluxos de processamento de imagens estejam utilizando a versão atualizada. Verifique se todas as plataformas de gestão de ativos digitais, aplicativos de organização de fotos e quaisquer scripts de processamento em lote de imagens executados em Macs estão habilitando o ExifTool versão 13.50 ou posterior, e se não contêm uma cópia incorporada mais antiga da biblioteca ExifTool.

Naturalmente, o ExifTool, como qualquer software, pode conter outras vulnerabilidades dessa mesma classe. Para reforçar a segurança, recomenda-se também:

• Isolar o processamento de arquivos não confiáveis. Processe imagens provenientes de fontes duvidosas em uma máquina dedicada ou dentro de um ambiente virtual, limitando rigorosamente o acesso desse ambiente a outros computadores, armazenamentos de dados e recursos de rede.
• Monitorar continuamente vulnerabilidades na cadeia de suprimentos de software. Organizações que dependem de componentes de código aberto em seus fluxos de trabalho podem utilizar Open Source Data Feed para acompanhamento.

Por fim, se você trabalha com freelancers ou prestadores autônomos (ou permite o uso de BYOD, Bring Your Own Device), autorize o acesso à sua rede somente se esses dispositivos tiverem uma solução abrangente de segurança para macOS instalada.

Ainda acha que o macOS é totalmente seguro? Então, vale conhecer algumas ameaças recentes direcionadas a Macs:

• Banshee: um malware de roubo de dados que persegue usuários do macOS
• Os Macs são seguros? Ameaças aos usuários do macOS
• O Infostealer entrou no chat
• AirBorne: Ataques a dispositivos da Apple através de vulnerabilidades no AirPlay
• Invasão de Android, macOS, iOS e Linux por meio de uma vulnerabilidade do Bluetooth

O avanço das fraudes digitais, especialmente as associadas ao roubo de cookies e sequestro de sessões, tem pressionado os modelos tradicionais de autenticação. Durante anos, a autenticação multifator (MFA) combinando senhas com SMS, tokens ou aplicativos autenticadores foi considerada suficiente para garantir acesso seguro. Contudo, o cenário de ameaças mudou de maneira radical. A explosão de malwares infostealers, ataques adversary-in-the-middle (AiTM), botnets e técnicas avançadas de phishing expôs uma fragilidade e mostrou que o MFA tradicional valida apenas o momento inicial do acesso, mas não protege a sessão ativa. Assim, quando um cookie é roubado, o invasor pode assumir a conta sem repetir o processo de login, explorando um ponto cego crítico para os métodos de autenticação clássicos.

Nesse contexto, a biometria comportamental surge como uma resposta altamente eficaz. Ao contrário dos fatores convencionais, que se baseiam no que o usuário sabe ou possui, ela se fundamenta em como o usuário se comporta. Ritmo de digitação, microvariações neuromusculares, padrões de movimentação do mouse, cadência de navegação e até pequenas rotinas motoras tornam-se sinais computáveis de identidade. A singularidade desses padrões cria um fator comportamental extremamente difícil de reproduzir, mesmo por atacantes humanos assistidos por IA ou bots avançados. Ao ser incorporada às plataformas modernas de IAM (Identity and Access Management), essa abordagem transforma a autenticação de um evento isolado para um processo contínuo.

O usuário não prova quem é apenas no login, ele confirma sua identidade a cada interação, de forma invisível e sem fricção. Quando ocorre qualquer mudança significativa no padrão comportamental, seja brusca ou mesmo sutil, o sistema reage com adaptações dinâmicas. Pequenas variações podem solicitar um desafio adicional, desvios maiores podem restringir ações críticas, e anomalias graves levam ao encerramento imediato da sessão. Esse monitoramento contínuo elimina precisamente o ponto cego explorado pelo roubo de sessões.

O setor financeiro, constantemente pressionado pelo dilema entre elevar a segurança e preservar uma experiência positiva do cliente, encontra aqui uma solução equilibrada. A biometria comportamental opera de maneira “invisível” e elimina dependências excessivas de desafios explícitos, reduzindo atritos e aumentando a resiliência contra fraudes baseadas em credenciais legítimas. Mesmo que um invasor possua senha, código MFA e cookie válido, ele não consegue replicar com precisão o comportamento cognitivo e motor do usuário real. Isso reduz de forma substancial tanto a eficácia do roubo de sessão quanto o sucesso de ataques que dependem de engenharia social.

Essa transformação também afeta a maneira como o MFA é compreendido. Ele não está sendo substituído, o que está contecendo na verdade é que ele está evoluindo para um modelo adaptativo, contextual e comportamental, no qual a confiança é recalculada continuamente, não apenas no instante do login. O MFA deixa de ser uma barreira estática e passa a integrar uma arquitetura de risco dinâmica, capaz de responder em tempo real ao comportamento do usuário e ao contexto da interação.

Do ponto de vista operacional, a biometria comportamental também reforça mecanismos de detecção de bots. Enquanto é relativamente fácil para um bot inserir códigos MFA ou repetir ações mecânicas, replicar comportamentos é praticamente impossível, pois trata-se de ações, muitas vezes involuntärias, neuromusculares, padrões motores consistentes ou a “assinatura digital” que caracteriza um ser humano. Isso amplia a capacidade de defesa contra fraude automatizada e ataques em escala.

Plataformas modernas já incorporam essa visão, como Microsoft Entra ID, Okta Adaptive MFA, BioCatch, LexisNexis Behavioral Biometrics e soluções avançadas de risco que utilizam sinais de identidade baseados em IA. Esses sistemas combinam análise comportamental, machine learning e detecção contínua de anomalias para identificar substituição de identidade, uso indevido de credenciais e tentativas de viver dentro da sessão comprometida.

A tendência é inexorável, as organizações que enxergam a autenticação apenas como um ponto de verificação isolado estarão cada vez mais expostas a riscos sofisticados. Por outro lado, aquelas que integram sinais comportamentais ao seu IAM estarão melhor preparadas para enfrentar a nova geração de fraudes digitais, onde o roubo de identidade tornou-se silencioso, persistente e altamente automatizado. A biometria comportamental não apenas reforça a segurança, mas redefine a própria noção de identidade digital ao transformar cada ação do usuário em uma confirmação de legitimidade.

Por vezes, a segurança mais forte é a que o usuário nem percebe.

Milhões de sistemas de TI, sendo que alguns deles são industriais e outros de IoT, podem começar a se comportar de forma imprevisível em 19 de janeiro. As possíveis falhas incluem: falhas no processamento pagamentos com cartão; alarmes falsos de sistemas de segurança; operação incorreta de equipamentos médicos; falhas nos sistemas automatizados de iluminação, aquecimento e abastecimento de água; e muitos tipos de erros mais ou menos graves. O problema é que… isso acontecerá em 19 de janeiro de 2038. Não que isso seja motivo para relaxar, muito pelo contrário! O tempo restante para providenciar os preparativos talvez seja insuficiente. A causa dessa infinidade de problemas será um estouro nos números inteiros que armazenam data e hora. Embora a causa raiz do erro seja simples e clara, corrigi-lo exigirá esforços extensos e sistemáticos em todos os níveis : de governos e organismos internacionais a organizações e indivíduos.

O padrão informal da Época Unix

A Época Unix é o sistema de cronometragem adotado pelos sistemas operacionais Unix que se tornou popular em todo o setor de TI. Ele conta os segundos de 00:00:00 UTC em 1º de janeiro de 1970, considerado o ponto zero. Qualquer momento no tempo é representado como o número de segundos que se passaram desde aquela data. Para datas anteriores a 1970, são usados valores negativos. Essa abordagem foi escolhida pelos desenvolvedores do Unix por sua simplicidade, em vez de armazenar o ano, mês, dia e hora separadamente, apenas um único número é necessário. Isso facilita operações como classificar ou calcular o intervalo entre datas. Hoje, a Época Unix é usada muito além dos sistemas Unix: em bancos de dados, linguagens de programação, protocolos de rede e em smartphones executando iOS e Android.

A bomba-relógio Y2K38

Inicialmente, quando o Unix foi desenvolvido, foi tomada a decisão de armazenar o tempo como um inteiro com sinal de 32 bits. Isso permitia representar um intervalo de datas de aproximadamente 1901 a 2038. O problema é que, em 19 de janeiro de 2038, às 03:14:07 UTC, esse número atingirá seu valor máximo (2.147.483.647 segundos) e sofrerá um estouro, tornando-se negativo, fazendo com que os computadores se “teletransportem” de janeiro de 2038 para 13 de dezembro de 1901. Em alguns casos, no entanto, uma “viagem no tempo” mais curta pode acontecer, até o ponto zero, que é o ano de 1970.

Esse evento, conhecido como “problema do ano 2038”, “Epochalypse” ou “Y2K38”, poderá ocasionar falhas em sistemas que ainda usam a representação de tempo de 32 bits, como terminais POS, de sistemas integrados e roteadores, passando por automóveis, até equipamentos industriais. Os sistemas modernos resolvem esse problema usando 64 bits para armazenar o tempo. Isso estende o intervalo de datas para centenas de bilhões de anos no futuro. No entanto, milhões de dispositivos com datas de 32 bits ainda estão em operação e precisarão ser atualizados ou substituídos antes da chegada do “dia Y”.

Neste contexto, 32 e 64 bits se referem especificamente ao formato de armazenamento de data. Só porque um sistema operacional ou processador é de 32 bits ou 64 bits, isso não significa automaticamente que ele armazene a data em seu formato de bits “nativo”. Além disso, muitos aplicativos armazenam datas de maneiras completamente diferentes e podem ser imunes ao problema Y2K38, independentemente de sua quantidade de bits.

Nos casos em que não há necessidade de tratar datas anteriores a 1970, a data é armazenada como um número inteiro não assinado de 32 bits. Esse tipo de número pode representar datas de 1970 a 2106, portanto, o problema chegará em um futuro mais distante.

Diferenças do problema do ano 2000

O infame problema do ano 2000 (Y2K) do final do século 20 era semelhante. Naquelas circunstâncias, os sistemas que armazenavam o ano como dois dígitos poderiam confundir a nova data com o ano 1900. Tanto os especialistas quanto a mídia temiam um apocalipse digital, mas, no fim, houve apenas numerosas manifestações isoladas que não resultaram falhas catastróficas globais.

A principal diferença entre Y2K38 e Y2K é a escala da digitalização em nossas vidas. O número de sistemas que precisarão de atualização é muito maior do que o número de computadores no século 20, e a contagem de tarefas e processos diários gerenciados por computadores está além do cálculo. Enquanto isso, o problema Y2K38 já foi, ou será muito em breve, corrigido em computadores e sistemas operacionais comuns com atualizações de software simples. No entanto, os microcomputadores que gerenciam aparelhos de ar-condicionado, elevadores, bombas, fechaduras eletrônicas e linhas de montagem industriais podem muito bem continuar operando pela próxima década com versões de software desatualizadas e vulneráveis ao Y2K38.

Possíveis problemas do Epochalypse

A passagem da data para 1901 ou 1970 afetará sistemas diferentes, de maneiras diferentes. Em alguns casos, como em um sistema de iluminação programado para ligar todos os dias às 19h, a programação poderá passar completamente despercebida. Em outros sistemas que dependem de carimbos de data/hora completos e precisos, uma falha completa poderá ocorrer – por exemplo, no ano 2000, terminais de pagamento e catracas de transporte público pararam de funcionar. Casos cômicos também são possíveis, como a emissão de uma certidão de nascimento com uma data em 1901. Muito pior seria a falha de sistemas críticos, como o desligamento completo de um sistema de aquecimento ou a falha de um sistema de análise de medula óssea em um hospital.

A criptografia ocupa um lugar especial no Epochalypse. Outra diferença fundamental entre 2038 e 2000 é o uso generalizado de criptografia e assinaturas digitais para proteger todas as comunicações. Os certificados de segurança geralmente falham na verificação se a data do dispositivo estiver incorreta. Isso significa que um dispositivo vulnerável seria eliminado da maioria das comunicações, mesmo que seus aplicativos de negócios principais não tenham nenhum código que manipule incorretamente a data.

Infelizmente, o espectro completo de consequências só poderá ser determinado por meio de testes controlados de todos os sistemas, com a análise separada de uma potencial cascata de falhas.

A exploração maliciosa do Y2K38

As equipes de TI e InfoSec devem tratar o Y2K38 não como um simples bug de software, mas como uma vulnerabilidade que poderá ocasionar várias falhas, inclusive a negação de serviço. Em alguns casos, ela poderá até mesmo ser explorada por agentes maliciosos. Para fazer isso, eles precisarão ter a capacidade de manipular a hora no sistema de destino. Isso é possível em pelo menos dois cenários:

• Interferência nos dados do protocolo NTP ao fornecer ao sistema invadido um servidor de tempo falso
• Falsificação do sinal de GPS, caso o sistema dependa da hora via satélite

A exploração desse erro é mais provável em sistemas OT e IoT, onde as vulnerabilidades são tradicionalmente lentas para serem corrigidas e as consequências de uma falha podem ser muito mais substanciais.

Um exemplo de uma vulnerabilidade facilmente explorável relacionada à contagem de tempo é CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8) nos consoles de medidor de tanque de combustível Dover ProGauge MagLink LX4. A manipulação do tempo pode causar uma negação de serviço no posto de gasolina e bloquear o acesso ao painel de gerenciamento da Web do dispositivo. Esse defeito ganhou seu próprio alerta da CISA.

O status atual da atenuação do Y2K38

Os parâmetros de resolução para o problema do Y2K38 foram estabelecidos com êxito nos principais sistemas operacionais. O kernel do Linux adicionou suporte para o tempo de 64 bits, mesmo em arquiteturas de 32 bits, a partir da versão 5.6, em 2020, e o Linux de 64 bits sempre foi protegido desse problema. A família BSD, macOS e iOS usam o tempo de 64 bits em todos os dispositivos modernos. Todas as versões do Windows lançadas no século 21 não são suscetíveis ao Y2K38.

A situação no armazenamento de dados e no nível do aplicativo é muito mais complexa. Sistemas de arquivos modernos, como ZFS, F2FS, NTFS e ReFS foram desenvolvidos com carimbos de data/hora de 64 bits, enquanto sistemas mais antigos como ext2 e ext3 permanecem vulneráveis. O Ext4 e o XFS exigem que sinalizadores específicos sejam ativados (inode estendido para ext4 e bigtime para XFS), além disso, eles podem necessitar da conversão off-line de sistemas de arquivos existentes. Nos protocolos NFSv2 e NFSv3, o formato de armazenamento de tempo desatualizado persiste. O cenário é igualmente fragmentado nos bancos de dados, o tipo TIMESTAMP do MySQL é intrinsecamente limitado ao ano de 2038 e exige migração para DATETIME, enquanto os tipos de carimbo de data/hora padrão do PostgreSQL são seguros. Para aplicativos escritos em C, os caminhos foram criados para usar o tempo de 64 bits em arquiteturas de 32 bits, mas todos os projetos precisam de recompilação. Linguagens como Java, Python e Go normalmente usam tipos que evitam o estouro, mas a segurança dos projetos compilados depende da possibilidade de interação com bibliotecas vulneráveis escritas em C.

Um grande número de sistemas de 32 bits, dispositivos integrados e aplicativos permanecem vulneráveis até que eles sejam reconstruídos e testados e, em seguida, tenham as atualizações instaladas por todos os usuários.

Várias organizações e entusiastas estão tentando sistematizar informações sobre isso, mas os esforços estão fragmentados. Consequentemente, não há um “banco de dados de vulnerabilidades Y2K38 comum” disponível (1, 2, 3, 4, 5).

Abordagens para correção do Y2K38

As metodologias criadas para priorizar e corrigir vulnerabilidades são diretamente aplicáveis ao problema do ano de 2038. O principal desafio consiste no fato de que nenhuma ferramenta contemporânea pode criar uma lista exaustiva de software e hardware vulneráveis. Portanto, é essencial atualizar o inventário de ativos de TI corporativos, garantir que ele seja enriquecido com informações detalhadas sobre firmware e software instalado e, em seguida, investigar sistematicamente a questão da vulnerabilidade.

A lista pode ser priorizada de acordo com a criticidade dos sistemas de negócios e com os dados na pilha de tecnologia na qual cada sistema está construído. As próximas etapas são: estudar o portal de suporte do fornecedor, fazer perguntas diretas aos fabricantes de hardware e software sobre seu status Y2K38 e, como último recurso, fazer a verificação por meio de testes.

Ao testar sistemas corporativos, é fundamental tomar precauções especiais:

• Nunca teste os sistemas que estão em produção.
• Crie um backup de dados imediatamente antes do teste.
• Isole o sistema em teste das comunicações, para que ele não interfira em outros sistemas da organização.
• Caso a alteração da data use NTP ou GPS, verifique e confirme se os sinais de teste do 2038 não podem alcançar outros sistemas.
• Após o teste, defina os horários de volta para a hora correta nos sistemas e documente minuciosamente todos os seus comportamentos observados.

Caso um sistema seja considerado vulnerável ao Y2K38, uma linha do tempo de correção deverá ser solicitada ao fornecedor. Caso uma correção seja impossível, planeje uma migração; felizmente, o tempo que nos resta ainda permite a atualização de sistemas bastante complexos e caros.

A coisa mais importante para enfrentar o Y2K38 é não pensar nele como um problema futuro distante cuja solução pode facilmente esperar mais cinco a oito anos. É altamente provável que já não tenhamos tempo suficiente para erradicar completamente o defeito. No entanto, dentro de uma organização com seu parque tecnológico, o planejamento cuidadoso e a abordagem sistemática para resolver o problema permitirão realmente fazer tudo isso em tempo hábil.

O Active Directory, serviço de diretório da Microsoft usado para gerenciar e organizar recursos de rede, continua sendo um dos principais focos dos agentes maliciosos, pois seu comprometimento garante amplo acesso acesso a todos os recursos gerenciados por ele. Esse trabalho visa realizar uma análise sobre a transição para o NetExec (nxc) em 2026, explorando como operadores de Red Team utilizam o abuso de protocolos para validar riscos e como Blue Teams constroem defesas resilientes contra movimentação lateral e abuso de credenciais.

No ecossistema de segurança cibernética de 2026, ferramentas de automação são vitais para medir a resiliência de uma rede. O CrackMapExec (CME) deu lugar ao NetExec (nxc), que se consolidou como a ferramenta para auditorias de segurança em ambientes Windows, particularmente focando no Active Directory.

Para o Red Team, o NetExec funciona como uma plataforma centralizada para execução de comandos em massa, suportando protocolos essenciais como SMB, WMI, WinRM, LDAP e MSSQL. Para o Blue Team, ele representa o “caso de teste” perfeito: se a ferramenta opera sem resistência, a visibilidade de logs do SIEM e a eficácia do EDR precisam de revisão imediata.

A força do NetExec não reside em explorar falhas de código (CVEs), mas em abusar de configurações nativas inseguras que persistem em redes corporativas.Um dos vetores mais eficazes é o Pass-the-Hash (PtH) em escala. O NetExec automatiza a tentativa de autenticação usando hashes NTLM em sub-redes inteiras, permitindo identificar rapidamente onde administradores deixaram sessões expostas ou reutilizaram credenciais em múltiplas máquinas. Complementarmente, a ferramenta realiza a enumeração silenciosa via LDAP, mapeando grupos de administradores de domínio e identificando usuários vulneráveis ao AS-REP Roasting, aqueles com “Pre-Authentication” desativada, com uma velocidade que processos manuais não alcançam.

Outro ponto crítico é o abuso de SMB Relay. Em redes onde a assinatura de pacotes (SMB Signing) não é obrigatória, o NetExec permite que o operador intercepte o tráfego e obtenha execução remota de código (RCE) sem jamais possuir uma senha válida, apenas redirecionando a autenticação de uma máquina legítima para o alvo desejado.

Para os defensores, o NetExec fornece o roteiro do que precisa ser protegido. O uso dessa ferramenta gera padrões comportamentais claros que devem ser o foco da engenharia de detecção. O primeiro indicador são as anomalias de log-on. O Blue Team deve buscar volumes atípicos de log-ons bem-sucedidos vindo de uma única origem para múltiplos destinos em um curto espaço de tempo. Além disso, o monitoramento de criação de serviços remotos é importantíssimo. O uso de módulos como do SMB gera processos de terminal ou PowerShell que devem disparar alertas imediatos nas proteções de EndPoint. Por fim, a detecção de tráfego RPC/SMB não criptografado em zonas críticas é um sinal claro de tentativa de Relay. Para neutralizar a eficácia dessas técnicas, a defesa deve implementar medidas estruturais que eliminem as vulnerabilidades de desenvolvimento exploradas pelo NetExec.

Para mitigar ataques de SMB Relay, a ação mais direta é impor o SMB Signing como obrigatório via GPO em toda a rede. Contra o Pass-the-Hash, é fundamental implementar o LAPS (Windows Local Administrator Password Solution), que garante senhas únicas para cada estação, e restringir privilégios de administradores locais para evitar a persistência lateral.

Protocolos obsoletos que facilitam o envenenamento de rede, como LLMNR e NBT-NS, devem ser desativados em favor do mDNS. Para proteger as credenciais na memória contra o LSASS Dumping, a ativação do Credential Guard do Windows é a defesa padrão em 2026. Por fim, ataques de força bruta ou Password Spraying devem ser contidos com a implementação de Autenticação de Múltiplos Fatores (MFA) em todos os pontos de acesso e políticas de bloqueio inteligente de contas.

Imagine que convidaram você para um jogo de pôquer privado com atletas famosos. Em quem você confiaria mais para embaralhar as cartas: em um crupiê ou em um dispositivo automatizado especializado? Fundamentalmente, essa questão se resume ao que você mais acredita: na honestidade do crupiê ou na confiabilidade da máquina. É provável que muitos jogadores de pôquer prefiram o dispositivo especializado, já que é muito mais difícil subornar ou coagir uma máquina do que um ser humano. No entanto, em 2023, pesquisadores de segurança cibernética demonstraram que um dos modelos mais populares, o DeckMate 2, fabricado pela Light & Wonder, é, na verdade, muito fácil de hackear.

Dois anos depois, a polícia encontrou vestígios de manipulação desses dispositivos não em um laboratório, mas em estabelecimentos. Esta postagem detalha como o embaralhador DeckMate 2 funciona, por que seu design facilita a trapaça, como os criminosos usaram o hack e o que o basquete tem a ver com tudo isso.

Como funciona o embaralhador automático de cartas DeckMate 2

O embaralhador automático DeckMate 2 começou a ser fabricado em 2012. Desde então, ele se tornou um dos modelos mais populares, usado em quase todos os principais cassinos e clubes de pôquer privados do mundo. O dispositivo é uma caixa preta, quase do tamanho de uma fragmentadora de papel comum, geralmente instalada sob a mesa de pôquer.

O DeckMate 2 é um embaralhador automático de cartas profissional que mistura rapidamente o baralho enquanto verifica se todas as 52 cartas estão presentes e se nenhuma carta extra foi inserida. Fonte

Na superfície da mesa, é possível ver apenas um pequeno compartimento onde as cartas são colocadas para serem embaralhadas. É provável que a maioria dos jogadores comuns não perceba que a parte “submersa” do “iceberg” é muito maior e mais complexa do que parece à primeira vista.

É assim que o DeckMate 2 se parece quando é instalado em uma mesa de jogo: a parte divertida está escondida sob a superfície. Fonte

Depois que o crupiê coloca o baralho dentro do DeckMate 2, a máquina faz as cartas passarem pelo módulo de leitura, uma a uma. Nesse estágio, o dispositivo verifica se o baralho contém todas as 52 cartas e nada além delas. Se houver algo fora do normal, a tela conectada exibirá um alerta. Depois, a máquina embaralha as cartas e devolve o baralho ao crupiê.

O DeckMate 2 leva apenas 22 segundos para embaralhar e verificar as cartas. A verificação de cartas ausentes ou extras é feita por uma câmera interna que confere todas. Ela também participa da ordenação do baralho. É difícil imaginar o uso prático desse último recurso em jogos de cartas. Supõe-se que os designers o adicionaram apenas porque podiam.

Seguindo adiante, foi exatamente essa câmera que literalmente permitiu que pesquisadores e infratores visualizassem a sequência das cartas. O modelo anterior, chamado Deck Mate, não tinha essa câmera e, portanto, não oferecia uma maneira de espiar a ordem das cartas.

Para impedir a ação de hackers, o DeckMate 2 utiliza uma verificação de hash que garante que o software permaneça inalterado após a instalação. Na inicialização, o dispositivo calcula o hash do firmware e o compara com a referência armazenada na sua memória. Se os valores coincidirem, a máquina entende que o firmware está íntegro e prossegue. Caso contrário, identifica uma tentativa de adulteração.

Além disso, o design do DeckMate 2 inclui uma porta USB, que é usada para carregar atualizações de firmware. Os dispositivos DeckMate 2 também podem ser alugados da Light & Wonder em um modelo de pagamento por uso, em vez de adquiridos. Nesse caso, é comum eles estarem equipados com um modem celular que transmite dados de uso ao fabricante para fins de cobrança.

Como os pesquisadores conseguiram comprometer o DeckMate 2

Os leitores de longa data do nosso blog provavelmente já detectaram várias falhas no design do DeckMate 2 que foram exploradas pelos pesquisadores para sua prova de conceito. Eles fizeram uma demonstração na conferência de segurança cibernética Black Hat em 2023.

A primeira etapa do ataque foi conectar um pequeno dispositivo à porta USB. Para a prova de conceito, os pesquisadores usaram um microcomputador Raspberry Pi, que é menor do que a palma da mão de um adulto. No entanto, eles observaram que, com recursos suficientes, os infratores conseguem executar o mesmo ataque usando um módulo ainda mais compacto, que tem o tamanho de uma unidade flash USB padrão.

Depois de conectado, o dispositivo modificava o código do DeckMate 2 e assumia o controle. Isso também concedeu aos pesquisadores acesso à câmera interna mencionada acima, usada para verificar o baralho. Agora eles conseguiam visualizar a ordem exata das cartas no baralho em tempo real.

Essas informações foram transmitidas via Bluetooth para um celular próximo, onde um app experimental mostrava a sequência das cartas.

O aplicativo experimental criado pelos pesquisadores: recebe a ordem das cartas do DeckMate 2 hackeado via Bluetooth.Fonte

O sucesso do golpe depende do fato de que o cúmplice do trapaceiro mantém o celular com o app instalado. Essa pessoa pode então usar gestos discretos para o jogador trapaceiro.

O que permitiu aos pesquisadores obter esse grau de controle sobre o DeckMate 2 foi uma vulnerabilidade nas suas senhas embutidas no código. Para os testes, eles compraram vários embaralhadores usados, e um dos vendedores forneceu a eles a senha de manutenção do DeckMate 2. Os pesquisadores extraíram as senhas restantes diretamente do firmware, incluindo a senha de root.

Essas senhas de sistema no DeckMate 2 são definidas pelo fabricante e devem ser iguais em todos os aparelhos. Enquanto estudavam o código do firmware, os pesquisadores descobriram que as senhas estavam embutidas no sistema, tornando-as difíceis de alterar. Como resultado, o mesmo conjunto de senhas, conhecido por muita gente, provavelmente protege a maioria das máquinas em circulação. Isso significa que quase todos os dispositivos estão potencialmente vulneráveis ao ataque desenvolvido pelos pesquisadores.

Para burlar a verificação de hash, os pesquisadores simplesmente substituíram o hash de referência armazenado na memória. Na inicialização, o dispositivo calcularia o hash do código alterado, compararia com o valor também alterado e aceitaria o firmware como autêntico.

Os pesquisadores também notaram que modelos com modem celular poderiam ser invadidos remotamente por meio de uma estação falsa, enganando o dispositivo em vez de usar uma torre real. Embora eles não tenham testado a viabilidade desse vetor, ele não parece improvável.

Como a máfia manipulou máquinas DeckMate 2 em jogos de pôquer reais

Dois anos depois, os avisos dos pesquisadores receberam uma confirmação no mundo real. Em outubro de 2025, o Departamento de Justiça dos EUA indiciou 31 pessoas por fraudarem vários jogos de pôquer. De acordo com os documentos do caso, nesses jogos, um grupo criminoso usou vários meios técnicos para obter informações sobre as cartas dos adversários.

Esses meios incluíam cartas com marcações invisíveis detectáveis por telefones, óculos especiais e lentes de contato capazes de ler essas marcas secretamente. Mas, para o contexto desta postagem, o ponto essencial é que os golpistas também invadiram máquinas DeckMate 2, programadas para transmitir secretamente quais cartas seriam distribuídas a cada jogador.

E é aqui que finalmente vamos falar sobre basquete e atletas da NBA. De acordo com a acusação, o esquema envolveu membros de várias famílias da máfia e ex-jogadores da NBA.

A investigação revelou que os golpistas organizaram vários jogos de pôquer de alto risco ao longo de muitos anos em diversas cidades dos EUA. Vítimas ricas foram atraídas pela oportunidade de jogar com estrelas da NBA (que negam qualquer irregularidade). Os investigadores estimam que as vítimas perderam mais de US$ 7 milhões.

Os documentos divulgados contêm um relato minucioso de como os golpistas usaram máquinas DeckMate 2 hackeadas. Em vez de alterar dispositivos DeckMate 2 de terceiros via USB (como demonstrado pelos pesquisadores), os criminosos usaram unidades já hackeadas. Houve até mesmo um caso em que membros da máfia apontaram uma arma para uma pessoa e tomaram seu dispositivo comprometido.

Apesar dessa modificação peculiar, o essencial do ataque seguiu quase igual à prova de conceito dos pesquisadores. As máquinas comprometidas do DeckMate 2 repassaram dados a um operador remoto, que os encaminhou ao telefone de um dos participantes. Os criminosos chamavam esse operador de “quarterback”. O golpista então usava sinais sutis para influenciar o jogo.

O que podemos aprender com essa história

Os fabricantes do DeckMate 2 afirmaram aos jornalistas que, após a pesquisa sobre a vulnerabilidade do dispositivo, implementaram várias alterações no hardware e no software. Essas melhorias incluíram desativar a porta USB exposta e atualizar as rotinas de verificação do firmware. Certamente, os cassinos licenciados já instalaram essas atualizações. Bem, esperamos que sim.

No entanto, a integridade desses dispositivos usados em clubes de pôquer privados e cassinos ilegais segue bastante duvidosa. Esses locais costumam usar máquinas DeckMate 2 usadas sem atualizações ou manutenção, tornando-as mais vulneráveis. E isso sem considerar quando o próprio estabelecimento pode querer manipular as máquinas.

Apesar de todos os detalhes intrigantes do hack do DeckMate 2, os precursores são comuns: senhas reutilizadas, uma porta USB e, claro, jogos não licenciados. A este respeito, o único conselho para entusiastas de jogos é evitar clubes ilegais.

A principal lição desta história é que senhas padrão devem ser trocadas em qualquer dispositivo, seja um roteador Wi-Fi ou um embaralhador de cartas. Para gerar uma senha forte e exclusiva e ser capaz de lembrá-la, use um gerenciador de senhas confiável. A propósito, você também pode usar o Kaspersky Password Manager para gerar códigos de uso único para autenticação em duas etapas.

Poucos especialistas em cibersegurança discordariam de que ataques a servidores Microsoft Exchange devem ser considerados inevitáveis e o risco de comprometimento permanece consistentemente elevado. Em outubro, a Microsoft encerrou o suporte ao Exchange Server 2019, tornando o Exchange Server Subscription Edition (Exchange SE) a única solução on-premises suportada até 2026. Apesar disso, muitas organizações continuam operando o Exchange Server 2016, 2013 e até versões ainda mais antigas.

Para agentes de ameaça, o Exchange é um alvo irresistível. Sua popularidade, complexidade, vasta quantidade de configurações e, principalmente, sua acessibilidade a partir de redes externas o tornam suscetível a uma ampla variedade de ataques:

• Infiltração de caixas de correio por meio de ataques de password spraying ou spearphishing
• Comprometimento de contas devido ao uso de protocolos de autenticação obsoletos
• Roubo de e-mails específicos mediante a injeção de regras maliciosas de fluxo de e-mail via Exchange Web Services
• Sequestro de tokens de autenticação de funcionários ou falsificação de mensagens explorando falhas na infraestrutura de processamento de e-mails do Exchange
• Exploração de vulnerabilidades do Exchange para executar código arbitrário (implantação de Web shells) no servidor
• Movimento lateral e comprometimento do servidor, em que o Exchange se torna um ponto de apoio para reconhecimento de rede, hospedagem de malware e tunelamento de tráfego
• Exfiltração de e-mails a longo prazo por meio de implantes especializados para Exchange

Para compreender de fato a complexidade e a variedade dos ataques ao Exchange, vale revisar as pesquisas sobre as ameaças GhostContainer, Owowa, ProxyNotShell e PowerExchange.

Dificultar o comprometimento do Exchange pelos invasores e reduzir o impacto de um ataque bem-sucedido não é impossível, mas exige uma série de medidas que vão desde simples alterações de configuração até migrações complexas de protocolos de autenticação. Uma revisão conjunta de medidas de defesa prioritárias foi publicada recentemente pelo Centro Canadense de Cibersegurança (CISA) e por outros órgãos reguladores de cibersegurança. Então, como começar o fortalecimento de segurança do seu Exchange on-premises?

Migração de versões EOL

A Microsoft e a CISA recomendam a transição para o Exchange SE para garantir o recebimento pontual de atualizações de segurança. Para organizações que não conseguem realizar a migração imediatamente, há uma assinatura paga de Extended Security Updates (ESU) disponível para as versões de 2016 e 2019. A Microsoft enfatiza que atualizar a versão de 2016 ou 2019 para o Exchange SE tem complexidade semelhante à instalação de uma Cumulative Update padrão.

Se, por qualquer motivo, for necessário manter em operação uma versão sem suporte, ela deve ser rigidamente isolada tanto da rede interna quanto da externa. Todo o fluxo de e-mail deve ser roteado por um gateway de segurança de e-mail especialmente configurado.

Atualizações regulares

A Microsoft lança duas atualizações cumulativas por ano, além de hotfixes de segurança mensais. Uma tarefa essencial para administradores de Exchange é estabelecer um processo para implantar essas atualizações sem demora, já que agentes maliciosos não perdem tempo em explorar vulnerabilidades conhecidas. É possível acompanhar o cronograma e o conteúdo dessas atualizações na página oficial da Microsoft. Para verificar o estado geral e a situação de atualização da sua instalação do Exchange, utilize ferramentas como SetupAssist e Exchange Health Checker.

Mitigações emergenciais

Para vulnerabilidades críticas exploradas ativamente, instruções temporárias de mitigação costumam ser publicadas no blog do Exchange e na página de mitigações do Exchange. O serviço mitigação de emergência (EM) deve estar ativado nos seus servidores Exchange Mailbox. O EM conecta-se automaticamente ao Office Config Service para baixar e aplicar regras de mitigação para ameaças urgentes. Essas medidas podem desativar rapidamente serviços vulneráveis e bloquear solicitações maliciosas por meio de regras de reescrita de URL no IIS.

Baselines de segurança

Um conjunto uniforme de configurações, abrangendo toda a organização e otimizado às suas necessidades, deve ser aplicado não apenas aos servidores Exchange, mas também aos clientes de e-mail em todas as plataformas e aos sistemas operacionais subjacentes.

Como as baselines de segurança recomendadas diferem entre sistemas operacionais e versões do Exchange, o guia da CISA faz referência aos populares e gratuitos CIS Benchmarks e às instruções da Microsoft. O CIS Benchmark mais recente foi criado para o Exchange 2019, mas também é totalmente aplicável ao Exchange SE, já que as opções de configuração atuais do Subscription Edition não diferem das do Exchange Server 2019 CU15.

Soluções de segurança especializadas

Um erro crítico cometido por muitas organizações é não instalar agentes de EDR e EPP em seus servidores Exchange. Para prevenir a exploração de vulnerabilidades e a execução de Web shells, o servidor precisa ser protegido por uma solução de segurança como Kaspersky Endpoint Detection and Response. O Exchange Server integra-se à Antimalware Scan Interface (AMSI), o que permite que ferramentas de segurança processem eventos no lado do servidor de forma eficaz.

A lista de permissão de aplicativos pode dificultar significativamente as tentativas de invasores de explorar vulnerabilidades do Exchange. Esse recurso é padrão na maioria das soluções EPP avançadas. No entanto, se for necessário implementá-lo usando ferramentas nativas do Windows, é possível restringir aplicativos não confiáveis usando App Control for Business ou AppLocker.

Para proteger funcionários e suas máquinas, o servidor deve utilizar uma solução como o Kaspersky Security for Mail Serve para filtrar o tráfego de e-mail. Isso resolve diversos desafios para os quais o Exchange on-premises, em sua configuração padrão, não possui ferramentas suficientes, como autenticação de remetentes por meio dos protocolos SPF, DKIM e DMARC, ou proteção contra spam sofisticado e spearphishing.

Se, por qualquer motivo, um EDR completo não estiver implantado no servidor, é fundamental ao menos ativar o antivírus padrão e garantir que a regra de Attack Surface Reduction (ASR) “Block Webshell creation for Servers” esteja ativada.

Para evitar a degradação de desempenho do servidor ao utilizar o antivírus padrão, a Microsoft recomenda excluir arquivos e pastas específicas das verificações.

Restrição de acesso administrativo

Invasores frequentemente elevam privilégios abusando do acesso ao Exchange Admin Center (EAC) e ao PowerShell Remoting. As boas práticas determinam que essas ferramentas sejam acessíveis apenas por meio de um número limitado de estações de trabalho com privilégios elevados (PAWs). Isso pode ser aplicado por meio de regras de firewall nos próprios servidores Exchange ou utilizando um firewall. As regras de Client Access nativas no Exchange também podem oferecer alguma utilidade nesse cenário, mas não conseguem impedir o abuso de PowerShell.

Adoção de Kerberos e SMB em vez de NTLM

A Microsoft está eliminando gradualmente protocolos de rede e de autenticação legados. Instalações modernas do Windows desativam SMBv1 e NTLMv1 por padrão, com versões futuras devendo também desativar NTLMv2. Iniciando com o Exchange SE CU1, o NTLMv2 será substituído pelo Kerberos, implementado usando MAPI over HTTP, como o protocolo de autenticação padrão.

As equipes de TI e segurança devem conduzir uma auditoria completa do uso de protocolos legados na infraestrutura e desenvolver um plano de migração para métodos modernos e mais seguros de autenticação.

Métodos de autenticação modernos

A partir do Exchange 2019 CU13, os clientes podem utilizar uma combinação de OAuth 2.0, MFA e ADFS para uma autenticação robusta: uma estrutura conhecida como Modern Authentication, ou Modern Auth. Assim, um usuário só consegue acessar sua caixa de e-mail após concluir com sucesso a MFA via ADFS, com o servidor Exchange recebendo então um token de acesso válido do servidor ADFS. Depois que todos os usuários tiverem migrado para Modern Auth, a autenticação básica deve ser desativada no servidor Exchange.

Ativação do Extended Protection

O Extended Protection (EP) fornece defesa contra ataques de retransmissão NTLM, Adversary-in-the-Middle, e técnicas semelhantes. Ela aprimora a segurança TLS usando um Channel Binding Token (CBT). Se um invasor roubar credenciais ou um token e tentar usá-los em uma sessão TLS diferente, o servidor encerra a conexão. Para ativar o EP, todos os servidores Exchange devem estar configurados para usar a mesma versão do TLS.

O Extended Protection é ativado por padrão em novas instalações de servidor iniciando com o Exchange 2019 CU14.

Versões seguras de TLS

Toda a infraestrutura de servidores, incluindo todos os servidores Exchange, deve estar configurada para usar a mesma versão de TLS: 1.2 ou, idealmente, 1.3. A Microsoft oferece orientações detalhadas sobre a configuração ideal e verificações prévias necessárias. É possível usar o script Health Checker para verificar a correção e uniformidade dessas configurações.

HSTS

Para garantir que todas as conexões estejam protegidas por TLS, também é necessário configurar o HTTP Strict Transport Security (HSTS). Isso ajuda a prevenir certos ataques AitM. Após aplicar as alterações de configuração do Exchange Server recomendadas pela Microsoft, todas as conexões ao Outlook on the Web (OWA) e ao EAC serão forçadas a usar criptografia.

Download Domains

O recurso Download Domains fornece proteção contra certos ataques de falsificação de solicitação entre sites e roubo de cookies, movendo o download de anexos para um domínio diferente daquele que hospeda o Outlook on the Web da organização. Isso separa o carregamento da interface e da lista de mensagens do download de arquivos anexados.

Modelo de administração baseado em funções

O Exchange Server implementa um modelo de controle de acesso baseado em funções (RBAC) para usuários privilegiados e administradores. A CISA destaca que contas com privilégios de administrador do AD muitas vezes também são usadas para gerenciar o Exchange. Nessa configuração, o comprometimento do servidor Exchange leva imediatamente ao comprometimento total do domínio. Portanto, é fundamental usar permissões divididas e RBAC para separar o gerenciamento do Exchange de outros privilégios administrativos. Isso reduz o número de usuários e administradores com privilégios excessivos.

Assinatura de fluxos do PowerShell

Administradores frequentemente usam scripts PowerShell conhecidos como cmdlets para modificar configurações e gerenciar servidores Exchange por meio do Exchange Management Shell (EMS). O acesso remoto ao PowerShell deve, idealmente, ser desativado. Quando estiver ativado, os fluxos de dados de comando enviados ao servidor devem ser protegidos com certificados. Desde novembro de 2023, essa configuração está ativada por padrão para Exchange 2013, 2016 e 2019.

Proteção de cabeçalhos de e-mail

Em novembro de 2024, a Microsoft introduziu uma proteção aprimorada contra ataques que envolvem a falsificação de cabeçalhos P2 FROM, que levava as vítimas a acreditarem que os e-mails tinham sido enviados por um remetente confiável. Novas regras de detecção agora sinalizam e-mails em que esses cabeçalhos provavelmente foram manipulados. Administradores não devem desativar essa proteção e devem encaminhar e-mails suspeitos contendo o cabeçalho X-MS-Exchange-P2FromRegexMatch para especialistas em segurança para análise adicional.

[Kaspersky Next banner]

Câmeras veiculares, populares em alguns países e ilegais em outros, geralmente são vistas como um seguro em caso de acidente ou disputa no trânsito. Mas uma equipe de pesquisadores de segurança cibernética de Singapura tem outra visão. Eles consideram as câmeras veiculares off-line uma base adequada para um sistema de vigilância em massa: e mais, capaz de se expandir automaticamente. Eles apresentaram os detalhes de sua pesquisa no Security Analyst Summit 2025.

O potencial de espionagem de uma câmera veicular

Então, como um dispositivo off-line pode ser usado para vigilância? Bem, embora seja verdade que a maioria das câmeras veiculares não está equipada com um cartão SIM ou conectividade 4G/5G, mesmo modelos baratos têm Wi-Fi. Isso permite que o telefone do motorista se conecte ao dispositivo por meio de um aplicativo móvel para ajustar configurações, baixar vídeos e para outros fins. E, como sabemos, muitas câmeras veiculares permitem ignorar a etapa de autenticação, o que possibilita que um agente mal-intencionado se conecte a elas a partir do próprio dispositivo e então baixe os dados armazenados.

Um invasor tem muito a ganhar com isso. Primeiro, há o vídeo de alta resolução, que mostra claramente placas e sinais de trânsito. Alguns modelos de câmeras veiculares também gravam o interior do carro, e outros possuem lentes grande-angulares e/ou câmeras traseiras. Em segundo lugar, as câmeras veiculares podem gravar áudio, principalmente conversas dentro do veículo. Terceiro, essas gravações de áudio e vídeo levam carimbos de data e hora precisos, além de tags de GPS.

Portanto, ao baixar dados de uma câmera veicular, alguém pode rastrear os movimentos do proprietário, obter imagens dos locais onde ele dirige e estaciona, descobrir sobre o que se fala no carro e, muitas vezes, obter fotos e vídeos dos passageiros do veículo ou de pessoas próximas ao carro. Naturalmente, para a vigilância direcionada, o hacker precisaria comprometer uma câmera veicular específica, enquanto para a vigilância em massa, ele precisaria comprometer um grande número de dispositivos.

Vetores de ataque para câmeras veiculares

Os pesquisadores iniciaram seus experimentos com uma popular câmera veicular Thinkware, mas rapidamente ampliaram o escopo do estudo para incluir duas dúzias de modelos de cerca de 15 marcas diferentes.

Eles descobriram muitas semelhanças no funcionamento dos diferentes dispositivos. A conexão inicial normalmente é feita a um ponto de acesso Wi-Fi criado pela própria câmera veicular, usando o SSID e a senha padrão do manual.

A maioria dos modelos testados pelos pesquisadores tinha uma senha codificada, permitindo que um invasor estabelecesse uma conexão com eles. Uma vez conectado, o hacker obtém acesso a uma configuração familiar encontrada em outros gadgets de IoT: um processador ARM e uma versão leve do Linux. O invasor então tem à disposição um arsenal de truques comprovados para burlar a autenticação do fabricante, projetada para distinguir o proprietário de um usuário não autorizado. Pelo menos um desses métodos normalmente funciona:

• Acesso direto ao arquivo. Enquanto o minúsculo servidor Web na câmera veicular aguarda que um cliente envie uma senha no ponto de entrada oficial, as solicitações maliciosas para downloads diretos de vídeo geralmente passam sem uma verificação de senha
• Falsificação de endereço MAC. Muitas câmeras veiculares verificam a identidade do proprietário confirmando o endereço MAC exclusivo do adaptador Wi-Fi do smartphone. O invasor pode captar o endereço via ondas de rádio e depois usar uma forma falsificada em suas próprias requisições, o que basta para estabelecer a conexão
• Ataque de reprodução. Ao simplesmente gravar toda a troca de dados Wi-Fi entre a câmera veicular e o smartphone do proprietário durante uma conexão legítima, o invasor pode reproduzir essa gravação posteriormente para obter as permissões necessárias

A maioria dos serviços on-line está protegida contra esses tipos de ataques há anos, senão décadas. No entanto, essas vulnerabilidades clássicas do passado ainda são comumente descobertas em dispositivos incorporados.

Para que usuários possam revisar rapidamente arquivos gravados na tela do celular ou até acompanhar uma transmissão ao vivo da câmera, as câmeras veiculares geralmente operam múltiplos servidores semelhantes aos utilizados na Internet. Um servidor FTP permite downloads rápidos de arquivos, enquanto um servidor RTSP transmite vídeo ao vivo e assim por diante. Em teoria, esses servidores possuem segurança própria baseada em senha para protegê-los contra acessos não autorizados. Na prática, eles geralmente usam uma senha padrão, codificada, idêntica para cada unidade daquele modelo, uma senha que pode ser facilmente extraída do aplicativo móvel do fabricante.

O hack como chave-mestra

Por que os pesquisadores estão convencidos de que esses dispositivos podem ser comprometidos em grande escala? Devido a dois fatores principais:

• Alguns poucos modelos populares de câmeras veiculares representam a maior parte do mercado. Por exemplo, em Singapura, quase metade de todas as câmeras veiculares vendidas pertence à marca IMAKE
• Modelos diferentes, às vezes de marcas diferentes, têm arquiteturas de hardware e software muito semelhantes. Isso ocorre porque esses fabricantes de câmeras veiculares obtêm seus componentes e firmware do mesmo desenvolvedor

Consequentemente, um único código malicioso capaz de testar algumas dezenas de senhas e aplicar três ou quatro métodos distintos de ataque pode comprometer com sucesso cerca de um quarto das câmeras veiculares em um ambiente urbano real.

Na versão inicial do ataque, os pesquisadores modelaram um cenário semiestacionário. Nessa configuração, um invasor com um laptop estaria em um local onde os carros param por alguns minutos, como um posto ou drive-through. Contudo, investigações posteriores revelaram algo ainda mais preocupante: todo o ataque pode ser realizado diretamente na própria câmera veicular! Eles conseguiram escrever um código que funciona como um worm de computador: uma câmera veicular infectada tenta se conectar e comprometer as câmeras veiculares de carros próximos enquanto o veículo está em movimento. Isso é viável quando os veículos trafegam a velocidades semelhantes, como em congestionamentos.

Do ataque em massa à vigilância em massa

Os autores do estudo não se limitaram a provar que o hack era possível; eles desenvolveram um sistema completo para coleta e análise de dados. Os dados de câmeras veiculares comprometidas podem ser enviados à central diretamente para o computador do invasor, por exemplo, um posto de gasolina, ou por meio de recursos de nuvem integrados às câmeras.

Alguns modelos de câmeras veiculares são equipados com um módulo LTE, permitindo que o código malicioso envie dados diretamente ao controlador do botnet. Mas também há uma opção para modelos mais simples. Por exemplo, uma câmera veicular pode conseguir carregar dados em um smartphone, que os sincroniza com a nuvem do fornecedor, ou o dispositivo pode encaminhar dados para outras câmeras veiculares, que então os encaminham ao invasor.

Às vezes, a segurança inadequada do armazenamento em nuvem permite que os dados sejam extraídos de maneira direta, especialmente se o invasor conhecer os identificadores de usuário armazenados na câmera.

O invasor pode combinar vários métodos para analisar os dados coletados:

• Extração de metadados de GPS de fotos e vídeos
• Analisar imagens de vídeo para detectar sinais de trânsito e reconhecer texto, identificando ruas e pontos de referência específicos
• Uso de um serviço semelhante ao Shazam para identificar músicas tocando no carro
• Usar modelos da OpenAI para transcrever áudio e gerar um resumo conciso de todas as conversas dentro do veículo

O resultado é um resumo breve e informativo de cada viagem: a rota, o tempo de viagem e os assuntos discutidos. À primeira vista, o valor desses dados parece limitado porque são anônimos. Na realidade, a desanonimização não é um problema. Às vezes, o nome do proprietário ou a placa do veículo são explicitamente listados nas configurações da câmera. Além disso, ao analisar a combinação de locais frequentemente visitados (como casa e trabalho), torna-se relativamente fácil identificar o proprietário da câmera veicular.

Conclusões e estratégias de defesa

As recentes revelações sobre a parceria entre a Flock e a Nexar ressaltam como as câmeras veiculares podem de fato se tornar um elo valioso em um sistema global de vigilância e monitoramento de vídeo. A Flock opera a maior rede de câmeras automáticas de leitura de placas para a polícia nos Estados Unidos, enquanto a Nexar mantém uma rede de câmeras veiculares conectadas à nuvem, projetadas para criar uma “visão colaborativa” das estradas.

No entanto, a invasão em massa de câmeras veiculares pode levar a um esforço de coleta de dados muito mais agressivo e malicioso, com informações sendo usadas para esquemas criminosos e fraudulentos. O combate a essa ameaça é, principalmente, responsabilidade dos fornecedores, que precisam adotar práticas de desenvolvimento seguras (Security by Design), implementar criptografia robusta e aplicar outros controles técnicos. Para os motoristas, as opções de autodefesa são limitadas e dependem muito dos recursos específicos de seu modelo de câmera veicular. Listamos abaixo essas opções, da mais à menos radical:

• Adquira um modelo sem os recursos LTE, Wi-Fi e Bluetooth. Essa é a alternativa mais segura
• Desative completamente o Wi-Fi, o Bluetooth e os outros recursos de comunicação na câmera veicular
• Desative a gravação de áudio e, se possível, desconecte fisicamente o microfone
• Desative o modo estacionamento. Esse recurso mantém a câmera veicular sempre ativa para registrar incidentes enquanto o carro está estacionado. No entanto, esse recurso consome toda a bateria do carro e, muito provavelmente, mantém o Wi-Fi ativado, o que aumenta significativamente o risco de uma invasão
• Verifique as configurações de Wi-Fi disponíveis na câmera veicular:
  • Se houver desligamento automático do Wi-Fi após certo tempo, configure-o para o menor tempo possível
  • Se puder alterar a senha padrão do Wi-Fi ou o nome da rede (SSID), não deixe de fazer isso
  • Se houver uma opção para ocultar o nome da rede (geralmente chamada de SSID Oculto, Transmissão Wi-Fi Desativada ou Modo Furtivo), ative-a
• Atualize regularmente o firmware da câmera veicular e seu aplicativo de smartphone emparelhado. Isso aumenta as chances de que vulnerabilidades, como as descritas neste artigo, sejam corrigidas ao instalar uma versão mais recente.

Os carros modernos também são suscetíveis a outros tipos de ataques cibernéticos:

• Hackers na estrada: ameaças cibernéticas a carros conectados
• Carros hackeados via Bluetooth
• Como milhões de carros Kia podem ser rastreados
• Eu sei o que você fez (no volante) no verão passado
• Espiões sobre rodas: como as montadoras coletam e revendem informações

Os ataques de ransomware estão longe de desacelerar. No último ano, foram registradas 11.796 vítimas diretas desse tipo de ciberataque ao redor do mundo, 1,3 vítimas por hora, segundo dados do BTTng da Apura Cyber Intelligence, plataforma de inteligência em ameaças cibernéticas. O impacto vai além dos números: empresas paralisadas, serviços essenciais comprometidos e milhões de pessoas expostas a riscos iminentes.

A onda de ataques abrange qualquer empresa de todos os segmentos, desde a saúde até os serviços públicos. Em maio passado, a Ascension Healthcare, uma das maiores operadoras de saúde dos EUA, foi alvo de um ataque cibernético que comprometeu sistemas críticos, incluindo registros médicos e comunicação interna. Hospitais ficaram sem acesso a informações essenciais por semanas, forçando equipes a recorrerem a procedimentos manuais. “Isso gerou riscos reais, com erros relatados no Kansas e em Detroit, que poderiam ter resultado em graves consequências médicas”, explica Anchises Moraes, Especialista de Theat Intel da Apura.

A Ascension não divulgou oficialmente o grupo por trás do ataque, mas investigações apontam para o Black Basta. Sete dos vinte e cinco mil servidores foram comprometidos, e 5,6 milhões de indivíduos receberam notificações sobre o possível vazamento de dados.

No Brasil, a TOTVS foi alvo do grupo BlackByte, com relatos de que dados da empresa foram acessados. A companhia informou seus acionistas, garantindo a continuidade dos serviços, mas sem dissipar completamente a incerteza. Já a Sabesp sofreu um ataque do grupo RansomHouse, que não apenas roubou dados, mas também os publicou posteriormente.

O futuro dos ataques: alvos menores, impactos maiores

Se antes os criminosos miravam grandes corporações exigindo valores exorbitantes, a tendência é que ataques menores, porém em massa, ganhem força em todo o mundo, incluindo o Brasil. Pequenas e médias empresas se tornaram alvos fáceis, já que possuem menos recursos para segurança e maior propensão a pagar resgates. “Elas têm mais dificuldade em recuperar dados roubados ou encriptados, tornando-se presas ideais para esses criminosos”, alerta Anchises.

A expansão internacional do grupo de cibercriminosos conhecido como Scattered Spider acendeu um sinal de alerta entre empresas latino-americanas. Especialistas em segurança apontam que, embora não haja registros confirmados de ataques desse grupo no Brasil ou vizinhos até o momento, seu alcance global e métodos sofisticados representam um risco iminente para organizações na região.

Com táticas de engenharia social elaboradas e capacidade de driblar defesas tradicionais, o Scattered Spider tem mirado grandes empresas em diversos países. “A questão não é mais ‘se’ seremos atacados, mas de ‘quando’ e ‘como’, afirma Felipe Guimarães, Chief Information Security Officer da Solo Iron. “As táticas empregadas pelo grupo exploram fragilidades universais, presentes em empresas em todo o mundo – o que inclui as empresas latino-americanas”, pondera o especialista.

Um dos maiores riscos é que os setores visados pelo Scattered Spider no exterior também são pilares econômicos na América Latina. O grupo historicamente focou suas ações em empresas de telecomunicações, terceirização de processos de negócios (BPO) e grandes empresas de tecnologia – indústrias que possuem ampla presença na região. Nos últimos tempos, foi observado um aumento de interesse do grupo pelo setor financeiro global, o que inclui bancos e instituições presentes no Brasil e países vizinhos.

“Isso significa que companhias latino-americanas, seja diretamente ou através de filiais e parceiras, podem entrar na mira à medida que o Scattered Spider amplia seu raio de atuação. Mesmo empresas que não operam internacionalmente devem se precaver, pois os criminosos podem enxergar organizações locais como pontes de entrada para fornecedores ou clientes globais, ou simplesmente como alvos lucrativos por si sós, caso identifiquem falhas de segurança exploráveis”, pontua Guimarães.

Na mira das agências de inteligência

Relatórios do FBI e da Agência de Segurança Cibernética e de Infraestrutura (CISA) dos EUA descrevem o Scattered Spider como “especialista em engenharia social”, empregando diversas técnicas para roubar credenciais e burlar autenticações.

Entre os métodos documentados estão phishing por e-mail e SMS (smishing), ataques de vishing (ligações telefônicas fraudulentas) em que os criminosos se passam por equipe de TI da própria empresa, e até esquemas elaborados de SIM swap – quando convencem operadoras de telefonia a transferir o número de celular de uma vítima para um chip sob controle deles. Essas táticas permitem interceptar códigos de autenticação multifator (MFA) enviados via SMS ou aplicativos, dando aos invasores as chaves para acessar sistemas internos.

Alguns incidentes recentes no cenário latino-americano já envolveram vetores parecidos, como uso de ferramentas legítimas em ataques e exploração de credenciais vazadas, o que reforça a necessidade de vigilância. Em 2024, por exemplo, houve casos de gangues de ransomware operando na região que abusaram de softwares legítimos e brechas em procedimentos internos de empresas, aplicando práticas muito similares ao do Scattered Spider.

Estratégias de mitigação

Diante da crescente ameaça representada por grupos como o Scattered Spider, Guimarães recomenda a adoção de estratégias com foco especial em fortalecer métodos avançados de autenticação multifator (MFA), preferencialmente resistentes a phishing, como chaves físicas de segurança ou soluções baseadas em certificados digitais. Técnicas como MFA com validação numérica e a restrição do uso de SMS para autenticação são essenciais para reduzir o risco de engenharia social e ataques por fadiga de notificações, muito usados pelo grupo.

Além disso, a adoção de uma abordagem mais robusta em relação à gestão de identidades e acessos (IAM) é uma estratégia muito importante na contenção desse tipo de ameaça. “As identidades digitais estão se tornando uma nova superfície de ataque; por isso, é fundamental que as empresas implementem políticas rígidas de gestão de identidades, controle granular de acessos e monitoramento contínuo das atividades dos usuários”, destaca.

“Também é muito importante o controle rigoroso sobre ferramentas de acesso remoto e a implantação de monitoramento avançado. É recomendável que as organizações restrinjam o uso dessas ferramentas por meio de listas autorizadas e adotem sistemas robustos como EDR e DLP para identificar rapidamente atividades suspeitas”, finaliza o especialista.

Relatórios recentes revelam que as vulnerabilidades em APIs, as chamadas Interfaces de Programação de Aplicações, são responsáveis por uma parte significativa das falhas de segurança nos sistemas modernos. Um estudo da Akamai apontou que 84% dos profissionais de segurança enfrentaram incidentes relacionados a APIs entre 2023 e 2024, refletindo um aumento contínuo nos últimos três anos. Essa crescente dependência tem gerado diversas preocupações com segurança.

As APIs desempenham um papel de extrema relevância na comunicação entre sistemas e na troca de dados, sendo importantes para o funcionamento de aplicativos móveis, plataformas de e-commerce e serviços em nuvem. No entanto, a grande exposição dessas interfaces às redes aumenta o risco de ataques, sendo exemplos de ameaças comuns a autenticação e autorização fracas, a exposição de dados confidenciais e a falta de controle adequado de acesso.

De acordo com o Relatório sobre o Estado da Segurança de API de 2025 da Salt Security, a rápida expansão dos ecossistemas de API –  impulsionada pela migração para a nuvem, integração de plataformas e monetização de dados – está superando as medidas de segurança existentes, expondo as empresas a riscos ainda maiores. “Com a ampliação da interconexão de aplicações e serviços online, as APIs se tornaram alvos atrativos para cibercriminosos, tornando a proteção dessas interfaces cada vez mais estratégica para a segurança de dados”, comenta Rogerio Rutledge,  DPO da Runtalent, empresa referência em tecnologia e serviços digitais.

O executivo destaca que, para proteger as APIs e evitar que elas sejam exploradas por cibercriminosos, as empresas precisam adotar estratégias robustas de segurança. “É preciso entender que as APIs são portas abertas para os dados da organização. Assim, proteger essas interfaces exige uma abordagem proativa, que vai além da autenticação básica e da criptografia de dados. Monitorar e auditar as APIs em tempo real, implementar controles rigorosos de acesso e adotar práticas de codificação segura são medidas fundamentais para garantir a integridade e a confidencialidade das informações”, explica.

Entre as principais práticas recomendadas para fortalecer a segurança das APIs, Rutledge destaca:

1. Autenticação e autorização fortes: Implementar autenticação multifatorial (MFA) e usar tokens de segurança como OAuth 2.0 para garantir que apenas usuários autorizados acessem as APIs.
2. Validação e sanitização de entradas: Realizar a validação rigorosa de todas as entradas e saídas para evitar a injeção de códigos maliciosos.
3. Uso de criptografia robusta: Garantir que todos os dados sensíveis, tanto em trânsito quanto em repouso, sejam criptografados com protocolos seguros como TLS e AES.
4. Monitoramento e auditoria contínuos: Implementar sistemas de monitoramento em tempo real para detectar atividades suspeitas e realizar auditorias regulares para garantir que as APIs não apresentem vulnerabilidades.
5. Testes de segurança regulares: Realizar testes de penetração e análise de vulnerabilidades nas APIs de forma contínua para identificar e corrigir falhas de segurança antes que possam ser exploradas.

O gestor ressalta que, com o aumento da dependência de APIs para o funcionamento de sistemas e serviços, as empresas precisam estar preparadas para os desafios crescentes de segurança que surgem nesse cenário. “O investimento em soluções eficazes de proteção é fundamental para proteger dados sensíveis e garantir a continuidade dos negócios. Negligenciar a proteção dessas interfaces pode expor organizações a prejuízos financeiros, danos à reputação e perdas irreversíveis de confiança. Portanto, adotar uma abordagem preventiva, automatizada e alinhada às melhores práticas do setor é o caminho mais seguro para manter a integridade dos sistemas e assegurar a resiliência digital das empresas”, finaliza o executivo.

Com o avanço acelerado da inteligência artificial generativa e a naturalização do trabalho digital em escala global, o phishing ganhou novas formas e complexidade. Se antes os golpes se restringiam a e-mails genéricos com links suspeitos, hoje eles simulam comunicações internas com impressionante realismo. Para se ter uma ideia dessa transformação, de acordo com relatório da KnowBe4, somente no primeiro trimestre de 2025, 60,7% das simulações clicadas no primeiro trimestre de 2025 imitavam comunicações de equipes internas, sendo que 49,7% mencionavam diretamente o setor de Recursos Humanos.

A frequência desses ataques também revela o quanto esse tipo de ciberataque se consolidou como uma ameaça constante e altamente eficaz. Segundo dados da GreatHorn, mais da metade das organizações (57%) relata lidar com tentativas de phishing diariamente ou pelo menos uma vez por semana. Já a CSO Online aponta que 80% dos incidentes de segurança cibernética reportados atualmente têm origem nesse tipo de golpe.

Para Vinicius Gallafrio, CEO da MadeinWeb, empresa referência em soluções digitais e inteligência artificial, os ataques de phishing deixaram de ser óbvios e evoluíram para se camuflar nas práticas do dia a dia corporativo. ”Mesmo com o avanço de tecnologias de proteção, o fator humano segue como a principal porta de entrada para invasores, explorando, sobretudo, a rotina e a pressa das equipes. Esses golpes exploram a linguagem comum entre colegas, imitam padrões visuais internos e simulam urgências típicas de lideranças ou do RH. O desafio está em perceber o que parece legítimo, mas não é. Por isso, mais do que tecnologia, precisamos cultivar uma cultura de segurança entre os colaboradores”, comenta.

Diante desse novo cenário, identificar comportamentos suspeitos exige atenção a sinais cada vez mais sutis. O primeiro passo é observar mudanças no tom da mensagem: pedidos urgentes, tom de cobrança inesperado e linguagem excessivamente formal ou fora do padrão da empresa são indícios comuns.

Outra característica marcante dos golpes mais recentes é o uso de horários estratégicos para envio, como início da manhã, finais de expediente ou períodos de maior volume de trabalho. O objetivo é capturar a atenção em momentos de menor vigilância. Além disso, ferramentas corporativas como mensageiros internos e plataformas de colaboração passaram a ser usadas como canal de disseminação de phishing, imitando interações autênticas entre colegas e gestores.

Com isso, o papel das equipes de segurança da informação vai além da aplicação de políticas técnicas ou da adoção de ferramentas robustas. É preciso estabelecer uma vigilância coletiva e constante, onde cada colaborador se reconheça como elo fundamental da defesa corporativa. A identificação de padrões sutis de fraude, o questionamento de comunicações atípicas e o reporte ágil de atividades suspeitas devem fazer parte do cotidiano organizacional.

“Nenhuma tecnologia, por mais avançada que seja, substitui o olhar atento de um time bem preparado. O phishing de 2025 não engana pela técnica, mas pelo contexto, e é nisso que precisamos estar atentos. A segurança digital começa onde termina a automatização: no senso crítico humano, na colaboração e na capacidade de questionar o que parece normal demais para ser verdade”, conclui

Atualmente, quem tenta atacar a infraestrutura de uma organização raramente se depara com o luxo de uma estação de trabalho sem um Agente de EDR, portanto, os agentes maliciosos estão se concentrando em sabotar os servidores, ou os diversos dispositivos especializados conectados à rede e que possuem privilégios de acesso bastante amplos, mas não possuem proteção EDR e, muitas vezes, até recursos de registro. Anteriormente, registramos em detalhes os tipos de dispositivos de escritório vulneráveis.

Em 2025, os ataques reais focaram em dispositivos de rede (como gateways de VPN, firewalls e roteadores), sistemas de vigilância por vídeo e os próprios servidores. Mas não devemos ignorar ataques a impressoras, como o pesquisador independente Peter Geissler lembrou ao público no Security Analyst Summit 2025. Ele descreveu uma vulnerabilidade que identificou em impressoras da Canon ( CVE-2024-12649 , CVSS 9.8), que permite a execução de código malicioso nelas. E o aspecto mais curioso sobre essa vulnerabilidade é que basta enviar um arquivo aparentemente inocente para impressão para explorá-la.

Cavalo de Tróia via fonte: um ataque via CVE-2024-12649

O ataque começa ao enviar um arquivo XPS para impressão. Esse formato, criado pela Microsoft, contém todos os pré-requisitos para imprimir um documento com sucesso e é uma alternativa ao PDF. Basicamente, o XPS é um arquivo comprimido ZIP com a descrição detalhada do documento, todas as suas imagens e as fontes utilizadas. As fontes costumam ser armazenadas em TTF (TrueType Font), um formato bastante conhecido e inventado pela Apple. E é exatamente a fonte, que não costuma ser vista como perigosa, que contém o código malicioso.

O formato TTF foi projetado para que as letras pareçam idênticas em qualquer meio e mantenham as proporções independentemente do tamanho, desde o menor caractere em uma tela até o maior em um pôster impresso. Para atingir esse objetivo, cada letra pode ter instruções de fonte escritas para si, que descrevam as nuances da exibição de letras de tamanhos pequenos. Essas instruções são comandos para uma máquina virtual compacta que, mesmo sendo bastante simples, é compatível com todos os elementos básicos da programação: gerenciamento de memória, saltos e ramificação. Geissler e seus colegas estudaram como essa máquina virtual é implementada em impressoras Canon. Eles descobriram que algumas instruções de TTF são executadas de maneira não segura. Por exemplo, os comandos da máquina virtual que gerenciam a stack não verificam se há esgotamento da memória.

Como resultado, eles conseguiram criar uma fonte maliciosa. Quando um documento que contém a fonte é impresso em determinadas impressoras Canon, ele causa esgotamento do buffer da stack, grava os dados fora dos buffers da máquina virtual e, por fim, executa código no processador da impressora. O ataque inteiro é conduzido através do arquivo TTF e o restante do conteúdo do arquivo XPS é benigno. Na verdade, detectar o código malicioso mesmo dentro do arquivo TTF é bem difícil: não é muito extenso, a primeira parte contém as instruções TTF da máquina virtual, e a segunda parte é executada no sistema operacional da Canon (DryOS).

Deve-se perceber que a Canon se concentrou em proteger o firmware da impressora nos últimos anos. Por exemplo, ela usa registros de DACR e sinalizadores NX (sem execução) compatíveis com processadores ARM que limitam a capacidade de modificar o código do sistema ou de executar código em fragmentos de memória destinados exclusivamente ao armazenamento de dados. Apesar desses esforços, a arquitetura geral do DryOS não permite a implementação efetiva de mecanismos de proteção de memória, como ASLR ou stack canary, que são típicos dos sistemas operacionais maiores e modernos. Por isso que os pesquisadores ocasionalmente encontram maneiras de contornar a proteção existente. Por exemplo, nesse ataque específico, o código malicioso foi executado com êxito ao ser colocado, por meio do truque TTF, dentro de um buffer de memória direcionado a outro protocolo de impressão (IPP).

Cenário de exploração realista

A Canon afirma, no boletim que descreve a vulnerabilidade, que ela pode ser explorada remotamente se a impressora estiver acessível pela Internet. Por isso, sugerem configurar um firewall para que a impressora só possa ser usada pela rede interna do escritório. Embora seja um bom conselho e a impressora deva ser removida do acesso público, esse não é o único cenário de ataque.

Em seu relatório, Peter Geissler indicou um cenário híbrido muito mais realista. Nele, o invasor envia a um funcionário um anexo em um e-mail ou mensagem por aplicativo e, sob algum pretexto, sugere que ele seja impresso. Se a vítima enviar o documento para impressão, mesmo que dentro da rede interna da organização e sem qualquer exposição à Internet, o código malicioso será executado na impressora. Obviamente, o malware fica muito mais limitado quando ele é executado na impressora em comparação com um malware que infecta um computador. No entanto, o malware pode, por exemplo, criar um túnel ao estabelecer uma conexão com o servidor do invasor, permitindo que os invasores ataquem outros computadores na organização. Outra possibilidade para esse malware na impressora seria que todas as informações impressas na empresa sejam encaminhadas diretamente para o servidor do invasor. Para algumas organizações, como escritórios de advocacia, isso pode resultar em uma grave violação de dados.

Como se defender dessa ameaça à impressora

A vulnerabilidade CVE-2024-12649 e diversos defeitos intimamente relacionados a ela podem ser eliminados com a atualização do firmware da impressora conforme as instruções da Canon. Infelizmente, muitas organizações, mesmo as que se empenham em atualizar o software de computadores e servidores, precisam de um processo sistemático para atualizar o firmware da impressora. O processo deve ser implementado em todos os equipamentos conectados à rede de computadores.

No entanto, os pesquisadores de segurança ressaltam que há uma grande variedade de ataques voltados a equipamentos especializados. Portanto, não há garantia de que os invasores não utilizarão um exploit similar e desconhecido pelos fabricantes de impressoras ou seus clientes. Para reduzir o risco de exploração:

• Segmente a rede, limitando a capacidade da impressora de estabelecer conexões de saída e aceitar conexões de outros dispositivos e usuários não autorizados a imprimir.
• Desative todos os serviços não utilizados na impressora.
• Defina uma senha de administrador única e forte para cada impressora/dispositivo.
• Implemente um sistema de segurança abrangente dentro da organização, incluindo a instalação de EDR em todos os computadores e servidores, um firewall moderno e monitoramento de rede abrangente baseado em um Sistema SIEM.

O Android aumenta constantemente as restrições de aplicativos com o intuito de impedir que golpistas consigam usar softwares maliciosos para roubar dinheiro, senhas e informações confidenciais de usuários. No entanto, uma nova vulnerabilidade apelidada de Pixnapping é capaz de driblar todas as camadas de proteção do Android, possibilitando que um invasor leia os pixels de imagem da tela de forma imperceptível, ou seja, faça uma captura de tela.

Um aplicativo malicioso sem nenhuma permissão pode ver senhas, saldos de contas bancárias, códigos de uso único e qualquer outra informação que o usuário do Android visualizar na tela. Felizmente, no momento, o Pixnapping é apenas um projeto baseado em pesquisa e ainda não está sendo explorado ativamente por atores de ameaças. Resta esperar que o Google corrija completamente a vulnerabilidade antes que o código de ataque seja incorporado a malwares do mundo real. Atualmente, a vulnerabilidade Pixnapping (CVE-2025-48561) deve afetar todos os smartphones modernos com sistema Android, incluindo os que executam as versões mais recentes deste sistema.

Por que a captura e leitura de telas e a projeção de mídias são perigosas

Conforme demonstrado pelo SparkCat, um malware de roubo de dados que usa OCR, os atores de ameaças já dominam o processamento de imagens. Se houver uma informação valiosa em uma imagem no smartphone, o malware poderá detectá-la, executar o reconhecimento óptico de caracteres diretamente no telefone e, em seguida, extrair os dados para o servidor do invasor. O SparkCat é particularmente significativo por ter conseguido se infiltrar nos marketplaces de aplicativos oficiais, incluindo a App Store. Não seria difícil para um aplicativo malicioso infectado com Pixnapping replicar esse truque, até mesmo porque o ataque não exige permissões especiais. Um aplicativo aparentemente útil e legítimo pode enviar simultânea e silenciosamente códigos únicos de autenticação multifator, senhas de carteiras de criptomoedas e qualquer outra informação aos golpistas.

Visualizar os dados necessários conforme são exibidos, em tempo real, também é uma tática popular usada pelos agentes maliciosos. Nessa abordagem de engenharia social, eles entram em contato com a vítima por meio de um aplicativo de mensagens e a convencem, sob vários pretextos, a ativar o compartilhamento de tela.

Anatomia do ataque Pixnapping

Os pesquisadores conseguiram capturar o conteúdo de outros aplicativos combinando métodos já conhecidos de roubo de pixels de navegadores e de unidades de processamento gráfico (GPUs) de telefones ARM. Furtivamente, o aplicativo de ataque sobrepõe janelas translúcidas às informações desejadas e, em seguida, analisa como o sistema de vídeo combina os pixels das janelas em uma imagem final.

Em 2013, pesquisadores descreveram um ataque em que um site foi capaz de carregar outro dentro de sua própria janela (usando um iframe) e, ao executar operações legítimas de sobreposição e transformação de imagens, deduzir exatamente o que foi desenhado ou escrito no outro site. Embora os navegadores mais modernos tenham conseguido evitar esse ataque específico, um grupo de pesquisadores dos EUA descobriu como realizá-lo no Android.

O aplicativo malicioso envia uma chamada do sistema para o aplicativo de destino. No Android, isso é conhecido como Intent. Os Intents costumam permitir tanto a inicialização simples do aplicativo quanto a abertura imediata de um navegador a partir de uma URL específica ou de um aplicativo de mensagens a partir de uma conversa com um contato específico. O aplicativo de ataque envia um Intent desenvolvido para forçar o aplicativo alvo a renderizar a tela com as informações confidenciais. São utilizadas bandeiras especiais de inicialização ocultas. Então, o aplicativo de ataque envia um Intent de inicialização para si mesmo. Essa combinação específica de ações faz com que o aplicativo não apareça na tela da vítima, mas exiba as informações solicitadas pelo invasor em uma janela em segundo plano.

No segundo estágio do ataque, o aplicativo malicioso sobrepõe várias janelas translúcidas com a janela oculta do aplicativo afetado, cada uma delas cobrindo e desfocando o conteúdo da janela abaixo de si. Esse mecanismo complexo permanece invisível para o usuário, mas o Android calcula cuidadosamente como seria a aparência dessa combinação de janelas se o usuário a trouxesse para o primeiro plano.

O aplicativo de ataque só é capaz de ler diretamente os pixels das suas próprias janelas translúcidas; o invasor não tem acesso direto à imagem combinada final, que incorpora o conteúdo da tela do aplicativo da vítima. Para contornar essa restrição, os pesquisadores empregam dois truques engenhosos: (i) o pixel que se deseja roubar é isolado dos outros ao seu redor, sobrepondo o aplicativo da vítima com uma janela fosca com um único ponto transparente compatível com o pixel desejado; (ii) coloca-se uma camada de ampliação com o desfoque elevado habilitado por cima dessa combinação.

Como a vulnerabilidade Pixnapping funciona

Para decifrar o mush resultante e determinar o valor do pixel da janela inferior, os pesquisadores se aproveitaram de outra vulnerabilidade famosa, a GPU.zip (esse link pode se parecer com o link de um arquivo, mas conduz ao site de uma pesquisa). Essa vulnerabilidade baseia-se no fato de que todos os smartphones modernos comprimem os dados de qualquer imagem enviada da CPU para a GPU. Essa compactação não gera perdas (como um arquivo ZIP), mas a velocidade de compactação e descompactação sofre alterações dependendo das informações transmitidas. A GPU.zip possibilita que um invasor analise o tempo necessário de compactação dos dados. E ao cronometrar essas operações, o invasor pode deduzir quais dados estão sendo transferidos. Com a ajuda da GPU.zip, o pixel isolado, desfocado e ampliado da janela do aplicativo da vítima pode ser lido com êxito pelo aplicativo malicioso.

Roubar algo significativo requer que todo o processo de roubo de pixels seja repetido centenas de vezes, pois ele precisa ser feito para cada ponto separadamente. No entanto, isso é totalmente viável dentro de um curto período de tempo. Nessa demonstração em vídeo do ataque, um código de seis dígitos do Google Authenticator foi extraído com sucesso em apenas 22 segundos, enquanto o código ainda estava válido.

Como o Android protege a confidencialidade da tela

Os engenheiros do Google possuem quase duas décadas de experiência no combate a diversos ataques de privacidade, o que resultou na criação de uma defesa estratificada contra a captura ilegal de telas e vídeos. Uma lista completa dessas proteções necessitaria de várias páginas. Portanto, selecionamos apenas algumas das principais:

• O sinalizador da janela FLAG_SECURE evita que o sistema operacional faça capturas de tela do conteúdo.
• O acesso às ferramentas de projeção de mídia (que capturam o conteúdo da tela como um fluxo de mídia) requer a confirmação explícita do usuário, podendo ser feito apenas por aplicativos visíveis e ativos.
• Restrições rígidas são impostas ao acesso a serviços administrativos, como o AccessibilityService, e à capacidade de renderizar elementos do aplicativo sobre outros.
• As senhas de uso único e outros dados secretos são ocultados automaticamente ao detectar a projeção de mídia.
• O Android impede que os aplicativos acessem os dados de outros aplicativos. Além disso, os aplicativos não podem solicitar uma lista completa de aplicativos instalados no smartphone.

Infelizmente, o Pixnapping dribla todas essas restrições existentes e não exige nenhuma permissão especial. O aplicativo invasor só precisa de dois recursos fundamentais: renderizar suas próprias janelas e enviar chamadas do sistema (Intents) para outros aplicativos. Essas são as estruturas operacionais básicas do Android. Portanto, é muito difícil restringi-las.

Quais dispositivos são afetados pelo Pixnapping e como se defender

A viabilidade do ataque foi confirmada nas versões 13 a 16 do Android em dispositivos Google Pixel das gerações 6 a 9, bem como no Samsung Galaxy S25. Os pesquisadores acreditam que também seja possível executar o ataque em outros dispositivos Android, já que todos os seus mecanismos são padrão. No entanto, pode haver nuances relacionadas à implementação da segunda fase do ataque (a técnica de ampliação de pixel).

O Google lançou um patch em setembro depois de ser notificado do ataque ocorrido em fevereiro. Infelizmente, o método escolhido para corrigir a vulnerabilidade não era confiável o suficiente, e os pesquisadores rapidamente criaram uma maneira de contornar o patch. O Google planeja uma nova tentativa de eliminar a vulnerabilidade na atualização de dezembro. Quanto à GPU.zip, não há planos de lançar um patch para esse canal de vazamento de dados. Desde que a falha se tornou pública em 2024, nenhum fabricante de GPU de smartphone anunciou planos para evitá-la até o momento.

As opções do usuário para se defender contra o Pixnapping são limitadas. Recomendamos as seguintes medidas:

• Atualize imediatamente para a versão mais recente do Android com todos os patches de segurança atuais.
• Evite instalar aplicativos de fontes não oficiais e desconfie de aplicativos de lojas oficiais se forem muito novos, tiverem poucos downloads ou avaliações ruins.
• Certifique-se de usar um sistema de segurança completo no seu telefone, como o Kaspersky para Android.

Que outros métodos de ataque fora do padrão existem no Android

• Spywares que fingem ser um antivírus
• Cavalos de Troia instalados em smartphones Android falsos
• Roubo de dados durante o carregamento do smartphone
• Suas fotos de gato estão em risco: a ameaça representada pelo novo Cavalo de Troia SparkKitty
• Como o Necro Trojan atacou 11 milhões de usuários do Android