BTMOB RAT: Por dentro de uma Plataforma de Fraud-as-a-Service com +1400 servidores ativos

O rastro

Em fevereiro de 2023, a processadora de pagamentos em criptomoedas Freewallet congelou cerca de US$ 75 mil em ganhos acumulados de um cliente na Síria. A empresa exigiu uma verificação KYC. Esse atrito financeiro acabou rompendo a segurança operacional que um ator de ameaça conhecido como EVLF vinha mantendo havia aproximadamente oito anos, e deu à empresa de cibersegurança CYFIRMA o fio de que precisava para desvendar uma das operações de RAT para Android mais prolíficas do mercado.

EVLF (também conhecido como EvilWolf ou "EVLF DEV") desenvolvia e vendia trojans de acesso remoto para Android a partir da Síria desde aproximadamente 2015. Seus primeiros produtos acompanhados publicamente foram o CypherRAT e o CraxsRAT, distribuídos por meio de uma loja na surface web e de um canal no Telegram (@craxso) que chegou a reunir mais de 10 mil inscritos. Ao longo de três anos, estima-se que 100 ou mais atores de ameaça tenham comprado licenças vitalícias. O ecossistema acabou se fragmentando quando compradores começaram a liberar versões crackeadas gratuitamente, um padrão que se repetiria, quase da mesma forma, com o BTMOB.

A linhagem que conecta o CraxsRAT ao BTMOB passa por uma família intermediária chamada SpySolr. Múltiplas análises independentes (Cyble, ESET, ANY.RUN, Mallory.ai) confirmam que o BTMOB é uma evolução do SpySolr, que por sua vez deriva da base de código do CraxsRAT. O "DNA" arquitetural é inconfundível: os mesmos padrões de abuso do Accessibility Service do Android, comunicação C2 semelhante baseada em WebSocket e estruturas de comando sobrepostas. Mas o BTMOB representou um salto de ambição: deixou de ser um RAT de uso geral para se tornar uma plataforma criada especificamente para fraude bancária, com uma experiência profissional para o operador.

Quando a Cyble Research e o Intelligence Labs (CRIL) publicaram a primeira análise pública em 12 de fevereiro de 2025, baseada em uma amostra descoberta em 31 de janeiro, o malware estava na versão BT-v2.5. Ele era distribuído como lnat-tv-pro.apk por meio de um site de phishing que se passava pelo iNat TV, uma plataforma de streaming turca.

O servidor C2 resolvia para hxxp://server[.]yaarsa[.]com/con. Esse domínio, yaarsa, continua presente como nome do diretório de backend em todos os pacotes de código-fonte vazados que analisamos. Todo o backend do C2 ainda fica em /yaarsa/private/, o banco de dados continua se chamando clients e todos os handlers PHP ainda seguem a convenção de nomes yarsap_NNNNN.php, estabelecida na época em que yaarsa[.]com era o servidor principal.
A infraestrutura mudou. O código se lembra.

Desde então, o BTMOB continuou evoluindo. Obtivemos os pacotes de código-fonte das versões 4.5.7 e 4.6, que juntos formam o kit completo do operador: o painel VB.NET (80 arquivos .vb), o pipeline server-side de build de APK (executáveis .NET SolrStarter/SolrWorker), a árvore completa do código Android (101 arquivos Java: código-fonte genuíno de desenvolvimento, não um decompile), o dropper e todo o backend C2.

O que o código-fonte revela vai muito além da adição de funcionalidades. Ele mostra uma transformação estrutural: de uma operação centralizada para uma franquia criminosa self-service, com API para revendedores, branding whitelabel, geração automatizada de APK e recursos que vão muito além da fraude bancária, incluindo DDoS, cryptomining e exploração de redes.

Este relatório acompanha a trajetória do BTMOB desde suas raízes nos projetos anteriores de malware de um desenvolvedor sírio até sua forma atual, como uma plataforma completa de ataques Android, e documenta o que o código-fonte vazado revela.

O desenvolvedor se pronuncia

EVLF opera a conta oficial no Telegram @CRAXSO e mantém uma loja na surface em btmobrat[.]net. A loja direciona os visitantes diretamente para o Telegram: um botão "Join us on Telegram" leva à comunidade da operação, composta por três grupos de conversa.

A mensagem de FAQ em um dos grupos do Telegram afirma que o desenvolvedor do BTMOB é "EVLF (EvilWolf), proprietário e administrador do canal oficial do Telegram @CRAXSO" e que ele está "presente exclusivamente neste canal".

O FAQ também aborda uma controvérsia que ilustra diretamente a fragmentação da plataforma: um impostor usando o handle @btmobadmin teria comprado o código-fonte e começado a lançar versões customizadas enquanto se passava pelo desenvolvedor original. Segundo o FAQ, isso acontece há mais de dois anos. Não se trata de um caso isolado; é a consequência inevitável de vender acesso ao código-fonte de uma ferramenta que já possui uma reputação estabelecida.

O preço real do código-fonte

O histórico de preços do BTMOB parece o de uma startup mudando de estratégia, com a diferença de que o produto é um trojan bancário.

A trajetória dos preços conta uma história de pressão de mercado. À medida que versões crackeadas e vazadas se proliferaram, os preços oficiais despencaram. Diversos vazamentos aceleraram a fragmentação: pacotes de código-fonte começaram a circular em fóruns underground e canais do Telegram em meados de 2025 e, em janeiro de 2026, o código-fonte do BTMOB v3.6.3 apareceu em um fórum da dark web. Por volta do mesmo período, os pacotes v4.x que analisamos,contendo o backend completo e todo o kit operacional, passaram a circular por canais de distribuição secundários.

De produto a franquia

O código-fonte revela o momento exato em que o modelo de negócio mudou.

No btlogin.php, a validação de HWID (Hardware ID), que antes vinculava cada conta de operador a uma única máquina, está comentada. O changelog da V3.2, de 13 de abril de 2025, deixa isso explícito: "Disabled BTMOB device hardware lock, you can now change your PC anytime."

Isso não foi um bug. Foi uma decisão de negócio. Ao remover o vínculo por HWID, EVLF transformou o BTMOB de um serviço centralizado e restrito em um produto portátil que os compradores poderiam executar em qualquer máquina. E mais importante: revender.

O backend confirma o novo modelo. Uma tabela resellers, com autenticação por sellerkey, permite que terceiros criem contas de operador, emitam códigos de ativação e recebam pagamentos em USDT.

Hoje, o BTMOB já não representa uma operação unificada. É uma marca associada a uma base de código amplamente disponível, operada por um número desconhecido de atores independentes, com diferentes níveis de competência e intenção.

BTMOB chega ao Brasil

O Brasil sempre foi terreno fértil para malware bancário em Android. Com o Pix, o sistema de pagamentos instantâneos do país, processando mais de 40 bilhões de transações em 2025, alta adoção de mobile banking e um underground cibercriminoso ativo e fragmentado, o mercado estava pronto para uma ferramenta como o BTMOB.

A chegada da plataforma ao Brasil seguiu o mesmo modelo de franquia observado em outros mercados: operadores locais adquiriram a ferramenta, adaptaram-na para alvos brasileiros: overlays bancários, iscas em português e fluxos específicos para Pix, e passaram a distribuí-la para outros compradores. A ThreatFabric documentou um desses operadores: um ator de ameaça conhecido como go1ano (também rastreado como "go1ano Developer"), que afirmava ser um "parceiro confiável" tanto do BTMOB quanto da família de spyware GhostSpy. A investigação da OSINT Industries sobre go1ano mapeou um padrão de dupla identidade que conectava atividade profissional legítima a operações cibercriminosas, com registros de domínio desde 2015 e aparições em oito vazamentos de dados entre 2015 e 2025.

Go1ano não é um caso isolado. Páginas de alerta associadas à marca BTMOB listam centenas de contas em blacklist, acusadas de revender a plataforma de forma não autorizada. Um número que diz menos sobre a eficácia desse controle e mais sobre a escala da distribuição paralela.

O builder traz 14 templates de isca pré-configurados imitando aplicativos populares: Netflix, variantes do WhatsApp, AdBlocker, Snaptube e Picsart, e a primeira amostra documentada tinha usuários turcos como alvo por meio de um falso aplicativo do iNat TV. No Brasil, porém, o phishing vai muito além desses templates. Campanhas observadas distribuem o BTMOB por páginas falsas e bem produzidas da Google Play Store, cobrindo diferentes categorias: aplicativos de rastreamento de encomendas que se passam por transportadoras como a Rodonaves, "módulos de segurança" bancários, serviços de streaming e apps utilitários. Cada clone vem completo, com avaliações fabricadas, milhares de avaliações falsas em português e seções de segurança de dados igualmente falsas.

O changelog da V3.3 (abril de 2025) adicionou páginas de acessibilidade em espanhol e português, e o dropper oferece localização para sete idiomas: EN, AR, ZH, TR, PT, RU e ES. A prioridade dada ao árabe e o suporte a interfaces da direita para a esquerda nas primeiras versões são consistentes com a origem síria de EVLF; o português foi adicionado posteriormente, impulsionado pela demanda do mercado.

Por dentro da plataforma

O BTMOB não é apenas um malware. É uma plataforma formada por cinco componentes interligados, todos executados em um único host Windows com XAMPP.

O payload APK (101 arquivos Java, código-fonte genuíno do Android Studio, não um decompile) é o RAT instalado nos celulares das vítimas. O dropper é um fork modificado do Shelter, um aplicativo open source que explora o Work Profile do Android para isolamento. O painel VB.NET (BTMob.exe) é o console desktop do operador. O backend C2 (PHP, MySQL, Node.js) gerencia 45 endpoints sob /yaarsa/private/. E o builder de APK (SolrStarter.exe/SolrWorker.exe) funciona como um pipeline baseado em templates: o operador preenche um formulário: nome do app, ícone, endereço C2, permissões, e o servidor gera um APK pronto para distribuição. Nenhum conhecimento de desenvolvimento é necessário.

O design é monolítico para os padrões atuais, mas operacionalmente simples: um servidor, uma instalação, tudo funciona. O cliente-alvo é um operador de fraude, não um engenheiro DevOps.

Rastreando a infraestrutura

O código-fonte vazado oferece algo valioso aos defensores: conhecimento exato de como um servidor C2 se apresenta externamente, antes mesmo de interagir com qualquer host ativo. Ao acessar a URL raiz do servidor, o que aparece é algo semelhante a uma instalação Apache mal configurada: uma página falsa de 403 Forbidden com um redirect em JavaScript para google[.]com após cinco segundos. Os endpoints operacionais reais ficam escondidos sob /yaarsa/private/.

O falso 403

Em yaarsa/server/websocket-server.js, a constante blocksmg define 18 linhas de HTML: uma página intitulada 403 Forbidden, com a mensagem "Redirecting in 5 seconds..." e um redirect em JavaScript para google[.]com após cinco segundos. A mesma página é servida na rota raiz do Node.js, na porta 3000. Cópias quase idênticas aparecem em yaarsa/index.php e yaarsa/user/login.php, com uma diferença: nesses arquivos, o timer em JavaScript dispara em 1 milissegundo, e não em 5 segundos, apesar de a página continuar exibindo a mensagem "5 seconds".

Do código-fonte à infraestrutura ativa

Plataformas como Shodan, FOFA, Censys, ZoomEye e Hunter indexam respostas HTTP de hosts acessíveis publicamente. Cada plataforma calcula suas próprias fingerprints de resposta: o Shodan usa html_hash, o FOFA usa body_hash, enquanto o Censys indexa o corpo completo das respostas, mas todas capturam o mesmo HTML bruto. Isso significa que a mesma página falsa de 403 encontrada no código-fonte pode ser pesquisada nas principais plataformas de varredura da internet.

Usamos o html_hash do Shodan para demonstrar a abordagem, mas o padrão do HTML do falso 403, a combinação de portas e a página padrão do IIS independem da plataforma.

A porta 80 na maioria dos servidores C2 do BTMOB exibe a página padrão de boas-vindas do IIS no Windows Server. Isso acontece porque o guia de instalação orienta os operadores a fazer o deploy em Windows Server usando XAMPP, mas não os manda desativar o serviço IIS que vem ativo por padrão. O resultado são dois servidores web no mesmo host: o IIS responde na porta 80 com sua página padrão, enquanto o Apache serve a aplicação C2 real em outras portas.

A porta 3000 é o flanco exposto. O servidor Node.js/Express entrega a página falsa de 403 em sua rota raiz, imitando um erro padrão do Apache antes de redirecionar para google[.]com após cinco segundos.

A página falsa de 403 na porta 3000 produz o valor de html_hash -983012381. No Shodan, a busca é:

http.html_hash:-983012381 port:3000

A consulta retornou 1.402 hosts. A grande maioria deles serve exatamente o HTML definido no código-fonte: um DOCTYPE HTML 2.0 imitando um erro do Apache, <title>403 Forbidden</title>, a mensagem "Redirecting in 5 seconds..." e um redirect em JavaScript para google[.]com.

Confirmando o achado

Entre os 1.402 resultados, verificamos manualmente diversos hosts e confirmamos que executavam a stack completa do BTMOB. Os servidores C2 confirmados compartilham uma assinatura de portas consistente. Ao visitar cada porta em um host confirmado, 77[.]111[.]101[.]24, é possível observar a stack completa:

As camadas de banco de dados e acesso remoto são igualmente visíveis. O MySQL na porta 3306 responde a conexões externas, enquanto o servidor WebSocket na porta 8080 se identifica com um 426 Upgrade Required quando acessado por HTTP convencional:

A fábrica de Bypass

Enquanto analisávamos resultados do Shodan em busca de servidores C2 do BTMOB, encontramos diversos hosts com um título de página inesperado: "painel de controle elite." Não eram painéis C2. Eram outra coisa completamente diferente. Um dork específico confirmou o padrão:

html:"painel de controle elite"

A busca retornou 19 hosts, a maioria no Brasil, todos executando uma plataforma compartilhada chamada "Painel de Controle Elite". O serviço normalmente roda na porta 5000 e oferece um fluxo direto: o operador envia um APK malicioso, a plataforma o processa para evadir o Google Play Protect e devolve uma versão modificada pronta para distribuição.

A segurança operacional está no mesmo nível de sofisticação que se esperaria de um serviço de bypass drag-and-drop: as credenciais padrão são admin:admin123, e a maioria dos operadores simplesmente nunca as altera. O mesmo login funciona em várias instâncias ativas, um detalhe que diz menos sobre a segurança da plataforma e mais sobre quem a opera.

Cada operador aplica sua própria marca à mesma plataforma. No momento da publicação, as seguintes instâncias estavam ativas:

O painel expõe o pipeline completo:

• Upload e processamento de APK: os operadores arrastam e soltam um APK; o serviço o modifica e devolve uma versão com bypass.
• Gerenciamento de revendedores: os operadores podem cadastrar usuários, acompanhar o histórico de builds e revogar acessos.

Isso não é um servidor C2 de RAT. É a camada da cadeia de distribuição que fica entre um builder como o BTMOB e o celular da vítima: gere o APK, envie-o para a plataforma, receba uma versão que passa pelo Play Protect e faça a distribuição. A instância "BT Bypass Rat" confirma que essa plataforma está sendo utilizada dentro do ecossistema BTMOB.

Essas são apenas as instâncias indexadas sob um único nome de painel compartilhado. O modelo de "bypass-as-a-service" é genérico: qualquer operador pode implantar sua própria instância com outro título.

RADAR: Personalize, Processe, Assine, Publique

Outra plataforma identificada durante nossa pesquisa opera sob o nome RADAR: um autodenominado "sistema de processamento Android" hospedado em playstoreapps[.]pro.

O RADAR automatiza todo o pipeline de preparação maliciosa de APKs. O operador envia um APK limpo, e o sistema cuida do restante em sete etapas: extração, decodificação com apktool, preparação do helper, injeção do payload, recompilação, assinatura com um keystore e entrega do pacote final. O log do build é transmitido em tempo real. Nenhum conhecimento técnico é necessário, a própria plataforma faz questão de dizer isso.

O painel administrativo, acessível com credenciais padrão que nunca foram alteradas, revela a escala operacional: três contas ativas, duas no tier "VIP Elite" e nove builds processados no dia em que realizamos a observação. A plataforma oferece gerenciamento de usuários com níveis de acesso, cotas de build e entrada de novos usuários por convite: o mesmo padrão de infraestrutura de franquia observado em todo esse ecossistema.

A lista de aplicativos dentro do painel mostra o que esses operadores estão construindo: iscas de rastreamento de encomendas (Jadlog, Movimente Express), plano de saúde (Amil), programas de fidelidade (Livelo), serviços governamentais (MeuINSS) e prompts genéricos de configuração, tudo adaptado para alvos brasileiros.

Nove builds em um único dia, em uma plataforma com três contas. A distância entre "quero executar uma campanha" e "tenho um APK assinado" se resume a arrastar e soltar um arquivo.

Uma entrega real, observada

Durante um trabalho de resposta a incidentes, observamos um operador do BTMOB mirando clientes de uma grande rede varejista brasileira. A cadeia de ataque consistia em uma operação de engenharia social em múltiplos estágios, conduzida inteiramente pelo WhatsApp e combinando mensagens automatizadas com interação de voz em tempo real, um nível de sofisticação operacional que vai muito além de uma campanha de phishing em massa.

Estágio 1: seleção precisa do alvo

O contato inicial chegou pelo WhatsApp a partir de um perfil configurado com a identidade visual e o logotipo oficiais da varejista. A mensagem, apresentada como um "Assistente Virtual", começava exibindo o nome completo da vítima, número de associado, CPF, data de nascimento, telefone e categoria atual do plano.

Esse nível de precisão sugere acesso a bases de dados previamente comprometidas ou a informações agregadas de múltiplos vazamentos brasileiros. O efeito é imediato: quando algo que parece ser um canal oficial repete seus próprios dados para você, o ceticismo desaparece antes mesmo de surgir.

Estágio 2: A oferta

Em seguida, a mensagem apresentava um falso upgrade de programa de fidelidade, uma categoria premium com benefícios inventados: cinco anos gratuitos, 20% de desconto em lojas parceiras e acesso prioritário a ofertas. A vítima recebia uma escolha binária: (1) Aceitar ou (2) Recusar. Um código interno de referência, (IFBM0I), aparecia na mensagem, sugerindo que o operador utilizava algum sistema para acompanhar campanhas entre diferentes vítimas.

A estrutura reproduz tão bem uma interação legítima de atendimento ao cliente que recusar parece significar abrir mão de um benefício real.

Estágio 3: A ligação, depois o payload

Depois que a vítima aceitou, o "Assistente Virtual" informou que um atendente faria uma ligação para "ativar" o novo plano. Em seguida, ocorreu uma chamada de voz de seis minutos. Esse é o passo crítico. A ligação cumpre três funções: humaniza a interação, dá ao operador a oportunidade de orientar a vítima a habilitar "fontes desconhecidas" no dispositivo Android e cria urgência suficiente para superar qualquer hesitação que ainda reste.

Poucos minutos após o fim da ligação, um arquivo .apk de 4,1 MB foi enviado diretamente pelo WhatsApp. Depois de instalado, o dropper iniciou o ciclo de infecção do BTMOB RAT.

O que isso mostra

Não se trata de uma campanha de "spray-and-pray". O operador já possuía os dados reais da vítima antes do primeiro contato, utilizou uma identidade de marca falsificada, seguiu um fluxo roteirizado de engenharia social com um sistema de rastreamento por referência, colocou uma pessoa real na ligação para contornar objeções e habilitar o "sideloading" e, por fim, entregou o payload pelo WhatsApp, um canal que a maioria das ferramentas de segurança não inspeciona. Cada etapa foi projetada para remover mais uma camada de dúvida.

Um vetor diferente: a Play Store falsa

Durante nossa pesquisa sobre os mecanismos de entrega do BTMOB, identificamos um segundo canal de distribuição operando em paralelo às campanhas de WhatsApp: um clone quase perfeito da Google Play Store hospedado em playstoreap[.]lovable[.]app.

O site reproduz o layout, a identidade visual e o fluxo de instalação da Play Store, servindo páginas falsas de aplicativos populares no Brasil: Nubank, TikTok e até um suposto serviço do Gov.BR. Cada página exibe avaliações e números de downloads fabricados para transmitir confiança, embora as falhas apareçam de perto: zero reviews, nenhuma descrição e todos os aplicativos classificados como "Outros".

A página inicial da loja revela todo o inventário do operador, incluindo uma entrada para GhostNFC, uma ferramenta de relay NFC pertencente ao mesmo ecossistema brasileiro de fraude em que o BTMOB circula.

A hospedagem merece atenção: lovable[.]app é uma plataforma legítima de criação de aplicações, o que dá ao Phishing um certificado TLS válido e a reputação limpa do domínio. Para a vítima, há um cadeado no navegador, um domínio .app e um botão verde de instalação. Nada parece suspeito. Após nossa pesquisa, a equipe do QuimeraX reportou o site à equipe de Trust & Safety da Lovable, e a loja falsa foi removida.

O que isso significa

O BTMOB não se destaca por uma capacidade isolada. Cada recurso que ele oferece já existe em outras famílias de malware. O que o torna relevante é a abrangência do pacote e o modelo de negócio construído ao redor dele.

De um único desenvolvedor na Síria criando o CypherRAT para uma audiência de script kiddies no Telegram a uma franquia com código-fonte disponível, APIs para revendedores, pagamentos em USDT, geração automatizada de APK e contribuidores externos adicionando bypasses específicos para bancos, a evolução do BTMOB acompanha a profissionalização do ecossistema cibercriminoso como um todo. O desenvolvedor não precisa atacar bancos. Ele vende as ferramentas, recebe pelas assinaturas e deixa uma rede crescente de operadores independentes assumir o risco.

Para os defensores, as implicações são claras. Bloqueios baseados em domínio falham porque não existe um único domínio C2; cada operador mantém sua própria infraestrutura. Os mesmos IOCs aparecem em campanhas sem relação entre si porque constantes criptográficas, delimitadores de protocolo, chaves de assinatura e strings de User-Agent estão embutidos no código-fonte e são compartilhados por todos os operadores. E, como o código-fonte está amplamente disponível, a barreira de entrada se resume a um tutorial no YouTube e uma VM Windows.

A boa notícia é que o esquema criptográfico do BTMOB não mudou desde a v2.5. A assinatura com testkey continua sendo um ponto de referência confiável. A convenção de nomes yarsap_* e a estrutura de diretórios yaarsa/ permanecem estáveis.

A plataforma continuará se fragmentando. Mais variantes, mais operadores, mais adaptações regionais. Mas o "DNA" continua identificável. Agora sabemos o que procurar.

O BTMOB é apenas uma campanha. O ecossistema por trás dele é muito maior

Famílias de malware, códigos-fonte vazados, redes de revendedores e infraestruturas expostas estão constantemente remodelando o cenário de ameaças. O QuimeraX ajuda organizações a identificar essas conexões, rastrear os atores por trás delas e transformar sinais fragmentados em inteligência acionável.

Se você quer entender quais ameaças estão mirando sua organização, e quais infraestruturas, atores e campanhas estão conectados a elas, fale com o QuimeraX.

→ Fale com nosso time de Threat Intelligence

Indicadores de Comprometimento (IOCs)

Fingerprints de Infraestrutura

Indicadores de Rede

Domínios

IPs

Nota: O IP acima é apenas um exemplo confirmado. A consulta do Shodan http.html_hash:-983012381 port:3000 retornou 1.402 hosts no momento da publicação. Use as consultas da tabela de Fingerprints de Infraestrutura acima para obter resultados atuais.

Caminhos do Backend C2