Seis aplicativos Android se passavam por soluções de segurança, abusavam do Serviço de Acessibilidade e distribuíam um stealer bancário com DGA, evasão e geofencing.
| Componente | Aplicativos Android falsos de antivírus no Google Play distribuindo o malware bancário Sharkbot. |
| Vetor | Instalação voluntária de aplicativos que aparentavam ser soluções de proteção móvel, seguida de abuso do Serviço de Acessibilidade e comunicação com servidor CnC. |
| Impacto | Roubo de credenciais e informações bancárias por sobreposições falsas, coleta de dados visíveis ao usuário e execução de ações remotas no dispositivo infectado. |
| Prioridade | Remover aplicativos suspeitos, revisar permissões de Acessibilidade e SMS, investigar tráfego HTTP POST criptografado e bloquear infraestrutura associada ao Sharkbot. |
| Artefatos | Seis aplicativos vinculados a três contas de desenvolvedor: Zbynek Adamcik, Adelmio Pagnotto e Bingo Like Inc. |
| Infraestrutura | O malware tenta uma URL estática antes de recorrer a DGA; foram observados 8 IPs de CnC em momentos diferentes. |
O Sharkbot foi distribuído por seis aplicativos Android publicados no Google Play com aparência de soluções antivírus. A cadeia abusava da confiança do usuário em ferramentas de proteção móvel para instalar um stealer bancário capaz de coletar credenciais e informações financeiras. Os aplicativos foram associados a três contas de desenvolvedor, Zbynek Adamcik, Adelmio Pagnotto e Bingo Like Inc, e somavam aproximadamente 15 mil instalações antes da remoção permanente da loja. Parte do histórico dessas contas indicava atividade anterior no segundo semestre de 2021, e alguns aplicativos vinculados a elas continuavam presentes em mercados não oficiais mesmo após remoções no Google Play.
O malware combina técnicas típicas de banker Android com recursos menos frequentes nesse ecossistema, como algoritmo de geração de domínios, geofencing e evasão de sandbox. O objetivo operacional é induzir a vítima a digitar credenciais em janelas que imitam formulários legítimos, capturar o conteúdo informado e encaminhar os dados ao servidor de comando e controle. A operação não tratava todos os dispositivos da mesma forma: o Sharkbot avaliava localização e ignorava usuários da China, Índia, Romênia, Rússia, Ucrânia e Belarus, reduzindo ruído operacional e exposição em regiões que o operador aparentemente não queria atingir.
A remoção dos aplicativos da loja reduz a exposição por distribuição oficial, mas não encerra o risco. O texto técnico indica que o Sharkbot seguia ativo no momento da publicação e que amostras relacionadas podiam persistir em lojas alternativas. Para equipes de defesa, o ponto central é tratar esse caso como comprometimento de endpoint móvel, não apenas como problema de reputação de aplicativo. Dispositivos que concederam permissões sensíveis, especialmente Acessibilidade e SMS, precisam ser revisados com foco em abuso de interface, sobreposição de telas, tráfego recorrente para CnC e alterações locais de configuração.
A infecção começa quando o usuário instala um aplicativo que se apresenta como antivírus. Depois da instalação, o Sharkbot busca permissões que ampliam sua capacidade de observar e interferir na interação do usuário com o dispositivo. O Serviço de Acessibilidade é o recurso mais crítico nessa cadeia, porque permite ao aplicativo acessar dados exibidos na tela e interagir com a interface como se fosse o próprio usuário. Em um banker Android, essa permissão sustenta sobreposições fraudulentas, bloqueio de telas específicas, automação de gestos e interferência em aplicativos bancários ou de configuração.
O Sharkbot utiliza janelas falsas para simular campos de credenciais de aplicativos legítimos. Quando a vítima informa dados nessas telas, o conteúdo é enviado ao servidor malicioso. O malware também implementa comandos remotos enviados pelo CnC, totalizando 22 comandos observados. Esses comandos cobrem ações como atualização de configuração local, alteração de endereço de CnC, envio de módulos adicionais, controle de permissões relacionadas a SMS, bloqueio de acesso a determinados pacotes, simulação de gestos na tela e manipulação de respostas automáticas em notificações. O texto técnico também descreve um módulo local chamado jarMod, carregado por meio de updateLib, usado para receber comandos adicionais do servidor.
A configuração do Sharkbot é mantida localmente em banco SQLite, com arquivos nomeados database.db ou sharked.db dentro da área privada do aplicativo. Os valores são armazenados de forma criptografada, o que dificulta inspeção direta por ferramentas simples de resposta. A comunicação com o CnC ocorre por HTTP usando requisições POST, com conteúdo protegido por RC4 e troca de chave envolvendo RSA. O bot envia pacotes periódicos ao servidor em intervalo padrão de 30 segundos, e esse intervalo pode ser alterado remotamente por comando de configuração.
A resiliência de infraestrutura é reforçada por DGA. Antes de recorrer ao algoritmo, o Sharkbot tenta se conectar a uma URL estática embutida. Se essa tentativa falha, o malware calcula domínios válidos para a data corrente e tenta contato com eles em sequência. Uma amostra com seed hardcoded gera 7 domínios por semana; considerando as combinações de seeds e algoritmos observadas, o total chega a 56 domínios semanais. Esse comportamento dificulta bloqueios estáticos, porque a defesa precisa acompanhar padrões de geração e não apenas uma lista fixa de domínios.
A superfície primária envolve dispositivos Android que instalaram os aplicativos falsos de antivírus antes da remoção do Google Play ou que obtiveram os mesmos pacotes por mercados não oficiais. O risco aumenta quando o usuário concedeu permissões de Acessibilidade, envio ou leitura de SMS, ou aceitou solicitações que permitiram ao aplicativo interferir em outras telas. Como o Sharkbot possui lógica para impedir acesso a pacotes específicos, incluindo configurações do Android e recursos de acessibilidade em dispositivos Samsung, a remediação pode ser dificultada quando o malware já está ativo.
O impacto confirmado fica concentrado em roubo de credenciais e dados bancários, controle de interface e execução de ações comandadas remotamente. O contexto não sustenta afirmar vazamento massivo de base de dados, exploração de vulnerabilidade no Android ou comprometimento de infraestrutura corporativa. A ameaça depende da instalação do aplicativo malicioso e da concessão de permissões sensíveis. Ainda assim, em ambientes corporativos com BYOD ou dispositivos gerenciados, um endpoint móvel infectado pode expor credenciais de aplicativos bancários, mensageria, autenticação por SMS e informações exibidas em tela.
As 27 versões observadas do bot diferem principalmente por seeds de DGA e campos como botnetID e ownerID. Essa variação indica evolução operacional e segmentação da infraestrutura, mas não altera o núcleo defensivo da análise: a detecção precisa correlacionar permissões abusivas, tráfego periódico, tentativas de contato com domínios gerados, sobreposições de credenciais e mudanças de configuração local. A presença de aplicativos removidos da loja oficial em mercados paralelos amplia a necessidade de inventário de origem de instalação, não apenas verificação de nome do pacote.
- Dispositivos Android que instalaram aplicativos falsos de antivírus associados ao Sharkbot.
- Usuários que concederam Serviço de Acessibilidade, leitura ou envio de SMS ao aplicativo malicioso.
- Ambientes que permitem instalação por lojas não oficiais ou sideload sem controle de reputação.
- Aplicativos bancários e formulários de credenciais expostos a sobreposição e captura de entrada.
A caça deve começar pelo inventário de aplicativos instalados e pelo histórico de origem de instalação. Em dispositivos gerenciados, a equipe deve procurar pacotes com comportamento de antivírus que solicitaram Acessibilidade, SMS ou exclusão de otimização de bateria sem justificativa operacional clara. O caso também exige atenção a aplicativos que tentam bloquear acesso a configurações do sistema, alterar aplicativo SMS padrão ou interagir com notificações de mensageiros. Esses sinais são especialmente relevantes quando aparecem combinados com tráfego de rede periódico e armazenamento local criptografado.
Na rede, o Sharkbot usa requisições HTTP POST para caminho raiz, com conteúdo criptografado e beaconing regular. Como a infraestrutura pode mudar por DGA, o bloqueio por indicador único é frágil. A telemetria deve buscar padrões de comunicação móvel incomuns, tentativas sucessivas para domínios recém-gerados, conexão inicial a endereço estático seguida por fallback para domínios calculados e intervalos de contato próximos ao padrão de 30 segundos quando não alterados pelo CnC. O texto técnico menciona 8 IPs usados como CnC em momentos diferentes, mas não fornece valores no material analisado; portanto, a defesa deve depender de inteligência interna e listas aprovadas, não de indicadores inventados.
No endpoint, sinais úteis incluem bancos SQLite database.db ou sharked.db na área privada do aplicativo suspeito, uso de módulos adicionais associados a jarMod, chamadas relacionadas a updateLib, mudanças de configuração local por updateSQL e comportamento de sobreposição diante de aplicativos sensíveis. Também é importante revisar eventos de concessão de Acessibilidade, solicitações de permissão de SMS, tentativas de desativar otimização de bateria e interações automatizadas com a tela. Em análise forense, a prioridade é preservar evidências de instalação, permissões, versão do bot, horários de beaconing e sequência de aplicativos exibidos durante a captura de credenciais.
- Aplicativo com perfil de antivírus solicitando Acessibilidade, SMS e desativação de otimização de bateria.
- Requisições HTTP POST periódicas com conteúdo criptografado e mudança de destino após falha de URL estática.
- Tentativas de contato com domínios gerados por DGA em ciclos semanais.
- Presença de
database.dbousharked.dbna área privada do aplicativo suspeito. - Bloqueio ou interferência em pacotes de configurações do Android e recursos de acessibilidade.
A primeira resposta é remover os aplicativos suspeitos e revogar permissões sensíveis concedidas a qualquer suposta solução de segurança sem origem confiável. Em dispositivos corporativos, a equipe deve aplicar política de instalação restrita, bloquear sideload quando não houver necessidade operacional e exigir distribuição por canais gerenciados. Quando o dispositivo já apresenta sinais de abuso de Acessibilidade, a limpeza manual pode ser insuficiente; nesses casos, o procedimento deve incluir isolamento, coleta de evidências, redefinição controlada do aparelho quando apropriado e troca de credenciais usadas no período de possível exposição.
A contenção de conta é tão importante quanto a remoção do aplicativo. Como o Sharkbot coleta credenciais por sobreposição e pode lidar com SMS, contas bancárias, contas de mensageria e identidades usadas no dispositivo devem ser revisadas. A rotação de senhas deve ocorrer a partir de dispositivo confiável, acompanhada de revisão de sessões ativas, fatores de autenticação, aplicativos autorizados e alertas de transações. Quando houver uso de SMS como fator de autenticação, a equipe deve avaliar migração para mecanismos menos expostos ao controle do endpoint infectado.
No controle preventivo, MDM, EDR móvel e gateway DNS devem ser configurados para detectar comportamento, não apenas nomes conhecidos. A organização deve alertar para aplicativos que se anunciam como antivírus e solicitam permissões incompatíveis com o escopo declarado, impedir instalação por lojas paralelas, registrar concessões de Acessibilidade e monitorar padrões de DGA. Como o Sharkbot utiliza geofencing e evasão de sandbox, análises automatizadas podem não reproduzir o comportamento completo; por isso, a validação deve combinar execução dinâmica, inspeção de permissões, análise de tráfego e revisão de artefatos locais.
- Remover aplicativos falsos de antivírus associados ao Sharkbot e verificar se há versões obtidas fora do Google Play.
- Revogar Acessibilidade, SMS e permissões administrativas concedidas a aplicativos desconhecidos ou incompatíveis com sua função.
- Isolar dispositivos com sinais de infecção, coletar evidências e redefinir o aparelho quando a integridade não puder ser garantida.
- Rotacionar credenciais digitadas no dispositivo durante a janela de exposição e revisar sessões ativas.
- Monitorar beaconing HTTP POST, domínios gerados por DGA e mudanças anormais de aplicativo SMS padrão.
- Aplicar política de instalação por canal gerenciado e bloquear lojas não oficiais em dispositivos corporativos.
0 Comentários