Campanhas que se passam por serviços governamentais iranianos induzem vítimas a instalar APKs maliciosos, capturam dados de cartão, leem mensagens SMS e transformam celulares infectados em nós de distribuição de phishing.
| Componente | Campanhas de smishing com páginas falsas de serviços iranianos e aplicativos Android maliciosos distribuídos como arquivos .apk. |
| Vetor | SMS com aparência legítima leva a uma página de phishing que solicita dados pessoais, induz o download do APK e apresenta uma cobrança pequena para reduzir suspeitas. |
| Impacto | Coleta de dados de cartão, acesso a SMS de autenticação, envio de novas mensagens de phishing a contatos ou alvos definidos e exposição adicional de dados em painéis mal protegidos dos operadores. |
| Prioridade | Bloquear domínios e APKs associados, remover aplicativos suspeitos, revisar permissões de SMS em dispositivos Android, monitorar cobranças indevidas e invalidar cartões potencialmente usados nas páginas falsas. |
| Artefatos | Amostras Android foram descritas com uso de Basic for Android, Firebase Cloud Messaging, arquivos de configuração como assets/port.txt e assets/url.txt, WebView para phishing e permissões de SMS e contatos. |
| IoCs | Infraestrutura citada inclui IP 45.153.241[.]194, domínio oliverdnssop[.]cf e uso recorrente de TLDs gratuitos ou baratos como .tk, .ml, .cf, .xyz e .gq. |
Uma onda de smishing observada no Irã combinou engenharia social, páginas falsas de serviços públicos e aplicativos Android maliciosos para escalar roubo financeiro e propagação automatizada. As mensagens SMS se apresentavam como notificações de sistemas governamentais, inclusive um serviço eletrônico judicial, e avisavam a vítima sobre uma suposta reclamação ou processo aberto. A pressão psicológica desse tema aumenta a taxa de clique, porque o usuário tende a tratar comunicações judiciais como urgentes e legítimas. O fluxo levava a uma página que imitava um portal oficial, coletava informações pessoais e direcionava a instalação de um arquivo .apk fraudulento.
O componente móvel não dependia de técnicas avançadas de exploração do sistema operacional. A operação se apoiava em permissões concedidas pelo próprio usuário e em um pretexto de pagamento de taxa pequena, como 20.000 ou 50.000 riais iranianos, para dar aparência de serviço público. Depois da instalação, o aplicativo solicitava permissões para receber, ler e enviar SMS, além de ler contatos e acessar a Internet. Com essas permissões, o operador conseguia associar dados de cartão capturados na página falsa ao identificador Android do aparelho e aos SMS de autenticação recebidos posteriormente.
A campanha também tinha característica de botnet. Dispositivos infectados não serviam apenas para roubar dados da própria vítima; eles recebiam instruções por Firebase Cloud Messaging e podiam enviar novas mensagens de phishing a outros números. Essa escolha reduz a dependência de números controlados diretamente pelos operadores, dificulta bloqueios simples por remetente e faz com que a cadeia de distribuição pareça vir de números residenciais. A escala descrita inclui dezenas de milhares de instalações ao longo de alguns meses, múltiplas campanhas simultâneas e perdas relatadas que chegaram a valores equivalentes a cerca de US$ 1.000 a US$ 2.000 por vítima em alguns casos.
A cadeia começava com uma mensagem SMS sobre uma suposta notificação judicial ou serviço governamental. O link apontava para uma página de phishing que imitava a aparência de um portal oficial e solicitava dados como nome, telefone e código nacional. Em seguida, a vítima era redirecionada para baixar um APK. Após a instalação, o aplicativo exibia uma tela falsa de autenticação relacionada ao serviço Sana, usado para notificações judiciais eletrônicas no Irã, e pedia número de telefone e número de identidade nacional. O mesmo fluxo apresentava uma cobrança pequena, conduzindo a vítima para uma página de pagamento falsa.
Quando os dados de cartão eram submetidos, a página exibia erro de pagamento, mas as informações já haviam sido repassadas ao operador. O APK permanecia instalado como canal de acesso aos SMS do aparelho. Esse detalhe é central para o impacto da campanha: o roubo do cartão por si só poderia ser bloqueado por mecanismos de autenticação adicional, mas a aplicação maliciosa monitorava novas mensagens e enviava conteúdo e remetente ao servidor de comando e controle. Em versões posteriores, havia marcação adicional para mensagens bancárias com base em termos em persa associados a banco, o que ajudava o operador a priorizar códigos de autenticação e notificações financeiras.
As amostras analisadas foram construídas com Basic for Android. No primeiro lançamento, o aplicativo criava um controle simples de execução por meio de um arquivo local, lia um valor de campanha em assets/port.txt e usava esse dado como identificador de tópico no Firebase Cloud Messaging. O aplicativo anunciava a nova instalação ao painel com o Android ID, coletava SMS existentes para um arquivo local e enviava esse material ao painel. Também carregava uma URL de phishing definida em assets/url.txt dentro de uma WebView, acrescentando o identificador do dispositivo como parâmetro para permitir correlação entre cartão, sessão de phishing e SMS recebidos.
A propagação era acionada por comando remoto. O painel enviava uma instrução de envio, e o aplicativo buscava arquivos com o texto da mensagem e a lista de alvos. Depois, tentava enviar SMS pelo aparelho infectado e reportava se a operação havia sido bem-sucedida comparando com a última mensagem enviada no dispositivo. A infraestrutura web incluía páginas de phishing, painéis de controle e integrações com Telegram para alertar operadores quando uma nova vítima submetia dados. O uso de domínios de curta duração em TLDs como .tk, .ml, .cf, .xyz e .gq permitia troca frequente de URLs com baixo custo operacional.
A superfície principal era composta por usuários Android que recebiam SMS em persa e eram induzidos a instalar aplicativos fora de uma cadeia confiável de distribuição. A exposição aumentava quando o usuário concedia permissões de SMS e contatos, porque o aplicativo passava a ter acesso a mensagens já armazenadas, novas mensagens recebidas e capacidade de enviar phishing a partir do próprio número da vítima. A campanha não exigia exploração de uma vulnerabilidade específica do Android; a eficácia dependia da combinação de pretexto confiável, interface falsa, cobrança pequena e autorização manual de permissões sensíveis.
A operação não se limitou a um único tema. Além de serviços governamentais e judiciais, foram observadas variações que imitavam previdência social iraniana, sistemas de rastreamento de dispositivos perdidos ou roubados, bancos, sites de namoro, comércio eletrônico e exchanges de criptomoedas. Isso indica um modelo reutilizável de campanha: o operador troca texto, marca visual, domínio e APK, mas preserva o núcleo funcional de captura, monitoramento de SMS, comando remoto e redistribuição por mensagens.
Outro ponto de exposição vinha da própria infraestrutura dos operadores. Painéis com baixo controle de acesso deixavam diretórios e arquivos acessíveis, incluindo dados de SMS coletados e estrutura de campanhas. Em um painel associado a oliverdnssop[.]cf, mais de dez campanhas reportavam ao mesmo ambiente, e a exposição de um diretório permitia inferir ou acessar dados de outras campanhas no mesmo painel. Para resposta a incidentes, isso significa que uma vítima pode sofrer dois impactos: roubo financeiro direto e exposição secundária de mensagens armazenadas em infraestrutura criminosa mal protegida.
- Usuários Android que receberam SMS com links para páginas falsas de serviços iranianos e instalaram APKs fora de lojas confiáveis.
- Dispositivos que concederam permissões
PERMISSION_RECEIVE_SMS,PERMISSION_READ_SMS,PERMISSION_SEND_SMSePERMISSION_READ_CONTACTS. - Cartões informados em páginas falsas que exibiam erro de pagamento após a submissão dos dados.
- Mensagens SMS existentes e novas mensagens recebidas, especialmente códigos de autenticação e notificações bancárias.
- Contatos ou listas de números usados para redistribuir SMS de phishing a partir de aparelhos já infectados.
A detecção deve combinar telemetria de endpoint móvel, rede, identidade financeira e reclamações de usuários. Em Android, o sinal mais forte é a presença de aplicativo recém-instalado que solicita permissões amplas de SMS, contatos e Internet logo no primeiro uso, especialmente quando associado a um fluxo de pagamento ou autenticação de serviço público. O uso de WebView para carregar URL externa de phishing e a leitura de arquivos internos como assets/port.txt e assets/url.txt são artefatos relevantes em análise de amostra, embora não devam ser tratados isoladamente como regra universal.
Em rede, a defesa deve procurar tráfego de dispositivos móveis para painéis de campanha e domínios de curta vida registrados em TLDs frequentemente usados pela operação. Requisições que enviam corpo de SMS, número do remetente, Android ID ou sinalização de mensagem bancária em parâmetros HTTP são fortes indícios de exfiltração de mensagens. Como os domínios mudavam quase diariamente, bloqueios estáticos precisam ser complementados por análise de reputação, idade do domínio, similaridade visual com serviços governamentais e correlação com mensagens SMS recebidas por usuários.
Em ambiente financeiro, a telemetria relevante inclui múltiplas tentativas de saque ou cobrança em pequenos valores após submissão de dados em página falsa, transações próximas ao horário em que códigos de autenticação foram recebidos e reclamações de esvaziamento de conta após contato por SMS. Para equipes de resposta, a correlação temporal entre recebimento da mensagem inicial, instalação do APK, concessão de permissões, chegada de SMS bancário e transações é mais útil do que procurar um único indicador fixo.
- Instalação recente de APK associado a serviço público, banco, rastreamento de dispositivo, namoro, compras ou criptomoedas, seguida de solicitação de permissões de SMS.
- Envio de SMS em volume incomum a partir de um aparelho que antes não apresentava esse padrão.
- Conexões para domínios recém-criados em
.tk,.ml,.cf,.xyzou.gq, principalmente quando imitam nomes de serviços oficiais. - Comunicação com infraestrutura defangada como 45.153.241[.]194 ou oliverdnssop[.]cf, quando presente em logs históricos.
- Requisições HTTP contendo identificadores de dispositivo, remetente de SMS, corpo de mensagem ou marcação relacionada a banco.
- Relatos de erro de pagamento em página falsa seguidos por débito, saque ou tentativa de autenticação financeira.
A resposta deve começar pela remoção do aplicativo suspeito e revogação do risco financeiro. Dispositivos que instalaram APKs relacionados à campanha devem ter permissões revisadas, aplicativo removido, mensagens e transações correlacionadas e credenciais financeiras reavaliadas. Como a campanha usa SMS de autenticação, a simples troca de senha pode não ser suficiente se o cartão ou a conta permanecerem ativos e o aparelho ainda estiver recebendo códigos. Cartões usados em páginas falsas devem ser bloqueados ou substituídos, e transações recentes precisam ser contestadas pelos canais apropriados.
No controle preventivo, organizações devem reforçar bloqueio de instalação de fontes desconhecidas, gestão de dispositivos móveis, alertas sobre concessão de permissões sensíveis e proteção contra smishing. O treinamento precisa explicar que mensagens sobre processos, notificações judiciais ou taxas pequenas podem ser usadas para induzir instalação de malware. A orientação defensiva mais importante é verificar serviços oficiais por canais independentes, sem seguir links recebidos por SMS, e tratar qualquer APK exigido por uma página de pagamento como alto risco.
Em operadoras, provedores e equipes de segurança de serviços públicos, a mitigação passa por derrubar domínios de phishing, bloquear URLs curtas ou domínios lookalike, monitorar abuso de marca, denunciar painéis de controle e criar canais oficiais de validação de mensagens. Para campanhas que usam dispositivos de vítimas como retransmissores, bloqueios baseados apenas no número remetente têm alcance limitado. A detecção precisa observar conteúdo, URLs, padrões de volume e denúncias agregadas, porque o remetente muda conforme novos aparelhos são incorporados à botnet.
- Remover APKs suspeitos e revisar permissões de SMS, contatos e Internet em dispositivos afetados.
- Bloquear ou substituir cartões inseridos nas páginas falsas e revisar transações feitas após o recebimento do SMS inicial.
- Desabilitar instalação por fontes desconhecidas em dispositivos gerenciados e aplicar políticas de MDM quando disponíveis.
- Bloquear domínios de phishing e painéis conhecidos, usando indicadores defangados e enriquecimento por idade de domínio e similaridade de marca.
- Alertar usuários para não instalar aplicativos exigidos por links recebidos por SMS, especialmente em fluxos que simulam cobrança governamental ou judicial.
- Coletar amostras de APK, mensagens recebidas, horários de instalação e registros de rede para preservar evidências sem publicar dados pessoais ou códigos de autenticação.
0 Comentários