Nova variante do TrickMo usa `TON` e `SOCKS5` para transformar Android infectado em pivô de rede

Trojan bancário para Android amplia controle remoto com proxy local para .adnl, reconhecimento de rede, tunelamento SSH e saída de tráfego pela conexão da vítima.

Componente	TrickMo C, variante do trojan bancário TrickMo para Android, com módulo carregado em tempo de execução como dex.module.
Vetor	Distribuição por sites de phishing e aplicativos dropper, incluindo iscas que se passam por versões adultas do TikTok divulgadas via Facebook; o malware final se disfarça como Google Play Services.
Impacto	Controle remoto do dispositivo, captura de credenciais, interceptação de SMS e OTP, registro de teclas, transmissão de tela, proxy SOCKS5, tunelamento SSH e reconhecimento a partir da rede da vítima.
Prioridade	Remover aplicativos suspeitos, revisar permissões de acessibilidade, bloquear instalação fora de lojas confiáveis, investigar tráfego para .adnl via proxy local e tratar dispositivos infectados como pontos de saída de tráfego malicioso.
Artefatos	dex.module, proxy nativo TON, hostnames .adnl, canal HTTP através de proxy local, comandos curl, dnslookup, ping, telnet e traceroute.
Alvos	Usuários de bancos e carteiras de criptomoedas na França, Itália e Áustria, com observação da atividade entre janeiro e fevereiro de 2026.

Resumo técnico

A nova variante do TrickMo amplia o papel tradicional de um trojan bancário Android para uma plataforma de tomada de dispositivo e pivoteamento de rede. A amostra mantém recursos clássicos de fraude móvel, como abuso de serviços de acessibilidade, phishing de credenciais, captura de teclas, gravação ou transmissão de tela, interceptação de SMS e roubo de OTP, mas adiciona uma camada operacional voltada a tráfego e reconhecimento. O componente carregado dinamicamente, identificado como dex.module, continua sendo o núcleo funcional executado após a etapa inicial de dropper, porém recebeu capacidades que permitem usar o aparelho comprometido como origem controlada de requisições, ponto de observação da rede local e nó de saída para ações conduzidas pelo operador.

O diferencial técnico está na combinação de comunicação por TON com funções de proxy e tunelamento. Em vez de depender somente de infraestrutura convencional de domínio, resolução pública e servidores diretamente bloqueáveis, o malware inicia um proxy nativo TON local e força o cliente HTTP do bot a encaminhar comunicações por esse processo. As requisições de comando e controle passam a mirar hostnames .adnl, resolvidos dentro do overlay da rede TON. Essa arquitetura dificulta bloqueios baseados apenas em domínio ou endereço IP e aumenta o custo de derrubada da infraestrutura, porque a comunicação maliciosa fica misturada a um ecossistema descentralizado que também pode transportar tráfego legítimo.

A campanha observada entre janeiro e fevereiro de 2026 teve foco em usuários de bancos e carteiras de criptomoedas na França, Itália e Áustria. A distribuição ocorre por sites de phishing e aplicativos dropper, com iscas relacionadas a versões adultas do TikTok divulgadas via Facebook. Depois da instalação, o malware se apresenta como Google Play Services, uma escolha que tenta explorar a familiaridade do usuário com um componente essencial do Android e aumentar a chance de concessão de permissões sensíveis. Para defesa, o ponto central é tratar a infecção não apenas como risco de fraude bancária, mas como exposição de rede: o telefone pode virar uma posição intermediária para tráfego, enumeração e fraude originada do próprio ambiente da vítima.

Fluxo técnico

A cadeia começa com o dropper instalado pelo usuário a partir de uma isca fora do fluxo normal de distribuição confiável. O dropper atua como carregador e busca em infraestrutura controlada pelo operador um APK carregado em tempo de execução, referenciado como dex.module. Esse modelo reduz a quantidade de lógica maliciosa visível no pacote inicial e permite alterar capacidades sem trocar toda a isca. Após o carregamento, o módulo ativa funções de tomada de dispositivo, solicita ou explora permissões de acessibilidade e passa a operar sobre telas, entradas e notificações. Essa etapa viabiliza captura de credenciais, leitura de códigos temporários, interação remota e sobreposição de telas falsas para serviços financeiros.

Nas versões anteriores, o controle remoto baseado em acessibilidade era associado a um canal em socket.io. A variante TrickMo C preserva a lógica de controle do dispositivo, mas adiciona um subsistema orientado a rede. Esse subsistema expõe comandos como curl, dnslookup, ping, telnet e traceroute, o que fornece ao operador uma capacidade próxima a um shell remoto para reconhecimento a partir da posição real do telefone. Se o aparelho estiver conectado a uma rede residencial ou corporativa por Wi-Fi, essas ações passam a refletir a visibilidade interna daquele segmento, incluindo serviços que não seriam acessíveis diretamente pela internet pública.

O proxy SOCKS5 autenticado é a capacidade de maior impacto operacional. Com ele, o dispositivo comprometido pode encaminhar conexões geradas pelo operador, fazendo com que acessos a bancos, comércio eletrônico ou corretoras de criptomoedas pareçam originados do endereço IP e do contexto de rede da vítima. Isso pode reduzir a eficácia de controles antifraude que dependem fortemente de reputação de IP, geolocalização, ASN, histórico de rede ou coerência entre sessão móvel e origem da conexão. Quando combinado com credenciais capturadas e OTP interceptado, o recurso permite que uma tentativa de fraude tenha mais sinais contextuais compatíveis com o usuário verdadeiro.

A presença de tunelamento SSH amplia esse uso para cenários de pivoteamento mais flexíveis. O operador pode encapsular tráfego e direcionar conexões por rotas que aproveitam a posição do telefone, em vez de se limitar a ações bancárias no próprio dispositivo. Embora o material analisado não traga endereços de comando e controle, hashes, certificados ou payloads adicionais, os artefatos comportamentais são suficientemente claros: inicialização de proxy local TON, comunicação para .adnl, execução de utilitários de diagnóstico de rede, abertura de proxy SOCKS5 e uso de permissões Android incompatíveis com a função declarada de um aplicativo legítimo.

Superfície afetada

A superfície primária é o dispositivo Android do usuário final, especialmente quando a instalação de aplicativos fora de lojas confiáveis está permitida ou quando o usuário concede permissões de acessibilidade a um aplicativo que se apresenta como serviço do sistema. Em Android, serviços de acessibilidade têm capacidade legítima para observar conteúdo de tela, interagir com elementos de interface e automatizar ações em nome do usuário. Em um trojan bancário, essa permissão se transforma em mecanismo de controle remoto, leitura de dados sensíveis e manipulação de sessões autenticadas. A falsa identidade de Google Play Services tenta induzir a concessão dessas permissões por parecer uma dependência operacional do aparelho.

A superfície secundária é a rede à qual o aparelho está conectado. Um telefone infectado dentro de uma rede doméstica pode enxergar roteadores, impressoras, painéis administrativos, dispositivos IoT e serviços locais expostos apenas no segmento interno. Em uma rede corporativa, o risco inclui enumeração de hosts, validação de portas abertas, teste de resolução interna e uso do endereço de saída corporativo como reputação para acessos fraudulentos. A variante não precisa comprometer diretamente um servidor interno para gerar valor ao operador: a simples capacidade de executar ping, traceroute, dnslookup, telnet e requisições por curl já fornece telemetria de alcance e conectividade a partir de uma posição confiável.

Há ainda indicadores de expansão futura. A amostra declara permissões extensas relacionadas a NFC e inclui o framework de hooking Pine, mas esses recursos aparecem dormentes e sem implementação funcional confirmada no contexto analisado. Isso não deve ser tratado como capacidade ativa de ataque por aproximação ou hooking avançado em todos os casos, mas merece acompanhamento porque mostra uma direção técnica plausível para evolução do malware. Em ambientes de alto risco, a combinação de fraude bancária, controle de tela, proxy de tráfego e possíveis permissões de proximidade aumenta a necessidade de inventário e resposta em dispositivos móveis.

• Dispositivos Android que instalaram dropper por fora de canais confiáveis e concederam permissões sensíveis de acessibilidade.
• Usuários de bancos e carteiras de criptomoedas, com atividade observada contra França, Itália e Áustria.
• Redes Wi-Fi domésticas ou corporativas às quais o aparelho infectado esteja conectado durante a operação do malware.
• Serviços antifraude que dependem de reputação de IP, origem geográfica e coerência de rede para pontuar risco de sessão.
• Ambientes com baixa visibilidade de tráfego móvel, ausência de MTD/EMM e permissões Android sem revisão periódica.

Hunting e telemetria

A caça deve começar no endpoint móvel, porque a cadeia depende de instalação local, carregamento dinâmico e permissões de alto impacto. Em soluções de MTD, EMM ou inventário Android, procure aplicativos que se passam por Google Play Services fora do pacote legítimo, apps recentes com origem desconhecida, permissões de acessibilidade concedidas a nomes não reconhecidos e presença de módulos carregados em tempo de execução. A investigação deve correlacionar data de instalação, origem do APK, concessão de permissões, criação de serviços em segundo plano e comportamento de rede imediatamente após a abertura do aplicativo.

Na rede, o sinal mais específico é a combinação de comunicação para hostnames .adnl com proxy local iniciado no próprio processo do malware. Como a comunicação é encaminhada por TON, bloqueios tradicionais por domínio podem não capturar toda a atividade. Ainda assim, ambientes com DNS corporativo, inspeção de tráfego móvel gerenciado, VPN corporativa ou logs de firewall podem procurar padrões incomuns de conexão relacionados ao overlay TON, conexões persistentes iniciadas por aplicativos Android que não deveriam usar esse ecossistema e aumento de tráfego de saída a partir de aparelhos móveis fora do perfil normal do usuário.

Para fraude e identidade, o hunting deve correlacionar eventos bancários ou de carteira com sinais de controle remoto. Sessões iniciadas a partir do mesmo IP residencial ou corporativo da vítima não devem ser automaticamente consideradas confiáveis quando houver indício de TrickMo. Procure alterações de dispositivo, sequência de navegação anormal, digitação automatizada, aprovação de transações logo após recebimento de SMS, alternância entre sessão móvel e tráfego proxy, e acessos a múltiplos serviços financeiros com o mesmo padrão de origem. O proxy SOCKS5 muda a premissa de análise: a origem de rede pode ser legítima, mas a ação ainda ser comandada por terceiro.

Em redes corporativas, telemetria de EDR em estáções não verá o malware Android diretamente, mas pode observar efeitos indiretos se o telefone estiver na mesma rede sem fio. Logs de DHCP, NAC, DNS interno e firewall lateral podem revelar consultas ou testes de conectividade vindos de um dispositivo móvel para recursos que ele não deveria acessar. A presença de curl, telnet, ping, traceroute e dnslookup como comandos controlados pelo operador significa que tentativas de enumeração podem aparecer como tráfego curto, distribuído e manual, não como varredura ruidosa tradicional.

• Aplicativo Android recente se passando por Google Play Services com assinatura, origem ou caminho de instalação divergente do componente legítimo.
• Permissão de acessibilidade concedida a aplicativo sem necessidade funcional clara, especialmente após instalação por APK externo.
• Carregamento em tempo de execução de dex.module ou comportamento compatível com busca de APK adicional em infraestrutura remota.
• Tráfego de aplicativo móvel para hostnames .adnl ou uso inesperado de overlay TON em dispositivo de usuário final.
• Conexões de saída compatíveis com proxy SOCKS5, tunelamento SSH ou encaminhamento de tráfego a partir do telefone.
• Execução remota de testes de rede observáveis por logs, incluindo dnslookup, ping, telnet, traceroute e requisições HTTP geradas por curl.

Mitigação

A resposta deve priorizar contenção do dispositivo, revogação de permissões e redução de dano financeiro. Quando houver suspeita de infecção, isole o aparelho de redes Wi-Fi corporativas e domésticas, remova aplicativos instalados fora de fontes confiáveis, desative permissões de acessibilidade concedidas a apps não essenciais e preserve evidências antes de reinstalação quando houver necessidade de análise forense. Para usuários afetados, altere credenciais bancárias e de carteiras de criptomoedas a partir de um dispositivo limpo, revogue sessões ativas, revise transações recentes e acione mecanismos antifraude dos provedores envolvidos.

Em organizações, a mitigação passa por política de dispositivos móveis e segmentação. Dispositivos pessoais ou não gerenciados não devem ter acesso amplo à mesma rede de ativos internos sensíveis. Redes Wi-Fi corporativas devem aplicar NAC, segmentação por perfil, DNS monitorado e restrições de tráfego lateral. Em aparelhos gerenciados, bloqueie instalação de APK fora de lojas aprovadas, limite serviços de acessibilidade a aplicações permitidas, monitore permissões de SMS, sobreposição de tela, captura de tela e uso de VPN/proxy. A detecção deve incluir comportamento, porque a infraestrutura por TON reduz a estabilidade de indicadores tradicionais.

Para times de fraude, é importante ajustar modelos que tratam IP conhecido como fator de confiança forte. O TrickMo C permite que o tráfego saia pela rede da vítima, então sinais como geolocalização esperada, endereço residencial e ASN usual precisam ser combinados com telemetria de dispositivo, integridade da sessão, velocidade de interação, ordem de eventos, uso de acessibilidade e histórico de desafio OTP. Sessões de alto risco devem exigir validação adicional quando houver mudança de comportamento, mesmo que a origem de rede pareça coerente.

A validação pós-resposta deve confirmar que o dispositivo não mantém serviços em segundo plano, que não há proxy local persistente, que permissões sensíveis foram revogadas e que a conta não permanece com sessões ou tokens ativos emitidos durante o período de comprometimento. Em ambientes corporativos, revise logs de DHCP, DNS, firewall, NAC e autenticação no intervalo em que o telefone esteve conectado. Se houver sinais de enumeração interna, trate o evento como possível reconhecimento a partir de um ativo móvel comprometido e não apenas como infecção isolada de usuário final.

• Bloquear instalação de APK por fontes desconhecidas e restringir permissões de acessibilidade a aplicativos explicitamente aprovados.
• Isolar dispositivos suspeitos de redes Wi-Fi confiáveis e remover aplicativos que imitam Google Play Services sem correspondência com o pacote legítimo.
• Monitorar ou bloquear tráfego inesperado relacionado a .adnl, TON, proxy SOCKS5 e tunelamento SSH em dispositivos móveis gerenciados.
• Revisar contas financeiras e de criptomoedas acessadas no período, revogar sessões, redefinir senhas e invalidar tokens emitidos durante a suspeita de infecção.
• Segmentar redes sem fio para impedir que celulares comprometidos alcancem serviços internos sem necessidade operacional.
• Correlacionar fraude com sinais de controle remoto e não confiar apenas em reputação de IP quando o acesso partir da rede usual da vítima.