Coruna: o framework usado na Operação Triangulação

Introdução

Em 4 de março de 2026, o Google e a iVerify publicaram relatórios sobre um exploit kit bastante sofisticado direcionado aos dispositivos iPhone da Apple. De acordo com o Google, o exploit kit foi descoberto pela primeira vez em ataques direcionados conduzidos por um cliente de um fornecedor de serviços de vigilância não identificado. Mais tarde, ele foi usado por outros atacantes em ataques de watering hole na Ucrânia e em ataques com motivação financeira na China. Além disso, os pesquisadores descobriram um caso em que a versão de debug do exploit kit estava sendo usada, o que revelou os nomes internos dos exploits e o nome do framework usado pelos seus desenvolvedores: Coruna. A análise do kit mostrou que ele se aproveita da exploração de muitas vulnerabilidades que já haviam sido corrigidas, além de incluir exploits para a CVE-2023-32434 e a CVE-2023-38606. Essas duas vulnerabilidades chamaram particularmente a nossa atenção, pois foram descobertas pela primeira vez como vulnerabilidades zero day usadas na Operação Triangulação.

A Operação Triangulação é uma campanha APT móvel complexa direcionada a dispositivos iOS. Nós a descobrimos enquanto monitorávamos o tráfego de rede da nossa própria rede Wi-Fi corporativa. Detectamos atividades suspeitas que se originaram de vários telefones baseados em iOS. Após a investigação, descobrimos que essa campanha utilizou um implante de spyware sofisticado e vários exploits zero day. A investigação durou mais de seis meses, durante os quais divulgamos nossas descobertas sobre o ataque. Os especialistas do Kaspersky GReAT também apresentaram essas descobertas no 37º Chaos Communication Congress (37C3).

Embora todas as informações sobre a CVE-2023-32434 e a CVE-2023-38606 já tenham sido disponibilizadas ao público há muito tempo e outros pesquisadores tenham desenvolvido seus próprios exploits sem nunca terem visto o código da Triangulação, decidimos investigar de perto os exploits usados no Coruna. Alguns dos links de distribuição do exploit kit fornecidos pelo Google estavam ativos no momento da publicação do relatório, o que nos permitiu coletar, descriptografar e analisar todos os componentes do Coruna.

Durante nossa análise, descobrimos que o exploit do kernel para as vulnerabilidades CVE-2023-32434 e CVE-2023-38606 usado no Coruna é, na verdade, uma versão atualizada do mesmo exploit usado na Operação Triangulação. As imagens abaixo ilustram uma visão geral das duas cadeias de ataque. O exploit em questão é destacado com um retângulo vermelho.

Cadeia de ataque da Operação Triangulação (simplificada)

Cadeia de ataque do Coruna (simplificada)

Além disso, descobrimos que o Coruna inclui quatro exploits adicionais do kernel que não havíamos visto serem usados na Operação Triangulação, dois dos quais foram desenvolvidos após a descoberta dessa operação. Todos esses exploits são baseados no mesmo framework de exploração do kernel e compartilham código em comum. Semelhanças de código entre os exploits do kernel também podem ser encontradas em outros componentes do Coruna. Essas descobertas nos levaram a concluir que esse exploit kit não foi montado a partir de códigos diferentes, mas sim projetado com uma abordagem unificada. Presumimos que se trata de uma versão atualizada do mesmo framework de exploração que foi usado, pelo menos em parte, na Operação Triangulação.

Detalhes técnicos

Enquanto continuamos investigando todas as vulnerabilidades e os exploits usados pelo Coruna, esta postagem fornece uma visão geral de alto nível do exploit kit e da cadeia de ataque.

Safari

A exploração começa com um stager que faz o fingerprint do navegador e seleciona e executa os exploits apropriados de execução remota de código (RCE) e de código de autenticação de ponteiro (PAC), dependendo da versão do navegador. Ela também contém uma URL para um arquivo criptografado com informações sobre todos os pacotes disponíveis que contêm exploits e outros componentes. O stager também inclui uma chave de 256 bits usada para descriptografar o arquivo. A URL e a chave de descriptografia são passadas para um payload incorporado nos exploits de PAC.

Payload

O payload é responsável por iniciar a exploração do kernel. Após a inicialização, o payload primeiro baixa um arquivo com informações sobre outros componentes disponíveis. Para extraí-lo, o payload executa várias etapas, processando vários formatos de arquivo.

Primeiro, o arquivo baixado é descriptografado usando a cifra de fluxo ChaCha20. A descriptografia produz um container com o número mágico 0xBEDF00D, que armazena dados comprimidos com a compressão LZMA.

O formato de arquivo usado pelo exploit kit para armazenar dados compactados

Os dados descompactados contêm outro container com o número mágico 0xF00DBEEF. Esse formato de arquivo é usado no exploit kit para armazenar e recuperar arquivos por meio dos seus IDs.

O formato de arquivo usado pelo exploit kit para armazenar arquivos

Abaixo, fornecemos uma descrição de todos os valores possíveis de ID de arquivo. Nesse estágio, quando o payload reúne informações sobre todos os pacotes de arquivos disponíveis, o container contém apenas um arquivo, e seu ID de arquivo é 0x70000.

Por fim, chegamos ao arquivo que contém informações sobre todos os pacotes de arquivos disponíveis. Ele começa com o valor mágico 0x12345678. O exploit kit usa esse formato de arquivo para obter URLs e chaves de descriptografia para componentes adicionais que precisam ser baixados.

O formato de arquivo usado pelo exploit kit para armazenar informações sobre pacotes de arquivos

Os componentes necessários para explorar um dispositivo visado são selecionados usando o ID do pacote. O byte superior especifica o tipo de pacote e o hardware necessário. Encontramos os seguintes tipos de pacotes:

• 0xF2: exploit para ARM64,
• 0xF3: exploit para ARM64E,
• 0xA2: loader Mach-O para ARM64,
• 0xA3: loader Mach-O para ARM64E,
• 2: implante para ARM64,
• 0xE2: implante para ARM64E.

O código do payload também é compatível com tipos de pacotes adicionais, como o 0xF1, que é um exploit para dispositivos ARM mais antigos que não são compatíveis com a arquitetura de 64 bits. No entanto, é curioso que os arquivos para tais exploits estejam ausentes.

Outros bytes do ID do pacote definem a versão de firmware compatível e a geração da CPU.

Alguns dos IDs de pacote observados (aqueles com conteúdo único)

Os arquivos dentro desses pacotes também são armazenados em containers 0xF00DBEEF criptografados e comprimidos, mas, desta vez, a compressão é opcional e determinada pelo segundo bit no campo Flags. Pacotes diferentes contêm conjuntos diferentes de arquivos. A tabela abaixo apresenta uma descrição de todos os IDs de arquivo possíveis.

IDs de arquivo observados

Depois de baixar os componentes necessários, o payload começa a executar exploits do kernel, loaders Mach-O e o iniciador do malware. O payload seleciona um loader Mach-O apropriado com base na versão do firmware, na CPU e na presença da permissão iokit-open-service.

Exploits do kernel

Analisamos todos os cinco exploits do kernel do kit e descobrimos que um deles é uma versão atualizada do mesmo exploit que descobrimos na Operação Triangulação. Há muitas pequenas alterações, mas as mais notáveis são as seguintes:

• O código leva em consideração mais valores das strings de versão do XNU, permitindo uma verificação mais precisa da versão.
• Foi adicionada uma verificação para o iOS 17.2. Tudo indica que essa era a versão mais recente do iOS no momento do desenvolvimento (lançada em dezembro de 2023).
• Foram adicionadas verificações para processadores mais recentes da Apple: A17, M3, M3 Pro, M3 Max (lançados no outono de 2023).
• Foi adicionada uma verificação para a versão 16.5 beta 4 do iOS. Essa versão corrigiu o exploit após nosso relatório ter sido enviado à Apple.

Por que o exploit precisa verificar o iOS 17.2 e as CPUs mais recentes se as vulnerabilidades visadas foram corrigidas no iOS 16.5 beta 4? A resposta pode ser encontrada ao se examinar outros exploits: todos eles são baseados no mesmo código-fonte. A única diferença está nas vulnerabilidades que eles exploram; portanto, essas verificações foram adicionadas para dar suporte aos exploits mais recentes e apareceram na versão mais antiga após a recompilação.

Iniciador

O iniciador é responsável por orquestrar as atividades de pós-exploração. Ele também usa o exploit do kernel e a interface que ele fornece. No entanto, como o exploit cria objetos especiais do kernel durante sua execução, que fornecem a capacidade de ler e gravar na memória do kernel, o iniciador reutiliza esses objetos sem a necessidade de acionar vulnerabilidades e percorrer todo o caminho de exploração novamente. O iniciador limpa os artefatos de exploração, recupera de uma configuração com o número mágico 0xDEADD00F o nome do processo no qual a injeção será feita, injeta um stager no processo alvo, usa-o para executar a si mesmo e inicia o implante.

Conclusões

Esse caso demonstra mais uma vez os perigos associados a essas ferramentas maliciosas decorrentes de seu potencial de uso amplo. Esse framework foi desenvolvido para fins de espionagem cibernética, mas agora está sendo usado por cibercriminosos de diferentes tipos, colocando em risco milhões de usuários com dispositivos não corrigidos. Dado seu design modular e sua facilidade de reutilização, esperamos que outros threat actors passem a incorporá-lo a seus ataques. Recomendamos que os usuários instalem as atualizações de segurança mais recentes o mais rápido possível, caso ainda não tenham feito isso.