Dropper publicado na loja oficial alternava comportamento após a aprovação, buscava configuração em Firebase e instalava payloads externos hospedados em GitHub.
| Componente | Aplicativos Android publicados no Google Play com o dropper Clast82, incluindo um caso identificado como CakeVPN. |
| Vetor | Aplicativos baseados em projetos Android legítimos recebiam configuração de um Firebase C2 e baixavam payloads externos a partir de repositórios GitHub controlados pelo operador. |
| Impacto | Instalação de AlienBot Banker e MRAT, com capacidade de injetar código em aplicativos financeiros, capturar credenciais e códigos 2FA e ampliar o controle remoto sobre o dispositivo. |
| Prioridade | Inventariar dispositivos Android que instalaram os aplicativos removidos, revisar permissões de instalação por origens desconhecidas, procurar tráfego para Firebase e GitHub usado como entrega de payload e remover os pacotes afetados. |
| Artefatos | Foram identificados mais de 100 payloads únicos associados ao AlienBot na campanha. |
| Mitigação | O Google confirmou em 9 de fevereiro a remoção de todos os aplicativos Clast82 da Google Play Store. |
Clast82 foi observado como um dropper Android distribuído pela Google Play Store para entregar duas cargas maliciosas: AlienBot Banker e MRAT. A relevância técnica do caso está no abuso de um canal oficial de distribuição combinado com mudança de comportamento após a fase de avaliação. Durante a análise da loja, o aplicativo conseguia permanecer sem acionar a rotina maliciosa principal; depois da publicação, o operador podia alterar um parâmetro remoto e ativar a cadeia de download e instalação do payload real. Esse desenho reduz a utilidade de uma inspeção pontual feita apenas antes da aprovação, porque a lógica decisiva ficava dependente de configuração externa.
O AlienBot é descrito como uma família de Malware-as-a-Service para Android com foco bancário. Sua função inicial é permitir que um operador remoto injete código malicioso em aplicativos financeiros legítimos, criando uma superfície para captura de credenciais e códigos de autenticação de dois fatores. Após assumir maior controle do dispositivo, o operador também poderia acionar funções como instalação de outro aplicativo e controle por ferramentas remotas, incluindo o uso de TeamViewer conforme observado no material técnico. O MRAT aparece como outra carga instalada pela mesma cadeia, compondo um cenário em que o dropper serve menos como malware final e mais como mecanismo de entrega, ativação e persistência operacional da campanha.
A campanha também mostra uma separação deliberada entre loja, configuração e payload. O aplicativo publicado no Google Play carregava a lógica do dropper, mas a carga maliciosa final não vinha diretamente do pacote submetido à revisão. A configuração era obtida de um banco Firebase em tempo real, enquanto o caminho do payload apontava para GitHub. Para cada aplicativo, o operador criou um novo usuário de desenvolvedor na loja e um repositório correspondente, permitindo distribuir payloads diferentes para dispositivos infectados por aplicativos distintos. Essa segmentação dificulta correlação simples entre pacotes e artefatos finais e reforça a necessidade de telemetria em endpoint, rede e comportamento de instalação.
O mecanismo de evasão de Clast82 dependia de um parâmetro chamado enable, recebido da infraestrutura Firebase usada como C2. Durante o período de avaliação na Google Play, esse parâmetro permanecia em false, impedindo que o comportamento malicioso fosse acionado no momento em que o aplicativo era analisado. Após a publicação do aplicativo, o parâmetro podia ser alterado para true, habilitando a sequência de dropper. O ponto crítico não é uma exploração de vulnerabilidade no Android, mas uma decisão lógica remota: o pacote aparentava ter uma função legítima, aguardava uma condição externa e só então seguia para a etapa de entrega do payload.
No caso citado como paciente zero, o aplicativo CakeVPN foi construído a partir de um projeto Android legítimo de código aberto, ao qual o operador adicionou código malicioso. A função aparente dava ao usuário uma justificativa para instalar o aplicativo, enquanto a execução real passava pela MainActivity, que iniciava um serviço e chamava o fluxo de dropper associado a LoaderService. O aplicativo também criava um serviço em primeiro plano para executar a tarefa de entrega. Como o Android exige uma notificação contínua para serviços desse tipo, o dropper apresentava uma notificação neutra com o texto GooglePlayServices, sem conteúdo adicional, reduzindo a chance de o usuário associar a atividade ao aplicativo recém-instalado.
A cadeia de instalação começa quando o serviço em primeiro plano registra um listener para o banco Firebase em tempo real. A partir dali, recebe o caminho do payload hospedado em GitHub e aciona a função loadAndInstallApp, responsável por buscar a carga externa. Em seguida, o método installApp finaliza a etapa de instalação. Quando o dispositivo bloqueava instalações por origens desconhecidas, Clast82 insistia em uma solicitação falsa atribuída a Google Play Services, tentando convencer o usuário a permitir a instalação. O material analisado informa que essa solicitação era reapresentada a cada cinco segundos, comportamento importante para detecção por UX, EDR móvel e análise comportamental.
Depois que a carga maliciosa era instalada com sucesso, o dropper iniciava o payload baixado. Foram identificados mais de 100 payloads únicos de AlienBot associados à campanha, o que indica rotação ou segmentação operacional, e não uma entrega única estática. Essa arquitetura permite que o operador substitua cargas, direcione variantes por aplicativo ou mantenha diferentes linhas de entrega sem republicar o pacote inicial na loja. Para defesa, o detalhe mais importante é que a ausência do payload no pacote original não reduz o risco: o aplicativo aprovado funcionava como ponte para buscar artefatos externos assim que a configuração remota autorizava a execução.
A superfície principal envolve dispositivos Android que instalaram aplicativos contendo Clast82 a partir da Google Play Store antes da remoção confirmada. O risco não se limita a usuários que habilitaram manualmente origens desconhecidas antes da infecção, porque o dropper incluía uma etapa de engenharia de permissão para induzir essa autorização durante a execução. Ambientes corporativos com política permissiva de instalação, ausência de controle MDM ou baixa visibilidade de tráfego de aplicativos móveis ficavam mais expostos ao fluxo completo, especialmente quando o usuário aceitava a solicitação apresentada como se viesse de um componente do Google.
O uso de aplicativos legítimos de código aberto como base ampliava a plausibilidade do pacote. Em vez de distribuir um aplicativo claramente malicioso, o operador incorporava a lógica de dropper a aplicativos que ofereciam alguma funcionalidade esperada, como no exemplo do CakeVPN. Essa estratégia complica a análise superficial baseada apenas em nome, categoria ou aparência do aplicativo. O risco se concentra em três camadas: o pacote instalado da loja, os serviços Android acionados em segundo plano e a comunicação externa com Firebase e GitHub para receber parâmetros e payloads.
Como as cargas instaladas incluíam AlienBot Banker, a superfície de impacto também alcança aplicativos financeiros presentes no dispositivo da vítima. O malware foi descrito como capaz de injetar código em aplicações bancárias legítimas e capturar credenciais e códigos de autenticação de dois fatores. Isso não significa que todos os dispositivos infectados tenham necessariamente sofrido fraude ou tomada completa de conta, mas estabelece o risco técnico confirmado da família entregue pelo dropper. O MRAT adiciona outra dimensão de controle remoto, ampliando o conjunto de ações possíveis após a instalação da carga.
Em 9 de fevereiro, todos os aplicativos Clast82 foram confirmados como removidos da Google Play Store. A remoção da loja reduz novas instalações por aquele canal, mas não limpa automaticamente dispositivos que já haviam instalado os pacotes nem elimina payloads entregues fora da loja. Por isso, a superfície residual deve ser tratada no endpoint: inventário de pacotes, estado de permissões, presença de aplicativos desconhecidos instalados por fora da loja e sinais de comunicação com infraestrutura usada no fluxo de entrega.
- Dispositivos Android que instalaram aplicativos Clast82 antes da remoção da Google Play Store.
- Aplicativos com serviços em primeiro plano exibindo notificação neutra como
GooglePlayServices. - Ambientes em que usuários podem autorizar instalação por origens desconhecidas sem controle centralizado.
- Aparelhos com aplicativos financeiros usados no mesmo perfil Android em que AlienBot foi instalado.
A caça deve começar pela linha do tempo de instalação de aplicativos Android. O sinal mais forte é a presença de pacotes instalados a partir da loja oficial que, após a primeira execução, tentaram iniciar serviços em primeiro plano e acionar instalação de outro aplicativo externo. Em MDM, EDR móvel ou logs do próprio Android, procure eventos de criação de serviço associados à atividade de instalação, mudanças de permissão para origens desconhecidas e abertura repetitiva de telas de autorização. A repetição da solicitação falsa atribuída a Google Play Services é um indício comportamental relevante porque cria uma sequência anormal de interação com o usuário.
Na camada de rede, a investigação deve correlacionar o aplicativo suspeito com acesso a Firebase em tempo real e GitHub usado como hospedagem de payload. O uso dessas plataformas não é malicioso por si só, mas a combinação de um aplicativo recém-instalado, listener persistente para configuração remota, recebimento de caminho de payload e download de APK externo forma um padrão de alto risco. Em ambientes corporativos, proxies móveis, DNS, CASB, EDR de Android e logs de firewall devem ser consultados para identificar conexões iniciadas pelo pacote suspeito logo após a execução do aplicativo.
No endpoint, busque artefatos de instalação de payload que não tenham origem direta na Google Play Store. O fluxo descrito chama funções internas identificadas como loadAndInstallApp e installApp, então a análise reversa de pacotes suspeitos deve priorizar chamadas relacionadas a download, instalação de APK e registro de listeners em Firebase. Como mais de 100 payloads únicos de AlienBot foram identificados, a defesa não deve depender apenas de um hash específico. O melhor resultado vem da combinação entre comportamento de dropper, permissões solicitadas, origem de download, pacote filho instalado e atividade posterior em aplicativos financeiros.
Indicadores estáticos podem ajudar na triagem, mas não devem ser o único critério. O contexto técnico inclui dois hashes associados à campanha, porém a rotação de payloads reduz a cobertura de uma lista curta. Para evitar exposição desnecessária de indicadores operacionais e manter o uso defensivo, a recomendação é tratar os hashes como pontos de pivote internos em ferramentas de EDR e inteligência, sem transformar a resposta em uma lista extensa de artefatos. O mesmo raciocínio vale para domínios e caminhos: priorize classes de tráfego, relação entre pacote e destino e sequência temporal de instalação.
- Aplicativo da loja iniciando serviço em primeiro plano e exibindo notificação neutra com aparência de componente do Google.
- Conexões do pacote suspeito para Firebase em tempo real antes do download de payload externo.
- Download de APK a partir de GitHub seguido por tentativa de instalação fora do fluxo normal da loja.
- Solicitações repetidas para permitir instalação por origens desconhecidas, apresentadas como se fossem do
Google Play Services. - Instalação de payload adicional e abertura imediata desse payload após conclusão do dropper.
- Atividade anormal envolvendo aplicativos financeiros após instalação de AlienBot Banker.
A resposta deve separar remoção da loja, limpeza do dispositivo e redução de exposição futura. A confirmação de que os aplicativos Clast82 foram removidos da Google Play Store em 9 de fevereiro impede novas instalações por aquele caminho, mas dispositivos já afetados precisam ser tratados individualmente. O primeiro passo defensivo é inventariar os aparelhos Android gerenciados, localizar pacotes relacionados à campanha, remover o aplicativo dropper e verificar se payloads adicionais foram instalados depois da primeira execução. Em dispositivos com suspeita de AlienBot ou MRAT, a simples exclusão do aplicativo inicial pode deixar a carga final ativa.
Em seguida, revise permissões e configurações de instalação. A cadeia dependia de induzir o usuário a permitir instalação por origens desconhecidas; portanto, essa permissão deve ser bloqueada por política sempre que possível, ou pelo menos monitorada quando alterada. Organizações com MDM devem impor instalação apenas por fontes aprovadas, restringir sideloading, registrar mudanças de permissões sensíveis e exigir aprovação administrativa para aplicativos que solicitem instalar outros pacotes. Usuários afetados devem trocar credenciais de contas financeiras e revisar mecanismos de autenticação apenas depois que o dispositivo for considerado limpo, porque uma troca feita em aparelho ainda comprometido pode expor novos segredos.
A mitigação técnica também deve incluir controles de rede e comportamento. Bloquear genericamente Firebase ou GitHub pode quebrar aplicações legítimas, então a medida mais prática é monitorar padrões de uso incomuns por aplicativos móveis, especialmente quando um pacote recém-instalado usa essas plataformas para recuperar caminhos de APK. Em ambientes corporativos, políticas de acesso condicional podem negar sessões financeiras ou sensíveis vindas de dispositivos sem conformidade, sem agente de segurança móvel ou com permissão de sideload habilitada. Para casos em que o dispositivo já apresenta sinais de MRAT, a contenção deve considerar isolamento do aparelho, coleta de evidências e restauração controlada.
Por fim, a prevenção precisa incorporar avaliação contínua pós-instalação. O caso de Clast82 mostra que análise pré-publicação não cobre campanhas que aguardam aprovação para ativar payloads por configuração remota. Defesas móveis devem observar comportamento por aplicativo ao longo do tempo: serviços em primeiro plano, downloads de APK, chamadas a instaladores, mudanças de permissão, comunicação com C2 e interação com aplicativos financeiros. O objetivo é detectar a transição de um aplicativo aparentemente legítimo para um dropper ativo, antes que a carga bancária ou de acesso remoto consiga operar com credenciais, códigos 2FA ou controle direto do dispositivo.
- Remover aplicativos Clast82 identificados e verificar se payloads adicionais foram instalados depois da execução inicial.
- Bloquear ou restringir instalação por origens desconhecidas em dispositivos corporativos Android.
- Correlacionar instalação de aplicativo, criação de serviço em primeiro plano, conexão com Firebase e download de APK externo.
- Aplicar MDM ou segurança móvel com monitoramento contínuo de comportamento, rede e permissões por aplicativo.
- Revisar credenciais e autenticação de contas financeiras somente após a limpeza ou substituição do dispositivo suspeito.
- Usar indicadores estáticos apenas como apoio, mantendo a detecção centrada no fluxo de dropper e na instalação externa de payload.
0 Comentários