Raio X do MacSync: novos métodos de distribuição e novo payload

O MacSync é uma família de infostealers de criptomoedas relativamente recente e em desenvolvimento ativo. Os anúncios das primeiras versões, sob o nome Mac.c, surgiram na darknet em 2025; mais tarde, os invasores renomearam o malware para MacSync. As primeiras versões foram implementadas como scripts AppleScript e se assemelhavam, em grande parte, à família de stealers AMOS, mas, com o tempo, o MacSync desenvolveu características próprias, incluindo um módulo de backdoor. Neste relatório, apresentamos a nova cadeia de infecção, que sofreu mudanças significativas em relação às versões anteriores e que identificamos em ambiente real pela primeira vez em setembro de 2026.

Principais pontos:

• Os autores da família mudaram a forma de distribuir o código malicioso, substituindo droppers em script por droppers binários.
• O código malicioso principal agora é composto por módulos em Objective-C e Swift.
• Em um dos estágios da infecção, os invasores usam a infraestrutura do iCloud para entregar o estágio seguinte.

As soluções da Kaspersky detectam as ameaças descritas abaixo com os seguintes veredictos:

• HEUR:Trojan.OSX.MacSync.*
• HEUR:Trojan-PSW.OSX.MacSync.*
• HEUR:Trojan-Dropper.OSX.MacSync.*
• HEUR:Trojan-Downloader.OSX.MacSync.*

Detalhes técnicos

Cadeia de infecção

O MacSync é um infostealer distribuído no modelo MaaS (malware como serviço). Por isso, o método específico de entrega do primeiro estágio da cadeia de infecção fica a cargo dos operadores. Os relatórios públicos mais recentes sobre o MacSync concentraram-se principalmente na entrega de módulos por meio de engenharia social e ataques do tipo ClickFix. Porém, tanto naquele momento quanto atualmente, o malware também se disfarça de versões gratuitas ou crackeadas de aplicativos conhecidos, além de supostos aplicativos novos. Por exemplo, identificamos o MacSync disfarçado de Toria, uma carteira de criptomoedas inexistente. Os invasores não apenas criaram um site para ela, mas também a promoveram na rede social X e no aplicativo de mensagens Telegram:

A versão mais recente do infostealer que identificamos inicia a cadeia de infecção a partir de imagens de disco maliciosas no formato DMG. Além disso, mesmo dentro de uma campanha que usa um único aplicativo falso, identificamos duas formas de entrega dos módulos de infostealer e backdoor no dispositivo da vítima. Em uma delas, o código malicioso dentro do DMG era um script JXA compilado que, após a execução, decodificava um shell script e o passava diretamente ao interpretador, sem gravá-lo no disco. Na outra forma, o mesmo script aparecia em um estágio mais avançado da infecção, após a execução da cadeia de droppers e loaders. Analisaremos a segunda cadeia de infecção, por ser mais complexa e interessante do ponto de vista técnico. O esquema geral da infecção é apresentado abaixo:

Convém ressaltar desde já que, em quase todos os estágios, o MacSync apresenta algumas características em comum:

• Todos os arquivos temporários são armazenados no diretório /tmp. Nele também são criados arquivos *.lock, que servem para impedir que o código malicioso seja executado mais de uma vez.
• Depois de concluir sua tarefa, o módulo apaga seus rastros, como arquivos temporários e os próprios logs.
• Todos os binários estão no formato Fat Mach-O e visam dispositivos com processadores tanto Apple quanto Intel.

Loader, calendário e dois droppers simples

Nesta cadeia de infecção, o código malicioso presente na imagem de disco é um aplicativo .APP. Ao ser executado, ele primeiro verifica se todo o bundle possui o atributo estendido de quarentena com.apple.quarantine e, caso o encontre, executa o comando xattr -cr <app_name> para remover todos os atributos. Em seguida, extrai do próprio overlay uma URL criptografada com o algoritmo XOR e a descriptografa usando a chave 73 6f 6e 6f 6d 61 62 6c 64 07. Após os dados criptografados, há 8 bytes que indicam o tamanho do texto cifrado, seguidos da palavra mágica SONOMAC1. Convém ressaltar que o malware lê o overlay de trás para frente. Primeiro, ele localiza a palavra mágica, depois lê o tamanho dos dados e, com base nele, determina os limites do bloco que contém o texto cifrado.

A URL obtida levava ao próximo script loader. Em alguns casos, era um link direto para um arquivo hospedado em um servidor controlado pelos invasores. Porém, em pelo menos uma amostra, ela apontava para um calendário público do iCloud:

Conteúdo do calendário baixado

Depois de obter o arquivo de calendário do servidor, o loader cria um canal anônimo, inicia o interpretador em modo de leitura de comandos a partir da entrada padrão (zsh -s), define esse canal como entrada padrão e redireciona para ele, linha a linha, o conteúdo do calendário. Como o conteúdo de um calendário normalmente não contém comandos, o interpretador trata as linhas como comandos inválidos até chegar ao código malicioso, situado após a linha DESCRIPTION:. Esses comandos acabam baixando do iCloud um arquivo tar.gz que contém um bundle .APP. O loader remove o atributo de quarentena desse bundle, assina-o localmente e o executa.

Desconhecemos o conteúdo dos scripts distribuídos pelo servidor do invasor, mas é altamente provável que se trate do mesmo script presente na descrição do evento do calendário.

O aplicativo baixado é um dropper. O código malicioso que ele extrai é um executável compactado com o algoritmo ZLIB e criptografado com AES no modo CBC (Cipher Block Chaining), com a chave e o vetor de inicialização a seguir:

O dropper descriptografa e descompacta o executável e o salva no caminho /tmp/.sys-<16-digit random value>.

Dentro dele há outro dropper, que, diferentemente dos estágios anteriores, conta com anti-debugging. Em especial, verifica se está sendo executado em uma máquina virtual por meio de chamadas sysctl com os parâmetros kern.hv_vmm_present e machdep.cpu.brand_string, além de definir a flag PT_DENY_ATTACH via ptrace, o que impede que um depurador se conecte ao processo. O payload é um shell script criptografado com AES no modo CBC, com a chave e o vetor de inicialização a seguir:

Código malicioso do segundo dropper

Como é possível ver na captura de tela acima, o segundo dropper entrega um script loader que obtém do servidor de C2 o código malicioso do próximo estágio, descriptografa-o com AES no modo CBC usando a chave e o vetor de inicialização a seguir e, então, o executa na memória:

Mais dois scripts

No script obtido, podemos identificar de imediato vários indicadores conhecidos da família MacSync:

• A função principal do script se chama daemon_function.
• O upload dos dados roubados para o servidor de C2 ocorre por meio de requisições PUT. Os dados são enviados em blocos de 90 megabytes. Em versões anteriores, o tamanho dos blocos era diferente.
• Um dos métodos de persistência no sistema é a injeção de um comando malicioso no .zshrc, arquivo de configuração do interpretador ZSH que contém os comandos executados sempre que ele é iniciado.
• O caminho da URL em que o executável do backdoor está hospedado no servidor de C2 começa com o diretório /loader/.

O script executa as seguintes tarefas:

• Download e descriptografia de módulos maliciosos adicionais: o infostealer, o backdoor e um utilitário especial para gerar chaves de criptografia e descriptografar os executáveis baixados.
• Persistência do backdoor no sistema.
• Upload dos dados obtidos pelo módulo infostealer para o servidor de C2.

Convém ressaltar um detalhe interessante. Em vez dos algoritmos de criptografia usuais (XOR, AES etc.), os invasores recorreram a outra abordagem para a entrega dos módulos maliciosos nesse estágio, que envolve o utilitário pkgunpack, de criação própria, com dois comandos implementados: genkey e decrypt.

1. O malware gera as chaves pública e privada de criptografia usando o comando genkey do pkgunpack. A função de geração utiliza uma implementação de código aberto do protocolo Diffie-Hellman sobre a curva elíptica Curve25519, a curve25519_donna.
2. A chave pública é codificada em base64 e enviada ao servidor de C2 junto com um código de uso único gerado pelo comando $(date +%s)-${RANDOM}-$$.
3. Em resposta, o servidor retorna o seguinte JSON:
   
   { "ok": true, "dek_wrap_b64": <base64_encoded_encrypted_key> , "build_pub_b64": "pFSxn/Uwg9bS45aVKCzA+8exSMfDHXpbpHC/f7G472w=", "crypto": "v2.5" }

   1 2 3 4 5 6

   {     "ok": true,     "dek_wrap_b64":  <base64_encoded_encrypted_key> ,     "build_pub_b64": "pFSxn/Uwg9bS45aVKCzA+8exSMfDHXpbpHC/f7G472w=",     "crypto": "v2.5" }

   
   Aqui, build_pub_b64 é a chave pública do servidor, também predefinida no próprio script, e dek_wrap_b64 é uma string codificada em base64 que contém a chave de criptografia do payload. Essa chave é criptografada no servidor com um segredo compartilhado, calculado a partir da chave pública gerada pelo pkgunpack no dispositivo da vítima.
   A seguir, a chave é descriptografada por meio do comando decrypt do pkgunpack.
   1. Com base na chave pública conhecida do servidor e na chave privada da sessão atual, o segredo compartilhado é calculado usando a mesma implementação do esquema de troca de chaves ECDH Curve25519 empregada na geração das chaves.
   2. O segredo compartilhado obtido é concatenado com a string sn-dek-wrap-v1, e o hash SHA-256 do resultado é calculado.
   3. Em seguida, o bloco dek_wrap_b64 recebido do servidor é decodificado. Ele tem a seguinte estrutura:
      1. Os primeiros 5 bytes são os dados adicionais autenticados (AAD).
      2. Os 12 bytes seguintes são o vetor de inicialização (IV).
      3. Em seguida, o texto cifrado.
   4. O texto cifrado é descriptografado com AES no modo GCM usando a chave, o IV e o AAD obtidos anteriormente.
      

      Bloco dek_wrap_b64 decodificado

4. O resultado obtido é a chave para descriptografar o código malicioso baixado. Esse código, por sua vez, também contém AAD e IV em seu cabeçalho e está criptografado com AES no modo GCM. O utilitário o descriptografa e conclui sua execução.

Convém ressaltar que, em cada estágio, o utilitário zera os buffers após usar as chaves de criptografia e os dados, aparentemente com o objetivo de dificultar a coleta de evidências forenses e a análise dinâmica das amostras.

Como mencionado anteriormente, nesse estágio, o script baixa apenas dois módulos: o infostealer e o backdoor. Depois de descriptografados, ambos são arquivos no formato .tar.gz, cujo conteúdo é extraído, limpo de todos os atributos estendidos (como com.apple.quarantine) e assinado localmente. Primeiro, é executado o módulo infostealer, que coleta os dados de interesse, os coloca em uma pasta temporária e os compacta em um arquivo .tar.gz, que o script depois envia ao servidor dos invasores. Em seguida, antes de iniciar o backdoor, o script garante sua persistência e também cria um backup. O backup, junto com os demais arquivos necessários para seu funcionamento, é armazenado em $HOME/Library/Application Support/System. Esse diretório não existe no macOS por padrão. É o script que o cria. O backdoor se disfarça de aplicativo Finder e permanece no sistema das seguintes maneiras:

• Uso de um agente de inicialização automática (LaunchAgent) chamado com.apple.finder.agent
• Injeção de um comando que executa o script .repair-run ao iniciar o interpretador ZSH a partir do .zshrc
• Injeção de um comando semelhante, que também executa o script .repair-run, nos hooks globais do GIT pre-commit e post-checkout

O script .repair-run verifica a existência dos arquivos do backdoor e restaura-os a partir do backup se estiverem ausentes. Ele também recria e reinicia o agente de inicialização automática, encerrando os processos do sistema BTMNotificationAgent, NotificationCenter e BackgroundTaskManagementAgent para impedir que o sistema notifique a adição de um novo agente.

O último ponto a destacar no funcionamento do script nesse estágio é o uso de um cabeçalho HTTP personalizado, X-Upload-Token, sem o qual o servidor de C2 responde às requisições com erros. Durante a pesquisa, observamos o uso dos seguintes tokens: b8b4b88205a8f594b95a841bc37342898f34cad8a5a9e4a22ce69a31a1208650 e ff3ab9ef841630364818396f62e696b72aed162cf0b895b6643ef25dad79b51d. Esses tokens também são usados posteriormente pelo backdoor para se comunicar com o servidor de C2.

Infostealer

O módulo infostealer é entregue como um aplicativo .APP, cujo executável principal é escrito em Swift. Assim como nas versões anteriores em AppleScript, o malware primeiro solicita ao usuário a senha de administrador. Para isso, ele adapta a janela exibida ao aplicativo que está imitando. Depois que a senha é digitada, o usuário vê uma janela falsa de notificação do sistema, que informa que o aplicativo está corrompido e sugere movê-lo para a lixeira.

Janelas pop-up falsas do stealer

É interessante notar que, para verificar a senha digitada, os invasores não recorreram ao método usado pela maioria das famílias de malware para macOS, o utilitário dscl. Em vez disso, usaram a API dos módulos de autenticação plugáveis (PAM). Trata-se de uma técnica bastante nova para malware de macOS, usada pela primeira vez em ambiente real em julho de 2026 na família Pam Stealer. Aparentemente, ela despertou o interesse dos autores de malware, e é possível que passemos a encontrá-la com mais frequência no futuro.

Verificação de senha usando PAM

Muitas strings (nomes de arquivos, diretórios, teamid etc.) no stealer estão criptografadas com o algoritmo XOR e armazenadas em arrays estáticos. As chaves de criptografia variam entre as amostras e são geradas com base no tamanho do texto cifrado.

Descriptografia de strings

O conjunto de dados coletados pelo stealer foi ligeiramente ampliado em relação às versões anteriores. A lista completa é a seguinte:

• Informações de navegadores: histórico, cookies, dados de extensões de carteiras de criptomoedas, logins e senhas salvos, arquivos Local State
• Dados de aplicativos de carteiras de criptomoedas
• Dados do Telegram
• Login e senha do dispositivo
• Arquivo de keychain
• Informações do sistema: lista de aplicativos instalados e processos em execução, modelo do dispositivo, hardware, UUID etc.
• Arquivos de configuração de SSH, ZSH, AWS, Kubernetes, GIT e outros serviços e programas
• Histórico de comandos dos interpretadores ZSH e Bash
• Avatar do usuário atual

Os dados coletados são salvos em um diretório oculto em /tmp/.

O módulo stealer também contém uma função interessante, que, em todas as amostras identificadas até o momento, está desativada e, aparentemente, ainda está em desenvolvimento. Sua tarefa é verificar se o arquivo KcHelper está presente nos recursos do aplicativo malicioso, no caminho <app_path>/Contents/Resources/Helpers, e, se estiver, executá-lo com parâmetros específicos. Na ausência desse arquivo, é executada a função alternativa _kc_grab_storage_item. Como o KcHelper não estava presente nos recursos do aplicativo no momento da pesquisa, só podemos supor sua finalidade com base na análise dessa função. Nela, primeiro é executado um comando que modifica o partition_id de uma entrada do keychain de um determinado serviço. Com isso, o acesso a essa entrada pode ser concedido, sem confirmação do usuário e sem a senha do keychain, a três categorias de aplicativos:

• teamid: o aplicativo é assinado com um certificado com um teamID específico (nesse caso, o do desenvolvedor do aplicativo-alvo)
• apple: o aplicativo é um serviço da Apple
• apple-tool: o aplicativo é um utilitário de linha de comando da Apple

Em seguida, o stealer tenta obter o conteúdo do segredo por conta própria usando a API do Security.framework, o que, no final, acaba gerando uma solicitação de confirmação da operação. Aparentemente, os invasores planejam, no futuro, aprimorar essa função para obter acesso irrestrito aos segredos mesmo que a senha do keychain seja alterada. Por ora, porém, isso não é possível. Por isso, a função está desativada. Nas strings criptografadas do stealer, vimos argumentos para o comando que modifica o partition_id, o que indica que os invasores têm interesse nos segredos de navegadores. Alguns exemplos:

Trecho de código que altera o acesso aos serviços no keychain

Backdoor

O backdoor é um executável Fat Mach-O escrito em Objective-C. Ele possui dois modos de execução: o modo normal e o modo com a flag --persist-status. No segundo caso, ele apenas verifica de que forma foi adicionado aos itens de inicialização automática, se por meio de um item de login (Login Item) ou de um agente de inicialização automática (LaunchAgent). No modo normal, antes de passar à execução de sua funcionalidade principal, o backdoor também verifica se já garantiu sua persistência de alguma forma. Caso não tenha garantido, é executado o mesmo mecanismo de persistência usado pelo script pai. Porém, para versões do macOS anteriores a 13.0, independentemente da presença de itens de inicialização automática, é usado um executável auxiliar separado, armazenado no próprio corpo do backdoor. A única tarefa desse auxiliar é adicionar aos itens de login o executável passado como argumento, usando a API do CoreServices.framework.

Assim como nos droppers dos primeiros estágios da cadeia de infecção, a configuração de comunicação com o C2 é armazenada no overlay do executável e criptografada com XOR usando a mesma chave. Ela consiste em várias strings separadas por bytes nulos:

• AGNT1: constante mágica que confirma que a configuração foi descriptografada corretamente
• URL do servidor de C2
• Token de acesso: o mesmo do script pai
• BLD-150: número da build do backdoor

O malware também grava logs no caminho $HOME/Library/Logs/.sysnotif-agent.log e oferece suporte a logs detalhados quando executado com a variável de ambiente LAUNCHER_DEBUG. A comunicação com o C2 ocorre pelo protocolo HTTP. A resposta do servidor deve ser um JSON. A tabela abaixo apresenta as requisições ao servidor de C2 e suas descrições:

Embora o backdoor ofereça vários comandos, todos eles se resumem, na essência, a uma única ação. O backdoor extrai do campo script_b64, na resposta do servidor, um script AppleScript codificado em base64 e o executa. Assim, os handlers de cada comando atuam como wrappers dos scripts, preenchendo corretamente a telemetria e realizando as requisições ao servidor de C2. Com base nos nomes dos comandos e nas mensagens enviadas ao servidor durante sua execução, conseguimos deduzir sua finalidade sem ter acesso direto aos scripts. O backdoor oferece suporte aos seguintes comandos:

• deploy_ext: injeta no navegador do usuário uma extensão baixada do servidor.
• deploy_ledger: substitui a carteira Ledger instalada por uma versão obtida do servidor.
• regrab: coleta novamente informações do sistema, arquivos específicos ou ambos. Desta vez, os dados coletados são armazenados em um arquivo típico da família MacSync, no caminho /tmp/osalogging.zip, a menos que outro caminho seja especificado no campo archive_path enviado junto com o comando.
• live_browser: é o único comando executado sem o envolvimento de scripts AppleScript. O backdoor verifica a presença do arquivo sn_relay em seus recursos e, caso não o encontre, baixa-o e o executa. Seu conteúdo e finalidade ainda são desconhecidos. Porém, a julgar pelo nome do comando e pelas mensagens enviadas ao servidor, podemos supor que, de alguma forma, os invasores realizam um ataque MitM ao tráfego proveniente do navegador da vítima.

Trecho do comando regrab que verifica a integridade do arquivo e calcula seu hash sum antes do envio

Conclusão

A nova versão do infostealer MacSync é bastante diferente das versões observadas anteriormente. Os invasores mudaram significativamente a forma de executar o código malicioso principal do stealer e do backdoor, migrando de scripts AppleScript para executáveis completos, escritos em Swift e Objective-C. Também convém ressaltar que a cadeia de infecção ficou mais complexa. Em vez de shell scripts ofuscados entregues por ataques do tipo ClickFix, esta versão utiliza droppers e loaders binários, inclusive empregando a infraestrutura da Apple como um dos estágios intermediários de entrega do código malicioso.

O tipo de dado que os invasores coletam no dispositivo da vítima, bem como as categorias de aplicativos de que o stealer se disfarça, indica claramente que a família tem como alvo principal desenvolvedores, entusiastas de criptomoedas e outros usuários de alguma forma associados a TI e ao universo cripto. O comprometimento de dispositivos de desenvolvedores de software pela família MacSync representa riscos de segurança específicos tanto para os usuários finais quanto para os sistemas corporativos, ampliando as possibilidades de movimentação lateral dos invasores.

Indicadores de comprometimento

Loader do primeiro estágio
26a0f7cdb9f7dc5ace9a40af825b1538
2d69812584269699fade26622e6490c5
7df1049cbd56c0bfa4a3364a379b4c2c
9f15fe9c4415cd668334339f705b94d8
fb90887592655a8c989e443c640167aa
6791dad263cac6d63ebba6a4b57e7d71

Calendário malicioso (segundo estágio)
3ded1d71a822b53b12c3b67bcaf633f5

Dropper do terceiro estágio
781ce50001d4b449600afa347c9b0208
8e84b01d5ac9624f0b181ade0e737193
980e2134679bc0c609f7659882883d77
4203ec932bfcc0907f91732440d6d997
eb760d5c88f13f7ee0f8f86ba3407123
f9f70096aabb4d22a6657014f4853a53

Dropper do quarto estágio
3deeed48fd38f22e369f5c3092bd68a1

Script do quinto estágio
f97d24212fa6a21be0c4d211e10f044c

Script do sexto estágio
00d12d842596bf5ee1805effb4571d30
9a0043d900a9ac78c886c59c9a328fd0

Script auxiliar .repair-run
7212229c85852c3bffaf9740002b2f39

Infostealer
c53d0ea45dbc622afb7f16ea3eec78bc

Backdoor
fc3ba5ed282d77127efd0b0f2403531b

Ferramenta auxiliar de inicialização automática
8dc8561349d144d4661bc66f2ec49f9f

URL
hxxps://toria[.]app/
hxxps://warpcast[.]asia/Toria.dmg
hxxps://streamyard.appstore.com[.]mx/installer.sh
hxxps://slack.apple03cloudstore[.]com/installer.sh
hxxps://toria.apple03cloudstore[.]com/
hxxps://waaako.appstore.com[.]mx/installer.sh
hxxps://toria.apple03cloudstore[.]com/e3c1a6b00bc31e14/stage2.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/stage2.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/CoreUpdate.pkg.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/Helper.pkg.enc
hxxps://caldav.icloud[.]com/published/2/MTk1NDMwMDMzNTUxOTU0M1aHCZ-nMxiyGzBTzPiodOf44DtKJ6PpjftAG28_ui2NCYMpL_vu4pF4ddsJ8ysg0QI7pR0VEIEbZYdilVZRw08
hxxps://gateway.icloud[.]com/caldav/1_MTk1NDMwMDMzNTUxOTU0M0pybtJB186GzhogprwCQUjY3oZNiDFHH8WVo6bmgUtI/attach/4GE4TKNBTGAYDGMZVGUYTSNJUGOAALDAFMDOJBGWNUCYJLZRNDCLCO2YMQ3I64RLGMNXVG3KYBPWQOGYIEI7MPBDDYHECFDYVENTXIYFNDCPOVRMCTYI236RCYZAE63V5U3RTUYGUMO2CO7PKCLWMCXE73M7OPTHSGRWH5DXQ4PCUQU4ELZTLW54JSTK2H7VQ6PD26WOA2R7PPIQ6RTJWDEWP34U3HB4YWMXXC6EJ6PKWILSPYRSDEVY6QGMWSIUN6PR5W35KO3D4QZE7CFPUVBAEKI/Loader.app.tar.gz/YXR0YWNoYXR0YWNoYXR0YRhrE8mQ0E-b_dTUSGStQgTQ0ULFxCanei3Ke-EuEyQL

C2
hxxps://docsend.appstore[.]com[.]mx
hxxps://toria.apple03cloudstore[.]com