Malware coleta dados do aparelho, recebe configuração de C2, manipula WebView quase invisível e automatiza etapas de assinatura em páginas de operadoras.
| Componente | WAPDropper, malware Android com módulo dropper e módulo discador voltado a páginas de serviços premium de telecomunicações. |
| Vetor | Após execução no dispositivo Android, o malware coleta informações do aparelho, consulta C2 hardcoded, baixa ou ativa payloads adicionais e carrega URLs em uma WebView quase invisível. |
| Impacto | A atividade observada permite automatizar interações em páginas de assinatura premium, remover cabeçalhos usados em validações web e contornar CAPTCHA por serviço externo de reconhecimento de imagem. |
| Prioridade | Identificar dispositivos Android com comunicação para C2 defangados, bloquear domínios relacionados, revisar assinaturas premium indevidas e remover aplicativos associados ao comportamento. |
| Artefatos | DEX descriptografado gravado como data.jar, biblioteca nativa carregada a partir da memória e uso de reflexão para ocultar chamadas de inicialização. |
| IoCs | Exemplos defangados incluem hxxp://ks7br7[.]3q03on[.]com:12038, hxxp://api[.]biwbrd[.]com/un, hxxp://l[.]facebook1mob[.]com/index.php?r=api/back e hxxp://upload[.]chaojiying[.]net/Upload/Processing.php. |
WAPDropper é um malware Android estruturado como dropper e discador, com foco em levar dispositivos infectados a interagir com páginas de serviços premium ligados a operadoras de telecomunicações. O comportamento descrito não se limita à exibição de publicidade ou à abertura simples de páginas: o código coleta informações do dispositivo, consulta infraestrutura de comando e controle, interpreta uma configuração em JSON, ativa componentes adicionais e prepara uma WebView minúscula para conduzir interações automatizadas. O objetivo técnico observado é manipular fluxos web que envolvem assinatura ou cobrança, simulando ações do usuário dentro do próprio ambiente do aparelho comprometido.
A cadeia começa depois que o malware já está em execução no Android. Nesse ponto, WAPDropper obtém dados do sistema e do dispositivo e os envia a um servidor de comando e controle hardcoded. A resposta do C2 principal fornece uma lista de outros endereços que passam a ser escolhidos de forma aleatória para requisições futuras, reduzindo dependência de um único ponto de comunicação. Em seguida, o malware analisa a configuração recebida para determinar quais payloads adicionais serão usados, quais parâmetros orientarão a operação e quais URLs serão carregadas no fluxo de assinatura. Essa arquitetura torna a operação mais flexível, pois a lógica do aplicativo instalado não precisa conter todos os destinos finais ou todas as regras de execução no binário inicial.
A análise também aponta sobreposição de infraestrutura com uma campanha anterior associada ao domínio ip[.]cooktracking[.]com. Essa relação deve ser tratada como vínculo técnico condicionado, não como atribuição definitiva. O dado mais relevante para defesa é que conexões para domínios e caminhos relacionados aparecem como ponto de partida para investigação de tráfego móvel, proxy corporativo, DNS seguro e telemetria de MTD. Como o malware atua no próprio endpoint móvel e usa componentes Android legítimos, controles baseados apenas em perímetro tendem a ter visibilidade parcial; a detecção precisa combinar comportamento local, rede e revisão de cobranças ou assinaturas incomuns.
Depois da etapa inicial de coleta e comunicação, o módulo discador descriptografa um arquivo DEX embutido no código e o grava no dispositivo com o nome data.jar. Em vez de chamar diretamente as rotinas de execução, WAPDropper usa reflexão e strings fortemente ofuscadas para dificultar a análise estática e reduzir a clareza das intenções do binário. A inicialização real do componente é chamada de forma indireta, e uma biblioteca nativa também é carregada a partir da memória e persistida no aparelho para uso posterior. Esses detalhes são importantes para engenharia reversa e resposta a incidente porque artefatos em disco podem surgir apenas depois da execução, enquanto a amostra original pode esconder parte relevante da lógica até que o fluxo seja ativado.
O malware passa então a enviar informações básicas do dispositivo infectado para um endpoint adicional, exemplificado no contexto como hxxp://api[.]biwbrd[.]com/un. Em paralelo, solicita ao C2 uma oferta de anúncio ou uma URL a ser processada. Quando recebe a resposta, cria um diálogo de 1 por 1 pixel, praticamente imperceptível para a vítima, contendo uma WebView. Essa escolha permite que o código carregue conteúdo web e execute automação sem depender de uma navegação visível convencional. Para a defesa, esse ponto é crítico: o tráfego pode parecer originado de um componente Android comum, mas o contexto visual e a dimensão do diálogo indicam uso abusivo de UI para esconder atividade automatizada.
Um dos recursos mais relevantes é a alteração de comportamento relacionada ao cabeçalho HTTP X-Requested-With. O malware usa a biblioteca nativa para remover esse cabeçalho das requisições da WebView, substituindo ocorrências da string por Accept-Encoding. O cabeçalho X-Requested-With é frequentemente usado por aplicações web como sinal auxiliar em validações contra requisições não esperadas ou tentativas de abuso em fluxos com estado. Ao removê-lo, WAPDropper reduz uma barreira que poderia diferenciar interações legítimas de requisições conduzidas por automação embutida. O efeito defensivo esperado é procurar sessões móveis com comportamento anômalo em páginas de assinatura, ausência inesperada de cabeçalhos em WebViews e padrões de navegação incompatíveis com interação humana.
A etapa seguinte envolve injeção de JavaScript malicioso na WebView vulnerabilizada. O código atua como interface entre o conteúdo remoto e o aparelho, permitindo que o site carregado acione ações dentro do fluxo controlado pelo malware. O contexto indica ainda capacidade de lidar com CAPTCHA. O malware pode baixar a imagem do desafio ou extrair sua representação a partir da árvore DOM, codificá-la em Base64 e enviá-la para um serviço externo de reconhecimento de imagem operado por uma empresa chinesa conhecida como Super Eagle. O serviço retorna coordenadas ou resultado de reconhecimento, que o malware usa para simular a resposta dentro da WebView. Essa capacidade mostra que a cadeia foi desenhada para atravessar etapas antifraude simples, especialmente quando o desafio visual é tratado como obstáculo isolado e não correlacionado com sinais de integridade do dispositivo, reputação de sessão e comportamento do usuário.
A superfície exposta são dispositivos Android nos quais o WAPDropper tenha sido instalado e executado. O material analisado não descreve o método inicial de distribuição, portanto não é correto afirmar que houve campanha por loja oficial, sideload, phishing ou pacote específico. A condição confirmada começa no pós-comprometimento do aplicativo: uma vez ativo, o malware possui lógica para coletar dados do aparelho, se comunicar com servidores remotos, carregar código adicional e automatizar navegação em páginas de serviços premium. Ambientes corporativos com frota Android, programas BYOD e usuários com faturamento móvel atrelado a operadoras são os cenários que exigem maior atenção operacional.
O risco técnico se concentra na combinação de WebView oculta, manipulação de cabeçalhos, automação de DOM e resolução de CAPTCHA. Operadoras e intermediários de cobrança que dependem apenas de interação web, cabeçalhos simples ou CAPTCHA isolado podem ter dificuldade para distinguir uma assinatura legítima de uma navegação automatizada no dispositivo da vítima. Para times de segurança, o incidente também mostra a importância de incluir telemetria de aplicativos móveis e cobrança telecom em fluxos de fraude, porque o efeito financeiro pode aparecer fora dos sistemas tradicionais de identidade corporativa, EDR de desktop ou SIEM centrado em servidores.
- Dispositivos Android com aplicativo malicioso já instalado e permissões suficientes para executar o fluxo descrito.
- WebViews iniciadas por código do aplicativo para carregar páginas remotas de assinatura ou ofertas premium.
- Sessões web móveis nas quais cabeçalhos esperados, como
X-Requested-With, desaparecem de forma incompatível com o aplicativo legítimo. - Contas de usuários ou linhas móveis com cobranças premium, assinaturas não reconhecidas ou picos de tráfego para domínios defangados relacionados à campanha.
A caça deve começar por telemetria de rede e DNS em dispositivos móveis, VPN corporativa, gateways seguros e soluções MTD. Endpoints que se comuniquem com domínios defangados associados ao fluxo, especialmente hxxp://ks7br7[.]3q03on[.]com:12038 e hxxp://api[.]biwbrd[.]com/un, merecem isolamento lógico e análise do inventário de aplicativos. A presença de tráfego para serviço externo de reconhecimento de CAPTCHA, como hxxp://upload[.]chaojiying[.]net/Upload/Processing.php, é um sinal relevante quando aparece a partir de aplicativos que não têm justificativa de negócio para processar desafios visuais. Como a infraestrutura pode mudar por configuração remota, a busca por classes de comportamento é mais resiliente do que depender apenas de indicadores estáticos.
No endpoint, a análise deve procurar criação do arquivo data.jar, carregamento dinâmico de DEX, uso intensivo de reflexão, materialização de biblioteca nativa após execução e strings ofuscadas relacionadas a cabeçalhos HTTP. Eventos de criação de WebView com dimensões mínimas ou diálogos praticamente invisíveis são difíceis de capturar em telemetria padrão, mas podem aparecer em análise dinâmica, sandbox móvel ou instrumentação de aplicativos suspeitos. Em ambientes com MTD, sinais como carregamento de código em tempo de execução, comunicação C2 em texto claro por HTTP e uso de bibliotecas nativas não esperadas devem elevar a severidade mesmo sem assinatura nominal do malware.
Também é útil cruzar eventos técnicos com evidências de negócio. Cobranças de serviços premium, mensagens de confirmação de assinatura, páginas de operadora acessadas sem intenção do usuário e reclamações de consumo indevido podem indicar que o fluxo já produziu impacto. Para DFIR, a linha do tempo deve correlacionar instalação do aplicativo suspeito, primeira comunicação com C2, criação de artefatos dinâmicos, acessos a páginas de telecomunicações e eventual cobrança. Esse encadeamento ajuda a separar infecção ativa de simples resolução DNS, além de reduzir falso positivo em redes que possam ter observado os domínios por pesquisa, sandbox ou bloqueio preventivo.
- Conexões HTTP para C2 defangados, especialmente porta 12038 no host hxxp://ks7br7[.]3q03on[.]com.
- Criação ou acesso ao arquivo
data.jarpor aplicativo Android que não deveria carregar DEX externo. - Carregamento de biblioteca nativa após execução e chamadas por reflexão para métodos de inicialização ocultos.
- WebViews com fluxo automatizado para páginas de telecomunicações, ofertas ou assinatura premium.
- Tráfego para serviço de reconhecimento de CAPTCHA sem justificativa funcional do aplicativo instalado.
- Reclamações de usuários ou registros de cobrança associados a assinaturas premium não solicitadas.
A resposta deve priorizar contenção do dispositivo, interrupção da comunicação e validação de impacto financeiro. Dispositivos com tráfego compatível devem ser removidos temporariamente de redes corporativas sensíveis, submetidos à análise por solução MTD e ter aplicativos suspeitos desinstalados ou colocados em quarentena conforme política interna. Bloqueios de DNS, proxy e gateway móvel devem incluir os indicadores defangados conhecidos, mas sem tratar essa lista como completa. Como o C2 principal fornece URLs adicionais dinamicamente, a defesa precisa bloquear padrões de infraestrutura confirmados e, ao mesmo tempo, manter detecção por comportamento de WebView, carregamento dinâmico e comunicação HTTP incomum.
Usuários afetados devem ter assinaturas premium revisadas junto à operadora, com contestação de cobranças indevidas quando aplicável. Em frotas gerenciadas, políticas de instalação devem restringir fontes não autorizadas, exigir reputação de aplicativos, impedir execução de pacotes desconhecidos e reforçar inspeção de comportamento após instalação. Para equipes responsáveis por aplicações de telecomunicações e cobrança, a mitigação defensiva inclui não depender apenas de CAPTCHA e cabeçalhos simples para validar intenção do usuário. Sinais como integridade do app, reputação do dispositivo, consistência de sessão, velocidade de interação, origem da WebView e confirmação fora do canal automatizado aumentam a resistência contra fluxos como o observado.
A validação pós-resposta deve confirmar que o dispositivo não mantém artefatos dinâmicos, que não há novas conexões para C2, que cobranças foram interrompidas e que a conta móvel não possui assinaturas remanescentes criadas durante a janela de infecção. Quando houver análise de amostra, os artefatos extraídos devem alimentar regras internas de detecção sem publicar payloads ou instruções de reprodução. O foco operacional é documentar precondições, indicadores, impacto e controles compensatórios, mantendo a investigação em escopo defensivo.
- Bloquear domínios e endpoints defangados observados na campanha em DNS, proxy, firewall móvel e ferramentas MTD.
- Isolar e analisar dispositivos Android com criação de
data.jar, carregamento dinâmico de DEX ou comunicação C2 compatível. - Remover aplicativos suspeitos e revisar políticas de instalação, reputação e execução de código em dispositivos gerenciados.
- Auditar cobranças e assinaturas premium vinculadas às linhas dos usuários afetados durante a janela de atividade.
- Reforçar controles antifraude em fluxos de assinatura com validação de sessão, integridade do dispositivo e confirmação resistente à automação.
- Manter hunting comportamental para WebViews ocultas, remoção de cabeçalhos esperados e uso anômalo de serviços de CAPTCHA.
0 Comentários