Em junho de 2026, descobrimos um malware incomum que tem como alvo… centrais multimídia automotivas baseadas em Android. Este é o primeiro caso documentado de malware distribuído para centrais multimídia automotivas por meio de um serviço de atualização automática de firmware. Já abordamos diversos incidentes de cibersegurança automotiva, mas, em geral, eles envolviam vazamentos de dados na infraestrutura digital das fabricantes ou testes conduzidos por pesquisadores de segurança.
No entanto, es
Em junho de 2026, descobrimos um malware incomum que tem como alvo… centrais multimídia automotivas baseadas em Android. Este é o primeiro caso documentado de malware distribuído para centrais multimídia automotivas por meio de um serviço de atualização automática de firmware. Já abordamos diversos incidentes de cibersegurança automotiva, mas, em geral, eles envolviam vazamentos de dados na infraestrutura digital das fabricantes ou testes conduzidos por pesquisadores de segurança.
No entanto, este caso envolve malware que cibercriminosos estão distribuindo ativamente. Os objetivos são cometer fraude publicitária e criar uma botnet de proxies formada por centrais multimídia automotivas infectadas. Neste artigo, explicamos o que é uma central multimídia automotiva, como os invasores infectam esses dispositivos e o que isso pode significar para os motoristas.
O que é uma central multimídia automotiva?
Primeiro, vamos esclarecer o que é exatamente uma central multimídia automotiva. O termo pode parecer técnico, mas, na realidade, a maioria dos motoristas interage com uma delas sempre que usa o carro. A central multimídia é o sistema de infoentretenimento do veículo, geralmente centrado em uma tela usada para controlar a navegação, a música e outras funções do veículo. Nos carros modernos, as centrais multimídia automotivas costumam estar conectadas à Internet.
As fabricantes usam frequentemente o Android nas centrais multimídia por sua praticidade, já que o sistema foi desenvolvido para atender a diferentes usos automotivos e oferece diversas vantagens:
muitas opções de personalização da interface;
facilidade para desenvolver aplicativos;
a possibilidade de adicionar aplicativos e componentes próprios ao sistema;
um grande ecossistema de aplicativos já existente.
No entanto, essas mesmas vantagens também criam riscos, pois os aplicativos podem ser maliciosos em vez de legítimos. E foi exatamente isso que aconteceu neste caso: usando um aplicativo malicioso, invasores incorporaram veículos a uma botnet. Veja como isso aconteceu…
Como os invasores infectam as centrais multimídia automotivas e qual malware utilizam?
Primeiro, é importante observar que esse malware não afeta todas as centrais multimídia automotivas, mas apenas aquelas que utilizam software desenvolvido pela empresa chinesa DoFun. A empresa desenvolve firmware, aplicativos e serviços de nuvem para sistemas de infoentretenimento automotivos baseados em Android e, de acordo com seu site, atende a mais de 30 milhões de proprietários de veículos em todo o mundo.
Para distribuir o malware para o sistema de infoentretenimento de um veículo, os invasores usam o TWCore, um aplicativo de sistema legítimo responsável pelas atualizações de software nas centrais multimídia automotivas da DoFun. Em condições normais, o TWCore obtém da nuvem da desenvolvedora informações sobre os arquivos que precisam ser baixados e instalados no dispositivo. Esses arquivos são, principalmente, atualizações de software já instalado na central multimídia, mas o mesmo mecanismo pode ser usado para instalar novos aplicativos. E é exatamente isso que os invasores exploram: eles usam o TWCore para instalar o JarService (um dropper de cavalo de Troia malicioso) nas centrais multimídia automotivas.
O JarService é essencialmente um aplicativo “vazio”. Ou seja, ele não tem uma interface de usuário e não tenta se passar por um serviço legítimo. A ausência de uma interface faz todo sentido neste caso: os invasores não precisam convencer o usuário a instalar o malware manualmente, e nenhuma interação do usuário é necessária.
O código do JarService contém, de forma criptografada, a carga útil da próxima etapa, além de informações sobre sua versão e ponto de entrada. A função do JarService é descriptografar esses dados e iniciar a próxima etapa da infecção: um módulo malicioso de download. Depois de iniciado, o módulo de download se conecta ao servidor de comando e controle (C2) dos invasores e envia informações sobre o malware instalado. Em resposta, o servidor fornece um link para a carga útil da próxima etapa. O módulo de download obtém essa carga útil, descriptografa-a e a executa.
Neste caso, o malware instala um tipo de malware conhecido como “clicker”, usado para aumentar fraudulentamente o número de impressões de anúncios. Depois de ser executado, o malware entra em contato regularmente com o servidor C2 e envia informações sobre o dispositivo infectado, incluindo seu modelo, resolução de tela, endereço MAC e detalhes da rede Wi-Fi conectada. Em troca, o malware pode receber vários comandos dos invasores. Por exemplo, ele pode fazer solicitações HTTP e abrir páginas da Web. Mas, mais importante ainda, pode baixar e executar código malicioso adicional no sistema de infoentretenimento do veículo comprometido.
Os invasores usam esse recurso para instalar um módulo malicioso chamado zhima, que adiciona a central multimídia infectada a uma botnet. A botnet resultante é usada para operar um serviço conhecido como proxy residencial, permitindo que os invasores direcionem seu tráfego por meio dos dispositivos infectados ao realizar ataques e outras atividades maliciosas.
Quem está por trás do malware e o que os invasores pretendem alcançar?
Os invasores infectam centrais multimídia automotivas com malware principalmente para expandir a botnet. Uma investigação realizada por especialistas da Kaspersky constatou que a operação está associada à plataforma maliciosa BADBOX e, mais especificamente, a um dos agentes de ameaça ligados a ela: o MoYu Group. Indícios no código do malware, juntamente com semelhanças em relação à infraestrutura anteriormente atribuída ao MoYu Group, apontam para o envolvimento do grupo. A própria BADBOX reúne uma série de atividades maliciosas voltadas à infecção de dispositivos Android e à exploração clandestina de seus recursos.
Os invasores, então, ganham dinheiro monetizando o acesso a recursos que pertencem a outras pessoas. Ao investigar a infraestrutura da botnet, nossos especialistas descobriram vínculos entre o MoYu Group e os serviços PXYEDGE e ProxyForU, que oferecem serviços de proxy residencial. Esses serviços permitem que clientes de todo o mundo direcionem seu tráfego de Internet por meio de dispositivos conectados à botnet e, assim, acessem a Internet usando os endereços IP desses dispositivos. Isso sugere que as centrais multimídia automotivas infectadas já podem estar sendo usadas como parte dessa infraestrutura.
Como o malware afeta os usuários?
Em primeiro lugar, o malware consome parte dos recursos computacionais da central multimídia automotiva. A carga adicional pode fazer com que o sistema de infoentretenimento do veículo fique mais lento ou menos estável. Ao mesmo tempo, é muito provável que a velocidade da conexão de Internet do dispositivo infectado também diminua, pois os invasores podem direcionar grandes volumes de tráfego por meio dele.
Também vale destacar que o malware não se limita a oferecer funcionalidade de proxy. Ele pode receber comandos dos invasores, além de baixar e executar código malicioso adicional. Como resultado, as consequências de uma infecção podem variar de acordo com a carga útil que os operadores da botnet decidirem instalar no dispositivo.
Conclusão
Este caso demonstra mais uma vez que ataques a todos os tipos de dispositivos conectados à Internet, de decodificadores de TV a sistemas de infoentretenimento automotivo, não são apenas uma possibilidade teórica, mas uma realidade concreta. Os invasores estão constantemente procurando novos dispositivos cujos recursos possam explorar para seus próprios fins. Por isso, a proteção contra malware é importante muito além de computadores e smartphones.
Nossos especialistas informaram a desenvolvedora sobre o esquema de distribuição do malware que identificaram, e ela corrigiu os problemas de segurança identificados.
Uma análise técnica completa do malware está disponível na Securelist.
Que outros métodos os invasores podem usar para comprometer um veículo e quais riscos eles representam para os motoristas? Leia mais em nossas publicações:
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
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 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.
Em uma postagem anterior, analisamos um exemplo prático para entender como a atribuição de ameaças ajuda nas investigações de incidentes. Além disso, apresentamos o Kaspersky Threat Attribution Engine (KTAE), a nossa ferramenta usada para fazer uma estimativa sobre qual grupo APT específico pertence uma amostra de malware. Para fazer a demonstração, usamos o Portal do Kaspersky Threat Intelligence, uma ferramenta baseada na nuvem que fornece acesso ao KTAE como parte de nosso serviço abrangente
Em uma postagem anterior, analisamos um exemplo prático para entender como a atribuição de ameaças ajuda nas investigações de incidentes. Além disso, apresentamos o Kaspersky Threat Attribution Engine (KTAE), a nossa ferramenta usada para fazer uma estimativa sobre qual grupo APT específico pertence uma amostra de malware. Para fazer a demonstração, usamos o Portal do Kaspersky Threat Intelligence, uma ferramenta baseada na nuvem que fornece acesso ao KTAE como parte de nosso serviço abrangente de Análise de Ameaças, juntamente com uma sandbox e uma ferramenta de pesquisa de similaridade sem atribuição. As vantagens de um serviço em nuvem são óbvias: os clientes não precisam investir em hardware, instalar nada ou gerenciar qualquer software. No entanto, assim como indica a experiência do mundo real, a versão na nuvem de uma ferramenta de atribuição não é para todo mundo…
Primeiro, algumas organizações estão sujeitas a restrições regulatórias que proíbem estritamente que quaisquer dados saiam de seu perímetro interno. Para os analistas de segurança dessas empresas, o upload de arquivos para um serviço de terceiros está fora de questão. Em segundo lugar, algumas empresas empregam caçadores de ameaças hardcore que precisam de um kit de ferramentas mais flexível, ou seja, um kit que permita trabalhar com a própria pesquisa proprietária juntamente com a inteligência de ameaças da Kaspersky. É por isso que o KTAE está disponível em duas opções: uma versão baseada na nuvem e uma implementação no local.
Quais são as vantagens do KTAE local em relação à versão na nuvem?
Em primeiro lugar, a versão local do KTAE garante a permanência total da confidencialidade de uma investigação. Toda a análise ocorre diretamente na rede interna da organização. A fonte de inteligência de ameaças é um banco de dados implementado dentro do perímetro da empresa que contém indicadores exclusivos e dados de atribuição de cada amostra maliciosa conhecida por nossos especialistas. Além disso, ele também contém as características relativas aos arquivos legítimos para excluir detecções de falsos positivos. O banco de dados recebe atualizações regulares, mas opera em um sentido, ou sejam, nenhuma informação sai da rede do cliente.
Aliás, a versão local do KTAE oferece aos especialistas a capacidade de adicionar novos grupos de ameaças ao banco de dados para que sejam vinculados a amostras de malware que foram descobertas por conta própria. Isso significa que a atribuição subsequente de novos arquivos será responsável pelos dados adicionados por pesquisadores internos. Isso permite que os especialistas cataloguem seus próprios clusters de malware exclusivos, trabalhem com eles e identifiquem semelhanças.
Qual é a finalidade de um plug-in de atribuição para um desmontador?
Para um analista de SOC que atua na triagem de alertas, atribuir um arquivo malicioso encontrado na infraestrutura é simples: basta que ele seja carregado no KTAE (nuvem ou local) para obter um veredito, como Manuscrypt (83%). Isso é suficiente para tomar as contramedidas adequadas em relação ao conjunto de ferramentas conhecido desse grupo e avaliar a situação geral. Um caçador de ameaças, no entanto, talvez não queira aceitar esse veredito pela aparência. Em um sentido alternativo, eles podem perguntar: “Quais fragmentos de código são exclusivos em todas as amostras de malware usadas por este grupo?” Então, nesse momento, usar um plug-in de atribuição para um desmontador pode ser uma boa ideia.
Dentro da interface do IDA Pro, o plug-in destaca os fragmentos de código desmontados e específicos que acionaram o algoritmo de atribuição. Isso permite não só o aprofundamento mais detalhado nas novas amostras de malware, mas também o refinamento das regras de atribuição em tempo real pelos pesquisadores. Assim, o algoritmo, e o próprio KTAE, continua evoluindo, tornando a atribuição mais precisa a cada execução.
Como configurar o plug-in
O plug-in é um script escrito em Python. Para executar o recurso, é necessário ter o IDA Pro. Infelizmente, ele não funcionará no IDA Free, pois não tem suporte para plug-ins Python. Se o Python ainda não tiver sido instalado, será necessário comprar o recurso, configurar as dependências (verifique o arquivo de requisitos em nosso repositório do GitHub) e garantir que as variáveis de ambiente do IDA Pro estejam apontando para as bibliotecas do Python.
Em seguida, será necessário inserir a URL de sua instância local do KTAE no corpo do script para fornecer o token de API (que está disponível comercialmente), assim como é feito no script de exemplo descrito na documentação do KTAE.
Por fim, basta simplesmente colocar o script na pasta de plug-ins do IDA Pro e iniciar o desmontador. Se isso for feito corretamente, depois de carregar e desmontar uma amostra, será possível ver a opção para iniciar o plug-in do Kaspersky Threat Attribution Engine (KTAE) em Editar → Plug-ins:
Como usar o plug-in
Quando o plugin é instalado, o seguinte ocorre nos bastidores: o arquivo atualmente carregado no IDA Pro é enviado via API para o serviço KTAE instalado localmente, no URL configurado no script. O serviço analisa o arquivo e os resultados da análise são enviados de volta ao IDA Pro.
Em uma rede local, o script geralmente termina o trabalho em questão de segundos (a duração depende da conexão com o servidor KTAE e do tamanho do arquivo analisado). Depois que o plug-in for encerrado, um pesquisador poderá começar a investigação nos fragmentos de código destacados. Um clique duplo leva diretamente à seção pertinente na montagem ou no código binário (exibição Hex) para análise. Esses pontos de dados extras facilitam a identificação de blocos de código compartilhados e o rastreamento de alterações em um kit de ferramentas de malware.
A propósito, este não é o único plug-in IDA Pro que a equipe do GReAT criou para facilitar a vida dos caçadores de ameaças. Também oferecemos outro plug-in IDA que acelera e agiliza significativamente o processo de engenharia reversa e que, aliás, foi vencedor do Concurso de plug-ins IDA 2024.
Em 2022, analisamos em profundidade um método de ataque chamado browser-in-the-browser, originalmente desenvolvido pelo pesquisador de cibersegurança conhecido como mr.d0x. Na época, ainda não havia exemplos reais desse modelo sendo utilizado em ataques. Quatro anos depois, a situação mudou: os ataques browser-in-the-browser deixaram de ser apenas um conceito teórico e passaram a ser utilizados em campanhas reais. Neste artigo, revisitamos o que exatamente é um ataque browser-in-the-browser, mos
Em 2022, analisamos em profundidade um método de ataque chamado browser-in-the-browser, originalmente desenvolvido pelo pesquisador de cibersegurança conhecido como mr.d0x. Na época, ainda não havia exemplos reais desse modelo sendo utilizado em ataques. Quatro anos depois, a situação mudou: os ataques browser-in-the-browser deixaram de ser apenas um conceito teórico e passaram a ser utilizados em campanhas reais. Neste artigo, revisitamos o que exatamente é um ataque browser-in-the-browser, mostramos como hackers estão utilizando essa técnica e, principalmente, explicamos como evitar se tornar a próxima vítima.
O que é um ataque browser-in-the-browser (BitB)?
Para começar, vale relembrar o que mr.d0x realmente desenvolveu. A base do ataque surgiu da observação de quão avançadas se tornaram as ferramentas modernas de desenvolvimento Web, como HTML, CSS e JavaScript. Essa constatação levou o pesquisador a conceber um modelo de phishing particularmente sofisticado.
Um ataque browser-in-the-browser é uma forma avançada de phishing que utiliza recursos de design e desenvolvimento Web para criar sites fraudulentos que imitam janelas de login de serviços conhecidos, como Microsoft, Google, Facebook ou Apple, com aparência praticamente idêntica à original. No conceito proposto pelo pesquisador, o atacante cria um site aparentemente legítimo para atrair as vítimas. Uma vez nesse site, o usuário descobre que não pode deixar comentários ou realizar uma compra sem antes fazer login.
O processo parece simples: basta clicar no botão Fazer login com {nome de um serviço popular}. É nesse momento que ocorre o golpe. Em vez de abrir a página real de autenticação do serviço legítimo, o usuário recebe um formulário falso renderizado dentro do próprio site malicioso, que se apresenta visualmente como se fosse… uma janela pop-up do navegador. Além disso, a barra de endereço exibida nessa janela, também renderizada pelos invasores, mostra uma URL aparentemente legítima. Mesmo uma inspeção cuidadosa pode não revelar a fraude.
A partir desse ponto, o usuário desavisado insere suas credenciais Microsoft, Google, Facebook ou Apple nessa janela renderizada, e esses dados são enviados diretamente aos cibercriminosos. Durante algum tempo, esse esquema permaneceu apenas como um experimento teórico do pesquisador de segurança. Hoje, porém, ataques reais já incorporaram essa técnica aos seus arsenais de phishing.
Roubo de credenciais do Facebook
Os atacantes adaptaram o conceito original de mr.d0x. Em ataques recentes do tipo browser-in-the-browser, o golpe começa com e-mails criados para alarmar o destinatário. Em uma campanha de phishing, por exemplo, os criminosos se passaram por um escritório de advocacia informando ao usuário que ele teria cometido uma violação de direitos autorais ao publicar conteúdo no Facebook. A mensagem incluía um link aparentemente legítimo que supostamente levaria à publicação problemática.
Os invasores enviaram mensagens em nome de um escritório de advocacia fictício alegando violação de direitos autorais, acompanhadas de um link que supostamente direcionava ao post problemático no Facebook. Fonte
Curiosamente, para reduzir a desconfiança da vítima, ao clicar no link não era exibida imediatamente uma página falsa de login do Facebook. Em vez disso, o usuário era primeiro apresentado a um CAPTCHA falso da Meta. Somente após “passar” por essa verificação é que a vítima recebia a janela pop-up de autenticação falsa.
Isso não é um pop-up real do navegador, mas um elemento da própria página que imita uma tela de login do Facebook. Esse truque permite que os invasores exibam um endereço aparentemente legítimo. Fonte
Naturalmente, a página falsa de login do Facebook segue o modelo descrito por mr.d0x. Ela é construída inteiramente com ferramentas de desenvolvimento Web para capturar as credenciais da vítima. Enquanto isso, a URL exibida na barra de endereço simulada aponta para o site verdadeiro do Facebook, www.facebook.com.
Como evitar se tornar uma vítima
O fato de golpistas já estarem utilizando ataques browser-in-the-browser demonstra que as técnicas de fraude digital evoluem constantemente. Ainda assim, existe uma forma eficaz de verificar se uma janela de login é legítima. Utilizar um gerenciador de senhas, que funciona como um teste de segurança confiável para sites.
Isso ocorre, porque, ao preencher credenciais automaticamente, o gerenciador de senhas verifica a URL real da página, e não aquilo que parece estar na barra de endereço ou o que a interface visual mostra. Diferentemente de um usuário humano, não é possível enganar um gerenciador de senhas por meio de técnicas como browser-in-the-browser, domínios com pequenas variações ortográficas (typosquatting) ou formulários de phishing ocultos em anúncios e pop-ups. A regra é simples: se o gerenciador de senhas oferecer o preenchimento automático de login e senha, você está em um site para o qual já salvou credenciais. Se ele permanecer silencioso, há um forte indício de que algo está errado.
Além disso, seguir algumas recomendações clássicas de segurança digital ajuda a se proteger contra phishing ou, pelo menos, reduzir os danos caso um ataque seja bem-sucedido:
Ative a autenticação em dois fatores (2FA) em todas as contas que suportam esse recurso. Idealmente, utilize códigos temporários gerados por um aplicativo autenticador dedicado como segundo fator. Isso ajuda a evitar golpes de phishing que interceptam códigos de confirmação enviados por SMS, aplicativos de mensagem ou e-mail. Leia mais sobre 2FA de código único em nosso post dedicado.
Utilize chaves de acesso. A opção de login com chave de acesso também pode indicar que você está em um site legítimo. Aprenda tudo sobre o que são chaves de acesso e como começar a usá-las em nossa análise aprofundada sobre essa tecnologia.
Crie senhas únicas e complexas para todas as contas. Faça o que fizer, nunca reutilize a mesma senha em contas diferentes. Recentemente explicamos em nosso blog o que torna uma senha realmente forte. Gerar combinações únicas, sem precisar memorizá-las, KPMé a melhor opção. Como benefício adicional, também pode gerar códigos temporários para autenticação em dois fatores, armazenar suas chaves de acesso e sincronizar suas senhas e arquivos entre seus diferentes dispositivos.
Por fim, este post serve como mais um lembrete de que ataques teóricos descritos por pesquisadores de cibersegurança frequentemente acabam sendo utilizados em ataques reais. Então, fique de olho no nosso blog, e assine nosso canal no Telegram para se manter atualizado sobre as ameaças mais recentes à sua segurança digital e saber como neutralizá-las.
Leia sobre outras técnicas de phishing criativas que os golpistas estão usando diariamente:
Entrar
