Sumário executivo

O cenário de ameaças móveis passou por uma evolução crítica, passando de Modificação do aplicativo (reempacotando APKs) para Manipulação do ambiente de execução por meio da estrutura LSposed. Esse novo vetor de ataque permite que os agentes de ameaças sequestrem aplicativos de pagamento legítimos e não modificados, “iluminando a gás” o sistema operacional Android subjacente. Como o módulo malicioso (no momento em que escrevo este blog se chamava “Digital Lutera”) conecta APIs no nível do sistema em vez do aplicativo em si, a assinatura digital do aplicativo de pagamento permanece válida, ignorando efetivamente o Google Play Protect e as verificações de integridade tradicionais que anteriormente sinalizavam binários modificados.

No centro dessa metodologia está o desmantelamento sistemático do Mecanismo de vinculação de SIM para pagamento móvel, um dos pilares de segurança do ecossistema financeiro indiano. Ao conectar o SMSManager e o TelephonyManager, os agentes de ameaças interceptam tokens de registro de saída, falsificam identidades de dispositivos (números de telefone) e exfiltram dados 2FA para o Telegram. Fundamentalmente, o módulo usa Socket.io para comando e controle (C2) em tempo real, permitindo que os invasores injetem remotamente registros SMS fabricados no banco de dados “Enviados” do dispositivo. Isso faz com que os servidores do banco verifiquem a “presença física do SIM” em um dispositivo localizado a milhares de quilômetros do cartão SIM real. No entanto, vale ressaltar aqui que o pré-requisito para realizar esse ataque é que os atacantes exijam que a vítima geralmente esteja comprometida por APKs trojanizados que permitem ao agente da ameaça ler/excluir/encaminhar mensagens SMS.

O impacto está permitindo a aquisição não autorizada de contas e a orquestração de fraudes em tempo real em grande escala. Para mitigar esse risco, as instituições financeiras devem ir além da detecção básica de raízes e implementar API de integridade do Google Play com um requisito estrito de MEETS_STRONG_INTEGRITY para garantir que o bootloader esteja bloqueado e que o sistema operacional esteja intacto. Além disso, os sistemas de back-end devem fazer a transição para Validação do lado da operadora, verificando se as mensagens de registro realmente atravessaram a rede celular em vez de depender da confirmação local do dispositivo.

Como a verificação por SMS vinculada a SIM funciona em sistemas de pagamento móvel?

O Vinculação de dispositivos O processo é um protocolo de segurança multicanal. Ao exigir uma correspondência entre um Sinal SIM físico (SMS) e um Solicitação de aplicativo digital (Internet), o sistema garante que, mesmo que um hacker tenha os dados bancários do usuário, ele não possa acessar a conta sem a posse física do telefone e do cartão SIM do usuário.

1. Configuração inicial (Fase 1.0 - 1.2)

O processo começa quando o usuário aciona o registro. O aplicativo requer Permissões de SMS e telefone para funcionar. Sem eles, o aplicativo não pode enviar a mensagem de verificação silenciosa nem identificar qual slot SIM está sendo usado.

2. Preparação de hardware (Fase 2.0 - 2.2)

Nesse estágio, o aplicativo cria uma “impressão digital” para a sessão:

• Etapa 2.1: O aplicativo identifica o hardware específico (por exemplo, vivo V2338).
• Etapa 2.2: Isso gera um Token secreto (por exemplo, 29DE0Hb... 797ZQ). Esse é um código aleatório único que evita “ataques repetidos” (hackers tentando reutilizar dados de verificação antigos).

3. A fase de prova física (fase 3.0 - 3.3)

Essa é a verificação de segurança “Zero-Trust” que prova que o cartão SIM está fisicamente dentro do telefone.

• Etapa 3.1 e 3.2: O aplicativo constrói um SMS silencioso com o formato TDL TRB [Token] e o envia para o número de verificação do banco.
• Etapa 3.3: Conforme o SMS passa pela rede celular (JIO/Airtel/qualquer outro provedor de rede), a operadora anexa automaticamente a identidade do remetente — o número do celular 8888888888—para o cabeçalho da mensagem. Esse é um “selo” de nível de hardware que o usuário não pode falsificar.

4. Mapeamento do lado do servidor do sistema financeiro (fases 4.0 - 4.3)

O servidor agora atua como um “Matchmaker”.

• Etapa 4.1 e 4.2: O Banco recebe o SMS, extrai o Token secreto do corpo do texto e registra o Número de celular do selo da rede.
• Etapa 4.3: Ele armazena esse par em um Banco de dados pendente. O Banco agora sabe: “O número 8888888888 está atualmente tentando vincular um dispositivo usando o código 29DE0hb...”

5. Fase de aperto de mão na Internet (fase 5.0 - 5.3)

Agora, o aplicativo precisa confirmar sua identidade pela internet para fechar o loop.

• Etapa 5.1: O aplicativo chama a API /bindDevice usando a conexão de dados do telefone (WiFi ou 5G).
• Etapa 5.2 (A partida crítica): O Banco compara o token recebido via Internet com o token recebido via SMS.
  
  • Se eles coincidirem, isso prova que Aplicativo (Internet) e o SIM (SMS) estão no mesmo dispositivo.
• Etapa 5.3: Após uma partida bem-sucedida, o Banco emite um Token de sessão segura, que é a “chave mestra” para todas as transações futuras neste aplicativo.

6. Descoberta e conclusão (Fase 6.0 - 6.3)

A etapa final completa a integração.

• Etapa 6.1 e 6.2: Usando o novo token seguro, o aplicativo solicita que o banco “descubra” todas as contas vinculadas às 8888888888.
• Etapa 6.3: As contas são vinculadas e o serviço de pagamento móvel fica ativo. O 8888888888 a conta agora está bloqueada criptograficamente para esse específico vivo V2338.

‍

‍

Como os agentes da ameaça exploraram anteriormente o SMS de vinculação de SIM do Sistema de Pagamento Móvel por meio de APKs modificados?

Ao combinar um Dispositivo móvel trojanizado (a vítima) e um APK de pagamento móvel modificado (no dispositivo do atacante), os agentes de ameaças podem fazer com que os servidores do banco acreditem que o cartão SIM da vítima está fisicamente presente no telefone do atacante.

‍

1. Sequestro de login de conta (Fase 1)

O ataque começa comprometendo o telefone da vítima com um Trojan (malware) que tem permissões de “leitura/gravação de SMS”. Isso geralmente é feito usando APK trojanizados, como APKs 'Vahan Chalan' ou 'Wedding Invitation', que o usuário é induzido a instalar por meio de engenharia social.

• A ação: O atacante usa uma versão modificada de um APK de pagamento em seu próprio dispositivo e insere o número do celular da vítima (8888888888).
• A violação: Quando o servidor envia um OTP de login para a vítima, o Trojan o intercepta silenciosamente e o encaminha para um painel controlado pelo atacante. Esses painéis são comumente usados pelos atacantes para visualizar e enviar mensagens SMS do dispositivo da vítima (conhecido como painel RAT nos fluxogramas acima).
• Resultado: O atacante faz login com sucesso no perfil da conta da vítima sem que ela veja nenhuma notificação.

2. Exfiltração de fichas vinculativas (fase 2)

Uma vez dentro do aplicativo, o atacante tenta ativar os pagamentos móveis.

• A ação: O dispositivo do atacante aciona o processo de “Verificação do Sistema de Pagamento Móvel”. O APK modificado gera um Token de vinculação secreta exclusivo para o hardware do atacante.
• O redirecionamento: Em vez de enviar o SMS de verificação localmente, o APK modificado intercepta a mensagem (usando a estrutura LSposed) e a envia para um grupo do Telegram.
• Por que isso é importante: O atacante agora tem a “chave” específica necessária ao banco para verificar seu dispositivo, mas não tem a prova do “SIM físico”.

3. Execução de SMS falsificada (fase 3)

Esse é o estágio mais crítico, em que o atacante usa o telefone da vítima como Gateway remoto de SMS.

• A ação: O atacante copia o token do Telegram e envia um comando para o Trojan no telefone da vítima.
• A paródia: O Trojan força o telefone da vítima a enviar um SMS silencioso (TDL TRB [Attacker's Token]) para o número do gateway do banco.
• O selo de telecomunicações: Como o SMS se origina do SIM físico da vítima, a rede celular o “carimba” com o número da vítima (8888888888).

4. Mapeamento do lado do servidor bancário (fase 4)

O sistema de segurança do Banco foi projetado para confiar na identificação da Rede de Telecomunicações.

• A decepção: O banco recebe o SMS e vê uma mensagem legítima de 8888888888 contendo um token válido.
• A partida: O Banco mapeia o número do celular da vítima para o token do atacante em seu banco de dados, acreditando que a vítima está simplesmente registrando um novo telefone.

5. Aperto de mão na Internet e redefinição do PIN (fase 5)

A fase final concede ao atacante controle total sobre os fundos.

• Sucesso vinculativo: O aplicativo do invasor chama a API /bindDevice. O banco vê que o token corresponde ao SMS “legítimo” recebido na Fase 4 e vincula a conta bancária da vítima ao telefone do atacante.
• Redefinição do PIN: O atacante usa o recurso “Esqueci o PIN do sistema de pagamento móvel”. O banco envia uma OTP redefinida para o número da vítima, que o Trojan novamente intercepta e encaminha para o atacante.
• Resultado: O atacante define um novo PIN do sistema de pagamento móvel e agora pode transferir todos os fundos das contas bancárias da vítima. O limite é de 5 mil INR nas primeiras 24 horas e 1 Lakh de INR por dia a partir de então.

Por que o ataque funciona:

1. Confie no cabeçalho SMS: O banco presume que um cabeçalho de SMS não pode ser falsificado, o que é verdade, mas não percebe a conteúdo foi enviado por um hacker remoto usando o SIM como marionete.
2. Integridade do aplicativo: O servidor do banco não consegue distinguir facilmente entre um APK legítimo e um APK modificado (reempacotado) usado por um invasor.
3. Interceptação silenciosa: Como o Trojan funciona em segundo plano, a vítima não tem ideia de que as mensagens SMS estão sendo enviadas ou recebidas até que o dinheiro já tenha acabado.

O modelo de segurança atual do Sistema de Pagamento Móvel se baseia no MSISDN (número de celular) fornecido pela rede de telecomunicações como prova absoluta de posse física. Esse ataque prova que A presença física do SIM não é a mesma que a segurança do dispositivo.

APKs modificados

Para acessar as contas da vítima, os atacantes usam as versões modificadas dos aplicativos móveis de pagamento legítimos usados no ecossistema bancário indiano. Após a análise estática, descobrimos que o invasor modificou o pacote APK original de forma que a mensagem SMS para autenticação do Sistema de Pagamento Móvel não seja enviada via SMS, mas redirecionada para um canal de telegrama de onde o atacante poderia encaminhar a mensagem do dispositivo da vítima por meio do trojan instalado. Para esse fim, um dos APKs de pagamento, o invasor modificou o Enviar SMS Funciona em pacotes como o Utils UltraSDK.SIM. Conforme visto no código fornecido abaixo, o atacante adicionou uma função chamada remetente () para a qual a string contendo o token de autenticação (variável chamada str2 nesse caso) foi passada. Já para a função sendTextMessage, a variável str2 não foi passada.

‍

Essa função de remetente estava presente em um pacote personalizado chamado Com. Jallad Baapbol criado pelo atacante especificamente para enviar a string de token para um canal de telegrama por meio de um token de bot de telegrama. A função usa o /Enviar mensagem ponto final do telegrama para encaminhar o token de autenticação conforme visto no código abaixo.

‍

O novo ataque: de APKs reembalados a decepção em nível de sistema operacional via LSposed

Essa metodologia de ataque representa uma mudança de Modificação do aplicativo (alterando o aplicativo) para Manipulação do ambiente de execução (mudando o mundo em que o aplicativo vive). Ao usar o LSposed, o agente da ameaça garante que a assinatura do aplicativo de pagamento permaneça válida, tornando-a invisível para muitas verificações de integridade padrão.

O que é Lsposed?

LSpoed é uma estrutura de conexão Android poderosa e moderna que serve como sucessora dos projetos originais Xposed e EdXposed. Ele opera integrando-se ao Android Runtime (ART) por meio de um método de injeção em nível de sistema (geralmente via Magisk/Zygisk ou Riru). Uma vez instalado, o LSposed permite que “módulos” especializados interceptem e modifiquem a comunicação entre aplicativos e o sistema operacional Android em tempo real. Ao contrário das modificações tradicionais do aplicativo, que exigem “reempacotar” ou “quebrar” um APK (alterando assim sua assinatura digital), o LSposed deixa o aplicativo de destino completamente não modificado no disco. Em vez disso, ele se “conecta” à memória do aplicativo enquanto está em execução, permitindo que o módulo altere o comportamento de métodos Java específicos, como forçar uma verificação de segurança a retornar “verdadeira”, falsificar coordenadas GPS ou, como visto no caso “Digital Lutera”, interceptar e bloquear mensagens SMS enviadas.

Embora o LSposed seja altamente valorizado pela comunidade de entusiastas do Android por personalizações legítimas para usuários avançados, como temas avançados, remoção de anúncios intrusivos ou adição de recursos às ROMs padrão, ele se tornou cada vez mais a ferramenta preferida dos agentes de ameaças. Como ele opera no nível do sistema, ele pode efetivamente aplicativos “cegos” para seu próprio status de segurança. Por exemplo, um módulo malicioso pode conectar as APIs do sistema que verificam o acesso root, fazendo com que o dispositivo pareça “limpo” a um aplicativo bancário enquanto a estrutura rouba simultaneamente dados em segundo plano. No contexto de fraude financeira, ele é usado para contornar a “vinculação do SIM” e a “impressão digital do dispositivo”, fornecendo ao aplicativo de pagamento números de telefone falsificados e registros de SMS injetados, fazendo com que o aplicativo confie em um dispositivo fraudulento como se fosse o telefone legítimo da vítima.

Modus Operandi

Pré-requisitos:

• Uma vítima infectada com recursos de leitura/gravação/encaminhamento de SMS.
• Um dispositivo enraizado a ser usado pelo agente da ameaça para fazer login na conta do Sistema de Pagamento Móvel da vítima (a partir de agora, o Redmi Note 8 Pro/OnePlus não foi testado e está sendo amplamente utilizado pelos TAs)
• O telefone enraizado deve ser atualizado com o OPOSTA módulo.

Parte 1: O mecanismo de ataque (iluminação a gás em nível de sistema operacional)

O ataque funciona “iluminando” aplicativos de pagamento legítimos. O aplicativo solicita informações ao sistema operacional Android (por exemplo, “Qual é o número de telefone do SIM?” ou “Enviar este SMS de registro”), e o módulo malicioso intercepta essa pergunta, fornece uma resposta falsa e oculta as evidências.

O fluxo de trabalho

1. Configuração do ambiente: O fraudador usa um dispositivo enraizado com o LSposed instalado. Eles instalam o módulo “Digital Lutera” e o legítimo, não modificado aplicativo de pagamento.
2. Sequestro do sistema: Na inicialização, o LSposed injeta o código malicioso no processo system_server e no processo do aplicativo de pagamento de destino.
3. Bypass de vinculação de SIM (de saída): Quando o usuário aciona o registro do Sistema de Pagamento Móvel, o aplicativo de pagamento tenta enviar um SMS em segundo plano. O módulo conecta SendTextMessage, captura o conteúdo da mensagem (que contém a chave de criptografia para registro), impede que o SMS real chegue à rede celular e envia os dados para um bot do Telegram. A partir do bot do telegrama, ele é enviado pelos agentes da ameaça a partir do dispositivo da vítima que foi comprometido por meio de engenharia social ou outros meios.
4. Falsificação de identidade: O aplicativo de pagamento chama getLine1Number () para verificar o SIM. O módulo intercepta isso e retorna um número falsificado fornecido pelo servidor de Comando e Controle (C2).
5. Plantio de evidências (entrada/banco de dados): Para satisfazer a verificação do aplicativo de que o SMS foi “enviado”, o servidor C2 envia um comando via Socket.IO. O módulo então grava manualmente um SMS falso no banco de dados interno de SMS do Android, fazendo com que ele apareça na pasta “Enviados”. É a mesma mensagem que foi enviada pelo dispositivo da vítima já comprometida.

Parte 2: Revisão do código técnico

1. O Interceptor: XposedHook.java

Esse é o “cérebro” da operação. Ele usa a API XposedHelpers.findAndHookMethod para modificar o comportamento do sistema.

‍

• Método: Ganchos de envio de SMS
• Lógica: Ele tem como alvo android.telephony.SMSManager.sendTextMessage.
• Ação maliciosa: Ele usa param.setResult (null). No Xposed, definir o resultado em BeforeHookedMethod evita que real método original de sempre em execução. Isso efetivamente silenciar o SMS enquanto o código exfiltra o conteúdo para o Telegram do fraudador.
• Método: Métodos de número de telefone Hook
• Lógica: Ele conecta GetLine1Number e SubscriptionInfo.getNumber.
• Ação maliciosa: Independentemente de qual SIM esteja no telefone, ele retorna a string mobileNo do arquivo de configuração. Isso permite que o fraudador registre uma conta no número de telefone A usando um dispositivo que realmente contém o cartão SIM B.

2. O cérebro remoto: HttpServerService.java

Ao contrário de um malware simples que apenas rouba dados, este módulo atua como um Trojan de acesso remoto (RAT).

‍

• Tecnologia: Usos Socket.io para comunicação full-duplex em tempo real.
• Ouvinte do evento: MSocket.on (“inserir sms”,...)
• Lógica: O módulo permanece conectado ao https://noob-production.up.railway.app. A qualquer momento, o atacante pode enviar um objeto JSON para o telefone. Isso é usado para controlar dinamicamente o dispositivo durante uma sessão de fraude ao vivo, permitindo que o invasor reaja aos desafios de verificação bancária em tempo real.

3. O fabricante de evidências: SmsContentInserter.java

Essa classe lida com a fase de “Injeção Local”.

‍

• URI de destino: conteúdo: //sms/sent
• Lógica: Ele usa o ContentResolver para inserir manualmente uma nova linha no provedor de SMS do sistema.
• Ação maliciosa: Ele define o tipo como 2 (Mensagem enviada) e o status como 0 (Sucesso). Isso garante que, se o aplicativo de pagamento escanear a pasta “Enviado” para verificar se o SMS de registro foi realmente enviado, ele encontre um registro perfeito e falsificado.

4. A configuração furtiva: ConfigManager.java

Essa classe gerencia as configurações e a persistência do módulo.

‍

• Técnica de endurecimento: Ele armazena sua configuração em /data/local/tmp/sms_hook_config.json. Esse diretório geralmente é usado para binários de sistema de baixo nível e geralmente é ignorado pelos aplicativos “limpadores” padrão de segurança móvel.
• Abuso raiz: O código chama runAsRoot (“chmod 666...”). Isso garante que, mesmo que o arquivo seja criado em um diretório protegido do sistema, o módulo (executado em diferentes processos do aplicativo) sempre possa ler e gravar nele. Ele também usa ReentrantReadWriteLock para garantir que a configuração possa ser atualizada pelo servidor C2 sem travar os ganchos.

Por que isso é uma “evolução” nas táticas de ameaças?

• Ignora a verificação de assinatura do APK: Os APKs reembalados falham no Google Play Protect e nas verificações de assinatura em nível bancário. Este módulo deixa o binário do aplicativo 100% original.
• Controle em nível de sistema operacional: Ao conectar o TelephonyManager, o invasor controla a percepção da realidade do aplicativo. O aplicativo não tem como saber se a string retornada por getLine1Number () é uma mentira.
• Orquestração de fraudes em tempo real: O uso do Socket.io em vez de uma simples pesquisa HTTP permite que o invasor sincronize suas ações com as ações da vítima (ou do banco), possibilitando superar janelas de registro urgentes.

Atribuição

A partir do código-fonte, descobrimos que este APK tinha codificado um nome de usuário de telegrama chamado @Syntext_Erorr (ID do telegrama: 7975048256). Nossa análise mais aprofundada da atividade de telegrama do nome de usuário revela:

• Ator alvo: @Syntext_Erorr/@Berlin_Market
• Alias primário: Berlim

A análise das comunicações do Telegram associadas ao @Syntext_Erorr (incorporado no módulo LSposed “Digital Lutera”) confirma que o ator é um desenvolvedor sofisticado especializado em Engenharia reversa do Android e Fraude fintech. O ator, operando sob o pseudônimo “Berlim”, atua como desenvolvedora de ferramentas e prestadora de serviços para operações de “desvio do sistema de pagamento móvel” e “saque”. As comunicações revelam esforços ativos para contornar SDKs de segurança móvel de ponta e um profundo envolvimento no ecossistema clandestino indiano de “cardagem” e “pilhagem”.

Principais descobertas e análise de intenções

A. Exploração do sistema de pagamento móvel e operações de saque

O ator anuncia explicitamente serviços que correspondem à funcionalidade do módulo “Digital Lutera”.

• Citações diretas: “Fazendo c @shout Pul byp @ss. Min 15K max 1L. 40% lungi ajao [vem com 40% de corte]. conjunto de pinos r3 disponível.”
• Análise: Berlim oferece a drenagem de contas bancárias por meio de desvios do Sistema de Pagamento Móvel. A menção de “redefinição de PIN” valida a revisão de código anterior, mostrando a capacidade do módulo de interceptar OTPs para redefinir os PINs do sistema de pagamento móvel, garantindo controle total sobre os fundos das vítimas.

B. Alvo: SDK antifraude do Axis Bank e do Protectt.ai

Uma mensagem crítica mostra o ator enfrentando uma falha em um aplicativo bancário específico.

• Aplicativo de destino: Axis Mobile (com.axis.mobile).
• Obstáculo de segurança: libprotect-native-lib.so.
• Análise: O ator forneceu um crash dump detalhado (JNI_Onload) indicando que eles estão tentando fazer engenharia reversa ou “conectar” o Protectt.ai biblioteca de segurança. O Protectt.ai é um SDK especializado em anti-fraude/anti-enganchamento usado pelos principais bancos indianos. Isso prova que o ator está trabalhando ativamente para desenvolver seu módulo para se manter à frente das defesas bancárias modernas.

C. Aquisição de identidade e conta

Berlim frequentemente busca canais de comunicação não rastreáveis.

• Requisito: “É necessário um número falso do WhatsApp em qualquer país para uso pessoal.”
• Especificidades: Solicita contas do Telegram com códigos de país como +977 (Nepal) ao declarar explicitamente “não +91 [Índia], +92 [Paquistão].”
• Análise: O ator está praticando a segurança operacional (OPSEC) evitando números de sua própria região (provavelmente a Índia) para complicar a atribuição e evitar a aplicação da lei local.

D. Conjunto de habilidades de engenharia reversa

As comunicações no “RevengI Chat” e no “Reverse Engineering Lab” mostram que o ator é visto como um desenvolvedor de alto nível.

• Conjunto de habilidades: Proficiência em modding em C ++, Java e Flutter.
• Pedagogia: Berlim afirma ter um “Curso Avançado” à venda, sugerindo que eles são mentores/fornecedores de outros agentes de ameaças de nível inferior.

Grupo Hinata

Com base nos registros do Telegram que analisamos, a conexão entre o ator @Syntext_Erorr (Berlim) e o “Grupo Hinata” é social e educacional, enraizado nos anos fundamentais do cenário indiano de modificação e engenharia reversa do Android.

Aqui está o detalhamento específico dessa conexão:

1. A relação “ex-alunos”

Em uma mensagem datada de 25 de setembro de 2025, Berlim responde a outro usuário do grupo MUNDO PAGAL 🔥, dizendo:

“Sou eu, Cyber Zone Academy, você se lembra do grupo de Hinata, onde todos nós passamos o tempo?”

Isso indica que Grupo Hinata era um centro principal ou “bebedouro” onde esses atores se encontravam e passavam um tempo significativo. No underground indiano do Telegram, “Hinata” (provavelmente um identificador inspirado no personagem de anime) se refere a um conhecido administrador de grupos dedicados a decifrar aplicativos e compartilhar dicas de engenharia reversa.

2. Transição de “Modder” para “Fraudster”

A conexão sugere um caminho evolutivo:

• A Era Hinata: Berlin provavelmente era estudante ou colaboradora do grupo de Hinata, com foco na modificação geral do Android (remoção de anúncios de aplicativos, desbloqueio de recursos premium).
• A era da Cyber Zone Academy: Berlim desenvolveu sua própria marca, “Academia da Zona Cibernética” onde ele passou de participante para mentor. Aqui, ele começou a vender “Cursos Avançados” (conforme mencionado na mensagem 91650).
• A era digital Lutera: Berlim agora transformou em arma as habilidades de engenharia reversa aprendidas nos dias de “Hinata” para criar o Lutera digital módulo para roubo financeiro e desvio do sistema de pagamento móvel.

3. Círculo social compartilhado

Os registros mostram Berlin interagindo com usuários que o reconhecem desde seus primeiros dias. Essa comunidade atua como sistema de comprovação. Ao mencionar o “Grupo Hinata”, Berlin está estabelecendo sua “credibilidade nas ruas” ou reputação como um ator de longo prazo capaz de criar confiança com potenciais “operadores” (clientes) que desejam comprar suas ferramentas de desvio do Sistema de Pagamento Móvel.

4. Link operacional (Cyber Zone Academy)

Berlim se identifica como o rosto de Academia Cyber Zone. Essa academia provavelmente atua como uma fachada ou um campo de recrutamento, onde ele identifica modders habilidosos do círculo de Hinata e os atrai para projetos de fraude financeira mais lucrativos e de alto risco, como os desvios do Axis Bank/Protectt.ai.

Berlim é um “graduado” proeminente do círculo de modding da Hinata. Ele usa o Grupo Hinata como um ponto de referência histórico compartilhado para interagir com outros engenheiros reversos veteranos que agora passaram de uma modificação inocente de aplicativos para crimes cibernéticos graves. Ele efetivamente aproveitou a comunidade criada pela Hinata para comercializar seu próprio malware “Academy” e seu malware “Digital Lutera”.

Ponteiros principais

• Origem geográfica: Alta confiança de Origem indiana.
  
  • O ator usa gírias em hindi/hinglish.
  • O foco principal da monetização é Sistema de pagamento móvel, um sistema exclusivo da Índia.
  • Segmentação específica do ecossistema de pagamentos móveis na Índia por meio de APKs modificados.
• Perfil psicográfico: Berlim é um ator “Alfa” nesse ecossistema. Ao contrário dos roteiristas que simplesmente compram ferramentas, Berlin entende o Android Runtime (ART) e o JNI (Java Native Interface). Eles provavelmente são um desenvolvedor autodidata ou um ex-desenvolvedor júnior de Android que fez a transição para o cibercrime para obter maiores margens de lucro (cortes de 40% em transferências de 1 lakh de INR)

Impacto

O impacto dessa mudança — de APKs modificados para sequestro de estruturas em nível de sistema — é profundo. Isso quebra fundamentalmente o modelo de segurança sobre o qual os ecossistemas bancários e de pagamento móveis modernos (como o Sistema de Pagamento Móvel) são construídos. Já podemos ver na captura de tela abaixo que os agentes de ameaças começaram ativamente a usar esse módulo LSPOSED para fazer login nas contas do Sistema de Pagamento Móvel de suas vítimas. Até agora, esse único grupo tem mais de 500 mensagens de login.

‍

1. Erosão da segurança “SIM Binding”

O principal pilar de segurança para pagamentos móveis em muitas regiões (especialmente na Índia) é Encadernação SIM—a suposição de que uma conta bancária só pode ser acessada se o cartão SIM físico estiver presente no dispositivo.

• O impacto: Este módulo torna o SIM Binding obsoleto. Ao falsificar o número de telefone e interceptar o SMS de registro, os agentes de ameaças podem registrar a conta bancária da vítima em um dispositivo localizado a milhares de quilômetros do SIM real. Isso permite aquisições de contas não autorizadas em grande escala.

2. Ignorar as verificações de integridade do aplicativo

Tradicionalmente, os bancos protegem seus aplicativos verificando a Assinatura APK. Se um hacker modificar o aplicativo para roubar dados, a assinatura muda e o aplicativo é bloqueado.

• O impacto: Porque o LSposed engancha o sistema e não o aplicativo, o aplicativo de pagamento permanece 100% original e inalterado no disco. Ele passa por todas as verificações de assinatura, escaneamentos do Play Protect e auditorias de integridade padrão, causando o ataque invisível para as soluções tradicionais de segurança móvel.

3. Orquestração de fraudes em tempo real (C2)

O uso do Socket.IO para uma conexão persistente com um servidor de Comando e Controle (C2) transforma um simples “ladrão” em um Trojan de acesso remoto (RAT).

• O impacto: Os atacantes podem orquestrar fraudes em tempo real. Quando uma vítima é solicitada a fazer uma OTP ou uma contestação de registro, o atacante pode “enviar” instantaneamente um comando para o dispositivo para injetar o SMS necessário ou falsificar a resposta necessária. Isso permite que eles ignorem os obstáculos de segurança urgentes que os bots automatizados podem ignorar.

4. Roubo da autenticação de dois fatores (2FA)

Ao conectar o SMSManager, o módulo tem uma “visão de Deus” de todo o tráfego de SMS de saída (e potencialmente de entrada).

• O impacto: Códigos 2FA legítimos, alertas de transações e comunicações bancárias confidenciais são enviados diretamente para o Telegram. Isso dá ao atacante a capacidade de autorizar transferências de alto valor, alterar senhas de contas e bloquear permanentemente as vítimas de suas próprias vidas financeiras.

5. Persistência oculta em nível de sistema

A maioria dos usuários sabe como desinstalar um aplicativo suspeito. No entanto, um módulo LSposed é uma extensão do próprio sistema operacional Android.

• O impacto: Mesmo que o usuário exclua o aplicativo de pagamento e o reinstale, os “ganchos” permanecem ativos na memória do sistema. O comprometimento é persistente no nível do sistema operacional, o que significa que cada aplicativo bancário ou de pagamento instalado nesse dispositivo é automaticamente comprometido a partir do momento em que é aberto.

6. Falha regulatória e de conformidade

As instituições financeiras são obrigadas por lei (como as diretrizes do RBI na Índia) a garantir a vinculação segura de dispositivos e a autenticação multifatorial.

• O impacto: Esse ataque cria uma “lacuna de conformidade”. Os bancos podem acreditar que estão em conformidade porque usam a vinculação SIM, mas este módulo prova que essas verificações estão sendo ignoradas. Isso leva a aumento da responsabilidade dos bancos e a perda da confiança do consumidor no ecossistema de pagamento digital.

7. Escalabilidade para “Fraude como serviço”

A arquitetura deste módulo (chaves de registro, servidor C2, bots do Telegram) sugere que ele foi construído para rede de fraude distribuída.

• O impacto: Um único desenvolvedor pode vender esse “kit” para centenas de “operadores” de baixo nível. Esses operadores não precisam de habilidades técnicas; eles simplesmente instalam o módulo, digitam a chave e começam a saquear contas. Isso reduz a barreira de entrada para crimes cibernéticos, levando a um aumento nas fraudes financeiras localizadas.

Remediações

Defender-se contra a conexão no nível do sistema é muito mais difícil do que detectar um APK modificado, pois o código do aplicativo permanece legítimo. Para combater esse ataque de “Gaslighting”, um Defesa em profundidade uma estratégia é necessária, com foco na certificação de hardware, autoproteção em tempo de execução e validação de back-end. Aqui estão as correções recomendadas para desenvolvedores e instituições financeiras:

1. Implemente a API Play Integrity (Strong Integrity)

A detecção tradicional de raízes é facilmente ignorada pelo LSposed. Os desenvolvedores devem migrar para o Google API Play Integrity.

• Ação: Verifique especificamente o veredicto de MEETS_STRONG_INTEGRITY. Isso confirma que o dispositivo está executando uma versão certificada do Android e que o bootloader está bloqueado.
• Impacto: Como o LSposed requer um bootloader desbloqueado ou uma partição de sistema comprometida, impor uma integridade forte bloqueará a maioria dos dispositivos capazes de executar esse módulo.

2. Autoproteção de aplicativos em tempo de execução (RASP)

Como o ataque acontece na memória do aplicativo durante o tempo de execução, o aplicativo deve auditar seu próprio ambiente:

• Detecção de gancho: Use código nativo (C/C++ via JNI) para verificar a presença de estruturas de conexão conhecidas. Procurar por liblsposed.so, libriru.so ou o XposedBridge.jar no arquivo de mapas (/proc/self/maps) pode identificar a estrutura.
• Análise de Stack Trace: Verifique periodicamente os rastreamentos de pilha de métodos críticos (como SendTextMessage). Se um método mostrar uma chamada originada de um pacote desconhecido ou inesperado (como de.robv.android.xposed), o aplicativo deverá encerrar a sessão.

3. Mova a lógica crítica para o código nativo (JNI/NDK)

O LSposed é principalmente uma estrutura de conexão em nível Java.

• Ação: Mova a lógica para verificação de identidade, verificação de SIM e envio de SMS para bibliotecas C/C++ nativas.
• Impacto: Embora a conexão nativa (por meio de ferramentas como a Frida) seja possível, ela é significativamente mais complexa de executar e manter do que os ganchos Java usados no módulo “Digital Lutera”.

4. Melhore a “vinculação do SIM” com a validação do lado da operadora

Não confie no dispositivo para informar que o SMS foi enviado.

• Ação: O fluxo de registro não deve depender do retorno de chamada “Sucesso” do aplicativo. Em vez disso, o back-end deve verificar se o SMS realmente chegou ao código abreviado/gateway do banco com os metadados corretos (data e hora, número de origem da operadora e carga útil de criptografia correspondente).
• Verificação fora da banda: Use um modelo “push-pull” em que o servidor envia uma notificação push criptografada para o aplicativo, e o aplicativo deve responder por meio de um canal de dados seguro (HTTPS), ignorando totalmente a camada de SMS para etapas confidenciais.

5. Detecção de indicadores ambientais “sujos”

Os APKs usados, como o módulo “Digital Lutera”, deixam rastros específicos que os SDKs de segurança podem procurar:

• Presença do arquivo: Procure o arquivo de configuração em /data/local/tmp/sms_hook_config.json ou o nome do pacote com.digitalluteraMobile Payment System.LSPosedModule.
• Assinatura dos serviços do sistema: Monitore conexões de soquete incomuns em tempo real (como Socket.IO) em execução no contexto de aplicativos no nível do sistema.

6. Fixação de certificados e criptografia de tráfego

Embora este módulo se concentre em ganchos de API locais, ele exfiltra dados via HTTPS para o Telegram e uma API remota.

• Ação: Certifique-se de que o aplicativo de pagamento use estritamente Fixação de certificados SSL.
• Impacto: Embora não impeça o gancho de API local, evita que o dispositivo seja submetido a ataques adicionais de man-in-the-middle (MITM) em nível de rede, que geralmente acompanham esses kits fraudulentos.

‍

Referências

• *Fonte de inteligência e confiabilidade da informação - Wikipedia
• ^#Protocolo de semáforo - Wikipedia
• https://github.com/LSPosed/LSPosed 
  

‍