Levem meu dinheiro: malware rouba criptomoedas via OCR no Google Play e na App Store

Update 07.02.2025: O Google removeu aplicativos maliciosos do Google Play.
Update 06.02.2025: A Apple removeu aplicativos maliciosos da App Store.

Em março de 2023, pesquisadores da ESET identificaram componentes maliciosos embutidos em diversos mods de apps de mensagens. Alguns desses apps vasculhavam as galerias de imagens dos usuários em busca de frases de recuperação de carteiras de criptomoedas. A busca usava um modelo de OCR (reconhecimento óptico de caracteres) para identificar imagens no dispositivo da vítima e enviá-las ao servidor C2 (comando e controle). A campanha, que teve como alvo usuários de Android e Windows, distribuiu o malware por meio de fontes não oficiais. No fim de 2024, identificamos uma nova campanha de malware, chamada SparkCat. Os operadores usaram táticas parecidas, mirando usuários de Android e iOS, com distribuição em lojas oficiais e não oficiais de aplicativos. Resumo das nossas conclusões:

• Identificamos apps para Android e iOS, alguns disponíveis na Google Play e na App Store, que incluíam um SDK/framework malicioso criado para roubar frases de recuperação de carteiras de criptomoedas. Os aplicativos infectados na Google Play haviam sido baixados mais de 242 mil vezes. Esta foi a primeira vez que um malware de roubo de dados foi encontrado na App Store da Apple.
• O módulo de malware para Android descriptografava e executava um plug-in de OCR desenvolvido com a biblioteca ML Kit do Google, usando-o para identificar textos presentes em imagens da galeria. Imagens que correspondiam às palavras-chave recebidas do C2 eram enviadas ao servidor. O módulo malicioso específico para iOS tinha um design semelhante e também contava com a biblioteca ML Kit do Google para OCR.
• O malware, que chamamos de “SparkCat”, usou um protocolo não identificado, implementado em Rust (uma linguagem atípica em aplicativos móveis), para se comunicar com o C2.
• Considerando os carimbos de data e hora nos arquivos de malware e as datas de criação dos arquivos de configuração nos repositórios do GitLab, o SparkCat está ativo desde março de 2024.

Um SDK de malware em aplicativos do Google Play

O primeiro app que despertou nossa suspeita foi o “ComeCome” (nome do APK: com.bintiger.mall.android), um aplicativo de entrega de comida usado nos Emirados Árabes Unidos e na Indonésia. Na época da análise, ele estava disponível na Google Play com mais de 10 mil downloads.

O método onCreate da subclasse Application (um dos pontos de entrada do aplicativo) foi substituído na versão 2.0.0 (f99252b23f42b9b054b7233930532fcd). Esse método inicializa um componente SDK chamado “Spark”. O código estava inicialmente ofuscado, por isso realizamos uma desofuscação estática antes de iniciar a análise.

O Spark foi escrito em Java. Ao ser inicializado, ele baixa um arquivo de configuração JSON de uma URL do GitLab integrada no corpo do malware. O JSON é decodificado com base64 e depois descriptografado com AES-128 no modo CBC.

Se o SDK não conseguir recuperar uma configuração, as configurações padrão serão usadas.

Conseguimos baixar a seguinte configuração do GitLab:

Os campos “http” e “rust” contêm endereços C2 específicos do SDK, e a flag tfm é usado para selecionar um C2. Se o valor de tfm for 1, “rust” será usado como o servidor C2; se o tfm tiver qualquer outro valor, será usado “http”.

O Spark usa requisições POST para se comunicar com o servidor “http”. Ele criptografa os dados com AES-256 no modo CBC antes de enviá-los e descriptografa as respostas do servidor com AES-128 no modo CBC. Em ambos os casos, as chaves são constantes inseridas diretamente no código (hard-coded).

O processo de envio de dados para o “rust” consiste em três etapas:

• Os dados são criptografados com AES-256 no modo CBC, usando a mesma chave do caso do servidor “http”.
• O malware gera um JSON, em que <PATH> é o caminho de upload dos dados e <DATA> corresponde aos dados criptografados na etapa anterior.

• O JSON é enviado ao servidor com a ajuda da biblioteca nativa libmodsvmp.so, por meio de um protocolo não identificado, utilizando sockets TCP. Escrita em Rust, a biblioteca se disfarça como um ofuscador popular para Android.

A análise estática da biblioteca não foi simples, já que o Rust utiliza uma convenção de nomenclatura não padronizada e o arquivo não continha nomes de funções. Conseguimos reconstruir o padrão de interação após realizar uma análise dinâmica com o Frida. Antes de enviar os dados para o servidor, a biblioteca gera uma chave de 32 bytes para o algoritmo de criptografia AES-GCM-SIV. Com esta chave, ele criptografa os dados, previamente comprimidos com ZSTD. O valor nonce do algoritmo não é gerado e está definido como “unique nonce” (sic) no código.

A chave AES é criptografada com RSA e enviada ao servidor. A chave publica RSA é passada como parametro ao chamar um metodo nativo do SDK, no formato PEM. A mensagem é preenchida com 224 bytes aleatórios antes da criptografia da chave AES. Ao receber a requisição, o servidor dos atacantes descriptografa a chave AES com uma chave RSA privada, decodifica os dados recebidos e, em seguida, comprime a resposta com ZSTD e a criptografa usando o algoritmo AES-GCM-SIV. Após ser descriptografada na biblioteca nativa, a resposta do servidor é repassada ao SDK, onde passa por decodificação em base64 e descriptografia, seguindo o mesmo procedimento utilizado na comunicação com o servidor “http”. Veja abaixo um exemplo de comunicação entre o módulo de malware e o servidor “rust”.

Uma vez que a configuração é baixada, o Spark descriptografa um payload localizada nos ativos e a executa em uma thread separada. Ele utiliza XOR com uma chave de 16 bytes como algoritmo de cifra.

O payload (c84784a5a0ee6fedc2abe1545f933655) é um wrapper (estrutura de encapsulamento) para a interface TextRecognizer na biblioteca ML Kit do Google. Ele carrega diferentes modelos de OCR dependendo do idioma do sistema, para reconhecer caracteres latinos, coreanos, chineses ou japoneses em imagens. Depois, o SDK envia informações do dispositivo no endpoint “/api/e/d/u” do servidor C2. O servidor responde com um objeto que controla outras atividades de malware. O objeto é um arquivo JSON e sua estrutura é mostrada abaixo. A flag uploadSwitch permite que o malware continue em execução (valor 1).

Em seguida, o SDK registra um callback do ciclo de vida das atividades do aplicativo. Sempre que o usuário inicia um chat com a equipe de suporte, implementado com o SDK legítimo Easemob HelpDesk, o manipulador solicita acesso à galeria de imagens do dispositivo. Se a flag pw no objeto mencionado anteriormente estiver configurado com o valor 1, o módulo continuará solicitando acesso caso a permissão seja negada. A justificativa para a solicitação do SDK parece lógica a princípio: os usuários podem anexar imagens ao entrar em contato com o suporte.

Se o acesso for concedido, o SDK executa sua funcionalidade principal. Isso começa com o envio de uma requisição para /api/e/config/rekognition no C2 e o recebimento de parâmetros para processamento dos resultados do OCR como resposta.

Esses parâmetros são usados por classes de processamento que filtram imagens com base nas palavras reconhecidas pelo OCR. O malware também solicita uma lista de palavras-chave em /api/e/config/keyword para o KeywordsProcessor, que usa essas palavras para selecionar imagens a serem enviadas ao servidor C2.

Além do KeywordsProcessor, o malware contém outros dois processadores: DictProcessor e WordNumProcessor. O primeiro filtra imagens usando dicionários localizados armazenados e descriptografados dentro de rapp.binary nos ativos, e o segundo filtra palavras por comprimento. Os parâmetros letterMin e letterMax para cada processo definem o intervalo permitido de comprimento das palavras. Para DictProcessor, o parâmetro wordlistMatchMin estabelece um limite mínimo para o número de correspondências de palavras de dicionário em uma imagem. Para WordNumProcessor, wordMin e wordMax definem o intervalo aceitável para o número total de palavras reconhecidas. O campo rs na resposta à solicitação de registro de um dispositivo com infecção controla qual processador será usado.

As imagens que correspondem aos critérios de pesquisa são baixadas do dispositivo em três etapas. Primeiro, uma requisição contendo o hash MD5 da imagem é enviada para /api/e/img/uploadedCheck no C2. Depois disso, a imagem é enviada ao armazenamento em nuvem da Amazon ou em file@/api/res/send no servidor “rust”. A seguir, um link para a imagem é enviado em /api/e/img/rekognition ao C2. Portanto, o SDK, que aparentemente foi desenvolvido para análise conforme sugere o nome do pacote com.spark.stat, é na verdade um malware que seletivamente rouba o conteúdo da galeria.

Tentamos entender que tipo de imagens os atacantes estavam procurando. Para descobrir, solicitamos aos servidores C2 uma lista de palavras-chave para pesquisa baseada em OCR. Em cada caso, recebemos palavras em chinês, japonês, coreano, inglês, tcheco, francês, italiano, polonês e português. Todos os termos indicavam que os atacantes tinham motivações financeiras, com foco específico em frases de recuperação (também conhecidas como “mnemônicos”) que podem ser usadas para recuperar o acesso a carteiras de criptomoedas.

Infelizmente, o ComeCome não foi o único aplicativo em que encontramos conteúdo malicioso integrado. Descobrimos vários outros aplicativos não relacionados, com diferentes temas. Juntos, esses aplicativos já haviam sido instalados mais de 242 mil vezes até o momento em que este artigo foi escrito, e alguns ainda estavam acessíveis no Google Play. Um inventário completo pode ser encontrado na seção Indicadores de Comprometimento. Alertamos o Google sobre a presença de aplicativos infectados em sua loja.

Além disso, nossa telemetria mostrou que aplicativos maliciosos também estavam sendo distribuídos por canais não oficiais.

Os recursos do SDK podem variar um pouco de aplicativo para aplicativo. Enquanto o malware no ComeCome solicitava permissões apenas quando o usuário abria o chat de suporte, em alguns outros casos, o lançamento da funcionalidade principal agia como gatilho.

Um pequeno detalhe…

Ao analisarmos os aplicativos Android infectados com o trojan, observamos que o SDK definia o campo deviceType como “android” nas informações do dispositivo enviadas ao C2, sugerindo a existência de um trojan semelhante para outras plataformas.

Uma investigação posterior revelou aplicativos maliciosos na App Store, infectados com um framework que continha o mesmo trojan. Por exemplo, o ComeCome para iOS foi infectado da mesma forma que sua versão para Android. Este é o primeiro caso conhecido de um aplicativo infectado com um spyware que usa OCR encontrado na loja oficial da Apple.

Frameworks maliciosos em aplicativos da App Store

Detectamos uma série de aplicativos com um framework malicioso integrado na App Store. Não podemos confirmar com certeza se a infecção foi resultado de um ataque à cadeia de suprimentos ou de uma ação deliberada dos desenvolvedores. Alguns dos aplicativos, como serviços de entrega de comida, pareciam ser legítimos, enquanto outros aparentemente foram criados para atrair vítimas. Por exemplo, vimos vários “aplicativos de mensagens” semelhantes com recursos de IA do mesmo desenvolvedor:

Além do próprio framework malicioso, alguns dos aplicativos infectados continham um script modify_gzip.rb na pasta raiz. Aparentemente, ele foi usado pelos desenvolvedores para integrar o framework no aplicativo:

O framework em si foi escrito em Objective-C e ofuscado com a ferramenta HikariLLVM. Nos aplicativos que detectamos, ele tinha um dos três nomes:

1. GZIP;
2. googleappsdk;
3. stat.

Assim como a versão específica para Android, o malware para iOS utilizava a interface do ML Kit, que fornecia acesso a um modelo de OCR do Google treinado para reconhecer texto, além de uma biblioteca em Rust que implementava um protocolo personalizado de comunicação C2. Entretanto, neste caso, ele foi integrado diretamente no executável malicioso. Diferente da versão para Android, o framework do iOS preserva os símbolos de depuração, permitindo a identificação de vários detalhes específicos:

• as linhas revelam os caminhos no dispositivo dos criadores do framework onde o projeto estava armazenado, incluindo os nomes de usuário:
  • /Users/qiongwu/: o diretório inicial do autor do projeto
  • /Users/quiwengjing/: o diretório inicial do criador da biblioteca Rust
• O módulo de comunicação C2-rust foi denominado im_net_sys. Além do cliente, ele contém código que o servidor dos atacantes provavelmente usa para se comunicar com as vítimas.
• O nome original do projeto é GZIP.

O framework contém várias classes maliciosas. As seguintes são especialmente relevantes:

• MMMaker: baixa uma configuração e coleta informações sobre o dispositivo.
• ApiMgr: envia dados do dispositivo.
• PhotoMgr: pesquisa fotos contendo palavras-chave no dispositivo e as envia ao servidor.
• MMCore: armazena informações sobre a sessão C2.
• MMLocationMgr: coleta a localização atual do dispositivo. Durante nossos testes, não enviou nenhum dado, portanto, o propósito exato dessa classe permaneceu indefinido.

Algumas classes, como a MMMaker, podem estar ausentes ou ter um nome diferente em versões anteriores do framework, mas isso não alterava a funcionalidade principal do malware.

A ofuscação complica significativamente a análise estática de amostras, pois as strings são criptografadas e o fluxo de controle do programa fica obscurecido. Para descriptografar rapidamente as strings de interesse, optamos pela análise dinâmica. Executamos o aplicativo usando o Frida e capturamos um dump da seção _data onde essas strings estavam armazenadas. O que chamou nossa atenção foi o fato de que o bundleID do aplicativo estava entre os dados descriptografados:

Conforme descobrimos, o framework também guardava outros identificadores de bundle de aplicativos utilizados no seletor +[MMCore config].

im.pop.app.iOS.Messenger	com.hkatv.ios	com.atvnewsonline.app
io.zorixchange	com.yykc.vpnjsq	com.llyy.au
com.star.har91vnlive	com.jhgj.jinhulalaab	com.qingwa.qingwa888lalaaa
com.blockchain.uttool	com.wukongwaimai.client	com.unicornsoft.unicornhttpsforios
staffs.mil.CoinPark	com.lc.btdj	com.baijia.waimai
com.ctc.jirepaidui	com.ai.gbet	app.nicegram
com.blockchain.ogiut	com.blockchain.98ut	com.dream.towncn
com.mjb.Hardwood.Test	com.galaxy666888.ios	njiujiu.vpntest
com.qqt.jykj	com.ai.sport	com.feidu.pay
app.ikun277.test	com.usdtone.usdtoneApp2	com.cgapp2.wallet0
com.bbydqb	com.yz.Byteswap.native	jiujiu.vpntest
com.wetink.chat	com.websea.exchange	com.customize.authenticator
im.token.app	com.mjb.WorldMiner.new	com.kh-super.ios.superapp
com.thedgptai.event	com.yz.Eternal.new	xyz.starohm.chat
com.crownplay.luckyaddress1

Nossas conclusões são as seguintes:

1. o trojan pode se comportar de maneira diferente dependendo do aplicativo em que está sendo executado.
2. Há mais aplicativos potencialmente infectados do que pensávamos inicialmente.

Alguns dos aplicativos associados a essas IDs foram removidos da App Store no momento da investigação, enquanto outros ainda estavam lá e continham código malicioso. Alguns dos IDs da lista se referiam a aplicativos que não continham o framework malicioso no momento desta investigação:

• com.kh-super.ios.superapp
• im.token.app
• com.unicornsoft.unicornhttpsforios
• com.hkatv.ios

Tal como na versão para Android, o trojan implementa três modos de filtragem da saída do OCR: palavras-chave, comprimento das palavras e dicionários localizados, que são armazenados de forma criptografada dentro do próprio framework, numa pasta chamada “wordlists”. Infelizmente, não conseguimos confirmar se o malware de fato fazia uso do último método. Nenhuma das amostras que analisamos continha links para os dicionários ou os acessava durante a execução.

O envio de fotos selecionadas contendo palavras-chave é uma etapa fundamental na operação do framework malicioso. Semelhante ao aplicativo para Android, o trojan solicita permissão para acessar a galeria apenas ao iniciar o View Controller responsável por exibir o chat de suporte. Na etapa de inicialização, o trojan, dependendo do aplicativo em que está sendo executado, substitui o método viewDidLoad ou viewWillAppear no controlador correspondente por seu próprio wrapper, que chama o método +[PhotoMgr startTask:]. Esse último verifica se o aplicativo tem acesso à galeria e solicita permissão, se necessário. Em seguida, caso o acesso seja concedido, o PhotoMgr pesquisa fotos que atendam aos critérios de envio entre aquelas disponíveis e que ainda não tenham sido processadas.

Embora tenham sido necessárias várias tentativas, conseguimos fazer com que o aplicativo enviasse uma foto a nuvem da Amazon e, em seguida, transmitisse informações sobre ela para o servidor dos atacantes. O aplicativo utilizava HTTPS para se comunicar com o servidor, e não o protocolo personalizado “rust”:

Os dados enviados têm o seguinte formato:

A versão mais antiga do framework malicioso que estávamos investigando foi criada em 15 de março de 2024. Embora não seja significativamente diferente das versões mais recentes, essa contém mais strings não criptografadas, incluindo endpoints de API e um único endereço C2 codificado diretamente. As respostas do servidor são recebidas em texto simples.

Recursos da campanha

Ao analisar os aplicativos Android, descobrimos que o código do processador de texto continha comentários em chinês. As descrições de erros retornadas pelo servidor C2 em resposta a requisições malformadas também estavam em chinês. Esses fatos, juntamente com o nome do diretório inicial do desenvolvedor do framework, que obtivemos ao analisar a versão específica para iOS, sugerem que o criador do módulo malicioso é fluente em chinês. Dito isso, não temos dados suficientes para atribuir a campanha a um grupo conhecido de cibercriminosos.

Nossa investigação revelou que os atacantes tinham como alvo frases de recuperação de carteiras de criptomoedas, que eram suficientes para obter controle total sobre a carteira de criptomoedas da vítima e roubar os fundos. É importante destacar que o malware é suficientemente flexível para roubar não apenas essas frases, mas também outros dados sensíveis da galeria, como mensagens ou senhas que possam ter sido obtidas em capturas de tela. Vários modos de processamento dos resultados do OCR reduzem os impactos de erros do modelo que poderiam comprometer o reconhecimento das imagens das frases de recuperação de acesso, caso fosse usado apenas o processamento por palavras-chave.

Nossa análise do código malicioso Rust dentro dos frameworks do iOS revelou código cliente para comunicação com o servidor “rust” e os componentes de criptografia do lado do servidor. Isso sugere que os servidores dos atacantes provavelmente também usam Rust para o gerenciamento do protocolo.

Acreditamos que essa campanha esteja, no mínimo, direcionada a usuários de Android e iOS na Europa e na Ásia, conforme indicado pelo seguinte:

• as palavras-chave usadas estavam em diversos idiomas nativos de países europeus e asiáticos.
• Os dicionários nos ativos também foram adaptados para os mesmos idiomas.
• Alguns dos aplicativos aparentemente operam em diversos países. Alguns apps de entrega de comida possibilitam o cadastro com números de telefone dos Emirados Árabes Unidos, Cazaquistão, China, Indonésia, Zimbábue e outros países.

Suspeitamos que usuários de dispositivos móveis de outras regiões além da Europa e Ásia também possam ter sido alvos dessa campanha maliciosa.
Um dos primeiros módulos maliciosos com os quais iniciamos nossa investigação era chamado “Spark”. O ID do pacote do próprio framework malicioso, “bigCat.GZIPApp”, chamou nossa atenção quando analisamos o trojan específico para iOS. Daí o nome “SparkCat”. A seguir estão algumas das características desse malware:

• сompatibilidade entre plataformas;
• uso da linguagem de programação Rust, raramente encontrada em aplicativos móveis;
• marketplaces oficiais de aplicativos como vetor de propagação;
• furtividade, com domínios de C2 frequentemente imitando serviços legítimos e frameworks maliciosos disfarçados como pacotes do sistema;
• ofuscação, que dificulta a análise e a detecção.

Conclusão

Infelizmente, apesar da rigorosa triagem dos marketplaces oficiais e da conscientização geral sobre golpes envolvendo roubo de carteiras de criptomoedas utilizando OCR, os aplicativos infectados ainda conseguiram chegar ao Google Play e à App Store. O que torna esse trojan particularmente perigoso é que não há indicação de um implante malicioso oculto no aplicativo. As permissões solicitadas podem parecer necessárias para sua funcionalidade principal ou parecer inofensivas à primeira vista. O malware também funciona de forma bastante furtiva. Este caso mais uma vez derruba o mito de que o iOS é, de alguma forma, imune às ameaças representadas por aplicativos maliciosos que têm como alvo o Android. Aqui estão algumas dicas que podem ajudar você a evitar se tornar vítima desse malware:

• Se você tiver algum dos aplicativos infectados instalado no seu dispositivo, remova-o e evite reinstalá-lo até que uma correção seja lançada.
• Evite armazenar na galeria capturas de tela com informações sensíveis, como frases de recuperação de carteiras de criptomoedas. Você pode armazenar senhas, documentos confidenciais e outras informações sigilosas em aplicativos especiais.
• Use um produto de segurança robusto em todos os seus dispositivos.

Nossos produtos de segurança apresentam os seguintes alertas ao detectar malware associado a essa campanha:

• HEUR:Trojan.IphoneOS.SparkCat.*
• HEUR:Trojan.AndroidOS.SparkCat.*

Indicadores de comprometimento

Aplicativos Android infectados
0ff6a5a204c60ae5e2c919ac39898d4f
21bf5e05e53c0904b577b9d00588e0e7
a4a6d233c677deb862d284e1453eeafb
66b819e02776cb0b0f668d8f4f9a71fd
f28f4fd4a72f7aab8430f8bc91e8acba
51cb671292eeea2cb2a9cc35f2913aa3
00ed27c35b2c53d853fafe71e63339ed
7ac98ca66ed2f131049a41f4447702cd
6a49749e64eb735be32544eab5a6452d
10c9dcabf0a7ed8b8404cd6b56012ae4
24db4778e905f12f011d13c7fb6cebde
4ee16c54b6c4299a5dfbc8cf91913ea3
a8cd933b1cb4a6cae3f486303b8ab20a
ee714946a8af117338b08550febcd0a9
0b4ae281936676451407959ec1745d93
f99252b23f42b9b054b7233930532fcd
21bf5e05e53c0904b577b9d00588e0e7
eea5800f12dd841b73e92d15e48b2b71

MD5s do framework do iOS:
35fce37ae2b84a69ceb7bbd51163ca8a
cd6b80de848893722fa11133cbacd052
6a9c0474cc5e0b8a9b1e3baed5a26893
bbcbf5f3119648466c1300c3c51a1c77
fe175909ac6f3c1cce3bc8161808d8b7
31ebf99e55617a6ca5ab8e77dfd75456
02646d3192e3826dd3a71be43d8d2a9e
1e14de6de709e4bf0e954100f8b4796b
54ac7ae8ace37904dcd61f74a7ff0d42
caf92da1d0ff6f8251991d38a840fb4a
db128221836b9c0175a249c7f567f620

Configuração de trojan no GitLab
hxxps://gitlab[.]com/group6815923/ai/-/raw/main/rel.json
hxxps://gitlab[.]com/group6815923/kz/-/raw/main/rel.json

C2
api.firebaseo[.]com
api.aliyung[.]com
api.aliyung[.]org
uploads.99ai[.]world
socket.99ai[.]world
api.googleapps[.]top
Armazenamento de fotos
hxxps://dmbucket102.s3.ap-northeast-1.amazonaws[.]com

Nomes de APKs Android infectados no Google Play
com.crownplay.vanity.address
com.atvnewsonline.app
com.bintiger.mall.android
com.websea.exchange
org.safew.messenger
org.safew.messenger.store
com.tonghui.paybank
com.bs.feifubao
com.sapp.chatai
com.sapp.starcoin
BundleIDs dos aplicativos iOS infectados na App Store
com.atvnewsonline.app
com.wukongwaimai.client
com.lc.btdj
com.feidu.pay
com.wetink.chat
com.websea.exchange
xyz.starohm.chat
com.crownplay.luckyaddress1
com.safew.messenger
com.thpay.bank
io.aicean.chat