Visualização de leitura

Pontos cegos na detecção: como os arquivos poliglotas são criados

Arquivos criados com a técnica poliglota têm aparecido cada vez mais em ciberataques nos últimos anos. Eles permitem que os invasores façam o malware passar pelos filtros de e-mail e pelos verificadores de arquivos, enganem as vítimas em ataques de phishing e dificultem as investigações de incidentes. Para conseguir isso, os invasores constroem deliberadamente um arquivo que o sistema pode interpretar como formatos diferentes, dependendo do aplicativo em que ele é aberto.  Um exemplo clássico é um arquivo que pode ser tratado como uma imagem PNG ou um arquivo ZIP. Basta alterar a extensão do arquivo ou simplesmente usar um ou outro aplicativo para abri-lo.

Vamos entender por que é possível criar arquivos desse tipo, quais combinações de formatos já foram usadas em ataques reais e como as organizações podem se proteger contra essa ameaça.

Por que é possível criar arquivos poliglotas

Os formatos de dados por trás dos arquivos poliglotas raramente são exóticos. Tudo se resume a uma combinação inteligente de formatos comuns que são estruturalmente compatíveis. Os poliglotas exploram pelo menos uma das seguintes peculiaridades em determinados formatos de arquivo:

  • A maioria dos formatos de arquivo precisa ser decodificada a partir do primeiro byte, mas alguns precisam ser lidos a partir do final. O exemplo mais claro é um arquivo ZIP: um início corrompido ou ausente não impede que os aplicativos leiam o arquivo, porque todos os cabeçalhos necessários ficam no final. Isso permite que os invasores simplesmente concatenem dois arquivos (no exemplo acima, um PNG e um ZIP). A parte inicial é lida como uma imagem PNG válida, enquanto a parte final é lida como um arquivo ZIP válido.
  • Muitos formatos funcionam como bonecas russas matrioscas: embora externamente tenham uma extensão específica correspondente ao uso pretendido, internamente o arquivo é, essencialmente, um arquivo ZIP que contém os dados necessários. Esse grupo inclui documentos modernos do Office (DOCX/XLSX/PPTX), pacotes de instalação do Android (APK), arquivos de biblioteca Java (JAR) e muitos outros.
  • Alguns formatos não têm requisitos estruturais rígidos ou têm requisitos suficientemente flexíveis para que o aplicativo que processa o arquivo consiga localizar o trecho de que precisa, mesmo quando esse trecho não está no início.

O repositório Polydet no GitHub apresenta vários exemplos de combinações possíveis de arquivos para criar um arquivo poliglota. De acordo com a classificação da MITRE, essa técnica se enquadra na categoria Masquerading (T1036.008, Masquerade File Type).

Exemplos de arquivos poliglotas em ciberataques conhecidos

Análises de campanhas de malware disponíveis publicamente revelam diversos tipos de arquivos poliglotas. Os invasores adaptam todo o cenário do ataque a uma combinação específica de tipos de arquivo.

O grupo Head Mare entregou o malware PhantomPyramid como um anexo ZIP. O arquivo consistia em código executável do Windows (EXE), com um pequeno arquivo ZIP concatenado ao final. Quando a vítima abriu o arquivo compactado, ele continha um arquivo com a extensão PDF.LNK que, então, iniciava esse mesmo anexo poliglota, desta vez como um arquivo executável.

No ataque documentado pela JPCERT, os invasores criaram um arquivo que começava como PDF e era detectado como PDF pela maioria dos verificadores, mas tinha uma extensão DOC e era aberto nos aplicativos do Office como um arquivo DOC válido contendo macros maliciosas.

Os ataques que disseminaram os cavalos de Tróia StrRAT e Ratty usaram um arquivo poliglota criado a partir de um pacote de instalação assinado do Windows (MSI), com código Java malicioso (JAR) anexado ao final.

Os ataques do StrelaStealer usaram um arquivo poliglota com extensão HTML: uma biblioteca do Windows (DLL) com um documento HTML de chamariz concatenado ao final. Um atalho no arquivo compactado iniciou o arquivo duas vezes: uma vez por meio do comando start (o equivalente a um clique duplo, que abriu um navegador exibindo o documento HTML) e outra por meio do rundll32 (que iniciou a DLL maliciosa).

Em um ataque simulado, mas engenhoso, os pesquisadores concatenaram dois arquivos ZIP comuns e descobriram que diferentes ferramentas populares de compactação exibiam o arquivo combinado de maneiras diferentes: algumas mostravam apenas o primeiro arquivo compactado, outras apenas o segundo, e outras mostravam ambos ao mesmo tempo, como se fossem um único arquivo compactado com conteúdo compartilhado. Se o invasor estiver familiarizado com a infraestrutura da vítima e souber quais softwares estão instalados, poderá usar essa combinação para mostrar um arquivo às ferramentas de segurança e outro à vítima.

Os invasores empregaram uma complexa matriosca de malware em uma campanha que distribuiu o infostealer IcedID. Eles anexaram um arquivo ZIP aos e-mails de phishing; descompactá-lo produziu um arquivo ISO. Esse ISO, por sua vez, era descompactado em um arquivo CHM (Ajuda do Windows) criado com a técnica poliglota. Quando a vítima o abriu com a ferramenta padrão de Ajuda do Windows, o arquivo executou um script JavaScript incorporado ao conteúdo da ajuda, que iniciou o aplicativo padrão mshta (host de aplicativos HTML da Microsoft) e o direcionou para esse mesmo arquivo CHM. Os autores da campanha empacotaram um aplicativo HTA dentro do arquivo CHM de forma que sua presença não interferisse na leitura do arquivo como um documento de ajuda inócuo. O manipulador de HTA, por sua vez, simplesmente ignora todos os dados irrelevantes no início do arquivo até encontrar o script HTA.

Como as ferramentas de segurança lidam com arquivos poliglotas

Os exemplos acima deixam claro como esse truque de leitura dupla permite que os invasores implantem malware no computador da vítima. Mas como os filtros de e-mail e os sistemas EDR realmente lidam com arquivos desse tipo? A resposta depende inteiramente da solução específica, portanto, isso precisa ser verificado, seja por meio da análise da documentação técnica do fornecedor, seja pela execução de um teste controlado na infraestrutura corporativa, com todas as devidas precauções.  De modo geral, apenas dois pontos são válidos em todos os casos:

  • A maioria das soluções de segurança não confia na extensão informada de um arquivo; em vez disso, verifica seu início para determinar sua estrutura real. É por isso que, no ataque descrito acima, o arquivo PDF com extensão DOC foi analisado como um PDF inofensivo, enquanto a macro maliciosa estava na parte DOC concatenada.
  • Se um arquivo começar como algo inofensivo (por exemplo, uma imagem) e sua extensão corresponder, uma análise mais sofisticada provavelmente não será aplicada a ele. Os invasores podem explorar isso: as instruções que acompanham o arquivo podem orientar a vítima a renomeá-lo para que o comportamento do sistema acabe associado à segunda carga útil, e não à imagem.

Como proteger uma organização contra ataques de arquivos poliglotas

A defesa contra arquivos poliglotas não requer soluções técnicas ou organizacionais complexas. O que exige são boas práticas de segurança sólidas e consistentes em toda a organização:

  • use listas fechadas de aplicativos autorizados a serem executados nas estações de trabalho dos funcionários. exclua aplicativos do Windows desatualizados, ferramentas administrativas da Microsoft não utilizadas, softwares de acesso remoto e de transferência de arquivos e qualquer outro software considerado potencialmente perigoso ou obsoleto.
  • use soluções de segurança de e-mail avançadas e equipadas com CDR (tecnologia de Desarme e Reconstrução de Conteúdo, que desarma anexos suspeitos e os reconstrói em versões mais seguras) e tecnologia de detonação (que executa anexos suspeitos em um ambiente isolado para análise). configure a análise aprofundada para anexos que apresentem sinais externos de serem arquivos poliglotas: todos os arquivos compactados e do Office, arquivos com extensões não padrão e assim por diante.
  • da mesma forma, configure a solução EDR para realizar uma análise aprofundada de possíveis arquivos poliglotas.
  • crie regras de monitoramento que gerem alertas para combinações incomuns entre um processo e os arquivos que ele recebe para processamento, como um arquivo CHM iniciado por meio do mshta ou um arquivo HTML iniciado por meio do rundll32, como nos exemplos acima.
  • adicione informações básicas sobre arquivos poliglotas ao programa de conscientização em segurança utilizado pela organização, para que os usuários fiquem atentos quando forem orientados a alterar a extensão de um arquivo ou a manipulá-lo de alguma forma incomum, por exemplo, abrindo-o em um aplicativo específico.

Malware em sistemas de infoentretenimento automotivos: como ocorre a infecção

Em junho de 2026, descobrimos um malware incomum que tem como alvo… centrais multimídia automotivas baseadas em Android. Este é o primeiro caso documentado de malware distribuído para centrais multimídia automotivas por meio de um serviço de atualização automática de firmware. Já abordamos diversos incidentes de cibersegurança automotiva, mas, em geral, eles envolviam vazamentos de dados na infraestrutura digital das fabricantes ou testes conduzidos por pesquisadores de segurança.

No entanto, este caso envolve malware que cibercriminosos estão distribuindo ativamente. Os objetivos são cometer fraude publicitária e criar uma botnet de proxies formada por centrais multimídia automotivas infectadas. Neste artigo, explicamos o que é uma central multimídia automotiva, como os invasores infectam esses dispositivos e o que isso pode significar para os motoristas.

O que é uma central multimídia automotiva?

Primeiro, vamos esclarecer o que é exatamente uma central multimídia automotiva. O termo pode parecer técnico, mas, na realidade, a maioria dos motoristas interage com uma delas sempre que usa o carro. A central multimídia é o sistema de infoentretenimento do veículo, geralmente centrado em uma tela usada para controlar a navegação, a música e outras funções do veículo. Nos carros modernos, as centrais multimídia automotivas costumam estar conectadas à Internet.

As fabricantes usam frequentemente o Android nas centrais multimídia por sua praticidade, já que o sistema foi desenvolvido para atender a diferentes usos automotivos e oferece diversas vantagens:

  • muitas opções de personalização da interface;
  • facilidade para desenvolver aplicativos;
  • a possibilidade de adicionar aplicativos e componentes próprios ao sistema;
  • um grande ecossistema de aplicativos já existente.

No entanto, essas mesmas vantagens também criam riscos, pois os aplicativos podem ser maliciosos em vez de legítimos. E foi exatamente isso que aconteceu neste caso: usando um aplicativo malicioso, invasores incorporaram veículos a uma botnet. Veja como isso aconteceu…

Como os invasores infectam as centrais multimídia automotivas e qual malware utilizam?

Primeiro, é importante observar que esse malware não afeta todas as centrais multimídia automotivas, mas apenas aquelas que utilizam software desenvolvido pela empresa chinesa DoFun. A empresa desenvolve firmware, aplicativos e serviços de nuvem para sistemas de infoentretenimento automotivos baseados em Android e, de acordo com seu site, atende a mais de 30 milhões de proprietários de veículos em todo o mundo.

Para distribuir o malware para o sistema de infoentretenimento de um veículo, os invasores usam o TWCore, um aplicativo de sistema legítimo responsável pelas atualizações de software nas centrais multimídia automotivas da DoFun. Em condições normais, o TWCore obtém da nuvem da desenvolvedora informações sobre os arquivos que precisam ser baixados e instalados no dispositivo. Esses arquivos são, principalmente, atualizações de software já instalado na central multimídia, mas o mesmo mecanismo pode ser usado para instalar novos aplicativos. E é exatamente isso que os invasores exploram: eles usam o TWCore para instalar o JarService (um dropper de cavalo de Troia malicioso) nas centrais multimídia automotivas.

O JarService é essencialmente um aplicativo “vazio”. Ou seja, ele não tem uma interface de usuário e não tenta se passar por um serviço legítimo. A ausência de uma interface faz todo sentido neste caso: os invasores não precisam convencer o usuário a instalar o malware manualmente, e nenhuma interação do usuário é necessária.

O código do JarService contém, de forma criptografada, a carga útil da próxima etapa, além de informações sobre sua versão e ponto de entrada. A função do JarService é descriptografar esses dados e iniciar a próxima etapa da infecção: um módulo malicioso de download. Depois de iniciado, o módulo de download se conecta ao servidor de comando e controle (C2) dos invasores e envia informações sobre o malware instalado. Em resposta, o servidor fornece um link para a carga útil da próxima etapa. O módulo de download obtém essa carga útil, descriptografa-a e a executa.

Neste caso, o malware instala um tipo de malware conhecido como “clicker”, usado para aumentar fraudulentamente o número de impressões de anúncios. Depois de ser executado, o malware entra em contato regularmente com o servidor C2 e envia informações sobre o dispositivo infectado, incluindo seu modelo, resolução de tela, endereço MAC e detalhes da rede Wi-Fi conectada. Em troca, o malware pode receber vários comandos dos invasores. Por exemplo, ele pode fazer solicitações HTTP e abrir páginas da Web. Mas, mais importante ainda, pode baixar e executar código malicioso adicional no sistema de infoentretenimento do veículo comprometido.

Os invasores usam esse recurso para instalar um módulo malicioso chamado zhima, que adiciona a central multimídia infectada a uma botnet. A botnet resultante é usada para operar um serviço conhecido como proxy residencial, permitindo que os invasores direcionem seu tráfego por meio dos dispositivos infectados ao realizar ataques e outras atividades maliciosas.

Quem está por trás do malware e o que os invasores pretendem alcançar?

Os invasores infectam centrais multimídia automotivas com malware principalmente para expandir a botnet. Uma investigação realizada por especialistas da Kaspersky constatou que a operação está associada à plataforma maliciosa BADBOX e, mais especificamente, a um dos agentes de ameaça ligados a ela: o MoYu Group. Indícios no código do malware, juntamente com semelhanças em relação à infraestrutura anteriormente atribuída ao MoYu Group, apontam para o envolvimento do grupo. A própria BADBOX reúne uma série de atividades maliciosas voltadas à infecção de dispositivos Android e à exploração clandestina de seus recursos.

Os invasores, então, ganham dinheiro monetizando o acesso a recursos que pertencem a outras pessoas. Ao investigar a infraestrutura da botnet, nossos especialistas descobriram vínculos entre o MoYu Group e os serviços PXYEDGE e ProxyForU, que oferecem serviços de proxy residencial. Esses serviços permitem que clientes de todo o mundo direcionem seu tráfego de Internet por meio de dispositivos conectados à botnet e, assim, acessem a Internet usando os endereços IP desses dispositivos. Isso sugere que as centrais multimídia automotivas infectadas já podem estar sendo usadas como parte dessa infraestrutura.

Como o malware afeta os usuários?

Em primeiro lugar, o malware consome parte dos recursos computacionais da central multimídia automotiva. A carga adicional pode fazer com que o sistema de infoentretenimento do veículo fique mais lento ou menos estável. Ao mesmo tempo, é muito provável que a velocidade da conexão de Internet do dispositivo infectado também diminua, pois os invasores podem direcionar grandes volumes de tráfego por meio dele.

Também vale destacar que o malware não se limita a oferecer funcionalidade de proxy. Ele pode receber comandos dos invasores, além de baixar e executar código malicioso adicional. Como resultado, as consequências de uma infecção podem variar de acordo com a carga útil que os operadores da botnet decidirem instalar no dispositivo.

Conclusão

Este caso demonstra mais uma vez que ataques a todos os tipos de dispositivos conectados à Internet, de decodificadores de TV a sistemas de infoentretenimento automotivo, não são apenas uma possibilidade teórica, mas uma realidade concreta. Os invasores estão constantemente procurando novos dispositivos cujos recursos possam explorar para seus próprios fins. Por isso, a proteção contra malware é importante muito além de computadores e smartphones.

Nossos especialistas informaram a desenvolvedora sobre o esquema de distribuição do malware que identificaram, e ela corrigiu os problemas de segurança identificados.

Uma análise técnica completa do malware está disponível na Securelist.

Que outros métodos os invasores podem usar para comprometer um veículo e quais riscos eles representam para os motoristas? Leia mais em nossas publicações:

Quando a IA encontra centenas de vulnerabilidades, o desafio deixa de ser corrigir tudo.

A atualização crítica da Oracle de julho de 2026 chamou a atenção da comunidade de segurança não apenas pelo número recorde de 1.449 correções, mas pelo que esse volume representa: a Inteligência Artificial está mudando a forma como vulnerabilidades são descobertas. Ao mesmo tempo em que fortalece a defesa, ela também cria novos desafios para as equipes de segurança, que precisam decidir rapidamente quais riscos tratar primeiro.

Durante muitos anos, a gestão de vulnerabilidades era vista como um processo relativamente previsível. Os fabricantes publicavam seus boletins de segurança, as equipes avaliavam o impacto, planejavam uma janela de manutenção e aplicavam as correções conforme a criticidade dos ativos.

Todavia, esse modelo está mudando. Em julho de 2026, o Critical Patch Update (CPU) da Oracle trouxe absurdos 1.449 novos patches distribuídos por centenas de produtos, incluindo Oracle Database, Fusion Middleware, E-Business Suite e diversos componentes de infraestrutura. O volume impressiona, mas o verdadeiro recado está por trás desses números: a descoberta de vulnerabilidades está entrando em uma nova era impulsionada pela Inteligência Artificial.

Para quem atua como CISO, gestor de risco ou analista de cibersegurança, essa mudança merece atenção. A IA deixou de ser apenas uma ferramenta para responder incidentes ou auxiliar na análise de logs. Hoje ela já participa da identificação automática de falhas de programação, revisa grandes volumes de código e ajuda pesquisadores a localizar vulnerabilidades que poderiam permanecer invisíveis durante anos. Trabalhos acadêmicos recentes e iniciativas como o DARPA AI Cyber Challenge demonstram que agentes inteligentes já conseguem apoiar a descoberta e validação de vulnerabilidades em escala cada vez maior.

Esse avanço poderia representar uma excelente notícia para quem desenvolve software, mas existe outro lado dessa história, pois quando um fornecedor publica milhares de correções simultaneamente, ele também divulga, de forma indireta, informações suficientes para que pesquisadores, e também criminosos, iniciem processos de engenharia reversa dos patches. Com apoio de IA, esse trabalho tende a ser muito mais rápido do que no passado. Além disso, indica falhas no desenvolvimento das soluções, o que gera questionamentos se os grandes desenvolvedores realmente aplicam as melhores práticas de desenvolvimento seguro e Secure by Desing.

A janela de exposição (window of exposure) surge enquanto a organização ainda está avaliando impactos, negociando períodos de manutenção ou aguardando homologações. Durante isso,  atacantes podem utilizar ferramentas automatizadas para comparar versões corrigidas e identificar exatamente qual vulnerabilidade foi eliminada. Em muitos casos, isso acelera a criação de exploits conhecidos como “1-day”, desenvolvidos logo após a publicação oficial do patch. O problema, portanto, já não é apenas descobrir vulnerabilidades, mas também o quanto conseguiremos decidir sobre quais delas realmente colocam o negócio em risco e priorizar a implementação de suas correções.

No cenário descrito, onde centenas ou milhares de correções são divulgadas simultaneamente, tentar aplicar tudo imediatamente deixa de ser uma estratégia realista. Surge um fenômeno conhecido entre equipes de segurança como patch fatigue, ou fadiga de patches: excesso de demandas, filas crescentes, recursos limitados e dificuldade para estabelecer prioridades. A pergunta deixa de ser:

“Quantos patches precisamos instalar?”

E passa a ser:

“Quais patches reduzem o maior risco para a organização?”

Essa mudança exige uma gestão muito mais orientada por inteligência do que por volume. Uma priorização madura considera diversos fatores simultaneamente:

  • o ativo está exposto à Internet?
  • existe exploração ativa conhecida?
  • há vulnerabilidades catalogadas pela CISA como exploradas em ambiente real?
  • o impacto para o negócio é elevado?
  • existe exploração pública ou PoC disponível?
  • qual a facilidade de exploração indicada pelo CVSS e por outras métricas contextuais.

Nenhuma dessas perguntas pode ser respondida apenas olhando a pontuação CVSS. Nesse momento entram em cena, o uso de Threat Intelligence, ASM e inventário de ativos, pois a gestão contínua de exposição passa a fazer parte da análise e solução.

Outro ponto importante é compreender que a IA democratiza capacidades. Se ela permite que fabricantes encontrem vulnerabilidades mais rapidamente, também reduz barreiras para pesquisadores independentes e, infelizmente, para agentes maliciosos. A comunidade de segurança já discute esse novo equilíbrio, observando que ferramentas baseadas em LLMs podem acelerar tanto a identificação quanto a correção de falhas, enquanto também aumentam o volume de análises e pesquisas sobre vulnerabilidades recém-divulgadas.

Ao chegar neste ponto da análise, podemos afirmar que o tratado não significa que a Inteligência Artificial seja um problema. Naverdade, muito pelo contrário, ela tende a se tornar um dos principais aliados dos programas modernos de Vulnerability Management. Apenas como exemplo, a IA possibilita termos modelos capazes de correlacionar CVEs, inventários, inteligência de ameaças, exposição externa e criticidade dos ativos, que poderão auxiliar equipes a decidir, em minutos, aquilo que hoje leva dias ou semanas para ser analisado manualmente.

Talvez essa seja a principal lição deixada pelo Oracle CPU de julho de 2026. O recorde de 1.449 patches não representa necessariamente que o software esteja menos seguro. Pode significar exatamente o contrário, que estamos entrando em uma fase em que as vulnerabilidades serão descobertas em uma velocidade sem precedentes graças à automação e à Inteligência Artificial. O verdadeiro diferencial competitivo não será a capacidade de instalar milhares de correções, mas de identificar rapidamente quais delas representam risco real para o negócio e agir antes que adversários façam o mesmo.

No entanto, cabe sempre reforçar que a segurança cibernética continuará sendo uma disputa entre velocidade, inteligência e capacidade de adaptação.

Infere-se, portanto, que o cenário da cibersegurança está passando por uma transformação significativa. A Inteligência Artificial deixou de ser uma promessa e passou a integrar o ciclo completo da gestão de vulnerabilidades, desde a identificação de falhas até a priorização das correções. Essa evolução amplia a capacidade de defesa das organizações, mas também acelera a atuação de agentes maliciosos que utilizam as mesmas tecnologias para reduzir o tempo entre a divulgação de uma vulnerabilidade e sua exploração.

Nesse contexto, a maturidade de um programa de segurança não será medida apenas pela quantidade de patches aplicados, mas pela capacidade de combinar inteligência de ameaças, conhecimento do ambiente, automação e gestão de riscos para tomar decisões rápidas e assertivas.

Mais do que acompanhar a evolução tecnológica, CISOs e analistas precisam desenvolver processos que permitam transformar informação em ação. A Inteligência Artificial deve ser encarada como um multiplicador de capacidades humanas, potencializando a experiência, o pensamento crítico e a capacidade de tomada de decisão.

A velocidade com que vulnerabilidades são descobertas continuará aumentando. O diferencial das organizações resilientes será sua capacidade de correlacionar inteligência, contexto e automação para reduzir a janela de exposição e responder aos riscos de forma eficiente.

Fiquem seguros e utilizem a Inteligência Artificial para evoluir suas técnicas de defesa. A tecnologia continuará evoluindo, e as organizações que aprenderem a utilizá-la de forma estratégica estarão mais preparadas para enfrentar os desafios da segurança cibernética.

As referências abaixo serviram como base técnica e conceitual para a elaboração deste artigo e são recomendadas para aprofundamento do tema.

Oracle Corporation. Critical Patch Update Advisory – July 2026. Disponível em: https://www.oracle.com/security-alerts/cpujul2026.html

Oracle Corporation. Oracle Security Alerts. Disponível em: https://www.oracle.com/security-alerts/

Cybersecurity and Infrastructure Security Agency (CISA). Known Exploited Vulnerabilities (KEV) Catalog. Disponível em: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

DARPA AI Cyber Challenge (AIxCC). Competição sobre Inteligência Artificial aplicada à descoberta e correção automatizada de vulnerabilidades. Disponível em: https://aicyberchallenge.com/semifinal-competition/

The Hacker News. Google’s AI Tool Big Sleep Finds Zero-Day Vulnerability in SQLite. Disponível em: https://thehackernews.com/2024/11/googles-ai-tool-big-sleep-finds-zero.html

CSO Online. Oracle’s July Update Fixes Ten Critical Vulnerabilities in Fusion Middleware. Disponível em: https://www.csoonline.com/article/4200184/oracles-july-update-fixes-ten-10-0-vulnerabilities-in-fusion-middleware.html

GitHub Security Advisories. Base pública de avisos de segurança e vulnerabilidades. Disponível em: https://github.com/advisories

National Vulnerability Database (NVD) – NIST. Base oficial de vulnerabilidades e métricas CVSS. Disponível em: https://nvd.nist.gov/

FIRST – Forum of Incident Response and Security Teams. Common Vulnerability Scoring System (CVSS). Disponível em: https://www.first.org/cvss/

Nota: As análises e reflexões apresentadas neste artigo foram elaboradas a partir de informações públicas disponíveis nas referências acima e representam uma interpretação técnica do autor sobre as tendências relacionadas à gestão de vulnerabilidades, Inteligência Artificial aplicada à cibersegurança e gerenciamento de riscos.

Brasil é o terceiro país que mais sofreu ataques de ransomwares em junho, aponta Cohesity

O Brasil foi o terceiro país que mais sofreu ataques com ransomwares em junho, registrando 23 casos. Os dados são da plataforma Ransomware.live, iniciativa de Julien Mousqueton, CISO da Cohesity, empresa líder em segurança de dados com IA. É a primeira vez que o Brasil aparece entre os dez países mais afetados desde o início da publicação de dados do site, em janeiro.

A plataforma monitora e coleta dados de sites de vazamento de grupos de ransomware continuamente para identificar e listar novas vítimas. Ransomwares são softwares maliciosos que bloqueiam o acesso de usuários ou organizações, exigindo pagamento de resgate para restauração, sob a ameaça de vazamento ou exclusão permanente.

O Brasil só aparece atrás de Estados Unidos, com 199 casos, e Alemanha, com 49. O Reino Unido vem logo após o Brasil, com 21, seguido de Índia e Canadá, ambos com 20. França (15), Itália (15), México (14) e Tailândia (13) completam o top 10.

“A emergência do Brasil, Índia e Tailândia como alvos recém identificados pode ser reflexo de uma estratégia deliberada de focar em jurisdições com menor maturidade na resposta a incidentes e na coordenação com forças de segurança”, avalia Gustavo Leite, vice-presidente da Cohesity para América Latina.

O número total de vítimas em junho, 708, representa uma redução de 10,5% em relação às 791 registradas em maio. “Apesar dessa diminuição mensal, o volume permanece historicamente elevado quando comparado aos doze meses anteriores, deixando claro o quão intenso e consistente é o atual cenário de ameaças”, aponta Leite.

Setores mais afetados

Em junho, o mercado B2B se manteve no topo dos alvos mais atingidos, registrando 123 vítimas — uma redução de 23,1% em comparação às 160 de maio. O setor de manufatura ficou na segunda colocação, com 83 ocorrências (queda de 19,4%), seguido por tecnologia, que somou 56 vítimas (recuo de 21,1%).

O segmento de saúde contabilizou 52 vítimas, registrando uma queda de 23,5% em relação às 68 do mês anterior. Na contramão, serviços ao consumidor foi o único a apresentar crescimento: uma alta discreta de 1,9%, passando de 52 para 53 vítimas. Já o setor de serviços financeiros teve um recuo de 26,5%, somando 25 vítimas, enquanto transporte/logística baixou 25,7%, chegando a 26 registros.

Números do site Ransomware.live são divulgados todos os meses pela Cohesity, que conta com a confiança de clientes em mais de 140 países, incluindo 70% da Fortune Global 500.

Ataques com ransomware nos últimos 12 meses:

  • Junho – 708
  • Maio – 791
  • Abril – 870
  • Março – 844
  • Fevereiro – 784
  • Janeiro – 702
  • Dezembro de 2025 – 882
  • Novembro de 2025- 717
  • Outubro de 2025 – 839
  • Setembro de 2025 – 598
  • Agosto de 2025 – 530
  • Julho de 2025 – 547

Setores com ransomwares mais afetados em junho:

  1. Mercado B2B – 123 (queda de 23.1% em relação a maio)
  2. Manufatura – 83 (queda de 19.4% em relação a maio)
  3. Tecnologia – 56 (queda de 21.1% em relação a maio)
  4. Serviços ao consumidor – 53 (aumento de 1.9% em relação a maio)
  5. Saúde – 52 (queda de 23.5% em relação a maio)
  6. Agricultura e produção de alimentos – 36 (queda de 7.7% em relação a maio)
  7. Construção – 27 (queda de 15.6% em relação a maio)
  8. Transportes/logísticas – 26 (queda de 25.7% em relação a maio)
  9. Serviços financeiros – 25 (queda de 26.5% em relação a maio)
  10.  Educação – 24 (queda de 14.3% em relação a maio)

Países mais afetados por ataques com ransomwares em junho:

  1. Estados Unidos – 199
  2. Alemanha – 49
  3. Brasil – 23
  4. Reino Unido – 21
  5. Índia – 20
  6. Canadá – 20
  7. França – 15
  8. Itália – 15
  9. México – 14
  10. Tailândia – 13

Cibersegurança: Como impedir que malware bancário roube dados financeiros do celular

Um tipo de software malicioso tem chamado a atenção de especialistas: o malware bancário. Trata-se de um programa criado para acessar e roubar dados de celulares e computadores e que dá aos criminosos o controle total do dispositivo infectado. Diferente de fraudes financeiras em que o golpista se passa por outra pessoa para pedir uma transferência, aqui o criminoso convence a vítima a instalar um software malicioso que dá acesso a aplicativos, contas bancárias, mensagens e informações pessoais, podendo, inclusive, realizar movimentações financeiras sem que a vítima perceba.

Malware bancário é um mecanismo usado para aplicar golpes digitais e acessar e roubar dados financeiros de celulares e computadores. Costuma chegar até o dispositivo das vítimas por meio de engenharia social, quando o criminoso engana a pessoa para que ela mesma realize alguma ação (como clicar em um link ou baixar um aplicativo de fonte desconhecida), acreditando que se trata de algo legítimo. Depois de instalado, o software funciona como um “espião” dentro do aparelho, transmitindo para o criminoso informações confidenciais como senhas, dados de contas e códigos de segurança.

Como criminosos aplicam golpes com o malware bancário?

Os golpes se iniciam em um contato direto, geralmente por WhatsApp. O criminoso se apresenta como um contato confiável, um representante de uma empresa conhecida, ou de um serviço que a vítima já usa ou tenha interesse. Durante a conversa, ele pede que a pessoa baixe ou atualize um aplicativo, ou até mesmo clique em um link. Em alguns casos, o golpista pode até fazer uma chamada de vídeo ou telefônica para parecer mais convincente, aumentar a sensação de segurança e acompanhar o processo em tempo real, gerando pressão e sentimento de urgência.

Depois disso, o programa malicioso é instalado no celular e o criminoso passa a interferir no funcionamento do aparelho sem que a pessoa perceba. É nesse momento em que ele aproveita para realizar ações em segundo plano, como movimentações financeiras sem autorização. Em poucos minutos, os golpistas podem realizar empréstimos, transferências e outras operações, gerando prejuízos significativos para a vítima.

Como saber se o celular foi infectado?

Alguns sinais podem indicar que há algo errado com o aparelho:

  • O celular trava ou fica lento com mais frequência;
  • A bateria acaba muito mais rápido que o normal;
  • A tela fica preta ou sem resposta por alguns momentos;
  • O dispositivo reinicia ou fecha aplicativos de forma repentina;
  • O celular esquenta de forma excessiva;
  • Mensagens são enviadas automaticamente pelo celular, sem que o usuário tenha realizado a ação;
  • Presença de aplicativos desconhecidos, com nomes genéricos ou incomuns, que a pessoa não se lembra de ter instalado;
  • Mudanças inesperadas nas configurações do celular ou nos aplicativos instalados;
  • Aplicativos solicitando permissões incomuns, como acesso a acessibilidade, mensagens ou controle do dispositivo

Além dos sinais visíveis, é importante ficar atento às permissões concedidas aos aplicativos. Alguns malwares bancários solicitam acesso aos recursos de acessibilidade do celular, uma funcionalidade criada para auxiliar usuários com necessidades específicas. Quando utilizada de forma indevida, essa permissão pode permitir que aplicativos maliciosos visualizem informações exibidas na tela e executem ações no aparelho. Por isso, desconfie sempre que um aplicativo solicitar esse tipo de acesso sem uma justificativa clara.

“Se você perceber comportamentos anormais ou sentir que perdeu o controle do seu aparelho, principalmente após clicar em links desconhecidos ou instalar aplicativos fora das lojas oficiais, o mais seguro é restaurar o dispositivo para as configurações de fábrica. Essa medida ajuda a remover aplicativos ocultos, eliminar permissões indevidas e reduzir o risco de o malware continuar ativo”, orienta Rodrigo Fernandes, Supervisor de Prevenção à Fraude da DM

Dicas para se proteger

A principal forma de prevenção é nunca seguir instruções de terceiros que envolvam a instalação de aplicativos ou o acesso ao seu dispositivo. “Não clique em links suspeitos enviados por mensagem e não baixe aplicativos fora das lojas oficiais, como App Store e Google Play. Desconfie de contatos inesperados, mesmo que pareçam conhecidos, ou feitos por números de empresas que não sejam oficialmente verificados. Além disso, não realize qualquer ação, instalação ou atualização de aplicativo seguindo instruções, nem clique em links enviados por pessoas que não são da sua confiança. E nunca conceda acesso ao seu aparelho durante uma ligação”, aponta Rodrigo Fernandes.

Caí no golpe. E agora?

Se a pessoa desconfia que caiu em um golpe, o mais importante é agir rápido. “Entre em contato com o seu banco ou com a sua instituição financeira pelos canais oficiais para informar o ocorrido e tentar bloquear movimentações. Em seguida, altere suas senhas, principalmente de aplicativos bancários e e-mail, para recuperar o controle dos acessos. Se houver suspeita de instalação de aplicativo malicioso, considere restaurar o dispositivo para as configurações de fábrica. Além disso, é recomendado registrar um boletim de ocorrência, que pode ajudar no acompanhamento do caso”, aconselha o especialista.

Camadas de segurança

Para auxiliar clientes a se prevenir contra os prejuízos causados pelos golpes, a DM conta com camadas de segurança que ajudam a proteger as transações, como:

  • Confirmação de compra: em caso de movimentações suspeitas, entramos em contato por ligação ou WhatsApp pra aprovar a transação;
  • Bloqueio temporário do cartão: o cliente pode bloquear o cartão rapidamente pelo DM App em caso de suspeita;
  • Bloqueio de pagamentos de madrugada: transações realizadas em horários ou padrões considerados fora do comum são bloqueadas;
  • Gestão de limite: o usuário pode ajustar o limite conforme o seu perfil de uso, o que ajuda a reduzir possíveis prejuízos.

Além das camadas de segurança presentes no aplicativo DM, os clientes contam com recursos adicionais de proteção, como o código de segurança dinâmico (CVC), que dificulta o uso indevido dos dados do cartão em compras online.

Relatório Executivo de Inteligência Cibernética – Vazamento de Dados do domínio gov.il pertence oficialmente ao Governo do Estado de Israel

O IDCiber Threat Intelligence Center, por meio do monitoramento contínuo de fontes abertas, fóruns clandestinos e canais especializados, identificou a divulgação de uma alegada base de dados associada ao domínio governamental www.gov.il, anunciada por um ator de ameaça em 22/06/2025. Segundo a publicação analisada, o grupo afirma ter explorado uma vulnerabilidade de API e obtido acesso não autorizado a informações de aproximadamente 268.938 registros de cidadãos, contendo dados pessoais diversos. As evidências observadas incluem amostras de registros supostamente extraídos da base comprometida e disponibilizados em plataforma pública de compartilhamento de conteúdo. Em conformidade com as melhores práticas de proteção à privacidade, os dados pessoais identificáveis (PII) presentes nas amostras foram anonimizados nesta análise, não sendo reproduzidos nomes, documentos, telefones, endereços, e-mails, identificadores ou quaisquer informações que permitam a identificação direta de indivíduos.

IDCiber Threat Intelligence Center
IDCiber Threat Intelligence Center

A análise preliminar indica que o conjunto de informações alegadamente exposto contém categorias de dados de elevada sensibilidade, incluindo dados cadastrais, informações demográficas, informações de contato, dados de localização e outros atributos pessoais. Caso a autenticidade e atualidade da base sejam confirmadas pelas autoridades competentes, o incidente poderá representar riscos significativos de fraude, engenharia social, campanhas de phishing direcionado, roubo de identidade, comprometimento de contas e outras atividades criminosas. O anúncio também demonstra intenção de monetização dos dados por parte do ator de ameaça, que disponibilizou canal de contato para potenciais interessados na aquisição do conteúdo.

Até o momento da análise, as evidências observadas permitem confirmar a existência de uma publicação reivindicando a violação e exibindo amostras de registros, porém a validação integral da autenticidade, integridade, abrangência e origem dos dados requer investigação técnica complementar pelas entidades responsáveis. Considerando o potencial impacto sobre cidadãos e organizações governamentais, recomenda-se a realização de procedimentos de resposta a incidentes, validação dos dados expostos, revisão dos controles de acesso, análise de vulnerabilidades em APIs, monitoramento reforçado de credenciais e comunicação adequada às partes potencialmente afetadas.

IDCiber Threat Intelligence Center
IDCiber Threat Intelligence Center
  • Classificação do incidente: Vazamento de Dados (Data Breach)
  • Organização alvo: Domínio governamental (www.gov.il)
  • Data da divulgação identificada: 22/06/2025
  • Volume alegado de impacto: 268.938 registros
  • Tipo de informação exposta: Dados pessoais e cadastrais (PII) – informações anonimizadas neste relatório
  • Severidade estimada: Alta
  • Status: Publicação identificada e em monitoramento

Fonte: IDCiber Threat Intelligence Center.

A Quarta Onda: Inteligência Artificial, Segurança Nacional e a Nova Corrida Tecnológica

1. Introdução

Alvin Toffler (1928-2016) foi um dos futuristas do século XX. Além de ensaios sobre avanços tecnológicos, escreveu o livro O Choque do Futuro, no ano de 1970.

Em seu livro de maior sucesso, A Terceira Onda (1980), Toffler organizou a história da humanidade não por séculos ou dinastias, mas por grandes “ondas” que representaram momentos de mudanças tecnológicas e sociais.

Para Toffler, uma “onda” ocorre quando uma nova tecnologia ou forma de produzir riqueza colide com a sociedade, transformando modelos econômicos, as relações interpessoais, a forma de produção cultural e até mesmo a maneira como vivemos. As três ondas que Toffler apresentou, resumidamente, foram:

1ª Onda: A Revolução Agrícola – Iniciada há cerca de 10 mil anos, representou a transição do nomadismo para o sedentarismo. Caracterizou-se pelo domínio da agricultura e do pastoreio, onde a terra era a principal fonte de riqueza e poder.

2ª Onda: A Revolução Industrial – iniciada no final do século XVIII (Inglaterra) e que dominou os séculos XIX e XX. Os motores da mudança foram: a máquina a vapor, os combustíveis fósseis e a produção em massa.

3ª Onda: A Era da Informação – emergiu na metade do século XX (década de 1950/1960), cujos motores da mudança foram: o computador, a internet, a biotecnologia.

Ao encerrarmos o primeiro quarto do século XXI, uma ferramenta tecnológica demonstra estar revolucionando o cotidiano da sociedade e, ao mesmo tempo, desafiando nada menos do que a própria inteligência humana: a Inteligência Artificial (IA).

Diante desse cenário, então, surge uma indagação: em que medida o comunicado emitido pelo Five Eyes sobre IA faz soar o alarme para uma quarta onda?

Seria o Mythos, da Anthropic, a corrente de vento que começa a agitar os “mares da tecnologia”, os mesmos que conectam as nações por meio de uma navegação entre bits e bytes?

2) A Inteligência e o alarme

Five Eyes significa a aliança existente entre as Agências de Inteligência dos seguintes países: Austrália, Canadá, Nova Zelândia, Reino Unido e Estados Unidos da América (EUA), e representa, em última instância, a extensão do antigo projeto Echelon (vide livro Contra & Inteligência, 2024, pág. 83).

Em 22/06/2026, agências de cibersegurança ligadas ao Five Eyes emitiram um comunicado conjunto que denotou ser um alerta quanto à rápida obsolescência dos recursos tradicionais de cibersegurança, indicando que o avanço dos modelos de IA de Fronteira pode reduzir significativamente a marcha do tempo em relação à validade de premissas que orientam a cibersegurança tradicional.

Segundo o Five Eyes, as alterações tecnológicas que anteriormente eram esperadas ao longo de anos poderão ocorrer em poucos meses, exigindo maior capacidade de adaptação por parte das organizações públicas e privadas.

Em síntese, Agências de Inteligência anunciaram que ferramentas de IA estão incorporando novas e mais potentes capacidades de encontrar e explorar vulnerabilidades, cada vez mais rapidamente. Ou seja, a marcha do tempo foi acelerada pela IA reduzindo a janela temporal entre o surgimento de uma vulnerabilidade e sua exploração prática.

O alerta baseia-se na rápida evolução dos modelos de IA, que demonstram capacidades para executar, com elevado grau de automação e velocidade, atividades que tradicionalmente exigiam equipes altamente especializadas. Entre elas destacam-se:

‒        o reconhecimento técnico de infraestruturas digitais, mediante o mapeamento automatizado de ativos físicos e serviços;

‒        a identificação e correlação de vulnerabilidades em softwares, sistemas operacionais e aplicações;

‒        a análise de grandes volumes de dados para identificação de padrões, anomalias e oportunidades de exploração; e

‒        a priorização de vetores de ataque e o apoio à tomada de decisão em operações defensivas ou ofensivas no domínio cibernético.

Tarefas que antes dependiam predominantemente de operadores dedicados passam a ser executadas com maior velocidade e escala por sistemas baseados em IA, que, entre outras capacidades, podem reduzir barreiras técnicas para agentes maliciosos, ampliando a velocidade, a automação e a complexidade das operações cibernéticas.

O cenário torna-se ainda mais complexo porque amplia a capacidade operacional tanto de grupos criminosos independentes ou de atores patrocinados por Estados, tornando os ataques mais frequentes, adaptáveis e difíceis de serem detectados.

Embora muitas das recomendações já integrem as boas práticas consolidadas da cibersegurança, tal como a sempre sugerida redução da superfície de ataque, o Five Eyes orienta para que as organizações adotem estratégias baseadas em resiliência operacional, partindo do pressuposto de que incidentes de segurança poderão ocorrer.

Entre as medidas sugeridas estão:

‒        incorporação da IA para as operações defensivas;

‒        modernização de infraestruturas legadas;

‒        cadência de patching;

‒        fortalecimento dos controles de acesso e a aplicação do princípio do menor privilégio; e

‒        aprimoramento das capacidades de detecção, contenção e resposta a incidentes.

O alerta também evidencia uma mudança na dinâmica da cibersegurança. Se, nas últimas décadas, a evolução das defesas ocorreu por meio de melhorias graduais, a IA tende a reduzir significativamente os ciclos de inovação, exigindo revisões mais frequentes das arquiteturas de segurança, dos processos de governança e das estratégias de gestão de riscos. Nesse contexto, a capacidade de adaptação contínua passa a ser um componente essencial da postura de segurança das organizações.

A terminologia IA de Fronteira tornou-se mundialmente reconhecida na Cúpula de Bletchley Park, em novembro de 2023, também conhecida como Artificial Intelligence Safety Summit. Segue-se a sua definição:

2.1 What do we mean by frontier AI models?

For the purposes of this paper, we define “frontier AI models” as highly capable foundation models2 that could exhibit sufficiently dangerous capabilities. Such harms could take the form of significant physical harm or the disruption of key societal functionson a global scale, resulting from intentional misuse or accident [25, 26]. It would be prudent to assume that next-generation foundation models could possess advanced enough capabilities to qualify as frontier AI models, given both the difficulty of predicting when sufficiently dangerous capabilities will arise and the already significant capabilities of today’s models.[1] (grifei)

3) Quem é Mythos 5?

O Mythos 5 é um modelo de IA de Fronteira desenvolvido pela empresa Anthropic, pertencendo à mesma linhagem e geração do Claude.

Enquanto o Claude Fable 5 é a versão comercial e distribuída para o público e empresas, o Claude Mythos 5, como “irmão gêmeo” do Fable 5, compartilha a mesma base de dados, porém com modificações especificamente para defesa técnica avançada.

O Mythos, como modelo de testes controlados, encontrava-se enclausurado dentro de uma sandbox, uma espécie de prisão digital. Ao operar fora dessa sandbox, em pouco tempo, o Mythos encontrou centenas de falhas em sistemas operacionais, tal como o OpenBSD, navegadores, vulnerabilidades zero-day em softwares, além de bugs no Linux, inconsistências essas antes desconhecidas pelas comunidades de cybersegurança.

Essas descobertas, segundo o governo norte-americano, foram entendidas como potencialmente graves à segurança nacional dos EUA, resultando, em 12/06/2025, na diretriz de controle de exportação do Departamento de Comércio dos EUA que exigiu a suspensão imediata do acesso aos dois modelos por qualquer cidadão estrangeiro, tanto fora quanto dentro dos EUA, incluindo os próprios funcionários estrangeiros da Anthropic.

Como consequência, a Anthropic informou que, diante da dificuldade operacional de verificar, em tempo real, a nacionalidade de todos os usuários, optou por desabilitar temporariamente os modelos para toda a sua base de clientes. Segundo a Anthropic, o governo norte-americano não apresentou detalhes técnicos sobre a preocupação de segurança. A empresa declarou entender que a decisão estaria relacionada à existência de um método capaz de contornar (“jailbreak”) determinadas salvaguardas do modelo Fable 5, permitindo sua utilização para identificar vulnerabilidades de softwares.

Segundo a Anthropic, o Mythos 5 estava restrito a um conjunto limitado de organizações participantes do programa Project Glasswing, voltado para defesa cibernética e proteção de infraestruturas críticas.

A preocupação do governo norte-americano, em relação ao Mythos, seria decorrente do alerta de pesquisadores da Amazon que usaram prompts para fazer o Fable 5 fornecer informações supostamente proibidas e que poderiam auxiliar ciberataques.

Em suma, a determinação de suspensão, segundo o governo dos EUA, se deve ao potencial do modelo para acelerar a identificação de vulnerabilidades em softwares complexos, fortalecendo atividades defensivas, como auditorias de segurança e identificação preventiva de falhas. Entretanto, o mesmo modelo poderia ser empregado para apoiar agentes maliciosos a conduzirem operações ofensivas.

4) Reflexões críticas para a cybersegurança

Embora o comunicado do Five Eyes não mencione diretamente a Anthropic ou o Mythos, ambos os episódios convergem para uma mesma preocupação estratégica: o rápido aumento das capacidades ofensivas e defensivas proporcionadas pelos modelos de IA de Fronteira.

A metáfora da “quarta onda” parece ganhar consistência justamente porque os elementos disruptivos dessa transformação não decorrem apenas da evolução tecnológica em si, mas da velocidade com que os modelos de IA de Fronteira passam a alterar o equilíbrio entre ataque e defesa no domínio cibernético, com consequência diretas nas relações socioeconômicas.

A principal mensagem do comunicado é que modelos cada vez mais avançados tendem a acelerar a descoberta de vulnerabilidades, reduzir barreiras técnicas para agentes maliciosos e encurtar significativamente o ciclo de eficácia das arquiteturas tradicionais de cibersegurança.

O caso Mythos 5 da Anthropic representa um exemplo concreto para esse cenário de evolução tecnológica. Ao que tudo indica, em vez de tratar o risco apenas sob uma perspectiva teórica, o governo norte-americano passou a considerar determinados modelos de IA como ativos estratégicos, submetendo-os a mecanismos de controle compatíveis com tecnologias sensíveis de interesse para a segurança nacional, não distante do próprio espectro militar.

Sob essa perspectiva, os dois episódios (Five Eyes e Anthropic) sinalizam uma possível mudança de paradigma. A IA deixa de ser percebida apenas como uma ferramenta de inovação tecnológica e passa a integrar, de forma crescente e dual (civil e militar), as agendas de segurança nacional, governança tecnológica e competição estratégica entre Estados.

Não por acaso, CEOs de gigantes tecnológicas como o Google, OpenAI e a Anthropic estiveram presentes na última reunião do G7, realizada na cidade francesa de Évian-les-Bains, em junho de 2026, coincidentemente dias antes do comunicado das Agências de Inteligência. A ocasião foi marcada por uma deliberação conjunta voltada para o estabelecimento de diretrizes de governança para a IA, com ênfase na proteção de menores em plataformas online.

5) Conclusão parcial

Na medida em que essa nova onda tecnológica ganha forma, a atuação das Agências de Inteligência com projeção global, como o Five Eyes, torna ainda mais relevante o acompanhamento desse fenômeno sob a perspectiva da Inteligência Estratégica e da Contrainteligência Corporativa.

Até recentemente, as preocupações relacionadas à espionagem empresarial concentravam-se na proteção de pessoas, documentos, sistemas e redes. A rápida evolução dos modelos de IA, contudo, introduz uma nova categoria de ativo estratégico: a própria capacidade computacional de acelerar a identificação de vulnerabilidades, de ampliar a produção de conhecimentos técnicos especializados e de influenciar diretamente a vantagem competitiva de Estados e organizações privadas.

Nesse contexto, observa-se também o fortalecimento do que a Bravus Consultoria cita como sendo o Complexo Industrial da Inteligência (vide Contra & Inteligência, 2024, p. 104), caracterizado pela crescente integração entre governos, empresas de tecnologia, universidades, centros de pesquisa e organizações de defesa na disputa por capacidades críticas na Atividade de Inteligência e agora, mais do que nunca, em IA.

Se Alvin Toffler identificou três grandes ondas de transformação da civilização, os acontecimentos recentes sugerem que a IA poderá representar a força motriz de uma quarta onda, cujos efeitos extrapolam o ambiente tecnológico para alcançar a geopolítica, a segurança nacional e, por conseguinte, a contrainteligência corporativa.

Se essa interpretação estiver correta, talvez o alerta do Five Eyes não deva ser compreendido apenas como mais um Relatório de Inteligência (RELINT) sobre cibersegurança, mas como um dos primeiros sinais institucionais de que a IA inaugura uma nova fronteira de competição estratégica entre Estados, empresas e organizações.

Luis Fernando Baptistella

Capitão de Mar e Guerra (Vet.)

Diretor da Bravus Consultoria || Consultor em Inteligência e Contrainteligência

Autor dos livros Contra & Inteligência 4.0 e Counter & Intelligence 4.0

Pós-graduado em Inteligência Estratégica

Fontes consultadas:

https://www.cisa.gov/news-events/news/five-eyes-cyber-security-agencies-statement

Eric Geller – https://www.cybersecuritydive.com/news/ai-cyberattacks-five-eyes-frontier-models-warning/823526/

Pieter Arntz – https://www.malwarebytes.com/blog/ai/2026/06/claude-fable-5-and-mythos-5-abruptly-disabled-after-us-gov-deems-them-too-clever?utm_source=iterable&utm_medium=email&utm_campaign=b2c_pro_oth_20260622_juneweeklynewsletter_v4_178177982315&utm_content=Claude_logo

Bloqueios da Anthropic vieram após alerta da Amazon – CISO Advisor

Professor Danilo Gato – @odanilogato

Nota de Esclarecimento: Embora este artigo de opinião seja fundamentado nas referências citadas, o conceito de Quarta Onda, com base em Alvin Toffler, no que tange à Atividade de Inteligência e à Cybersegurança, é uma tese autoral desenvolvida pelo autor através de pesquisas e estudos próprios. Os direitos sobre esta metodologia/abordagem específica são reservados.


[1] Disponível em https://arxiv.org/abs/2307.03718.

 

Fonte: https://www.linkedin.com/pulse/quarta-onda-intelig%25C3%25AAncia-artificial-seguran%25C3%25A7a-e-nova-baptistella-xloif/

Sequestro de dados: 79% das empresas financeiras atacadas pagaram resgate a hackers

O setor financeiro global enfrenta uma crise sem precedentes na segurança digital, onde pagar o resgate de dados sequestrados virou a regra, não a exceção. Nos últimos 12 meses, 79% das instituições financeiras que sofreram ataques cibernéticos optaram por pagar os criminosos para recuperar seus sistemas. O dado alarmante faz parte de um novo estudo da Cohesity, empresa líder em segurança de dados com Inteligência Artificial, que ouviu 390 tomadores de decisão de TI e segurança em grandes corporações da América do Sul, América do Norte, Europa e Ásia.

O levantamento traça um diagnóstico severo sobre a vulnerabilidade do mercado: 77% das empresas financeiras globais já foram vítimas de cibercriminosos, sendo que mais da metade (57%) foi alvo de investidas apenas no último ano. O impacto financeiro e reputacional é quase inevitável, com 87% das organizações registrando perdas diretas de receita e 93% enfrentando severas consequências regulatórias ou legais após as invasões.

Apesar do cenário de terra arrasada, a pesquisa revela uma desconexão preocupante entre a realidade dos ataques e a percepção de segurança das lideranças. O cenário atual exige uma mudança profunda de postura, já que as ameaças deixaram de ser eventos isolados para se tornarem uma constante no ambiente digital, com frequência e sofisticação cada vez maiores.

  • Confiança em alta: Mesmo com uma em cada quatro empresas sendo atacada repetidamente, 46% dos entrevistados afirmam ter total confiança em suas estratégias de resiliência.
  • O fator IA: A Inteligência Artificial surge como a grande aposta de defesa para 39% dos executivos, que acreditam que a tecnologia assumirá um papel central na detecção de ameaças e na tomada de decisões autônomas, otimizando a eficiência das equipes internas e do SOC (Security Operations Center) na resposta a incidentes.

A Estratégia da Sobrevivência: Organização Mínima Viável (MVC)

Diante do consenso de que é praticamente impossível blindar as empresas contra todos os tipos de ameaças, o mercado financeiro passou a adotar uma nova filosofia de sobrevivência: o conceito de Minimum Viable Company (MVC), ou Organização Mínima Viável.

Em vez de gastar energia e tempo tentando reerguer toda a infraestrutura tecnológica de uma só vez após um apagão cibernético, o foco da estratégia MVC muda drasticamente. A prioridade máxima passa a ser a recuperação estritamente essencial. O objetivo é colocar de pé a menor versão funcional possível da empresa, garantindo que o negócio continue operando (mesmo que de forma limitada ou sob condições degradadas) até que a crise seja totalmente controlada.

Medidas Práticas: O Caminho para a Resiliência

Para enfrentar o aumento dessas ameaças, viabilizar a estratégia de MVC e reduzir vulnerabilidades críticas, a Clavis Segurança da Informação destaca medidas prioritárias, com foco no SOC, voltadas à proteção e rápida recuperação do ambiente digital corporativo:

Treinamento de Colaboradores: A capacitação contínua transforma o elo mais fraco em defesa activa, reduzindo drasticamente a eficácia de ataques de phishing e engenharia social.

Controle de Identidade: A adoção de Autenticação Multifator (MFA) é a barreira mais eficiente para impedir que credenciais roubadas permitam o acesso indevido a dados sensíveis.

Monitoramento e Auditoria: O acompanhamento em tempo real permite detectar anomalias rapidamente, enquanto auditorias frequentes corrigem vulnerabilidades antes que sejam exploradas por criminosos.

Automação de Segurança: O uso de ferramentas automatizadas acelera a resposta a incidentes e reduz a janela de exposição de falhas críticas, que pode superar 55 dias.

Backup e Recuperação: Manter cópias de segurança isoladas e planos de recuperação testados garante a continuidade do negócio e protege a empresa contra extorsões digitais.

A segurança de redes corporativas consolida-se como um pilar indispensável para a estabilidade e o crescimento sustentável no mercado brasileiro. Com ameaças cada vez mais ágeis e onerosas, investir em um ecossistema que integre soluções tecnológicas, processos automatizados e conscientização humana deixa de ser uma demanda técnica para se tornar um diferencial competitivo estratégico.

Incidente no Defesa Civil Alerta: análise técnica de um disparo indevido em sistema crítico nacional

Um disparo indevido no sistema Defesa Civil Alerta expôs a superfície de ataque de uma infraestrutura crítica baseada em redes móveis 4G e 5G, Cell Broadcast e integrações entre governo e operadoras. Este artigo analisa o incidente sob a ótica de arquitetura provável desse sistema, segurança cibernética e telecomunicações.

Na madrugada de sábado, um disparo indevido do sistema Defesa Civil Alerta provocou o envio de mensagens de emergência para diversas regiões do Brasil, sem que houvesse um evento emergencial real correspondente. Segundo nota oficial, a plataforma foi retirada do ar após a identificação de um acesso não autorizado e a Polícia Federal foi acionada para investigação. Embora o episódio tenha sido inicialmente tratado como “possível invasão cibernética”, a análise técnica exige uma leitura mais ampla: trata-se de um sistema altamente distribuído, dependente de múltiplas camadas de infraestrutura, desde aplicações governamentais até redes móveis 4G e 5G operadas por “telecoms”.

O Defesa Civil Alerta é baseado no conceito de Cell Broadcast Service (CBS), padronizado em redes móveis LTE e 5G. Diferente de SMS tradicional, que é ponto a ponto, o Cell Broadcast funciona como um broadcast geográfico, pois a mensagem é injetada na rede da operadora e distribuída para todos os dispositivos conectados a células específicas da antena. Isso reduz latência e garante entrega mesmo em cenários de congestionamento.

Do ponto de vista de arquitetura, o fluxo típico envolve:

  • Interface de autorização e gestão de alertas (IDAP ou equivalente institucional)
  • Sistema central de decisão da Defesa Civil
  • Gateways de integração com operadoras móveis
  • Infraestrutura de rede 4G/5G (eNodeB/gNodeB)
  • Camada de broadcast para dispositivos finais

Essa cadeia cria uma superfície de ataque ampla e distribuída, onde a segurança não depende de um único ponto, mas da coerência entre autenticação, autorização e integração entre sistemas heterogêneos. Podemos observar que, segundo documentação oficial de concepção de sistemas de alerta, esses sistemas são estruturados em quatro pilares: monitoramento de risco, análise, decisão e comunicação de alerta. O incidente em questão afeta diretamente o último pilar, que é a comunicação, mas pode ter origem em qualquer ponto anterior, incluindo a camada a integração com operadoras.

A nota oficial indica que o sistema foi “acionado remotamente por alguém não autorizado”, o que sugere uma quebra de controle de acesso lógico. Em arquiteturas modernas, isso pode ocorrer por diferentes vetores:

  • Credenciais comprometidas em sistemas administrativos
  • Token de API exposto ou mal protegido
  • Falha em autenticação entre sistemas federados
  • Exploração de vulnerabilidade em interface web ou middleware
  • Má configuração em gateways de integração com operadoras

Um ponto crítico aqui é que sistemas como o IDAP e plataformas de alerta não operam isoladamente: eles são integrados a múltiplos serviços e dependem de autenticação forte entre domínios administrativos diferentes. Qualquer falha nesse encadeamento pode permitir a emissão indevida de alertas válidos do ponto de vista técnico da rede, mas inválidos do ponto de vista de governança.

Outro aspecto relevante é o papel das redes 4G e 5G. O Cell Broadcast é implementado diretamente na camada de controle da rede móvel, o que significa que, uma vez autorizado o envio, a distribuição é extremamente eficiente e praticamente imune a congestionamentos. No entanto, essa eficiência também implica um risco: a mensagem não passa por validações individuais em cada dispositivo. Ou seja, o controle precisa ser rigorosamente feito na origem. Em termos de segurança, isso caracteriza um modelo de alto impacto e baixa granularidade de controle no endpoint, o que reforça a necessidade de proteção forte na camada de backend.

A presença de um alerta classificado como “Alerta Extremo” com conteúdo fora do padrão esperado, incluindo termos não técnicos como “misantropia”, indica possível comprometimento não apenas do canal de envio, mas também da integridade do payload da mensagem. Isso sugere que o atacante teve capacidade de manipular o conteúdo estruturado do alerta, e não apenas acioná-lo.

Nesse contexto, a análise forense digital torna-se essencial. A perícia normalmente se concentra em:

  • Logs de autenticação (quem acessou o sistema e quando)
  • Trilha de auditoria de ações administrativas
  • Integridade de APIs e tokens de sessão
  • Eventual movimentação lateral dentro de redes governamentais
  • Correlação com acessos externos via VPNs ou redes administrativas

A retirada imediata do sistema do ar indica uma ação de contenção, típica de resposta a incidentes de alta severidade. Em sistemas críticos, essa decisão é tomada para preservar evidências, impedir novos disparos e reduzir impacto operacional enquanto a integridade do ambiente é verificada.

Do ponto de vista de projeto de sistemas críticos, o incidente evidencia um ponto estrutural a ser destacada, que sistemas de alerta precisam ser desenhados sob o princípio de fail-safe control, onde qualquer comportamento fora do padrão esperado deve resultar em bloqueio automático de emissão, e não em execução.

Além disso, há uma dimensão de confiança pública. Sistemas de alerta via celular funcionam como mecanismos de alta credibilidade. Uma vez acionados incorretamente, há um risco de degradação de confiança. Este fenômeno, conhecido como alert fatigue, representa a situação onde usuários passam a ignorar notificações devido a falsos positivos.

O episódio também evidencia a complexidade da integração entre governo e operadoras de telecomunicações. Redes 4G e 5G operam com múltiplos nós distribuídos e virtualização de funções de rede (NFV), o que amplia a superfície de ataque quando há integração com sistemas externos. Embora o Cell Broadcast seja robusto do ponto de vista de entrega, ele depende criticamente da integridade da camada de sinalização e dos gateways de controle.

Em síntese, o incidente no Defesa Civil Alerta não deve ser interpretado apenas como um evento isolado de invasão, mas como um caso clássico de falha potencial em um sistema complexo com impacto nacional, onde segurança não depende apenas de software, mas da interação entre redes móveis, governança institucional e controles de acesso rigorosos.

A resposta das autoridades, que realizaram a remoção do sistema do ar e acionamento da Polícia Federal, segue o protocolo esperado em incidentes dessa natureza. O desafio agora é estrutural: reforçar autenticação, segmentação de rede, auditoria contínua e mecanismos de validação dupla antes da emissão de qualquer alerta crítico.

No final, o caso reforça uma verdade central da cibersegurança moderna, quanto mais crítico o sistema, menor pode ser a tolerância a falhas de autorização, porque o impacto não é digital, é diretamente na sociedade.

51% das instituições financeiras pesquisadas perdem mais de US$10 milhões ao ano com fraudes no Brasil

As perdas financeiras e o volume de golpes no setor bancário brasileiro continuam em uma escalada agressiva. Uma nova pesquisa da BioCatch, líder em prevenção a fraudes por inteligência comportamental, revela que 89% dos líderes bancários no Brasil relatam aumento nas tentativas de golpe em 2026. O número representa um salto notável frente aos 77% do ano anterior e supera a média global atual, que é de 81%

O estudo inédito entrevistou 100 profissionais de alta liderança (gerência, diretoria e C-suite) das áreas de gestão de fraudes, prevenção a crimes financeiros, risco e compliance no país. O perfil dos participantes reflete o peso do ecossistema financeiro nacional: 99% atuam em instituições com mais de US$ 10 milhões sob gestão, e metade (50%) gerencia ativos que superam a marca de US$ 1 bilhão.

Embora o Brasil tenha se posicionado como o mercado mais próximo das médias globais entre todos os países pesquisados, os dados nacionais de perdas e sofisticação acendem um alerta vermelho para o setor.

O prejuízo financeiro das fraudes no ecossistema brasileiro

A pressão financeira exercida pelas atividades criminosas já dita o orçamento dos grandes bancos, gerando impactos severos tanto para as instituições quanto para os usuários. No âmbito institucional, mais da metade dos entrevistados no Brasil (51%) perde acima de US$ 10 milhões para fraudes todos os anos. Ao mesmo tempo, para 19% dos entrevistados esse rombo supera os US$ 25 milhões anuais e, para 3%, o dano ultrapassa a marca de US$ 100 milhões.

Na outra ponta, o prejuízo transferido ao cliente final é igualmente alarmante. Cerca de 74% dos executivos afirmam que seus clientes perdem mais de US$ 5 milhões anualmente em fraudes autorizadas e golpes, e quase metade (44%) relata perdas de clientes acima de US$ 10 milhões ao ano.

Esse cenário é ainda mais agravado pelo dinamismo e rapidez dos ataques, que preocupam diretamente os comitês de risco: atualmente, 82% dos líderes de fraude no Brasil declaram estar muito preocupados com o aumento na velocidade da atividade fraudulenta, um índice superior aos 76% registrados na média global.

Deepfakes e novas vulnerabilidades

A inteligência artificial transformou-se rapidamente em uma arma de engenharia social nas mãos de organizações criminosas, desafiando as defesas tradicionais das instituições brasileiras. Essa nova realidade é evidente no avanço dos ataques baseados em deepfakes, já observados por quase dois terços (63%) dos executivos no Brasil nos últimos 12 meses, um índice significativamente superior à média global de 50%. Na prática, a tecnologia não está criando golpes inteiramente novos, mas tornando as táticas existentes muito mais críveis em um mercado onde o Pix, o WhatsApp, o mobile banking e o comércio em redes sociais estão profundamente enraizados no cotidiano.

Um dos reflexos disso no dia a dia do ecossistema nacional são os golpes de emergência familiar por chamadas ou mensagens no WhatsApp, em que criminosos utilizam áudios gerados por IA para imitar a voz de filhos ou cônjuges simulando uma urgência e solicitando transferências Pix imediatas. Da mesma forma, os criminosos clonam a voz de gerentes ou utilizam áudio e vídeo alterados por IA em falsas chamadas de suporte bancário; a vítima é induzida a acreditar que sua conta está sob ataque e acaba convencida a transferir fundos para uma suposta ‘conta segura’ ou a instalar softwares de acesso remoto.

Paralelamente, o país enfrenta sérias dificuldades para barrar golpes de falsificação de identidade (impersonation), com 60% dos tomadores de decisão locais classificando como muito ou extremamente difíceis de reconhecer. E, olhando para o futuro, a preocupação com a próxima onda de ataques é um consenso: para 90% dos profissionais brasileiros entrevistados, a IA Agêntica pode se tornar a maior vulnerabilidade explorável pelo crime organizado no próximo ano. E, além de tudo, 83% apontam que será extremamente desafiador mitigar o problema e distinguir ações legítimas assistidas por IA de atividades maliciosas ou manipuladas.

“A grande virada de chave tecnológica que estamos presenciando reside na evolução dos agentes de IA tradicionais para a chamada IA Agêntica. Enquanto um agente comum executa de forma rígida uma única tarefa programada, a IA Agêntica possui autonomia para traçar caminhos alternativos e contornar barreiras até atingir seu objetivo”, afirma Diego Baldin, diretor de Global Advisory da BioCatch para a América Latina.

“Quando essa tecnologia é capturada pelo crime organizado, passamos a lidar com sistemas automatizados capazes de conduzir interações complexas de engenharia social, persuadindo uma vítima até que ela esteja totalmente convencida, para só então repassar o ataque para um operador humano, que  conclui o golpe. Esse ecossistema não apenas automatiza o roubo de dados, mas é inteligente o suficiente para filtrar e priorizar as informações mais valiosas, conectar-se a outras ferramentas maliciosas e aprender com os próprios erros em tempo real. Se o algoritmo encontra um bloqueio de segurança, ele recalcula a rota autonomamente até conseguir violar o sistema.”

A urgência da inteligência interbancária

Diante de um cenário em que a autenticação tradicional perde eficácia contra a persuasão digital e a tecnologia avançada, a alta liderança bancária do país aponta o compartilhamento de dados em rede como uma das principais soluções.

A grande maioria dos executivos brasileiros (88%) acredita que o compartilhamento de inteligência entre bancos teria um impacto positivo significativo na capacidade de conter fraudes e crimes financeiros. Indo além, 89% afirmam que obter inteligência em tempo real sobre a conta destinatária envolvida em uma transação seria o divisor de águas para identificar e conter golpes financeiros antes que o dinheiro seja pulverizado.

Curiosamente, a pesquisa também revelou uma característica cultural do mercado nacional: os líderes bancários brasileiros são significativamente menos propensos do que seus pares internacionais a afirmar que suas instituições investem em prevenção de fraudes para evitar a perda de clientes (churn). Apenas 23% dos executivos no Brasil citam a perda de clientes como motivo para investimentos na área, contra 39% globalmente. O foco do país está direcionado firmemente no combate à sofisticação tática do crime e na proteção sistêmica do fluxo financeiro.

“A IA já está redefinindo a velocidade e a sofisticação das ameaças no Brasil, permitindo que criminosos escalem ataques de engenharia social com o uso de deepfakes em um ritmo muito superior à média global”, conta Baldin.

“O dado mais revelador é que no ecossistema brasileiro, ao contrário do mercado global, a liderança local investe em prevenção a fraudes motivada pela blindagem financeira imediata. Em um ambiente hiperconectado e de transações instantâneas, a urgência financeira e operacional parece ter prioridade, ao conter o vazamento monetário e a velocidade do crime. Para vencer essa corrida, o setor precisa ir além das checagens estáticas de identidade: o futuro depende do entendimento contínuo e em tempo real do comportamento e da intenção do usuário, combinado com uma rede de inteligência interbancária que neutralize as contas de laranjas usadas para lavar o produto das fraudes.”

Acesse a pesquisa completa aqui.

Gen alerta sobre uma campanha sofisticada de falsas ofertas de emprego projetada para roubar credenciais

Os pesquisadores de ameaças da Gen (NASDAQ: GEN), líder global na promoção da liberdade digital por meio de um portfólio de marcas confiáveis que inclui Norton, Avast, LifeLock e MoneyLion, entre outras, identificaram uma sofisticada campanha de fraude que utiliza falsas ofertas de emprego e processos de recrutamento aparentemente legítimos para roubar credenciais de acesso dos usuários e obter informações sensíveis. Os criminosos exploram a reputação de organizações e marcas amplamente reconhecidas, assim como o interesse gerado por grandes acontecimentos internacionais, para dar maior credibilidade aos seus golpes.

Entre os exemplos analisados, foram encontrados sites que se passavam pela FIFA e por outras entidades e marcas vinculadas a um dos eventos esportivos mais aguardados de 2026. No entanto, os pesquisadores também observaram tentativas semelhantes que utilizavam a imagem de empresas reconhecidas de diferentes setores para gerar confiança nos usuários.

A investigação revelou que os criminosos não se limitam a publicar vagas falsas. Em muitos casos, eles constroem processos completos de contratação que incluem perfis falsos de recrutadores, alguns deles baseados em fotografias e informações de profissionais reais disponíveis publicamente em plataformas como o LinkedIn. Além disso, enviam convites de calendário e direcionam as vítimas para sites projetados para imitar páginas legítimas de recrutamento.

Os pesquisadores alertam que uma página de emprego com aparência profissional não garante que seja autêntica. Os cibercriminosos podem copiar logotipos, fotografias, descrições de vagas e até botões de login de sites legítimos para criar páginas fraudulentas altamente convincentes. Além disso, o uso de ferramentas de inteligência artificial facilitou a criação desse tipo de sites maliciosos, tornando-os cada vez mais difíceis de detectar.

Uma vez no site, os usuários são convidados a iniciar sessão por meio de opções conhecidas, como o acesso com o Google. No entanto, por trás dessas páginas há formulários criados para capturar credenciais e outras informações sensíveis. Os pesquisadores observaram que algumas campanhas rejeitavam contas pessoais e solicitavam especificamente contas corporativas, com o objetivo de obter acesso a sistemas internos, arquivos e outros recursos empresariais.

“A engenharia social tornou-se cada vez mais sofisticada. Os cibercriminosos já não dependem apenas de e-mails suspeitos ou mensagens mal redigidas; agora são capazes de replicar processos completos de recrutamento, inclusive com ajuda da IA, e aproveitar a confiança gerada por marcas e organizações reconhecidas. Isso transforma as falsas ofertas de emprego em uma ameaça especialmente perigosa, já que as vítimas acreditam estar diante de uma oportunidade profissional legítima quando, na realidade, estão entregando acesso a informações valiosas”, afirma Iskander Sanchez-Rola, Diretor Sênior de IA e Inovação na Norton.

Os pesquisadores também descobriram que, uma vez que uma página maliciosa é removida, os criminosos geralmente registram novos domínios para dar continuidade à campanha. Essa capacidade de adaptação dificulta a detecção e permite que as ameaças permaneçam ativas por mais tempo.

Desde 1º de maio de 2026, os produtos da Gen, incluindo Norton, bloquearam mais de 250 ataques relacionados a essas campanhas, embora os especialistas alertem que o alcance real pode ser maior devido à constante evolução das táticas utilizadas pelos cibercriminosos.

Para ajudar os usuários a identificar esse tipo de ameaça, os especialistas da Norton recomendam:

  • Desconfiar de ofertas de emprego inesperadas ou excessivamente atraentes.
  • Verificar se as vagas provêm de sites oficiais e prestar atenção ao endereço do site.
  • Confirmar a legitimidade dos recrutadores antes de fornecer informações pessoais.
  • Evitar inserir credenciais em páginas acessadas por links recebidos por e-mail ou aplicativos de mensagens.
  • Suspeitar de qualquer processo de recrutamento que solicite credenciais corporativas ou informações sensíveis em etapas iniciais.
  • Confirmar a existência da vaga diretamente nos canais oficiais da organização.
  • Utilizar ferramentas de cibersegurança, como o Norton 360 com Norton Scam Protection, que utiliza inteligência artificial para ajudar a detectar tentativas de phishing e sites fraudulentos antes que comprometam informações pessoais ou credenciais de acesso.

À medida que as campanhas de fraude evoluem, a combinação entre engenharia social e o uso indevido de marcas reconhecidas continua se tornando uma das ferramentas mais eficazes para os cibercriminosos. Manter uma postura crítica e verificar cada etapa do processo pode ajudar a diferenciar uma oportunidade legítima de uma fraude projetada para comprometer informações pessoais e corporativas.

Sobre a Gen

Gen (NASDAQ: GEN) é uma empresa global dedicada a impulsionar a Liberdade Digital por meio de suas marcas de consumo confiáveis, incluindo Norton, Avast, LifeLock, MoneyLion e outras. A família de marcas da Gen tem como base a oferta de segurança cibernética e empoderamento financeiro para as primeiras gerações digitais. Hoje, a Gen capacita as pessoas a viverem suas vidas digitais com segurança, privacidade e confiança para as gerações futuras. A Gen oferece produtos e serviços premiados em cibersegurança, privacidade online, proteção de identidade e bem-estar financeiro para quase 500 milhões de usuários em mais de 150 países. Saiba mais em GenDigital.com.

Sobre os Laboratórios de Ameaças da Gen

Os Laboratórios de Ameaças da Gen representam a equipe de pesquisa e tecnologia de Segurança Cibernética dentro da Gen, focada em descobrir e analisar as mais recentes ameaças digitais e golpes em todo o mundo. Com base em dados, pesquisa e experiência técnica, a equipe mapeia padrões e riscos que moldam um cenário de ameaças em constante evolução. Essas descobertas impulsionam tecnologias de segurança que protegem as pessoas em todo o portfólio de marcas confiáveis da Gen, incluindo Norton, Avast e LifeLock, entre outras.

Sobre a Norton

Norton é líder em cibersegurança e faz parte da Gen (NASDAQ: GEN), empresa global dedicada a promover a Liberdade Digital por meio de um portfólio de marcas confiáveis para o consumidor. A Norton capacita milhões de pessoas e famílias com proteção premiada para seus dispositivos, privacidade online e identidade digital. Os produtos e serviços da Norton são certificados por organizações independentes de testes, incluindo AV-TESTAV-Comparatives e SE Labs. A Norton também é membro fundadora da Coalition Against Stalkerware. Saiba mais em https://br.norton.com

Serviços financeiros em risco: os ataques de DDoS estão maiores, mais longos e mais complexos, segundo uma pesquisa da Akamai

Os cibercriminosos agora visam os serviços financeiros mais do que qualquer outro setor para ataques de negação de serviço distribuída (DDoS) na web e em APIs (camadas 3 e 4), revela a Akamai (NASDAQ: AKAM) em seu relatório State of the Internet (SOTI) intitulado AI-Empowered Botnets and API Visibility Gaps: Attack Trends in Financial Services. As descobertas revelam uma mudança perigosa à medida que hacktivistas pró-Irã e bots impulsionados por IA usam táticas de DDoS para interromper serviços bancários online, sistemas de pagamento e aplicações críticas.

Impulsionada por infraestruturas alimentadas por IA, a duração média dos ataques globais de DDoS das camadas 3 e 4 direcionados ao setor de serviços financeiros aumentou 738% desde 2024. Isso mostra que, embora a transformação digital tenha permitido avanços como serviços bancários online e pagamentos em tempo real, ela também facilitou as invasões.

Algumas descobertas importantes do relatório:

  • Entre os líderes de serviços financeiros entrevistados no Estudo sobre o impacto da segurança de APIs de 2026, 96% relataram pelo menos um incidente com a segurança de APIs nos últimos 12 meses, o índice mais alto entre todos os setores.

  • Em 2025, 60% do total de ataques na web e 83% das incursões contra pontos de extremidade de APIs visaram serviços bancários.

  • Quase 80% das instituições financeiras enfrentaram ataques de ransomware nos últimos dois anos, mas menos da metade adotou tecnologias avançadas de segurança.

  • A atividade avançada de bots aumentou 147% no final de 2025 e, em um estudo de caso, impressionantes 96% de todo o tráfego de websites foram identificados como bots de scraping mal-intencionados.

  • Os métodos de ataques cibernéticos contra serviços financeiros variam significativamente de acordo com a região: a EMEA é o principal alvo de DDoS das camadas 3 e 4 (62%), a APAC é a mais visada por DDoS da camada 7 (52%) e, na América do Norte, os ataques na web são os mais predominantes (44%).

“Os cibercriminosos e hacktivistas continuam impulsionando os ataques de DDoS, transformando-os em uma ameaça constante, e os serviços financeiros estão na mira”, afirma Steve Winterfeld, CISO consultivo da Akamai. “Além disso, os dados mostram que as APIs são cada vez mais visadas, pois a IA não reduz os riscos de segurança tradicionais, ela os amplifica. Felizmente, as organizações de serviços financeiros podem aproveitar as estratégias de segurança e as práticas recomendadas detalhadas neste relatório.”

O relatório também mostra tendências baseadas em dados sobre atividades criminosas, a participação do CISO da FS-ISAC, um destaque de segurança sobre recursos MITRE, um destaque de nuvem sobre as diferenças entre arquiteturas de IA e estratégias práticas de mitigação de ataques de DNS e DDoS.

Já em seu 12º ano, os relatórios SOTI Security da Akamai continuam oferecendo insights críticos sobre tendências de cibersegurança e desempenho na web, extraídos de ataques observados na infraestrutura protetiva de cibersegurança da Akamai, que lida com uma parcela significativa do tráfego global da web.

Sobre a Akamai

A Akamai é a empresa de cibersegurança e computação em nuvem que potencializa e protege negócios online. Nossas soluções de segurança líderes de mercado, inteligência avançada contra ameaças e equipe de operações globais oferecem defesa em profundidade para garantir a segurança de dados e aplicações empresariais em todos os lugares. As abrangentes soluções de computação em nuvem da Akamai oferecem desempenho e acessibilidade na plataforma mais distribuída do mundo. Empresas globais confiam na Akamai para obter a confiabilidade, a escala e a experiência necessárias para expandir seus negócios com confiança. Saiba mais em akamai.com e akamai.com/blog, ou siga a Akamai Technologies no X e no LinkedIn.

Ferramentas de vigilância baseadas em veículos

É melhor pensar no carro moderno como um computador sobre rodas que constantemente envia dados de diagnóstico para os servidores da montadora ou do revendedor. Ao entrar no carro, você encontrará dezenas de sensores: GPS, velocímetros, microfones com viva-voz, câmeras externas e até mesmo sensores menos óbvios (mas muito ativos) de pressão do pedal, pressão dos pneus, temperatura do motor e muito mais. Ainda que esses dados não sejam transmitidos à montadora em tempo real, eles são registrados na memória interna do carro e podem revelar uma grande quantidade de informações sobre as viagens, os hábitos e o entorno do motorista. Já explicamos como as montadoras coletam dados para uso comercial e para quem eles são vendidos (alerta de spoiler: as seguradoras são as maiores compradoras de telemetria), mas hoje mostraremos como os órgãos de segurança pública e as agências de inteligência utilizam essa mina de ouro.

Provas digitais

Os departamentos de polícia do mundo todo reconhecem o imenso valor dos dados armazenados nos veículos. Quando um carro ou o seu proprietário está envolvido em um crime, os investigadores fazem mais do que apenas verificar impressões digitais ou DNA. A tecnologia Car Intelligence (CARINT) permite que eles vasculhem todos os sistemas a bordo do carro, extraindo dados como:

  • Histórico de viagens fornecido pelo GPS
  • Registros de chamadas, atividade do player de mídia e comandos de voz
  • Listas de dispositivos pareados e de contatos sincronizados
  • Estatísticas de condução: quilometragem, modos de desempenho do motor e outros parâmetros técnicos

Há vários casos em que esses dados serviram como prova e desmentiram álibis. Em um caso ocorrido nos EUA, um comando de voz gravado representou a prova concreta de que a pessoa tida como suspeita era a autora do crime.

Com o aumento de carros conectados com SIM próprio e comunicação direta com a montadora, agentes de segurança pública não precisam mais de acesso físico ao veículo. Dados importantes, como o histórico de localização fornecido pelo GPS, podem ser obtidos diretamente dos servidores da montadora. Além disso, uma investigação conduzida pelo Senado dos EUA revelou que nove das 14 montadoras investigadas estavam fornecendo esses dados sem um mandado.

Os principais fornecedores de software de inteligência automotiva, como Ateros, Berla, TA9/Rayzone e Toka, vendem apenas para agências governamentais e policiais, por isso são pouco conhecidos pelo público.

Vigilância abrangente

Para rastrear pessoas, os dados extraídos do seu próprio veículo são cruzados com informações de outras fontes. Segundo vazamentos à imprensa, os principais produtos dessa categoria combinam dados do SIM do carro, registros de Bluetooth, imagens de câmeras de segurança de monitoramento urbano e informações disponibilizadas para venda por corretores de dados. Esse conjunto de dados híbrido simplifica o mapeamento abrangente dos movimentos e contatos de uma pessoa sob investigação. Jornalistas descobriram que algumas empresas permitem ativar remotamente microfones e câmeras do veículo sem que o proprietário descubra, permitindo a eles ouvir conversas em tempo real. No entanto, especialistas observam que, devido à diversidade de implementações técnicas em diferentes sistemas, invadir o sistema de um carro continua sendo uma tarefa difícil e sem garantia de sucesso. Muitas vezes, é mais simples correlacionar outros conjuntos de dados, mais acessíveis, para obter o mesmo resultado.

Ferramentas de espionagem nativas

Recursos como a ativação secreta de câmeras, microfones e outros sensores podem, em teoria, fazer parte das funcionalidades de fábrica de um veículo, em vez de serem resultado de uma invasão. Embora não tenhamos encontrado nenhuma prova pública de tais casos, sabe-se que os veículos fabricados na China estão sob crescente escrutínio em vários países. Eles foram banidos de instalações militares israelenses, com exceção de um único modelo da Chery, desde que seu sistema multimídia tenha sido removido. O Reino Unido e a Polônia também estabeleceram proibições semelhantes, sendo que os funcionários do Ministério da Defesa do Reino Unido são instruídos a não conectar o telefone de trabalho a carros fabricados na China. Na Alemanha, as análises de segurança de veículos chineses foram realizadas pelas agências especializadas BfV e ZITiS, mas as descobertas permanecem confidenciais.

Vigilância de baixo custo

Para rastrear um veículo, ou milhares deles, não é necessário invadir os sistemas a bordo nem acessar extensas redes de leitores de placas. Um estudo científico recente demonstrou que os sistemas de monitoramento da pressão dos pneus (TPMS), que à primeira vista parecem inocentes, fornecem dados suficientes para um rastreamento eficaz. Os dados desses sensores são transmitidos por rádio sem qualquer criptografia e incluem um ID exclusivo que facilita a identificação de um carro específico. Isso permite mais do que apenas confirmar o movimento do veículo; também pode ser usado para estimar o peso do motorista ou determinar se ele está viajando sozinho. Pode não parecer tão impressionante quanto acessar remotamente as câmeras de um carro, mas exige pouco investimento e funciona até em veículos mais antigos sem conexão com a Internet.

Como se proteger contra o rastreamento de veículos

Rastrear alguém pelo carro compromete a privacidade. No entanto, equilibrar a mitigação desse risco é difícil, pois muitas medidas são complexas e ineficazes, reduzindo a utilidade, a segurança e a conveniência dos veículos modernos. Assim, antes de tomar qualquer medida, você deve ponderá-la em relação ao seu perfil de risco pessoal.

Para reduzir o risco de vazamento de dados, verifique as configurações de privacidade no aplicativo do fabricante, no sistema multimídia do carro e no smartphone conectado. Um carro conectado pode transmitir para a nuvem dados sobre seu funcionamento: informações sobre viagens, localização, estilo de direção, condição do veículo e funcionamento de seus componentes. Alguns desses dados são necessários para navegação, diagnóstico e manutenção, mas nem todas as permissões são indispensáveis: revise as configurações e desative a transmissão de dados não relacionados às funções necessárias.

Tenha cuidado com as permissões de acesso ao microfone, à câmera, aos contatos, às mensagens e à geolocalização. Conecte ao carro apenas seus próprios dispositivos e não salve telefones de outras pessoas nem dispositivos Bluetooth desconhecidos no sistema. Ao sincronizar o smartphone, selecione apenas recursos dos quais precisa: chamadas, música e navegação, em vez de conceder acesso total a todos os dados do aparelho.

Não recorra a técnicos que ofereçam “desbloquear” o carro, reprogramar unidades de controle eletrônico ou instalar softwares para ampliar recursos, aumentar a potência ou interferir no funcionamento do carro. Esses softwares não foram testados pelo fabricante: eles podem agir de forma imprevisível, coletar e transmitir dados para agentes maliciosos, desativar recursos de segurança ou afetar sistemas críticos do veículo: incluindo direção, frenagem e funcionamento do motor.

Ao escolher um carro novo, pergunte na concessionária não apenas sobre a pontuação nos testes de segurança NCAP, potência do motor ou consumo de combustível, mas também sobre as tecnologias de cibersegurança utilizadas no veículo. Soluções como o Kaspersky Automotive Secure Gateway, que é baseado no KasperskyOS, fornecerão a proteção necessária para carros novos contra ameaças cibernéticas.

Que outras ameaças os carros conectados escondem? Leia mais em nossas publicações:

Como proteger sua organização contra vulnerabilidades de Wi-Fi do AirSnitch

Na conferência de segurança da informação NDSS Symposium 2026, realizada em fevereiro em San Diego, um renomado grupo de pesquisadores apresentou um estudo que revelou o ataque AirSnitch, capaz de contornar o recurso de isolamento de clientes Wi-Fi, também conhecido como rede de visitantes ou isolamento de dispositivos. Esse ataque permite conectar-se a uma rede sem fio por meio de um ponto de acesso e, a partir daí, acesse outros dispositivos conectados, inclusive os que usam identificadores de rede (SSIDs) diferentes no mesmo hardware. Os dispositivos-alvo podem facilmente estar em sub-redes sem fio protegidas por WPA2 ou WPA3. Na verdade, o ataque não quebra a criptografia; ele explora a maneira como os pontos de acesso lidam com chaves de grupo e roteamento de pacotes.

Na prática, isso significa que redes de visitantes oferecem um nível muito baixo de segurança real. Se as redes corporativa e de visitantes estiverem no mesmo dispositivo físico, o AirSnitch permite que um invasor conectado injete tráfego malicioso em SSIDs vizinhos. Em alguns casos, ele pode até realizar um ataque man-in-the-middle (MitM) completo.

A segurança do Wi-Fi e o papel do isolamento

A segurança do Wi-Fi está em constante evolução. Sempre que surge um ataque viável contra a geração de proteção mais recente, o setor responde com algoritmos e processos mais complexos. Esse ciclo começou com os ataques FMS, usados para quebrar chaves de criptografia WEP, e continua até hoje. Exemplos recentes incluem os ataques KRACK ao WPA2 e os FragAttacks, que afetam todas as versões do protocolo de segurança WEP até WPA3.

Atacar redes Wi-Fi modernas de forma eficaz (e discreta) não é uma tarefa simples. A maioria dos profissionais considera que usar WPA2/WPA3 com chaves complexas e separar redes por finalidade costuma ser suficiente para a proteção. No entanto, apenas especialistas sabem que o isolamento de clientes nunca foi padronizado nos protocolos IEEE 802.11. Fabricantes diferentes implementam esse isolamento de formas distintas, usando a Camada 2 ou 3 da arquitetura de rede (ou seja, no roteador ou no controlador Wi-Fi), o que significa que o comportamento de sub-redes isoladas varia bastante dependendo do ponto de acesso específico ou do modelo do roteador.

Embora o marketing afirme que o isolamento de clientes é ideal para impedir que visitantes de restaurantes ou hotéis ataquem uns aos outros, ou para garantir que visitantes corporativos não possam acessar nada além da Internet, na prática, esse isolamento muitas vezes depende do fato de ninguém tentar explorá-lo. É justamente isso que a pesquisa sobre o AirSnitch demonstra.

Tipos de ataques AirSnitch

O nome AirSnitch não se refere a uma única vulnerabilidade, mas a toda uma família de falhas de arquitetura em pontos de acesso Wi-Fi. Também é o nome de uma ferramenta de código aberto usada para testar roteadores quanto a esses pontos fracos específicos. Ainda assim, os profissionais de segurança precisam lembrar que a linha entre teste e ataque é bastante tênue.

O modelo desses ataques é sempre parecido: um cliente malicioso se conecta a um ponto de acesso com isolamento ativado. Outros usuários (as vítimas) estão conectados ao mesmo SSID ou a SSIDs diferentes no mesmo ponto de acesso. Esse cenário é comum; por exemplo, uma rede de visitantes pode estar aberta e sem criptografia, ou um invasor pode simplesmente obter a senha do Wi-Fi de visitante se passando por um visitante legítimo.

Para determinados ataques AirSnitch, o invasor precisa saber previamente o endereço MAC ou o IP da vítima.  Em última análise, a eficácia de cada ataque depende do fabricante do hardware (veja mais detalhes abaixo).

Ataque de GTK

Após o handshake do WPA2/WPA3, o ponto de acesso e os clientes compartilham uma Group Transient Key (GTK) para lidar com o tráfego de broadcast. Nesse cenário, o invasor encapsula os pacotes destinados a uma vítima específica dentro de um pacote de tráfego de transmissão. Em seguida, ele envia esses pacotes diretamente à vítima, falsificando o endereço MAC do ponto de acesso. Esse ataque permite apenas a injeção de tráfego, o que significa que o invasor não recebe uma resposta. Mesmo assim, já é suficiente para enviar anúncios de roteamento ICMPv6 maliciosos ou mensagens DNS e ARP ao cliente, ignorando efetivamente o isolamento. Essa é a forma mais universal do ataque, funcionando em redes WPA2/WPA3 que usam uma GTK compartilhada. Alguns pontos de acesso corporativos, no entanto, permitem a randomização da GTK por cliente, o que neutraliza esse método.

Redirecionamento de pacotes de transmissão

Nessa versão do ataque, o invasor nem precisa se autenticar primeiro no ponto de acesso. Ele envia pacotes ao ponto de acesso com um endereço de destino de transmissão (FF:FF:FF:FF:FF:FF) e a sinalização ToDS definida como 1.  Como resultado, muitos pontos de acesso tratam esse pacote como tráfego de transmissão legítimo, o criptografam usando a GTK e o enviam para todos os clientes na sub-rede, incluindo a vítima. Assim como no método anterior, é possível encapsular o tráfego especificamente destinado a uma única vítima dentro dos pacotes.

Redirecionamento via roteador

Esse ataque explora uma falha de arquitetura entre as Camadas de segurança 2 e 3 presente no hardware de alguns fabricantes. O invasor envia um pacote ao ponto de acesso, definindo o endereço IP da vítima como destino na camada de rede (L3).  No entanto, na camada sem fio (L2), o destino é definido como o próprio endereço MAC do ponto de acesso, evitando que o filtro de isolamento seja acionado. O subsistema de roteamento (L3) depois encaminha o pacote de volta à vítima, contornando completamente o isolamento da L2. Assim como nos métodos anteriores, trata-se de um ataque apenas de transmissão em que o invasor não vê a resposta.

Roubo de porta para interceptação de pacotes

O invasor se conecta à rede usando uma versão falsificada do endereço MAC da vítima e inunda a rede com respostas ARP dizendo: “este endereço MAC está na minha porta e SSID”.  O roteador da rede alvo atualiza suas tabelas MAC e começa a enviar o tráfego da vítima para essa nova porta. Com isso, o tráfego destinado à vítima acaba sendo recebido pelo invasor, mesmo que a vítima esteja conectada a outro SSID.

Se o invasor estiver em uma rede aberta e sem criptografia, isso significa que o tráfego destinado a um cliente em uma rede protegida por WPA2/WPA3 pode acabar sendo transmitido “em claro”, permitindo que qualquer pessoa próxima o capture.

Roubo de porta para envio de pacotes

Nessa versão, o invasor se conecta diretamente ao adaptador Wi-Fi da vítima e o bombardeia com solicitações ARP, falsificando o endereço MAC do ponto de acesso. Como resultado, o computador da vítima passa a enviar seu tráfego ao invasor em vez da rede. Ao combinar essas duas técnicas de roubo de porta, um invasor pode, em vários cenários, realizar um ataque completo de MitM.

Consequências práticas dos ataques AirSnitch

Ao combinar várias dessas técnicas, um hacker pode realizar algumas ações bastante graves:

  • Interceptação completa de tráfego bidirecional para um ataque MitM. Isso significa que o invasor pode capturar e modificar dados entre a vítima e o ponto de acesso sem que ela perceba.
  • Movimentação entre SSIDs. Um invasor em uma rede de visitantes pode alcançar hosts em uma rede corporativa restrita, desde que ambas usem o mesmo ponto de acesso físico.
  • Ataques ao RADIUS. Como muitas empresas usam a autenticação via RADIUS no Wi-Fi corporativo, um invasor pode falsificar o endereço MAC do ponto de acesso para interceptar os pacotes iniciais de autenticação RADIUS. A partir daí, ele pode tentar descobrir o segredo compartilhado por força bruta. Com isso em mãos, ele pode criar um servidor RADIUS e um ponto de acesso falsos para capturar dados de qualquer dispositivo que se conecte a eles.
  • Exposição de dados não criptografados em sub-redes “seguras”: o tráfego que deveria estar protegido por WPA2/WPA3 pode ser retransmitido a um cliente em uma rede de visitantes aberta, ficando exposto a qualquer pessoa próxima.

Para executar esses ataques com eficiência, um hacker precisa de um dispositivo capaz de transmitir e receber dados simultaneamente com o adaptador e o ponto de acesso da vítima. Em um cenário do mundo real, isso geralmente envolve um notebook com dois adaptadores Wi-Fi usando drivers Linux configurados especificamente para esse tipo de operação. Vale destacar que o ataque não é totalmente discreto: ele gera um grande volume de pacotes ARP, pode causar pequenas instabilidades no Wi-Fi quando é iniciado e reduzir a velocidade para cerca de 10 Mbps. Mesmo com esses sinais, ainda representa uma ameaça real em muitos ambientes.

Dispositivos vulneráveis

Como parte do estudo, vários pontos de acesso e roteadores corporativos e domésticos foram testados. A lista incluiu produtos da Cisco, Netgear, Ubiquiti, Tenda, D-Link, TP-Link, LANCOM e ASUS, além de roteadores com firmwares populares na comunidade, como DD-WRT e OpenWrt. Todos os dispositivos testados apresentaram vulnerabilidade a pelo menos algumas das técnicas descritas. Mais preocupante ainda: os modelos D-Link DIR-3040 e LANCOM LX-6500 foram vulneráveis a todas as variações do AirSnitch.

Curiosamente, alguns roteadores já contam com mecanismos de proteção que bloqueiam esses ataques, mesmo que as falhas de arquitetura de base continuem presentes. Por exemplo, o Tenda RX2 Pro desconecta automaticamente qualquer cliente cujo endereço MAC apareça simultaneamente em dois BSSIDs, o que na prática impede o roubo de porta.

Os pesquisadores destacam que qualquer administrador de rede ou equipe de segurança de TI que leve a proteção a sério deve testar suas próprias configurações. Essa é a única maneira de identificar exatamente quais ameaças se aplicam ao ambiente da organização.

Como proteger a rede corporativa contra o AirSnitch

O risco é maior para organizações que operam redes Wi-Fi de visitantes e corporativa no mesmo ponto de acesso, sem segmentação adicional por VLAN. Também há riscos significativos para empresas que utilizam RADIUS com configurações desatualizadas ou segredos compartilhados fracos para autenticação sem fio.

Em resumo, é preciso deixar de tratar o isolamento de clientes como uma medida real de segurança e passar a vê-lo apenas como um recurso de conveniência. A segurança real precisa ser tratada de outra forma:

  • Segmentar a rede com VLANs. Cada SSID deve ter sua própria VLAN, com marcação de pacotes 802.1Q aplicada de ponta a ponta: do ponto de acesso até o firewall ou roteador.
  • Implementar inspeção de pacotes mais rigorosa no nível de roteamento, dependendo dos recursos de hardware. Recursos como Inspeção dinâmica de ARP, DHCP snooping e limitação do número de endereços MAC por porta ajudam a proteger contra a falsificação de IP/MAC.
  • Ativar chaves GTK individuais por cliente, se o equipamento for compatível.
  • Usar configurações mais robustas de RADIUS e 802.1X, incluindo conjuntos de cifras modernos e segredos compartilhados robustos.
  • Registrar e analisar anomalias de autenticação EAP/RADIUS no SIEM. Isso ajuda a identificar diversas tentativas de ataque além do AirSnitch. Outros sinais de alerta a serem observados incluem um mesmo endereço MAC aparecendo em diferentes SSIDs, picos de solicitações ARP ou clientes alternando rapidamente entre BSSIDs ou VLANs.
  • Aplicar segurança em camadas superiores na topologia de rede. Muitos desses ataques perdem força se a organização tiver implementado TLS e HSTS de forma abrangente em todo o tráfego de aplicações corporativas, exigir o uso de VPN ativa em todas as conexões Wi-Fi ou tiver adotado plenamente uma arquitetura de confiança zero.

O iPhone não é tão invencível assim: uma análise do DarkSword e do Coruna | Blog oficial da Kaspersky

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çõesPrivacidade e segurançaOtimizaçã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çõesPrivacidade e segurançaModo de bloqueioAtivar 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:

Gerenciamento de vulnerabilidades de código aberto | Blog oficial da Kaspersky

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.

Riscos que surgem durante o desenvolvimento ou o uso de software de código aberto | Blog oficial da Kaspersky

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:

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

Ataques mais notáveis a cadeias de suprimentos em 2025 | Blog oficial da Kaspersky

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.

Integração de cavalos de Troia nas soluções Trivy, Checkmarx e LiteLLM | Blog oficial da Kaspersky

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.

Os aplicativos de saúde mental estão vazando seus pensamentos mais íntimos. Como você lida com a sua segurança? | Blog oficial da Kaspersky

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”.

Tipo de aplicativo Instalações Vulnerabilidades de segurança
Gravidade alta Gravidade média Gravidade baixa Total
Rastreador de humor e hábitos Mais de 10 milhões 1 147 189 337
Chatbot de terapia de IA Mais de 1 milhão 23 63 169 255
Plataforma de saúde emocional de IA Mais de 1 milhão 13 124 78 215
Rastreador de saúde e sintomas Mais de 500 mil 7 31 173 211
Ferramenta de gerenciamento da depressão Mais de 100 mil 0 66 91 157
Aplicativo de ansiedade baseado em TCC Mais de 500 mil 3 45 62 110
Terapia on-line e comunidade de apoio Mais de 1 milhão 7 20 71 98
Autoajuda para ansiedade e fobia Mais de 50 mil 0 15 54 69
Gerenciamento de estresse militar Mais de 50 mil 0 12 50 62
Chatbot AI CBT Mais de 500 mil 0 15 46 61
Total Mais de 14,7 milhões 54 538 983 1575

Vulnerabilidades encontradas nos 10 aplicativos de saúde mental testados. Fonte

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:

❌