Por Dentro do Coruna - Exploit iOS via Web Script

O kit que mudou de mãos três vezes em um ano

No início de 2025, um cliente de um fornecedor comercial de vigilância não identificado foi observado usando um framework de exploração JavaScript até então desconhecido contra dispositivos iOS. Em julho de 2025, um grupo suspeito de espionagem russo havia adotado o mesmo framework e o injetava silenciosamente em sites industriais e de varejo ucranianos como um iframe oculto. Em dezembro de 2025, um agente de ameaça chinês com motivação financeira o implantou em uma rede de sites falsos de criptomoedas e jogos de azar sem restrições geográficas, visando qualquer usuário de iPhone que clicasse no link errado. Pense assim: a mesma ferramenta poderosa migrou da espionagem para o crime financeiro em questão de meses, adaptando-se a diferentes objetivos e alvos. Por exemplo, o site de uma empresa de energia ucraniana foi comprometido para entregar payloads de espionagem, enquanto, mais tarde, um site falso de exchange de criptomoedas enganou usuários do mundo inteiro para infectá-los.

O Google Threat Intelligence Group (GTIG) nomeou publicamente esse framework como Coruna (também rastreado como CryptoWaters) em 4 de março de 2026. Ele contém cinco cadeias completas de exploração para iOS e 23 exploits individuais abrangendo as versões 13 a 17.2.1 do iOS. A iVerify o chamou de "a primeira exploração em massa observada contra dispositivos iOS" e apontou semelhanças estruturais com ferramentas desenvolvidas por agentes de ameaça afiliados ao governo dos EUA. Eis por que isso importa: tais semelhanças estruturais sugerem o reuso ou a adaptação de técnicas sofisticadas de nível governamental nas mãos de criminosos, elevando o nível de risco para os defensores. Na prática, isso significa que os atacantes não estão mais limitados a exploits básicos — eles agora empregam métodos avançados que antes eram reservados a operações de estados-nação.

Obtivemos amostras ao vivo de domínios de entrega ativos e analisamos cada camada do JavaScript. O que se segue é um relato detalhado do que esse kit faz, desde a primeira linha de código ofuscado até o binário Mach-O criptografado depositado no dispositivo da vítima, junto com uma análise completa da infraestrutura dos domínios e IPs envolvidos. Essa análise aprofundada revela não apenas a mecânica técnica, mas também a pegada operacional por trás do Coruna. Por exemplo, rastreamos como o payload JavaScript do exploit se transforma dinamicamente durante a execução, evadindo a detecção enquanto mantém estabilidade entre as versões do iOS.

O problema da entrega: por que o seu site é a superfície de ataque

Antes de mergulhar na mecânica do exploit, vale esclarecer o que "entrega" significa aqui, pois muitas organizações ainda não consideraram esse aspecto plenamente. Entrega é o método pelo qual o exploit chega ao dispositivo da vítima, frequentemente por meio de uma página web aparentemente inofensiva.

O Coruna é entregue como um arquivo HTML autocontido, normalmente chamado de group.html ou analytics.html, embutido como um `

Redes de anúncios. Um único criativo malicioso veiculado por uma rede de anúncios programática alcança todos os publishers que executam a tag dessa rede. O servidor do publisher nunca toca o payload. O WAF do publisher nunca o vê. A equipe de segurança do publisher não tem visibilidade sobre o que a tag de anúncio carregou no navegador do usuário. Se o Coruna tivesse sido distribuído por uma rede de anúncios de médio porte, teria alcançado milhões de usuários do Safari em milhares de sites legítimos e respeitáveis simultaneamente. Nenhum desses publishers saberia. Por exemplo, imagine uma rede de anúncios veiculando um banner malicioso em um site de notícias popular, e cada visitante poderia ter sido exposto sem o conhecimento do site.

Scripts de terceiros comprometidos. O site médio de e-commerce ou mídia carrega de 30 a 50 tags JavaScript de terceiros: analytics, widgets de chat, ferramentas de teste A/B, rastreadores de afiliados, gerenciadores de consentimento. Cada um desses scripts é um ponto de injeção em potencial. Um comprometimento na cadeia de suprimentos de qualquer um deles — como as campanhas do Magecart ou o incidente do polyfill[.]io — poderia ter transformado cada site que usasse esse script em um nó de entrega do Coruna. Novamente, o servidor de origem não mostraria nada incomum. O payload é executado no navegador do usuário e reporta de volta a um domínio C2 que o publisher jamais ouviu falar. Pense assim: mesmo um provedor de scripts confiável pode se tornar um cavalo de Troia se for comprometido. Por exemplo, se o script de um provedor popular de analytics fosse sequestrado, milhares de sites poderiam entregar o Coruna sem saber.

Assets de CDN em cache. Vários dos URLs de entrega que identificamos eram servidos a partir de infraestrutura CDN compartilhada (tubeluck[.]com, 668ddf[.]cc). Um atacante com acesso de escrita a um bucket de origem de CDN ou com capacidade de envenenar um cache de CDN obtém o mesmo resultado. Por exemplo, se um atacante conseguir fazer upload de um arquivo malicioso em um bucket de CDN usado por vários sites, ele pode entregar exploits silenciosamente a todos os visitantes desses sites. Esse cenário se concretizou em ataques anteriores, nos quais atacantes envenenaram caches de CDN amplamente utilizados para disseminar malware rapidamente.

O ponto não é que esses vetores específicos foram usados. O ponto é que nada no payload do Coruna exige que o atacante seja dono do site de entrega. O payload é um arquivo JavaScript. Ele vai aonde o JavaScript vai. E o JavaScript vai a todo lugar.

Como ele chega ao navegador: infraestrutura de entrega

As campanhas que analisamos usaram mais de 50 domínios de entrega, organizados em temas de isca reconhecíveis.

Muitos desses sites instruem explicitamente os usuários a acessá-los por um dispositivo móvel para uma "melhor experiência" — um empurrãozinho de engenharia social para garantir que o alvo abra a página no Safari no iOS, e não em um navegador desktop. Essa tática aumenta a probabilidade de o exploit ser executado com sucesso, já que ele visa versões específicas do iOS. Por exemplo, um site falso de bingo pode exibir um popup dizendo "Para a melhor experiência, abra esta página no seu iPhone", induzindo as vítimas ao ambiente certo.

---

Análise de infraestrutura: DNS, rDNS, WHOIS e hospedagem

Realizamos resolução DNS completa, lookups de DNS reverso, consultas de registro WHOIS/RDAP e pivôs de IP em todos os domínios de entrega e C2. Os resultados revelam uma estratégia de infraestrutura deliberada: abuso de grandes CDNs em nuvem para ocultar a origem real, um pequeno número de IPs dedicados para os sites de isca mais sensíveis e padrões de registro que se concentram fortemente no final de 2025 e início de 2026. Essa coordenação sugere uma campanha bem planejada, e não uma atividade oportunista aleatória.

Distribuição de hospedagem

A infraestrutura de entrega se divide em quatro camadas distintas de hospedagem.

Camada 1: Proxy Cloudflare. A maior parte dos domínios de entrega de jogos de azar e games — incluindo 7p[.]game, b27[.]icu, h4k[.]icu, spin7[.]icu, 7ff[.]online, 26a[.]online, tubeluck[.]com, ai-scorepredict[.]com e dbgopaxl[.]com — resolve para IPs anycast da Cloudflare. A Cloudflare fornece proteção contra DDoS, terminação TLS e ocultação eficaz do IP de origem. Os servidores de backend reais não são visíveis pelo DNS. Essa configuração permite que os atacantes mascarem sua verdadeira infraestrutura por trás de um serviço respeitável, complicando os esforços de remoção. Pense assim: a Cloudflare age como um escudo, dificultando o rastreamento dos servidores reais dos atacantes.

Camada 2: AWS CloudFront. Um segundo grande cluster usa o AWS CloudFront como camada de CDN. Domínios incluindo 4u[.]game, seven7[.]vip, seven7[.]to, 4kgame[.]us, 7uspin[.]us, n49[.]top, 98a[.]online, cy8[.]top, 7fun[.]icu, k96[.]icu, t7c[.]icu, y4w[.]icu e o cluster de bingo (land[.]77bingos[.]com, land[.]bingo777[.]now, land[.]777bingos[.]xyz) resolvem para nós de borda do CloudFront. O cluster de bingo compartilha um único conjunto de quatro IPs do CloudFront, indicando que são servidos pela mesma distribuição e provavelmente pela mesma origem S3 ou EC2. Essa consolidação ajuda os atacantes a gerenciar múltiplas iscas com eficiência, mantendo a resiliência. Por exemplo, se um domínio for derrubado, os outros permanecem operacionais, garantindo a entrega contínua.

Camada 3: IPs dedicados em hospedagem tolerante a abusos. A descoberta operacionalmente mais significativa é o uso de IPs dedicados em provedores de hospedagem conhecidos pela tolerância a abusos para os sites de isca mais sensíveis. cryptocurrencyworld[.]top e bestcryptocurrency[.]top compartilham um único IP dedicado: 95.214.181.109, registrado na Datacamp Limited em Hong Kong (AS212238), um provedor de hospedagem à prova de balas bem documentado. Esses dois domínios são os únicos nesse IP. mkkku[.]com resolve para 185.53.179.128 (Team Internet AG, Alemanha). O DNS reverso desse IP revelou sete domínios de jogos de azar adicionais no mesmo servidor: bet247[.]ac, gem88[.]ac, gemwin[.]ac, gunbet[.]ac, i9-bet[.]ac, sbet[.]ac e taisunwin[.]ac — todos consistentes com o tema mais amplo de entrega do Coruna. btrank[.]top resolve para uma instância dedicada do AWS EC2 em Tóquio (54.248.167.86). ddus17[.]com resolve para 103.110.221.8 (JT Telecom International, Japão), sem domínios co-hospedados, consistente com um servidor dedicado. Essa camada mostra como os atacantes equilibram ocultação e controle operacional. Em outras palavras, eles usam hosts à prova de balas onde podem operar livremente, ao mesmo tempo em que aproveitam serviços em nuvem para escalabilidade.

Camada 4: China Unicom. pc6[.]com, um grande portal chinês de download de software listado entre os URLs de entrega, resolve para nove IPs no backbone da China Unicom (AS4837). Os pivôs de DNS reverso nesses IPs retornaram centenas de domínios co-hospedados cada, todos com nomes em chinês e TLDs .cn, .cc e .cloud. Isso é consistente com um ambiente de hospedagem compartilhada de grande porte. O URL de entrega do pc6[.]com provavelmente representa uma página comprometida em um site legítimo existente, e não uma infraestrutura própria dos atacantes. Esse exemplo destaca como os atacantes exploram plataformas legítimas para distribuir seus payloads. Por exemplo, um popular portal chinês de software pode hospedar iframes maliciosos sem saber, colocando milhões de usuários em risco.

Cronograma de registro WHOIS

Os dados de registro RDAP foram obtidos com sucesso para um subconjunto dos domínios de entrega. As datas se concentram de forma estreita, confirmando uma campanha de registro coordenada. Por exemplo, muitos domínios foram registrados com dias ou semanas de diferença entre si no final de 2025 e início de 2026, sugerindo um lançamento planejado em vez de aquisições aleatórias de domínios. Esse padrão indica que os atacantes prepararam sua infraestrutura com cuidado, em vez de improvisar.

Todas as datas de registro confirmadas estão entre novembro de 2025 e janeiro de 2026 — uma janela apertada de 10 semanas que se alinha perfeitamente com a escalada observada da campanha, da espionagem direcionada à exploração financeira em larga escala. Eis por que isso importa: um período de registro tão concentrado sugere um esforço coordenado para implantar infraestrutura rapidamente. Por exemplo, pepeairdrop01[.]com está atualmente suspenso pelo seu registrador por falha na verificação do domínio, o que indica pressão ativa de remoção por parte dos defensores. Pense assim: esse domínio provavelmente foi sinalizado e retirado do ar rapidamente para interromper as operações da campanha. Enquanto isso, dbgopaxl[.]com se destaca como um caso fora do padrão, registrado ainda em abril de 2024. Isso sugere que pode ser um ativo pré-posicionado, configurado meses antes para uso futuro, ou talvez um domínio legítimo que foi comprometido e reaproveitado para essa campanha.

Os domínios C2 — os 27 domínios .xyz gerados por DGA — retornaram erros 404 do servidor RDAP. Isso significa que foram excluídos do registro ou nunca foram registrados em um caminho consultável pelo RDAP padrão. Eis o que isso significa na prática: esses domínios funcionam como domínios de fallback de curta duração, gerados algoritmicamente. Os operadores os registram e descartam de forma contínua para se manterem à frente dos esforços de remoção e evitar a detecção. Por exemplo, se um domínio for bloqueado pelos defensores, outro pode rapidamente tomar seu lugar sem nenhuma intervenção manual, mantendo a infraestrutura de comando e controle resiliente.

Transparência de certificados

Os logs de transparência de certificados nos fornecem uma linha do tempo independente de quando os domínios começaram a usar HTTPS. Os principais achados incluem: b27[.]icu emitiu seu primeiro certificado TLS em 01/06/2025 (Amazon CA), confirmando que o domínio estava ativo pelo menos seis meses antes do pico da campanha. Essa atividade precoce sugere que pode ter sido usado para testes iniciais ou reconhecimento. Outro exemplo é 7p[.]game, que apareceu pela primeira vez nos logs de CT em 21/03/2024 (GoDaddy CA). É o mais antigo do conjunto de entrega, o que implica ser uma operação de jogos de azar de longa data que adotou a entrega do Coruna, em vez de um site de isca criado especificamente para isso. ai-scorepredict[.]com emitiu seu primeiro certificado em 29/01/2026, exatamente na mesma data de registro no RDAP, confirmando que foi criado especificamente para essa campanha. Por fim, tubeluck[.]com apareceu pela primeira vez nos logs de CT em 2019, tornando-o o domínio mais antigo de todo o conjunto de dados. Isso indica que é um serviço de CDN ou hospedagem estabelecido há muito tempo, que o operador está usando como infraestrutura, provavelmente para misturar tráfego malicioso com conteúdo legítimo.

Infraestrutura de domínios C2

Todos os 27 domínios C2 gerados por DGA atualmente não retornam registros DNS do tipo A, ou seja, não resolvem para nenhum endereço IP. Dois domínios, vvri8ocl4t3k8n6[.]xyz e rlau616jc7a7f7i[.]xyz, tinham entradas no URLScan datadas de 4 de março de 2026, o dia da divulgação pelo GTIG. Ambos resolviam para IPs da Cloudflare naquele momento. Isso confirma que a infraestrutura C2 estava ativa e com fronting da Cloudflare no dia da divulgação. Desde então, a infraestrutura foi derrubada ou rotacionada para novos domínios. Pense nisso como trocar as fechaduras após um arrombamento: os operadores rapidamente moveram seu comando e controle para evitar interrupções e a detecção pelos defensores.

---

Quatro camadas de ofuscação antes de você ver um único exploit

Abrir a página de entrega em um editor de texto não revela nada útil à primeira vista. O framework Coruna usa uma sofisticada arquitetura de ofuscação em quatro camadas, projetada especificamente para derrotar ferramentas de análise estática e sandboxes automatizadas. Isso significa que até analistas experientes enfrentam um desafio difícil só para entender o que o código faz.

Camada 0: o bootstrap externo

O HTML de entrega contém um bootstrap JavaScript mínimo. Toda string significativa está oculta como um array de inteiros decodificados por XOR em tempo de execução. Por exemplo:

[107, 49, 105, 97].map(x => String.fromCharCode(x ^ 84)).join("")

Aqui, cada inteiro é submetido a XOR com a chave 84 para revelar o caractere real. A chave XOR varia por string, portanto não há um único padrão a ser identificado em todo o arquivo. A lógica principal está oculta dentro de new Function(atob("..."))(): uma string codificada em Base64 que é avaliada como uma nova função. Isso mantém o código real fora da árvore de análise inicial e da maioria dos scanners estáticos. Em outras palavras, o código está bloqueado por um enigma que só se revela em tempo de execução, tornando a análise estática praticamente impossível.

Camada 1: o despachante de módulos

Após decodificar a Camada 0, você obtém um objeto JavaScript registrado como globalThis.vKTo89. Esse objeto contém uma implementação completa de SHA-256 e uma tabela de consulta de módulos de exploit indexados pelos seus hashes SHA1. O despachante expõe cinco funções de API:

A função LBrh4t implementa um protocolo de entrega de módulos com chave. Dado um ID de hash de módulo, ela calcula SHA256(salt + hash_id).substring(0, 40) e busca o nome de arquivo resultante no servidor. O salt observado nas amostras analisadas é cf40de81867d2397. Sem conhecer o salt, um analista não consegue prever quais nomes de arquivo solicitar, mesmo que conheça os IDs de hash dos módulos. A URL base é derivada de location.href.slice(0, lastIndexOf("/") + 1), o que significa que todos os módulos de exploit são servidos pelo mesmo domínio da página de entrega. Essa configuração dificulta que defensores interceptem ou prevejam as buscas de módulos, ocultando efetivamente os próximos passos do atacante.

Camada 2: código do módulo

Cada módulo é armazenado como uma string codificada em Base64. Quando decodificado, o JavaScript do módulo continua usando arrays de strings codificados por XOR para todos os literais sensíveis: caminhos de framework, nomes de API, endereços de memória, constantes de versão. Essa ofuscação em camadas garante que, mesmo que uma camada seja decodificada, os dados sensíveis permaneçam ocultos, forçando os analistas a remover múltiplas camadas antes de entender o payload.

Camada 3: payloads binários inline

Os módulos maiores incorporam seus payloads binários como strings codificadas em Base64 dentro do JavaScript. O shellcode ARM64 é armazenado como binário bruto. O binário Mach-O é armazenado com cada byte preenchido com zero para dois bytes (codificação UTF-16LE), adicionando uma camada extra de ofuscação contra detecção de assinatura binária. Pense nisso como embrulhar um pacote duas vezes para dificultar a identificação. Esse truque inteligente ajuda o malware a escapar de ferramentas de detecção baseadas em assinatura.

Medidas anti-análise

O framework implementa várias verificações ativas anti-análise antes de executar qualquer código de exploit. Ele é abortado se o Modo de Bloqueio da Apple for detectado. Ele ignora a execução no modo de navegação privada. Ele verifica se um motor de renderização WebKit real está presente criando um elemento <math> e verificando se mathcolor="blue" renderiza como rgb(0, 0, 255). Ele também verifica a disponibilidade de RTCPeerConnection para confirmar um ambiente de navegador genuíno em vez de uma sandbox headless. Após a execução, ele reporta o resultado ao C2 via uma requisição GET para <base_url>?e=<code>, onde 0 significa sucesso, 1000 significa falha no exploit, 1001 significa que a versão alvo não é suportada e 1003 significa que uma sandbox foi detectada. Essas verificações ajudam o malware a evitar a execução em ambientes onde poderia ser analisado ou falhar, aumentando as chances de exploração bem-sucedida.

---

A cadeia de exploit: seis fases do carregamento da página ao Mach-O

Fase 1: fingerprinting do alvo

O módulo de fingerprinting é executado primeiro e decide se o alvo vale a pena atacar e qual cadeia de exploit usar. O script verifica a string User-Agent em busca de Version/ (presente em todos os UAs do Safari) e AppleWebKit/. Se nenhum for encontrado, ele para imediatamente. Em seguida, distingue iOS de macOS Safari usando uma combinação de typeof TouchEvent !== "undefined" e um teste de inserção de Blob no IndexedDB. Especificamente, tentar armazenar um objeto Blob no IndexedDB lança a exceção "BlobURLs are not yet supported" no Safari do iOS, o que serve como um fingerprint de plataforma confiável.

A parte tecnicamente mais sofisticada do fingerprinting é um oráculo de memória WebAssembly. O script instancia uma WebAssembly.Table e uma WebAssembly.Instance, depois lê as tags de tipo de célula JSC (JavaScriptCore) internas da memória. O valor de tag 0x10016 indica macOS Safari; 0x10017 indica iOS Safari. Essa técnica lê a representação interna de objetos do JavaScriptCore diretamente da memória, exigindo conhecimento profundo do código-fonte do WebKit. A versão do iOS é extraída do User-Agent e comparada com uma tabela de consulta de 19 versões conhecidas do iOS (10.0.0 a 17.0.0) e 13 versões do Safari para macOS, com caminhos de exploit separados selecionados para iOS 13 a 15.x e iOS 16.x e superior. Esse fingerprinting preciso garante que a cadeia de exploit corresponda perfeitamente ao ambiente do alvo, aumentando as chances de sucesso.

Fase 2: execução remota de código via confusão de tipos JIT (CVE-2024-23222)

A cadeia de exploit principal nas amostras que analisamos é a cassowary, visando a CVE-2024-23222, um bug de confusão de tipos no JavaScriptCore corrigido pela Apple em janeiro de 2024 com o iOS 17.3.

O exploit começa chamando uma função exatamente 1.000.000 de vezes com argumentos de ponto flutuante. Isso força o compilador JIT do JSC a especializar a função para operações com arrays de float, gerando código de máquina otimizado que assume que todo elemento do array sempre será um float de precisão dupla. Após a compilação JIT, o exploit substitui um elemento do array alvo por um objeto JavaScript em vez de um float. O código compilado pelo JIT lê esse valor como um float, interpretando o ponteiro do objeto como um double de 64 bits. Essa é a confusão de tipos: JSObject* está sendo tratado como double. Ao ler de volta o valor float confundido, o exploit recupera o endereço do objeto no heap do JSC. Esse é o primitivo addrof.

A operação inversa, escrever um float manipulado no array, faz o JSC interpretar o double como um ponteiro de objeto, criando um primitivo fakeobj apontando para memória controlada pelo atacante. Usando addrof e fakeobj juntos, o exploit constrói um objeto ArrayBuffer falso cujo ponteiro de armazenamento de apoio é definido para um endereço arbitrário. Ler ou escrever por meio desse ArrayBuffer falso fornece leitura/escrita arbitrária completa na memória do processo. O exploit estabiliza esse primitivo usando heap spraying com arrays de 16 elementos de valores float específicos e uma classe de abstração de inteiros de 64 bits personalizada. Essa combinação permite ao atacante manipular a memória à vontade, um passo crítico para exploração adicional.

Fase 3: derrotando o ASLR via varredura do cache compartilhado do dyld

Com leitura/escrita arbitrária estabelecida, o exploit varre a memória do processo em busca do cache compartilhado do dyld para derrotar o ASLR. No iOS, ele localiza WebCore, CoreUtils e IOKit varrendo os cabeçalhos do segmento __TEXT. No macOS, ele visa CoreFoundation, CoreGraphics, ActionKit e RESync. O exploit lê os cabeçalhos do segmento __TEXT de cada framework para determinar seus endereços de carregamento e localiza _ZN3JSC16jitOperationListE para encontrar regiões de memória executável alocadas pelo JIT. Esse passo é crucial porque o ASLR randomiza os locais de memória, e conhecer esses endereços permite ao exploit executar código de forma confiável.

Fase 4: escapando da sandbox

O módulo de escape de sandbox combina duas técnicas. Um exploit de filtro SVG <feConvolveMatrix> corrompe a memória no processo compositor do WebKit, permitindo que o exploit escape da sandbox do renderizador. Simultaneamente, o exploit usa pthread_main_thread_np, uma API privada do macOS e iOS, para manipular o armazenamento local de thread e obter acesso ao contexto de execução da thread principal, que carrega privilégios de sistema mais amplos do que a thread do renderizador. Pense assim: escapar da sandbox é como sair de uma sala trancada para acessar o prédio inteiro.

Fase 5: contornando a autenticação de ponteiros no Apple Silicon

Em dispositivos Apple Silicon (todo iPhone desde o XR e todo Mac da série M), o exploit precisa derrotar os Pointer Authentication Codes (PAC), o mecanismo de integridade de fluxo de controle imposto por hardware da Apple. O módulo stager para macOS contém os seguintes símbolos C++ internos do JSC:

_ZN3JSC20SecureARM64EHashPins27allocatePinForCurrentThreadEv
_ZN3JSC10LinkBuffer8linkCodeERNS_14MacroAssemblerENS_20JITCompilationEffortE
_ZN3WTF13MetaAllocator8allocateEmPv
jitCagePtr

O exploit abusa de jitCagePtr e SecureARM64EHashPins para alocar memória executável dentro da jaula JIT e assinar o shellcode ARM64 com uma assinatura PAC válida. Isso permite que código nativo não assinado seja executado em hardware com PAC aplicado. A técnica aloca 40 MB de memória com new Uint32Array(10000000) e preenche a memória JIT com padrões previsíveis usando um JIT spray de instruções x += 1 repetidas. Essa abordagem engana o hardware para confiar no código malicioso, contornando as proteções PAC.

Fase 6: execução do shellcode e entrega do payload

Os módulos stager finais contêm três componentes binários incorporados:

O shellcode ARM64 começa com o prólogo de função padrão STP X29, X30, [SP, #-16]! e é injetado na memória executável alocada pelo JIT. Ele usa dlsym contra /usr/lib/system/libdyld.dylib para resolver funções do sistema em tempo de execução, evitando importações estáticas. O binário Mach-O referencia frameworks privados do iOS, incluindo SpringBoard, PassKitCore, CoreML, MediaToolbox e AppleMediaServices. Isso indica capacidades em nível de sistema, como acesso ao keychain, enumeração de aplicativos instalados e manipulação da tela inicial. O payload final, PlasmaLoader (também chamado de PLASMAGRID pelo Google GTIG), é buscado no domínio de entrega como um arquivo .min.js criptografado. Ele decodifica QR codes de imagens, busca módulos adicionais do C2 e exfiltra dados de carteiras de criptomoedas de carteiras populares como MetaMask, Exodus, Bitget Wallet e Base. Isso evidencia a clara motivação financeira da campanha e o sofisticado direcionamento a ativos valiosos.

---

Vinte e três exploits, cinco cadeias, quatro anos de CVEs

A cadeia cassowary é uma das doze cadeias de exploit nomeadas dentro do Coruna. O kit completo cobre iOS 13 a 17.2.1 sem lacunas. Essa cobertura completa significa que os atacantes podem visar praticamente qualquer dispositivo executando essas versões do iOS, deixando poucos refúgios seguros para as potenciais vítimas.

Duas dessas cadeias, Photon e Gallium, exploram vulnerabilidades anteriormente usadas como zero-days na Operação Triangulação, a sofisticada campanha de espionagem no iOS documentada pela Kaspersky em 2023. Seu reuso em uma campanha criminosa com motivação financeira ilustra diretamente como ferramentas ofensivas de estados-nação migram para o ecossistema de ameaças mais amplo assim que as CVEs subjacentes se tornam de conhecimento público. Por exemplo, após a divulgação dessas CVEs, grupos criminosos rapidamente as adotaram para atacar usuários comuns visando lucro, transformando ferramentas avançadas de espionagem em malware de massa. Em 5 de março de 2026, a CISA adicionou CVE-2021-30952, CVE-2023-41974 e CVE-2023-43000 ao seu catálogo de Vulnerabilidades Exploradas Conhecidas com prazo de remediação de 26 de março de 2026 para agências federais. Isso evidencia a urgência de aplicar patches nessas vulnerabilidades para prevenir exploração e proteger infraestruturas críticas.

A arquitetura de módulos completa

[Página de Entrega: group.html / analytics.html]
    |
    +-- Camada 0: Bootstrap (JS com ofuscação XOR)
    |   +-- Inicializa o dispatcher globalThis.vKTo89
    |
    +-- Camada 1: Objeto MM (Base64 -> JS)
    |   +-- Módulo 1ff010bb: Biblioteca matemática/utilitária
    |   |   +-- SHA256, aritmética BigInt, análise de URL
    |   +-- Módulo 6b57ca33: Motor de fingerprinting
    |       +-- Análise de UA, detecção de plataforma
    |       +-- Oráculo de memória WebAssembly (tags de célula JSC 0x10016/0x10017)
    |       +-- Teste de Blob no IndexedDB (detecção de iOS)
    |       +-- Teste de renderização MathML
    |       +-- Verificação de ambiente WebRTC
    |
    +-- Módulos Remotos (obtidos via URLs com chave SHA256)
        +-- 8dbfa3fd: Exploit de confusão de tipos JIT (addrof/fakeobj)
        +-- 55afb1a6: Primitiva de leitura/escrita arbitrária (ArrayBuffer falso)
        +-- 5264a069: Variante de exploit baseada em WebAssembly
        +-- 166411bd: JIT spray via WebAssembly / primitiva BigUint64Array
        +-- d6cb72f5: Exploit de compilador JIT (aquecimento com 1M de iterações)
        +-- dbfd6e84: Escape de sandbox (feConvolveMatrix + pthread)
        |
        +-- [caminho iOS] bcb56dc5: Scanner de cache compartilhado dyld do iOS
        |   +-- Localizador dos frameworks WebCore, IOKit, CoreUtils
        |
        +-- [caminho macOS] 2d2c721e: Scanner de cache compartilhado dyld do macOS
        |   +-- Localizador de CoreFoundation, CoreGraphics, ActionKit
        |
        +-- [stager iOS] 164349160: Stager de payload para iOS
        |   +-- Shellcode ARM64 (31.308 bytes)
        |   +-- Binário Mach-O criptografado (14.954 bytes)
        |
        +-- [stager macOS] 6241388a: Stager de payload para macOS
            +-- Shellcode ARM64 (31.308 bytes)
            +-- Binário Mach-O criptografado (14.954 bytes)
            +-- Bypass de PAC (jitCagePtr, SecureARM64EHashPins)
            +-- Cadeia ROP via JIT

---

Atribuição e contexto do agente de ameaça

A campanha que distribui o Coruna por meio de iscas de criptomoedas e jogos de azar é atribuída ao UNC6691, um agente de ameaça com motivação financeira que se acredita operar a partir da China. Veja por que essa atribuição faz sentido: a infraestrutura usa intensamente TLDs como .icu, .top, .online e .game, que são comumente associados a redes de fraude operadas por chineses. Por exemplo, domínios como mijieqi[.]cn e 668ddf[.]cc usam caracteres chineses ou convenções de nomenclatura típicas de grupos de ameaça chineses. Pense assim: essas escolhas de domínio e pistas de idioma fornecem sinais fortes sobre a origem do operador. É importante destacar que o exploit não impõe restrições de geolocalização; ele tem como alvo qualquer usuário do Safari no mundo, tornando-se uma ameaça global.

A migração do framework Coruna de um fornecedor comercial de software de vigilância, passando por um agente de espionagem de Estado-nação (UNC6353), até um grupo criminoso com motivação financeira (UNC6691) em aproximadamente um ano evidencia o mercado secundário ativo para exploits móveis avançados. Na prática, isso significa que exploits sofisticados de zero-day, inicialmente desenvolvidos para espionagem, são rapidamente reaproveitados para crimes cibernéticos com fins lucrativos. Por exemplo, as duas CVEs da Operação Triangulation incorporadas ao kit — CVE-2023-32434 e CVE-2023-38606 — foram documentadas publicamente pela primeira vez como zero-days usados em uma campanha de espionagem de alto nível. Agora, essas mesmas vulnerabilidades alimentam uma ferramenta de exploração em massa voltada para carteiras de criptomoedas, mostrando com que rapidez os agentes de ameaça mudam de tática.

---

O que você deve fazer

A proteção mais eficaz é simples: atualize todos os dispositivos Apple imediatamente. O kit falha explicitamente contra a versão mais recente do iOS disponível no momento da divulgação. Por exemplo, usuários com iOS 17.3 ou posterior estão protegidos contra o exploit principal da cadeia cassowary. Melhor ainda: o kit completo é neutralizado no iOS 17.4 e superior. Não espere — atualizar seu dispositivo é a defesa mais simples e confiável.

Para equipes de desenvolvimento web especificamente: a questão não é apenas se seus usuários atualizaram os dispositivos. Você também precisa considerar se o seu site pode ser usado para entregar esse payload a usuários sem atualização. Por exemplo, uma tag de anúncio comprometida, um script de analytics envenenado ou um asset de CDN sequestrado carregado pelas suas páginas poderia transformar seu site em um nó de distribuição sem que você soubesse. Seus logs de servidor não mostrariam nada suspeito, porque o exploit roda inteiramente no navegador, reporta para um domínio C2 que você nunca ouviu falar e depois sai silenciosamente. Esse sigilo torna a detecção extremamente difícil sem monitoramento especializado.

---

Indicadores de comprometimento

Domínios C2 (gerados por DGA, TLD .xyz)

vvri8ocl4t3k8n6[.]xyz    rlau616jc7a7f7i[.]xyz    ol67el6pxg03ad7[.]xyz
6zvjeulzaw5c0mv[.]xyz    ztvnhmhm4zj95w3[.]xyz    v2gmupm7o4zihc3[.]xyz
pen0axt0u476duw[.]xyz    hfteigt3kt0sf3z[.]xyz    xfal48cf0ies7ew[.]xyz
yvgy29glwf72qnl[.]xyz    lk4x6x2ejxaw2br[.]xyz    2s3b3rknfqtwwpo[.]xyz
xjslbdt9jdijn15[.]xyz    hui4tbh9uv9x4yi[.]xyz    xittgveqaufogve[.]xyz
xmmfrkq9oat1daq[.]xyz    lsnngjyu9x6vcg0[.]xyz    gdvynopz3pa0tik[.]xyz
o08h5rhu2lu1x0q[.]xyz    zcjdlb5ubkhy41u[.]xyz    8fn4957c5g986jp[.]xyz
uawwydy3qas6ykv[.]xyz    sf2bisx5nhdkygn3l[.]xyz  roy2tlop2u[.]xyz
gqjs3ra34lyuvzb[.]xyz    eg2bjo5x5r8yjb5[.]xyz    b38w09ecdejfqsf[.]xyz

Domínios de entrega (selecionados)

ai-scorepredict[.]com         pepeairdrop01[.]com
goodcryptocurrency[.]top      cryptocurrencyworld[.]top
bestcryptocurrency[.]top      binancealliancesintro[.]com
b27[.]icu                     7p[.]game
4u[.]game                     h4k[.]icu
spin7[.]icu                   seven7[.]vip
seven7[.]to                   4kgame[.]us
7uspin[.]us                   n49[.]top
98a[.]online                  7ff[.]online
26a[.]online                  cy8[.]top
btrank[.]top                  mkkku[.]com
goanalytics[.]xyz             kanav[.]blog
land[.]77bingos[.]com         land[.]bingo777[.]now
land[.]777bingos[.]xyz        dbgopaxl[.]com
lddx3z2d72aa8i6[.]xyz         dd9l7e6ghme8pbk[.]xyz
fxrhcnfwxes90q[.]xyz          3v5w1km5gv[.]xyz
sj9ioz3a7y89cy7[.]xyz         appstoreconn[.]com
ddus17[.]com                  tubeluck[.]com

IPs de infraestrutura (não-CDN)

Domínios adicionais encontrados via pivô rDNS (Team Internet AG, 185.53.179.128)

bet247[.]ac    gem88[.]ac    gemwin[.]ac
gunbet[.]ac    i9-bet[.]ac   sbet[.]ac
taisunwin[.]ac

Assinaturas JavaScript

Dispatcher de módulo:  globalThis.vKTo89
Funções de API:        WLEBfI, ksQccv, OLdwIx, LBrh4t, tI4mjA
Ofuscação de URL:      lysNguL, lysNguk, lysNgu6, lysNguv
Salt de implantação:   cf40de81867d2397
Padrão XOR:            [n1,n2,...].map(x => String.fromCharCode(x ^ K)).join("")
Aquecimento JIT:       new Uint32Array(10000000) + x += 1 repetido
Limites de versão:     13E4, 16E4

IDs de hash SHA1 dos módulos

1ff010bb3e857e2b0383f1d9a1cf9f54e321fbb0  (biblioteca utilitária)
6b57ca3347345883898400ea4318af3b9aa1dc5c  (fingerprinting)
8dbfa3fdd44e287d57c55e74a97f526120ffd8f0  (confusão de tipos JIT)
55afb1a69f9e35265f29b113adaa6f34e8215813  (leitura/escrita arbitrária)
5264a0694295c0a1978d1b4b03b2ab909e5c6d09  (exploit WASM)
166411bd90ee39aed912bd49af8d86831b686337  (primitiva BigUint64)
d6cb72f5888b2ec1282b584155490e3b6e90a977  (exploit de compilador JIT)
dbfd6e840218865cb2269e6b7ed7d10ea9f22f93  (escape de sandbox)
bcb56dc5317128d4e53b8474535f4c099bf322b3  (scanner dyld do iOS)
2d2c721e64fbbb49c39654930563758332e4eff3  (scanner dyld do macOS)
164349160d3d35d83bfdcc001ccd23cd1b3b75d5  (stager do iOS)
6241388ab7da11aa490d4ecfed44d952568f008a  (stager do macOS)

Assinaturas binárias

Shellcode ARM64:  31.308 bytes | começa com fd 7b bf a9 fd 03 00 91 (prólogo STP X29, X30)
Payload Mach-O:   14.954 bytes | ARM64 (0xFEEDFACF) | preenchido com UTF-16LE em JS
PlasmaLoader:     ~1.324 bytes criptografados | nome do arquivo: [hex com 40 caracteres].min.js

---

Resumo rápido

O Coruna é um kit de exploit para iOS de nível spyware que contém 23 exploits individuais distribuídos em cinco cadeias. Ele cobre todas as versões do iOS de 13.0 a 17.2.1. Originalmente, foi criado por desenvolvedores para um fornecedor comercial de software de vigilância. Em seguida, um grupo de espionagem russo o utilizou. Agora, um agente de ameaça chinês com motivação financeira o implanta ativamente contra carteiras de criptomoedas. Essa evolução mostra como os exploits podem circular entre diferentes tipos de agentes.

O kit roda inteiramente no navegador como um payload JavaScript autocontido. Ele usa quatro camadas de ofuscação e um protocolo de entrega de módulos com chave que torna a análise estática praticamente impossível sem o salt de implantação. A cadeia de execução tem seis fases, terminando com um shellcode ARM64 assinado, um binário Mach-O e um implante final que exfiltra dados das carteiras MetaMask, Exodus, Bitget Wallet e Base. Em termos simples: trata-se de um ataque altamente sofisticado e de múltiplos estágios que tem como alvo carteiras de criptomoedas populares diretamente no ambiente do navegador.

A cadeia principal, chamada cassowary (CVE-2024-23222), tem como alvo versões do iOS de 16.6 a 17.2.1 usando uma vulnerabilidade de confusão de tipos JIT no JavaScriptCore. Outras duas cadeias reutilizam zero-days originalmente descobertos durante a Operação Triangulation. Vale destacar que três CVEs deste kit foram adicionadas ao catálogo de Vulnerabilidades Exploradas Conhecidas (KEV) da CISA no dia seguinte à divulgação pública, o que reforça a gravidade delas.

A infraestrutura por trás do Coruna abrange mais de 50 domínios de entrega registrados em uma janela de 10 semanas entre novembro de 2025 e janeiro de 2026. Esses domínios estão hospedados na Cloudflare, AWS CloudFront, em um provedor bulletproof de Hong Kong (Datacamp Limited) e em uma instância dedicada do AWS EC2 em Tóquio. Os 27 domínios C2 são gerados por DGA usando a semente "lazarus" e estavam com fronting via Cloudflare no momento da divulgação. Essa configuração de hospedagem diversificada ajuda os operadores a escapar de esforços de derrubada e a manter a resiliência.

O ponto crítico para equipes de desenvolvimento web é este: esse payload é um arquivo JavaScript. Ele não precisa estar no seu servidor para chegar aos seus usuários. Uma tag de anúncio comprometida, um script de terceiros envenenado ou um asset de CDN sequestrado seriam suficientes. Seus logs não mostrariam nada suspeito. O cside monitora em tempo real todos os scripts executados nos navegadores dos seus usuários — essa é a única camada onde esse ataque se torna visível. Sem esse monitoramento, você pode nunca detectar essa ameaça.

---

---

Referências

1. Google Threat Intelligence Group, "Coruna iOS Exploit Kit Uses 23 Exploits Across Five Chains Targeting iOS 13-17.2.1," The Hacker News, 4 de março de 2026.
2. Aviso de Segurança da Apple, "CVE-2024-23222: Problema de confusão de tipos no WebKit," janeiro de 2024. nvd.nist.gov
3. Catálogo de Vulnerabilidades Exploradas Conhecidas da CISA, 5 de março de 2026. cisa.gov
4. Help Net Security, "Apple corrige zero-day do WebKit explorado ativamente (CVE-2024-23222)," 23 de janeiro de 2024.
5. Infosecurity Magazine, "Coruna Exploit Kit Targets Older iPhones in Multi-Stage Attack," março de 2026.
6. Security Affairs, "Google uncovers Coruna iOS Exploit Kit targeting iOS 13-17.2.1," março de 2026.

---

Esta análise é baseada na inspeção direta de amostras ativas do Coruna obtidas de domínios de entrega em operação (b27[.]icu, 7p[.]game), combinada com inteligência de ameaças pública do Google GTIG, CISA e iVerify. A análise de infraestrutura envolveu resolução de DNS, pivôs de DNS reverso via HackerTarget, consultas de registro RDAP, logs de transparência de certificados via crt.sh e DNS passivo via URLScan. Toda a análise binária foi realizada em um ambiente isolado para garantir a segurança.