Recentemente, fizemos uma postagem sobre tokenomics e ataques de “negação de carteira” (denial of wallet): um novo tipo de ataque DDoS que busca gerar gastos excessivos com tokens de IA. Antes de começarem a proteger os processos de IA de seus colegas contra essa nova ameaça, os profissionais de segurança precisam considerar que as próprias atividades do departamento de segurança da informação também podem ser alvo desse tipo de ataque. Como as equipes de segurança estão testando e implementando ativamente diferentes formas de automação baseada em IA, a ameaça de interferência externa destinada a paralisar o sistema de defesa pode afetar diretamente seus próprios processos e tecnologias.
A Elastic estima que, conforme a arquitetura do SOC baseado em agentes, a triagem de um único alerta de um host pode custar US$ 0,69 com um conjunto de agentes especializados ou US$ 3,42 com um agente de uso geral capaz de executar 14 tipos diferentes de tarefas.
No entanto, esses valores médios ocultam uma enorme variação nos custos. A qualquer momento, o processamento inicial de um alerta simples (como, por exemplo, mil tokens) pode desencadear uma investigação sobre o processamento de milhões de entradas de registro, chamadas de API, e de outros dados relacionados, consumindo milhões de tokens em questão de minutos.
A própria Elastic reconhece que utiliza o modelo Claude Sonnet 4.6 em seu SOC. Isso levanta uma questão imediata: o que acontece quando o orçamento se esgota ou os filtros de segurança do modelo são acionados? No pior cenário, o SOC baseado em IA aciona uma “orquestra de agentes” para investigar eventos suspeitos que se assemelham a movimentos laterais na infraestrutura. O agente faz uma chamada à API da Anthropic, mas o orçamento mensal do departamento já se esgotou, e a API retorna erros. A investigação fica paralisada, e a equipe só percebe o problema meio dia depois. Além disso, se os “filtros de segurança” de um grande provedor de IA, que estão em constante mudança, classificarem as solicitações do SOC como maliciosas, o mesmo poderá ocorrer mesmo que ainda haja orçamento disponível. Isso ficou evidente na experiência da Hugging Face ao investigar a invasão de sua infraestrutura pela OpenAI.
É claro que um invasor tem interesse em provocar esse tipo de situação. O invasor pode aumentar diretamente os custos da equipe de defesa ao inserir prompts maliciosos nos dados que ela processa, como registros DNS TXT, cabeçalhos HTTP, comentários no código e nomes de arquivos, sabendo que esses prompts serão analisados pelos sistemas de segurança da informação. No ataque GhostJacking, registros do WAF são usados como vetor para a injeção de prompts. Em outro método, apresentado em um estudo acadêmico, pesquisadores conseguiram atacar as próprias proteções de segurança dos LLMs, aumentando a latência das solicitações em 148 vezes e o consumo de tokens em 63 vezes. Em teoria, o sistema continua funcionando normalmente, mas o processamento dos alertas fica muito mais lento e os custos associados aumentam significativamente.
Em sistemas baseados em agentes, o esgotamento do orçamento nem sempre gera um erro explícito com a mensagem “limite de solicitações excedido” e um alerta imediato aos responsáveis. Em determinadas configurações, pode ocorrer degradação silenciosa: quando uma solicitação ao modelo excede o tempo limite, o sistema muda automaticamente para um modelo mais barato, reduzindo a qualidade das respostas e interrompendo a execução de subagentes e tarefas periódicas. Enquanto isso, a equipe de segurança pode passar horas acreditando que tudo continua funcionando normalmente.
Gerenciar os custos, é claro, não se resume a “evitar gastos excessivos”. O setor já caiu nessa armadilha ao implementar soluções SIEM: quando as empresas passaram a pagar de acordo com o volume de telemetria coletada, começaram a restringir seletivamente a coleta de registros, nem sempre de forma eficaz. Como resultado, surgiram pontos cegos na detecção de ameaças. O mesmo pode acontecer com os tokens, mas de forma mais rápida e em maior escala. Uma política de redução de custos mal planejada pode comprometer a profundidade das investigações e a qualidade das respostas. Sem uma política desse tipo, a decisão sobre o que cortar ficará a cargo do analista de plantão às 3h da manhã, e não do arquiteto ou do CISO durante a fase de projeto do sistema. Outra possibilidade é que o próprio fornecedor do sistema imponha limites automaticamente.
Alguns princípios simples ajudam a evitar aumentos previsíveis de custos e a gerenciar melhor situações realmente imprevisíveis.
Não recorra à IA para analisar informações que podem ser verificadas por meio de consultas convencionais. Tarefas repetitivas e previsíveis devem continuar sendo executadas da maneira tradicional, com regras e consultas a dados. Essas regras e consultas podem ser desenvolvidas com o auxílio da IA, mas devem funcionar de maneira determinística. O modelo deve ser usado apenas quando for realmente necessário avaliar uma situação ambígua.
Estabeleça limites rigorosos e emita alertas imediatos aos usuários sempre que forem ultrapassados. Combine diferentes tipos de limite, como limites por tarefa, limites diários e assim por diante. Os alertas de violação dos limites devem chegar imediatamente tanto aos analistas de plantão quanto aos responsáveis por todo o sistema.
Defina com antecedência o que fazer quando um limite for atingido. A decisão entre interromper o processo para economizar, mesmo que isso reduza o controle, ou continuar e arcar com os custos deve ser tomada antes que ocorra um incidente.
Restrinja as permissões dos agentes e as ferramentas às quais eles têm acesso. Quanto mais restrito o conjunto de ações, melhor será seu desempenho em tarefas específicas. Isso também reduz as oportunidades de elevar os custos e a probabilidade de exploração por agentes externos.
Examine rigorosamente os dados externos não confiáveis. Solicitações, consultas, mensagens, comentários e campos técnicos de texto livre, como registros DNS, cabeçalhos HTTP e nomes de arquivos, podem servir tanto para injetar prompts maliciosos quanto para sobrecarregar deliberadamente o sistema. Limite o tamanho desses dados e monitore a carga de trabalho que geram.
Para evitar interrupções causadas por provedores externos e manter o controle total sobre os dados da organização, avalie a possibilidade de usar modelos locais implantados na própria infraestrutura, pelo menos nas atividades de segurança da informação. Embora não sejam os modelos mais avançados, sua especialização e seu ajuste fino com dados da empresa podem garantir bom desempenho e reduzir o risco de falhas inesperadas.
Em arquiteturas mais complexas, os LLMs podem ser divididos em níveis de gravidade. A primeira linha de defesa, responsável por roteamento, filtragem de ruído e enriquecimento de dados é tratada localmente por modelos compactos. Isso reduz significativamente a imprevisibilidade dos custos. O segundo nível conta com um modelo local de maior porte, responsável pelo trabalho analítico principal: correlacionar eventos, testar hipóteses e reconstruir o cenário do incidente. Esse modelo também não gera custos por solicitação, mas tem capacidade limitada, o que pode causar gastos além do orçamento, sobrecargas e acúmulo de eventos em filas. Apenas casos excepcionais e realmente complexos são encaminhados a modelos avançados na nuvem, de preferência com a aprovação explícita de um analista. Nesse modelo, ainda há custos variáveis, mas eles ficam restritos a poucos casos. Cada encaminhamento é uma decisão consciente, e não uma consequência inesperada de um script executado durante a noite.
Na prática, essa abordagem reproduz o modelo clássico de SOC em vários níveis: a primeira linha faz a triagem, e a terceira conduz as investigações. A diferença é que essas funções são desempenhadas por modelos, e não por pessoas.
Há pouco tempo, muitas empresas começaram a implementar agentes de IA em uma ampla variedade de fluxos de trabalho. Rapidamente, o custo de uso desses agentes se tornou uma questão urgente para as empresas. Além disso, a questão vai muito além do departamento financeiro. Além das preocupações orçamentárias, surgiram problemas de confiabilidade, estabilidade operacional e até de segurança da informação. Isso ocorre porque o custo de automatizar um mesmo processo varia significativamente entre implementações, é imprevisível e pode ser afetado por fatores externos.
Além disso, para um agente malicioso, qualquer processo automatizado com IA e vulnerável a influências externas é, na prática, um alvo conveniente para o “novo tipo de ataque DDoS”. Relatórios de erros de aplicativos, avaliações de produtos ou solicitações de suporte técnico podem, assim como qualquer outro dado externo processado pela empresa com IA, ser usados em um ataque para aumentar o consumo de tokens (fragmentos de palavras que são a unidade básica de entrada e saída de um LLM).
Em 2026, grandes empresas gastaram pela primeira vez muito além do orçamento destinado a seus sistemas de IA. A Uber já havia gasto todo o orçamento anual até abril, enquanto uma empresa não identificada não definiu limites de gastos para o Claude e gastou US$ 500 milhões em um único mês. Embora os provedores de IA anunciem regularmente preços mais baixos e modelos mais eficientes, a transição de chatbots para sistemas agênticos que operam de forma contínua e autônoma aumenta o consumo de tokens em centenas ou milhares de vezes. Ao mesmo tempo, o modelo de “assinatura fixa de US$ 20 ou US$ 100” para empresas é coisa do passado. Todos os principais provedores estão migrando clientes corporativos para o modelo de pagamento conforme o uso.
Como resultado, as empresas estão enfrentando um problema já conhecido pelos setores de armazenamento em nuvem e telecomunicações. Sem sistemas especializados de contabilização e gerenciamento de custos, uma organização só descobre quanto um determinado processo ou projeto custou depois de concluí-lo. Nos setores de telecomunicações e nuvem, esse problema acabou sendo resolvido com o desenvolvimento de sistemas sofisticados de faturamento, e os clientes desses setores até adotaram o termo especializado FinOps. No caso da IA, esse processo ainda está em estágio inicial. Além disso, a natureza probabilística da IA generativa torna esse problema ainda mais difícil de resolver.
Para entender por que os custos aumentam tão rapidamente e são tão difíceis de prever e controlar, precisamos lembrar como funciona um modelo de linguagem e o que o transforma em um agente de IA. O modelo não armazena informações de estado. Em outras palavras, não retém informações entre as interações. A cada nova etapa, todo o histórico de trabalho de uma determinada tarefa (o contexto) precisa ser reenviado ao modelo: o prompt inicial, o raciocínio anterior, o conteúdo dos arquivos lidos e as respostas de todas as ferramentas. A cada etapa, essa “recapitulação” fica mais longa, especialmente se a tarefa envolver loops iterativos. Se uma etapa falhar, a resposta não for clara ou uma ferramenta retornar um erro, o agente simplesmente tenta novamente, aumentando ainda mais o tamanho do contexto. E, se a tarefa for executada por vários agentes, que dividem o trabalho entre si e trocam resultados, esse volume aumenta proporcionalmente ao número de agentes. Como resultado, o consumo de tokens não aumenta gradualmente, mas em saltos, e é quase impossível prevê-lo no início da tarefa.
Ao executar duas sessões diferentes de um agente de IA para resolver exatamente a mesma tarefa (dois tíquetes de suporte técnico, duas tarefas de análise e assim por diante), a quantidade de tokens consumidos pode variar. A diferença pode chegar a 30 (!) vezes. Isso depende do número de etapas, erros e tentativas necessárias para concluir a tarefa. O aumento do consumo de recursos não depende necessariamente da complexidade da tarefa. Há casos conhecidos em que a IA ficou presa em um “loop de raciocínio” e desperdiçou uma quantidade absurda de recursos em tarefas triviais.
Três gerações de IA em sistemas corporativos consomem recursos de maneiras completamente diferentes:
Como as chamadas a LLMs são significativamente mais caras que as chamadas de software convencionais, automatizar tarefas corporativas rotineiras pode sair muito caro. Por exemplo, o Gartner estima que resolver uma única solicitação de suporte ao cliente usando um LLM custa aproximadamente US$ 3. É fácil imaginar como invasores poderiam bombardear uma empresa com milhares de solicitações longas e sofisticadas geradas por um LLM barato, causando um prejuízo financeiro significativo. Como o processo é automatizado, as anomalias podem não ser detectadas imediatamente.
Se um invasor souber qual sistema de agentes e qual LLM são usados em um processo de negócios, poderá realizar um ataque mais preciso e causar danos significativamente maiores. Os autores do estudo GitInject estimaram que um invasor capaz de criar incidentes no GitHub em uma organização que usa agentes de IA para análise de erros pode, com um único ataque (antes da ação dos mecanismos de defesa do GitHub), causar até US$ 111 em prejuízos e consumir 400 minutos do GitHub Actions da conta da vítima. Naturalmente, esse ataque pode ser repetido várias vezes, sem nenhum custo para o invasor.
O maior risco, embora seja difícil quantificá-lo em termos financeiros, vem de ataques que induzem os LLMs a um raciocínio excessivo. No artigo OverThink, os autores demonstraram como uma tarefa formulada de maneira inofensiva, quando enviada a um modelo de linguagem, produz um resultado correto, mas, nesse processo, consome 46 (!) vezes mais tokens do que deveria. Além disso, todas as tarefas testadas pelos pesquisadores passaram pelos filtros de segurança existentes.
Na nova versão do guia OWASP Top Risks for Language Models, esse problema alcançou a mais alta prioridade já registrada: o consumo ilimitado de tokens agora é classificado como LLM06:2026 e, entre suas variantes, o ataque de “denial of wallet” (negação de carteira), que esgota o orçamento da vítima para o uso de LLMs, é explicitamente destacado.
Antes de tudo, é preciso abandonar o princípio de “usar IA só por usar IA”. Não faz sentido delegar todas as tarefas a agentes autônomos. É recomendável analisar periodicamente o custo-benefício do uso de inteligência artificial.
Além disso, você deve limitar as permissões e o conjunto de ferramentas disponíveis para um agente autônomo de IA. Quanto menos ações o sistema puder executar, mais eficiente será em tarefas específicas, menos oportunidades terá de aumentar os custos e menor será a chance de alguém conseguir “manipulá-lo” para gastar tokens desnecessariamente.
Também recomendamos definir limites rígidos para o consumo de tokens e configurar um sistema de notificações para alertar as pessoas quando esses limites forem ultrapassados. Também é recomendável definir vários limites simultaneamente: por tarefa, por dia e assim por diante. Os alertas de limite excedido devem ser enviados imediatamente ao especialista responsável pelo sistema, para que ele decida se o processo deve continuar ou ser interrompido.
Verifique rigorosamente os dados externos não confiáveis. Qualquer informação processada pela IA que venha de fontes externas, como solicitações, consultas, mensagens, comentários ou campos técnicos que possam conter texto arbitrário (registros DNS, cabeçalhos HTTP, nomes de arquivos), pode não apenas levar à injeção de prompt, mas também aumentar deliberadamente a carga de trabalho. É recomendável limitar o tamanho desses dados e monitorar a carga que geram.
Calcule o custo unitário do trabalho e compare as faturas do fornecedor com seus próprios dados. O custo por análise, solicitação ou verificação é a única maneira de entender pelo que você está pagando e identificar erros nas faturas.
Os threat actors desenvolvem constantemente novos esquemas de ataque, desde roubo de token OAuth até ataques a agentes de IA, mas os métodos clássicos nunca saem completamente de seu repertório. Em qualquer dia, um funcionário pode receber malware anexado diretamente a um e-mail ou à espreita atrás de um link incorporado em um e-mail. Tornar esses ataques bem-sucedidos ainda requer um grau de criatividade e, nos últimos anos, os invasores adotaram cada vez mais formatos de arquivo exóticos. Os usuários não consideram esses formatos perigosos; mais importante ainda, muitas soluções de EDR e de segurança de e-mail ignoram totalmente esses formatos. No entanto, eles provaram ser altamente eficazes na implementação de malware ou na coleta de credenciais.
A seguir estão os tipos de arquivo que podem representar pontos cegos na estratégia de detecção da sua organização, apesar de já terem sido observados em ataques cibernéticos reais.
Essa é a categoria de anexos mais ampla e perigosa. Uma imagem de disco pode conter um conjunto de arquivos totalmente preparado e corretamente estruturado, adaptado a uma ampla variedade de cenários de ataque. Ela é montada como um volume separado (disco virtual independente) e, nesse processo, geralmente usa ferramentas integradas ao sistema operacional. A vítima não precisa descompactar nada nem criar diretórios suspeitos no disco.
O formato mais versátil é o ISO, herdado da era dos CDs multimídia. As imagens ISO são montadas nativamente em todos os principais sistemas operacionais, sem a necessidade de utilitários adicionais, seja por meio de ferramentas simples, como o Explorador de Arquivos, ou pela interface de linha de comando. É exatamente por isso que os threat actors enviam arquivos ISO como anexos de e-mail sem hesitar.
Os contêineres IMG são um pouco menos comuns; eles também podem ser montados sem ferramentas adicionais no macOS ou Linux, mas exigem a instalação de um pequeno utilitário gratuito, como o OSFMount, no Windows, ou o uso do WSL2 (Windows Subsystem for Linux), que vem integrado às versões recentes do Windows. Um arquivo com conteúdo idêntico pode ter a extensão DD.
Os threat actors também usam VHD, um formato de disco virtual nativo do Windows que também funciona em máquinas Linux (via qemu-nbd ou guestmount). No macOS, porém, um utilitário adicional como o qemu-nbd é necessário para a montagem. Observe que em sistemas Windows sem patches, a vítima não precisa fazer nada após montar o disco: o CVE-2025-24993, uma vulnerabilidade ativamente explorada em ataques reais, dispara a execução automática logo após montar a imagem.
Para completar: também vale a pena detectar o VMDK, formato de imagem de disco usado pelo VMware, embora ele seja, em grande parte, ineficaz em ataques contra usuários comuns, pois todos os sistemas operacionais populares exigem software adicional para montá-lo.
Todos esses formatos de imagem podem ser visualizados e descompactados tanto com ferramentas especiais para arquivos comprimidos, quanto com utilitários padrão como 7-Zip ou RAR. Como resultado, as chances de o usuário cair nessa armadilha são surpreendentemente altas.
Além disso, como não são reconhecidos como formatos perigosos, imagens de disco oferecem aos invasores outra vantagem: arquivos extraídos delas no Windows geralmente carecem do sinalizador Mark of the Web, e podem ser iniciados sem nenhum alerta adicional do sistema.
Há mais uma razão para o EPP/EDR verificar máquinas virtuais e imagens de disco: esses formatos também são usados nos estágios posteriores de um ataque. Para ocultar a atividade do sistema de arquivos das ferramentas de monitoramento, gangues de ransomware às vezes executam todo o processo de criptografia em uma máquina virtual no computador da vítima. A cepa de ransomware RagnarLocker usou o VirtualBox para essa finalidade, enquanto a campanha CRON#TRAP contou com um ambiente QEMU.
Não, não se trata de arquivos DOC com macros. A Microsoft bloqueou completamente as macros em documentos baixados, exigindo um esforço considerável do usuário para ativá-las, e ativá-las requer um esforço considerável do usuário. Mas, o Office conta com dezenas de formatos de arquivo, e alguns dos menos comuns ainda oferecem brechas aos invasores.
Os arquivos OneNote (.one) são menos familiares aos usuários e às soluções de segurança. Embora sejam simples notas, podem conter anexos incorporados, incluindo não apenas imagens, links e scripts, mas também scripts VBS/WSF/BAT. Normalmente, um anexo aparece como um ícone dentro da nota, mas os invasores o cobrem com uma imagem que simula uma mensagem com o botão “Visualizar”.
Outro formato do Office popular entre invasores é o complemento do Excel. Embora usem a extensão .xll, esses arquivos são, na verdade, DLLs (bibliotecas de vínculo dinâmico) completas do Windows com funcionalidade irrestrita. As vítimas recebem um e-mail com um documento que parece uma fatura; o ícone sugere que abrirá no Excel. Ignorar o aviso de segurança resulta em infecção por infostealer.
A descrição do formato SVG (Scalable Vector Graphics) soa totalmente inofensiva. De fato, 99% dos arquivos SVG são logotipos e ícones de interface. Diferentemente de PNG ou JPG, porém, arquivos SVG são documentos XML que podem conter não apenas formas geométricas, mas também JavaScript. Em termos de potencial malicioso, o SVG não fica muito atrás de uma página da Web completa. Em ataques reais, os arquivos SVG podem redirecionar usuários para páginas de phishing ao abrir, ou renderizar a página decodificando um bloco codificado em Base64 em HTML.
Arquivos SVG representam um risco significativo para portais corporativos que aceitam uploads de usuários. Se a Política de Segurança de Conteúdo (CSP) não for suficientemente restritiva, um SVG malicioso carregado pode ter seu JavaScript roubar cookies, injetar conteúdo ou sequestrar credenciais.
Os formatos de arquivos poliglotas são menos exóticos por si mesmos, mas contêm mais do que o esperado. Eles são chamados de arquivos poliglotas porque os invasores criam um arquivo que pode ser interpretado corretamente de várias maneiras. Por exemplo, ele pode ser, ao mesmo tempo, um arquivo ZIP válido e um executável válido. O objetivo é evitar detecção por soluções de segurança e enganar o usuário. Abordamos os arquivos poliglotas detalhadamente em uma postagem separada.
O destaque em nosso resumo é uma campanha maliciosa que distribui o infostealer IcedID. As vítimas recebem e-mails com um anexo ZIP contendo uma imagem ISO. Isso ainda é descompactado em um arquivo CHM (formato de Ajuda do Windows) que funciona como aplicativo mshta (host de aplicativos HTML da Microsoft), baixando o malware principal.
Esses ataques exploram a falha de muitas soluções de segurança em verificar formatos incomuns ou inspecioná-los adequadamente. Para se defender da ameaça, comece por presumir que a sua infraestrutura não tem essa limitação:
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.
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.
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.
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.
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
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 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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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 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.
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).
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.
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.
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.
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.
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.
Ao combinar várias dessas técnicas, um hacker pode realizar algumas ações bastante graves:
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.
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.
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:
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.
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.
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 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.
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.
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:
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.
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.
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:
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.
Discover how passwordless authentication reduces friction in SMB software, speeds payments, and prevents revenue loss in service businesses.
The post Passwordless for Service SMB Software: Where Friction Actually Kills Revenue appeared first on Security Boulevard.
Why Small and Mid-Size Businesses Need CIAM in 2026 (And Why the Cost Objection No Longer Holds)
The post Why Small and Mid-Size Businesses Need CIAM in 2026 (And Why the Cost Objection No Longer Holds) appeared first on Security Boulevard.
Entrar