Malware móvel infectou cerca de 25 milhões de dispositivos ao combinar repacotamento de aplicativos, abuso de vulnerabilidades conhecidas do Android e interceptação de eventos de anúncios.
| Componente | Dispositivos Android com aplicativos instalados que podiam ser substituídos por versões repacotadas pelo malware Agent Smith. |
| Vetor | Instalação inicial por aplicativos repacotados distribuídos por loja de terceiros, seguida por cadeia em três estágios que explorava Janus, Bundle e Man-in-the-Disk para substituir aplicativos sem interação visível do usuário. |
| Impacto | Execução de módulos maliciosos dentro de aplicativos legítimos comprometidos, exibição de anúncios fraudulentos e tentativa de impedir atualizações que removeriam as alterações. |
| Prioridade | Restringir lojas de terceiros, remover aplicativos suspeitos com identidade visual associada a serviços do Google, revisar aplicativos substituídos e validar atualizações de segurança do Android. |
| Alcance | A campanha foi associada a cerca de 25 milhões de dispositivos infectados, com concentração em usuários na Índia e impacto também observado em Paquistão, Bangladesh, Arábia Saudita, Reino Unido e Estados Unidos. |
| Artefatos | A estrutura descrita inclui módulos loader, core, boot e patch, com núcleo criptografado e disfarçado como arquivo JPG dentro do APK inicial. |
| Finalidade | O objetivo confirmado era monetização por fraude publicitária, com substituição ou interceptação de fluxos de anúncios em aplicativos comprometidos. |
Agent Smith foi descrito como uma campanha de malware móvel para Android que adotou uma cadeia de infecção mais complexa do que simples instalação de aplicativo falso. O malware começava em um aplicativo legítimo repacotado, usado como dropper, e avançava para a substituição de outros aplicativos já presentes no dispositivo. A operação não dependia de uma interação explícita do usuário para cada substituição: depois da instalação inicial, o código malicioso verificava quais aplicativos populares estavam no aparelho, comparava versão e hash MD5 quando essas condições eram relevantes para o fluxo, preparava uma versão alterada do aplicativo e tentava instalá-la como se fosse uma atualização legítima.
O impacto técnico confirmado estava ligado à fraude publicitária. Ao final da cadeia, o malware executava seu payload dentro do contexto de aplicativos comprometidos e passava a exibir banners ou a interceptar eventos de anúncios legítimos para redirecionar monetização para identificadores controlados pela campanha. A pesquisa também descreve mecanismos voltados a manter a alteração ativa: o módulo responsável pelo patch observava diretórios de atualização dos aplicativos afetados e removia arquivos de atualização quando eles apareciam, além de alterar parâmetros de espera para dificultar a substituição da versão maliciosa por uma atualização legítima.
A operação foi associada a cerca de 25 milhões de dispositivos infectados. A maior concentração de alvos estava na Índia, mas o alcance não ficou restrito a esse país: Paquistão, Bangladesh, Arábia Saudita, Reino Unido e Estados Unidos também foram citados como locais afetados. A distribuição inicial teve relação com a loja de terceiros 9Apps, voltada a públicos indiano, árabe e indonésio. No momento da publicação original, os aplicativos maliciosos relacionados que haviam sido identificados na Play Store já não permaneciam disponíveis naquele canal.
A cadeia começava com um dropper embutido em um aplicativo legítimo repacotado. Esse dropper carregava um módulo loader, cuja função era extrair e iniciar o módulo core. O núcleo ficava armazenado dentro do APK com uma camada de disfarce: os primeiros bytes imitavam um cabeçalho de JPG e o restante do conteúdo era codificado por XOR. Depois da extração, o carregamento era feito com mecanismos legítimos do Android para lidar com arquivos DEX grandes e com reflexão para inicializar o código. Essa abordagem reduzia a exposição do núcleo malicioso durante a inspeção superficial do pacote.
Uma vez ativo, o módulo core se comunicava com um servidor de comando e controle para receber uma lista atualizada de aplicativos populares que deveriam ser procurados no dispositivo. Caso essa comunicação falhasse, havia uma lista padrão. Para cada aplicativo visado, o malware verificava se a versão e o hash MD5 correspondiam ao esperado e também observava se o aplicativo estava em execução no espaço do usuário. Quando os critérios eram atendidos, o Agent Smith tentava preparar uma versão adulterada do aplicativo. A infecção podia seguir dois caminhos: decompilação e recompilação em nível de smali/baksmali, ou aplicação de patch binário quando a decompilação falhava.
A substituição do aplicativo dependia do abuso da vulnerabilidade Janus para contornar a validação de integridade do APK. Como a técnica permitia alterar o código, mas não os recursos do pacote da mesma maneira, o malware contornava a limitação escrevendo seus recursos após a seção de dados do DEX. O carregador ART ignorava o conteúdo anexado depois dessa região, enquanto o arquivo alterado passava a carregar o DEX malicioso. Dessa forma, o gerenciador de pacotes interpretava o APK como atualização assinada pelo mesmo certificado, embora o código executado no dispositivo tivesse sido modificado.
A instalação silenciosa era apoiada por falhas conhecidas de um dia, chamadas no material de Bundle, que permitiam acionar atividades internas de aplicativos de sistema mesmo quando essas atividades não estavam exportadas. O fluxo abusava do processamento de contas de rede pelo AccountManagerService e levava a uma chamada que abria a atividade de instalação de aplicativo, burlando verificações esperadas. Quando essa rota não funcionava, o malware recorria a uma técnica Man-in-the-Disk contra aplicativos como SHAREit ou Xender, substituindo arquivos de atualização armazenados em cartão SD por payloads maliciosos.
A superfície exposta era formada por dispositivos Android nos quais o usuário instalava aplicativos a partir de uma loja de terceiros e por aplicativos populares já instalados que correspondiam à lista de alvos mantida pelo malware. A campanha também dependia de condições específicas por aplicativo: versão, hash MD5 e estado de execução eram avaliados antes da tentativa de infecção. Isso indica que a substituição não era completamente genérica; ela era calibrada para aplicativos e builds conhecidos, o que reduzia falhas operacionais e aumentava a chance de o APK alterado continuar funcionando para o usuário.
Os aplicativos repacotados assumiam aparência associada a componentes do Google, como atualizadores ou módulos ligados ao ecossistema Google Play. Esse disfarce era relevante porque ajudava o dropper a parecer parte da operação normal do dispositivo. Depois da infecção de um aplicativo alvo, o módulo boot passava a funcionar como carregador dentro do aplicativo comprometido, extraindo o módulo patch do conteúdo anexado ao DEX. O resultado era a execução de código malicioso a partir de um aplicativo que o usuário já conhecia, o que dificultava a percepção de que a origem dos anúncios anômalos ou da falha de atualização estava em uma substituição local do pacote.
- Aplicativos Android instalados a partir da loja de terceiros 9Apps foram usados como vetor de distribuição inicial.
- Aplicativos populares já presentes no dispositivo eram avaliados por versão e hash MD5 antes da substituição.
- Dispositivos com aplicativos de transferência como SHAREit ou Xender podiam ser impactados pela rota Man-in-the-Disk descrita.
- Usuários na Índia foram o alvo principal observado, com impacto adicional em outros países asiáticos e em alguns mercados desenvolvidos.
A investigação defensiva deve priorizar sinais de substituição de aplicativos e inconsistências entre o pacote instalado e a origem esperada da atualização. Como o malware tentava instalar versões alteradas de aplicativos existentes, uma trilha relevante é a presença de atualizações locais fora do fluxo normal da loja oficial, principalmente em dispositivos que também possuem aplicativos obtidos por lojas de terceiros. Diferenças entre versão declarada, assinatura esperada, hash conhecido e origem do instalador são sinais úteis para separar atualizações legítimas de pacotes repacotados.
No endpoint móvel, os eventos mais relevantes incluem aplicativos que ocultam o ícone após a instalação, pacotes que se apresentam como atualizadores ligados ao Google sem correspondência com componentes oficiais, uso incomum de reflexão para carregar código adicional e presença de DEX com conteúdo anexado além da área esperada. Também é importante revisar tentativas de desabilitar ou bloquear atualizações automáticas: o módulo patch observava diretórios de atualização e removia arquivos, comportamento que pode aparecer como falha recorrente de atualização, ausência de atualização apesar de disponibilidade conhecida ou alteração indevida de parâmetros relacionados ao tempo de espera de verificação.
Na camada de rede, a comunicação do módulo core com comando e controle era usada para obter listas de aplicativos alvo. O material analisado não fornece domínios, endereços IP ou caminhos específicos, portanto a detecção deve se apoiar em classes de comportamento: aplicativos repacotados fazendo requisições de configuração para infraestrutura não associada ao desenvolvedor legítimo, tráfego originado de pacotes que deveriam ser apenas utilitários locais e padrões de anúncios carregados por aplicativos que normalmente não deveriam exibir aquele volume ou tipo de publicidade. A caça deve evitar depender de um único indicador estático, porque a própria cadeia previa lista remota e comportamento modular.
- Pacotes com ícone oculto e nomes que imitam atualizadores ou componentes ligados ao Google.
- Aplicativos reinstalados ou atualizados fora do fluxo esperado da loja oficial.
- Arquivos DEX com recursos anexados após a seção de dados e carregamento posterior por reflexão.
- Falhas repetidas de atualização de aplicativos comprometidos ou remoção de arquivos em diretórios de atualização.
- Requisições de configuração feitas por aplicativos repacotados para infraestrutura não compatível com sua função legítima.
A resposta deve começar pela contenção do vetor de distribuição. Ambientes administrados devem restringir a instalação por lojas de terceiros quando isso não for necessário para a operação, revisar políticas de sideloading e manter inventário de pacotes instalados com origem, assinatura e data de atualização. Em dispositivos já suspeitos, a prioridade é identificar aplicativos que se apresentam como componentes Google sem validação oficial, aplicativos com ícones ocultos e pacotes obtidos de repositórios externos. A remoção deve considerar que o aplicativo inicial pode ter servido apenas como dropper, enquanto outros aplicativos legítimos podem ter sido substituídos depois.
A correção técnica passa por atualização do sistema Android e dos aplicativos afetados por canais confiáveis. Como a cadeia explorava vulnerabilidades conhecidas, incluindo Janus, Bundle e Man-in-the-Disk, a exposição diminui quando o sistema e os aplicativos deixam de aceitar os comportamentos abusados pela campanha. Para aplicativos possivelmente comprometidos, a reinstalação limpa a partir de uma fonte confiável é mais adequada do que confiar apenas em uma atualização local que o malware possa tentar bloquear. Também é necessário verificar se aplicativos como SHAREit ou Xender mantêm arquivos de atualização em armazenamento externo e se há evidência de substituição desses arquivos.
Depois da contenção inicial, a validação deve confirmar que os aplicativos críticos têm assinatura e hash compatíveis com versões legítimas, que atualizações automáticas voltaram a ocorrer e que não há módulo persistente observando diretórios de atualização. Equipes com gerenciamento de dispositivos móveis devem criar regras de conformidade para impedir lojas não aprovadas, alertar sobre aplicativos com ícone oculto e sinalizar pacotes que usem nomes enganosos ligados a serviços do Google. Em paralelo, a análise de tráfego deve procurar padrões de fraude publicitária associados a aplicativos que não deveriam injetar anúncios fora de seu fluxo original.
- Bloquear ou restringir lojas de terceiros e instalações por sideload em dispositivos corporativos.
- Remover aplicativos repacotados suspeitos e reinstalar aplicativos afetados a partir de fonte confiável.
- Atualizar o Android e os aplicativos para versões que corrijam as vulnerabilidades conhecidas exploradas na cadeia.
- Comparar assinatura, versão e hash de aplicativos críticos com referências confiáveis do desenvolvedor legítimo.
- Investigar falhas de atualização recorrentes e diretórios de atualização manipulados em aplicativos afetados.
0 Comentários