O malware móvel infectou 14 milhões de aparelhos Android, obteve root em cerca de 8 milhões e abusou do Zygote para controlar atividades de aplicativos e desviar receita de anúncios.
| Componente | Dispositivos Android, processo Zygote, processo system_server, gerenciador de pacotes e fluxo install_referrer do Google Play. |
| Vetor | Aplicativos populares reempacotados com o malware e distribuídos por lojas de terceiros, além de golpes de phishing; não houve evidência de distribuição pelo Google Play. |
| Impacto | 14 milhões de dispositivos infectados, cerca de 8 milhões com root, quase 100 milhões de anúncios fraudulentos exibidos e receita estimada em aproximadamente US$ 1,5 milhão. |
| Prioridade | Identificar dispositivos Android 5 ou anteriores sem correções, remover aplicativos fora de lojas confiáveis, revisar sinais de root não autorizado e bloquear comunicação com infraestrutura de comando e controle conhecida internamente. |
| Versões | Exploração voltada a Android 5 e versões anteriores, usando falhas antigas como CVE-2014-4321, CVE-2014-4324, CVE-2013-6282, CVE-2015-3636 e CVE-2014-3153. |
| Artefatos | Pacote de atualização baixado de bucket S3, instalação persistente em diretório de sistema, uso de /system/app, /data/app, Zygote, system_server e substituição de IDs de referência. |
CopyCat foi uma campanha de malware móvel voltada a Android que combinou exploração local, persistência em área de sistema e fraude publicitária em grande escala. A operação infectou 14 milhões de dispositivos no mundo, obteve privilégios de root em cerca de 8 milhões deles e usou esse controle para manipular fluxos de anúncios, instalações de aplicativos e atribuição de receita. A atividade teve pico entre abril e maio de 2016, com concentração de vítimas no Sudeste Asiático, mas também alcançou mais de 280 mil usuários nos Estados Unidos. A escala da campanha mostra que adware com capacidade de root deve ser tratado como malware de alto impacto, não como simples incômodo visual.
O ponto técnico mais relevante é o abuso do Zygote, daemon responsável por iniciar aplicativos no Android. Ao injetar código nesse processo, o malware passou a influenciar atividades de aplicativos lançados no dispositivo. Depois disso, também interagiu com o system_server, que concentra serviços centrais do sistema operacional, incluindo componentes associados a telefonia, gerenciamento de pacotes e atividades. Essa posição permitiu que o operador exibisse anúncios fraudulentos de forma difícil de atribuir a um aplicativo específico, interceptasse fluxos relacionados ao Google Play e substituísse identificadores de referência por valores controlados pela campanha.
A monetização ocorreu por três caminhos principais. Uma parte dos dispositivos exibiu anúncios fraudulentos, outra foi usada para desviar crédito de instalações feitas pelo usuário no Google Play, e um módulo separado instalou aplicativos fraudulentos diretamente no aparelho com apoio dos privilégios de root. A estimativa de receita total ultrapassou US$ 1,5 milhão em dois meses, incluindo aproximadamente US$ 120 mil associados a quase 100 milhões de anúncios exibidos, mais de US$ 660 mil por crédito fraudulento em instalações e mais de US$ 735 mil em 4,9 milhões de instalações fraudulentas conduzidas pelo próprio malware.
A infecção começava com a instalação de um aplicativo reempacotado ou obtido por meio de engenharia social. O malware não iniciava imediatamente sua atividade mais visível; ele aguardava a reinicialização do dispositivo, reduzindo a associação direta entre o aplicativo recém-instalado e os comportamentos maliciosos subsequentes. Após o reinício, baixava um pacote de atualização de um bucket S3. Esse pacote continha seis exploits comuns, usados para tentar obter root no aparelho. A lista de falhas exploradas incluía vulnerabilidades antigas do ecossistema Android, como CVE-2014-4321, CVE-2014-4324, CVE-2013-6282, CVE-2015-3636 e CVE-2014-3153.
Quando a etapa de root era bem-sucedida, CopyCat instalava outro componente no diretório de sistema, criando persistência mais resistente à remoção comum pelo usuário. Essa persistência era crítica para manter controle após reinicializações e para sustentar a injeção nos processos centrais do Android. O índice de sucesso relatado foi incomum para uma campanha desse tipo: 54% dos dispositivos infectados foram enraizados. A eficácia se explica menos por novidade das falhas e mais pela presença de aparelhos sem correções, especialmente em versões Android 5 e anteriores, onde exploits antigos ainda eram viáveis.
A injeção no Zygote ampliava a visibilidade do malware sobre aplicativos lançados no dispositivo. Em seguida, a atuação no system_server permitia registrar eventos e observar mudanças de atividade. Para exibir anúncios, o malware avaliava condições como localização do usuário, aplicativo em execução e intervalo desde a última exibição. Ele evitava interferir em aplicativos populares predefinidos, como Facebook e WhatsApp, para reduzir suspeita do usuário. Quando as condições favoreciam a fraude, acionava bibliotecas de anúncios associadas a redes como Facebook, AdMob ou UC, ocultando a origem do pop-up e dificultando a identificação do aplicativo responsável.
O desvio de receita por referência explorava o momento em que o usuário navegava no Google Play. O malware monitorava a abertura do processo, coletava o nome do pacote visualizado e consultava o servidor de comando e controle para obter um identificador de referência ligado ao operador. Em seguida, bloqueava intents de install_referrer e os substituía pelo identificador recebido. Assim, uma instalação legítima feita pelo usuário podia ser contabilizada como se tivesse sido originada pela campanha maliciosa. A terceira técnica, baseada em instalação direta de APKs, aproveitava o comportamento do gerenciador de pacotes ao observar diretórios como /system/app e /data/app, onde a presença de arquivos APK pode levar à instalação pelo sistema.
A superfície principal eram dispositivos Android com correções antigas, especialmente Android 5 e anteriores, expostos a aplicativos fora de canais confiáveis. O contexto não indica distribuição pelo Google Play; a campanha foi associada a aplicativos populares reempacotados em lojas de terceiros e a phishing. Isso desloca a prioridade defensiva para controle de origem de aplicativos, políticas de instalação, inventário de versões e capacidade de detectar root não autorizado em dispositivos pessoais ou corporativos. Em ambientes empresariais, o risco aumenta quando aparelhos comprometidos têm acesso a e-mail, VPN, redes Wi-Fi internas ou aplicações corporativas.
O malware também armazenava informações sobre os dispositivos infectados em servidores de comando e controle, incluindo marca, modelo, versão do sistema operacional e país. Esses dados não equivalem, por si só, a roubo de credenciais ou exfiltração de conteúdo sensível, mas permitem segmentação, medição da campanha e escolha de comportamento por região ou versão. A operação também evitava atingir dispositivos na China, característica descrita como possível tentativa de reduzir atenção local. Há conexões técnicas com MobiSummer, incluindo servidor compartilhado com atividades da empresa, código assinado e serviços remotos criados por ela, mas a autoria não foi confirmada; o uso de código ou infraestrutura por terceiros permanece uma hipótese possível.
Para defesa, o ponto crítico é não tratar fraude de anúncios como evento isolado de navegador. No caso CopyCat, a fraude era consequência de comprometimento profundo do sistema operacional. Um aparelho com root não autorizado perde garantias importantes de isolamento, integridade de aplicativos e controle de permissões. Em uma frota corporativa, esse estado deve acionar quarentena, revogação de confiança do dispositivo, revisão de sessões e validação de aplicativos instalados.
- Dispositivos Android 5 ou anteriores, principalmente quando sem nível recente de correção de segurança.
- Aparelhos que permitem instalação por fontes desconhecidas ou uso frequente de lojas de terceiros.
- Aplicativos reempacotados que imitam programas populares e passam a executar comportamento após reinicialização.
- Ambientes corporativos que aceitam dispositivos móveis sem verificação de integridade, root e postura de segurança.
A investigação deve começar pela postura do dispositivo: versão do Android, nível de patch, origem dos aplicativos, presença de root e alterações em diretórios de instalação. Como CopyCat aguardava reinicialização antes de acionar etapas mais visíveis, a linha do tempo precisa correlacionar instalação de aplicativo, reboot, download de componente adicional e mudanças persistentes em área de sistema. Em MDM, EDR móvel ou telemetria de segurança, eventos de root inesperado, instalação fora de loja confiável e presença de APKs em caminhos monitorados pelo gerenciador de pacotes são sinais de alta relevância.
Na camada de rede, a defesa deve procurar comunicação com servidores de comando e controle usados para enviar pacotes de atualização, receber nomes de pacotes visualizados no Google Play, retornar identificadores de referência e registrar resultados de instalação. O contexto não fornece domínios ou endereços IP específicos, portanto a caça deve ser baseada em padrões: conexões de aplicativos recém-instalados para armazenamento remoto, chamadas repetidas após reinicialização, tráfego relacionado a módulos baixados dinamicamente e comunicação associada a eventos de instalação de aplicativos. Indicadores específicos, quando disponíveis internamente, devem ser defangados em relatórios e tratados como material de bloqueio, não como links ativos.
No endpoint móvel, sinais úteis incluem pop-ups de anúncios sem origem aparente, mudança de comportamento após reboot, aplicativos desconhecidos instalados sem ação clara do usuário e discrepâncias entre a fonte real de instalação e a referência atribuída. Para equipes de fraude e engenharia de aplicativos, o abuso de install_referrer também merece atenção: padrões anômalos de atribuição, crescimento artificial de instalações por uma mesma referência e concentração em dispositivos com sinais de comprometimento podem indicar manipulação do ecossistema de anúncios.
- Root inesperado em dispositivos que não deveriam estar modificados.
- Instalação ou presença de APKs em
/system/appe/data/appsem origem administrativa legítima. - Download de componentes adicionais após reinicialização do dispositivo.
- Pop-ups publicitários disparados por aplicativos não relacionados à navegação do usuário.
- Eventos anômalos envolvendo
install_referrere atribuição de instalações no Google Play. - Comunicação recorrente com infraestrutura de comando e controle logo após abertura do Google Play ou instalação de aplicativos.
A resposta deve priorizar contenção do dispositivo e remoção de confiança, não apenas desinstalação do aplicativo suspeito. Quando há root não autorizado e persistência em diretório de sistema, a remoção manual pode falhar ou deixar componentes residuais. Em ambiente corporativo, o aparelho deve ser isolado de redes internas, retirado de políticas de acesso condicional e submetido a restauração confiável ou substituição, conforme o nível de controle disponível. Sessões corporativas associadas ao dispositivo precisam ser revisadas, especialmente se o aparelho acessava e-mail, VPN, aplicações internas ou contas com privilégios.
A mitigação estrutural envolve reduzir a exposição a aplicativos reempacotados e corrigir a base instalada. Dispositivos Android 5 e anteriores, quando ainda em uso, devem ser tratados como ativos de risco elevado se não receberem correções. A política deve bloquear instalação de fontes desconhecidas, exigir lojas confiáveis, validar integridade do sistema e impedir acesso corporativo quando houver root. Para organizações com MDM, controles de conformidade devem incluir versão mínima do sistema, nível de patch, detecção de jailbreak ou root, inventário de aplicativos e resposta automática para perda de postura.
Na camada de detecção, equipes devem criar regras comportamentais focadas em sequência e contexto: aplicativo de origem duvidosa, reinicialização, download de pacote adicional, tentativa de exploração local, persistência em área de sistema e atividade publicitária anômala. A proteção também precisa contemplar análise estática e dinâmica de aplicativos móveis, pois a campanha usava módulos e ações dependentes do estado do dispositivo. Como a operação explorava vulnerabilidades antigas, o caso reforça que correções acumuladas e gestão de ciclo de vida são controles diretamente ligados à redução de malware, não apenas à conformidade.
- Bloquear instalação de aplicativos por fontes desconhecidas em dispositivos corporativos.
- Exigir Android com nível de correção compatível com a política interna e retirar Android 5 ou anteriores de acessos sensíveis quando não houver atualização.
- Quarentenar aparelhos com root não autorizado e revisar sessões corporativas associadas.
- Restaurar o dispositivo a partir de imagem confiável quando houver persistência em diretório de sistema.
- Monitorar alterações em diretórios de aplicativos e eventos anômalos de instalação.
- Revisar métricas de atribuição publicitária para identificar padrões compatíveis com substituição de referência.
0 Comentários