Estrutura Coruna: um kit de exploração e vínculos com a Operação Triangulação

Introdução

Em 4 de março de 2026, Google e iVerificar publicou relatórios sobre um kit de exploração altamente sofisticado direcionado a dispositivos Apple iPhone. Segundo o Google, o kit de exploração foi descoberto pela primeira vez em ataques direcionados conduzidos por um cliente de um fornecedor de vigilância não identificado. Mais tarde, foi utilizado 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 uma instância com a versão de depuração do kit de exploração, que revelou os nomes internos das explorações e o nome da estrutura usada por seus desenvolvedores – Coruna. A análise do kit mostrou que ele depende da exploração de muitas vulnerabilidades corrigidas anteriormente e também inclui explorações para CVE-2023-32434 e CVE-2023-38606. Essas duas vulnerabilidades chamaram nossa atenção principalmente porque foram descobertas pela primeira vez como dias zero usadas na Operação Triangulação.

A Operação Triangulação é uma campanha complexa de APT móvel direcionada a dispositivos iOS. Descobrimos isso enquanto monitorávamos o tráfego de rede de nossa própria rede Wi-Fi corporativa. Notamos atividades suspeitas originadas em vários telefones com iOS. Após a investigação, descobrimos que esta campanha empregou um sofisticado implante de spyware e múltiplas explorações de dia zero. A investigação durou mais de seis meses, durante os quais divulgamos nossas descobertas relacionadas ao ataque. Os especialistas do Kaspersky GReAT também apresentou essas descobertas no 37º Congresso de Comunicação do Caos (37C3).

Embora todos os detalhes de CVE-2023-32434 e CVE-2023-38606 estejam disponíveis publicamente há muito tempo, e outros pesquisadores tenham desenvolvido suas próprias explorações sem nunca ver o código de triangulação, decidimos investigar de perto as explorações usadas em Coruna. Alguns dos links de distribuição do kit de exploração fornecidos pelo Google permaneceram 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 que foi usado na Operação Triangulação. As imagens abaixo ilustram uma visão geral de alto nível das duas cadeias de ataque. A exploração em questão é destacada com um retângulo vermelho.

Cadeia de ataque da Corunha (simplificada)

Além disso, descobrimos que Coruna inclui quatro explorações de kernel adicionais que não vimos usadas na Operação Triangulação, duas das quais foram desenvolvidas após a descoberta da Operação Triangulação. Todas essas explorações são construídas na mesma estrutura de exploração do kernel e compartilham código comum. Semelhanças de código de explorações de kernel também podem ser encontradas em outros componentes do Coruna. Estas descobertas levaram-nos a concluir que este kit de exploração não foi remendado, mas sim concebido com uma abordagem unificada. Presumimos que seja uma versão atualizada da mesma estrutura de exploração que foi usada — pelo menos até certo ponto — na Operação Triangulação.

Detalhes técnicos

Enquanto continuamos investigando todas as explorações e vulnerabilidades usadas pelo Coruna, esta postagem fornece uma visão geral de alto nível do kit de exploração e da cadeia de ataque.

Safári

A exploração começa com um stager que identifica o navegador e seleciona e executa explorações apropriadas de execução remota de código (RCE) e código de autenticação de ponteiro (PAC), dependendo da versão do navegador. Ele também contém uma URL para um arquivo criptografado com informações sobre todos os pacotes disponíveis contendo explorações e outros componentes. O stager também inclui uma chave de 256 bits usada para descriptografá-lo. A URL e a chave de descriptografia são passadas para uma carga incorporada nas explorações do PAC.

Carga útil

A carga útil é responsável por iniciar a exploração do kernel. Após a inicialização, a carga primeiro baixa um arquivo com informações sobre outros componentes disponíveis. Para extraí-lo, a carga 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 contêiner com o número mágico 0xBEDF00D, que armazena dados compactados em LZMA.

O formato de arquivo usado pelo kit de exploração para armazenar dados compactados

Os dados descompactados apresentam outro contêiner com o número mágico 0xF00DBEEF. Este formato de arquivo é usado no kit de exploração para armazenar e recuperar arquivos por seus IDs.

O formato de arquivo usado pelo kit de exploração para armazenar arquivos

Fornecemos uma descrição de todos os valores possíveis de ID de arquivo abaixo. Neste estágio, quando a carga coleta informações sobre todos os pacotes de arquivos disponíveis, esse contêiner contém apenas um arquivo e seu ID de arquivo é 0x70000.

Finalmente, chegamos ao arquivo com informações sobre todos os pacotes de arquivos disponíveis. Começa com o valor mágico 0x12345678. O kit de exploração 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 kit de exploração para armazenar informações sobre pacotes de arquivos

Os componentes necessários para explorar um dispositivo de destino são selecionados usando o ID do pacote. Seu byte alto especifica o tipo de pacote e o hardware necessário. Vimos os seguintes tipos de pacotes:

• 0xF2 – exploração para ARM64,
• 0xF3 – exploração para ARM64E,
• 0xA2 – Carregador Mach-O para ARM64,
• 0xA3 – Carregador Mach-O para ARM64E,
• 2 – implante para ARM64,
• 0xE2 – implante para ARM64E.

O código de carga útil também suporta tipos de pacotes adicionais, como 0xF1, uma exploração para dispositivos ARM mais antigos que não suportam arquitetura de 64 bits. Curiosamente, porém, os arquivos para tais explorações estão faltando.

Outros bytes do ID do pacote definem a versão de firmware suportada e a geração de CPU.

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

Os arquivos dentro desses pacotes também são armazenados em contêineres 0xF00DBEEF criptografados e compactados, mas desta vez a compactação é opcional e é determinada pelo segundo bit no campo Flags. Diferentes pacotes contêm diferentes conjuntos de arquivos. Uma descrição de todos os IDs de arquivo possíveis é fornecida na tabela abaixo.

IDs de arquivo observados

Depois de baixar os componentes necessários, a carga começa a executar explorações de kernel, carregadores Mach-O e inicializador de malware. A carga seleciona um carregador Mach-O apropriado com base na versão do firmware, CPU e presença da permissão iokit-open-service.

Explorações 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. Existem muitas pequenas mudanças, mas as mais visí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 de versão mais precisa.
• Adicionada uma verificação para iOS 17.2. Presumimos que esta era a versão mais recente do iOS no momento do desenvolvimento (lançada em dezembro de 2023).
• Adicionadas verificações para processadores Apple mais recentes: A17, M3, M3 Pro, M3 Max (lançado no outono de 2023).
• Adicionada uma verificação para iOS versão 16.5 beta 4. Esta versão corrigiu a exploração após nosso relatório à Apple.

Por que a exploração precisa verificar o iOS 17.2 e CPUs mais recentes se as vulnerabilidades direcionadas foram corrigidas no iOS 16.5 beta 4? A resposta pode ser encontrada examinando outras explorações: todas elas são baseadas no mesmo código-fonte. A única diferença está nas vulnerabilidades que eles exploram, portanto essas verificações foram adicionadas para dar suporte às explorações mais recentes e apareceram na versão mais antiga após a recompilação.

Lançador

O lançador é responsável por orquestrar as atividades pós-exploração. Ele também usa o exploit do kernel e a interface que ele fornece. No entanto, como a exploração cria objetos especiais do kernel durante sua execução que fornecem a capacidade de ler e gravar na memória do kernel, o inicializador simplesmente 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 o nome do processo para injeção de uma configuração com o número mágico 0xDEADD00F, injeta um stager no processo de destino, usa-o para executar a si mesmo e inicia o implante.

Conclusões

Este caso demonstra mais uma vez os perigos associados a essas ferramentas maliciosas que residem na sua potencial utilização generalizada. Originalmente desenvolvida para fins de ciberespionagem, esta estrutura está agora a ser utilizada por cibercriminosos de um tipo mais amplo, colocando em risco milhões de utilizadores com dispositivos não corrigidos. Dado o seu design modular e facilidade de reutilização, esperamos que outros agentes de ameaças comecem a incorporá-lo nos seus ataques. Recomendamos fortemente que os usuários instalem as atualizações de segurança mais recentes o mais rápido possível, caso ainda não o tenham feito.