Ransomware Lucy para Android volta com criptografia de arquivos e abuso de acessibilidade

Nova variante da família Black Rose Lucy usa engenharia social para obter permissões de acessibilidade, instalar carga maliciosa, criptografar arquivos e exibir falsa cobrança atribuída ao FBI.

Componente	Família Black Rose Lucy, botnet e dropper MaaS para Android com capacidade de ransomware em variantes recentes.
Vetor	Distribuição principalmente por links em redes sociais e aplicativos de mensagens, com amostras disfarçadas de reprodutor de vídeo e solicitação enganosa para ativar o serviço de acessibilidade.
Impacto	Criptografia de arquivos locais, bloqueio operacional percebido pelo usuário, instalação de aplicativos maliciosos, persistência após reinicialização e exibição de falsa cobrança de US$500 com solicitação de dados de cartão.
Prioridade	Bloquear instalação fora de lojas confiáveis, monitorar abuso de acessibilidade, revogar privilégios de administrador suspeitos, isolar dispositivos afetados e validar backups de dados móveis.
Artefatos	Extensão .Lucy, receptor uyqtecppxr, eventos BOOT_COMPLETE e QUICKBOOT_POWERON, uso de WakeLock e WifiLock.
Comunicação	Quatro servidores de comando e controle codificados como domínios, concatenados em uma string, com rotação entre APIs e URIs diferentes.
Limites	O texto recebido não traz domínios, hashes, pacotes Android, versões afetadas específicas ou evidência confirmada de exfiltração real de dados pessoais.

Resumo técnico

A família Black Rose Lucy voltou a aparecer em amostras Android com uma mudança relevante de capacidade: além do papel de botnet e dropper, a variante analisada passou a operar como ransomware móvel. O malware é apresentado ao usuário como um aplicativo aparentemente inofensivo de reprodução de vídeo, mas seu fluxo real depende de engenharia social para obter permissão de acessibilidade. Uma vez concedido esse acesso, o código automatiza interações no dispositivo, reduz a necessidade de ação manual da vítima e cria as condições para instalar carga maliciosa, manipular permissões e iniciar a criptografia de arquivos disponíveis no armazenamento local.

O ponto técnico central é o abuso do serviço de acessibilidade do Android. Esse recurso existe para permitir automação assistiva e simplificação de interações, mas também pode ser usado por malware para simular toques, confirmar diálogos e contornar fricções de segurança que normalmente exigiriam consentimento explícito. A variante Lucy apresenta uma solicitação de ativação relacionada a “SVO”, descrita como otimização de streaming de vídeo, e usa a confirmação do usuário como porta de entrada para o controle automatizado. O modelo não explora uma vulnerabilidade do sistema operacional no sentido clássico; ele combina disfarce, permissão sensível e automação de interface.

Após obter as condições necessárias, o malware enumera diretórios do dispositivo, tenta localizar áreas de armazenamento e aplica criptografia aos arquivos que passam por verificações de tamanho e permissão. Arquivos processados recebem a extensão .Lucy, e o usuário vê uma nota de resgate aberta no navegador. A mensagem tenta se passar por comunicação oficial do FBI dos Estados Unidos, acusa a vítima de posse de conteúdo pornográfico e afirma que dados teriam sido enviados a um centro de crimes cibernéticos. Essa alegação faz parte da coerção exibida na tela; o dado técnico confirmado no material é a criptografia local e a exigência de pagamento de uma “multa” de US$500 por meio de informações de cartão, não por Bitcoin.

Fluxo técnico

A cadeia começa com distribuição de amostras associadas à variante ativa, observadas principalmente em links compartilhados por redes sociais e aplicativos de mensagem. O aplicativo se apresenta como reprodutor de vídeo, o que reduz a suspeita inicial do usuário e cria um motivo visual para pedir uma função supostamente ligada à otimização de streaming. Quando a vítima aceita o diálogo, o malware direciona o processo para a ativação do serviço de acessibilidade. A partir desse ponto, a interação deixa de depender apenas de cliques voluntários do usuário e passa a ser conduzida pelo código malicioso, que pode automatizar telas e confirmar ações dentro do ambiente Android.

O código registra um receptor chamado uyqtecppxr para reagir aos eventos BOOT_COMPLETE e QUICKBOOT_POWERON, indicando preocupação com execução após reinicialização ou retomada rápida do dispositivo. Também há lógica para verificar se o código de país do aparelho pertence a um antigo Estado soviético, o que sugere filtragem geográfica ou regra de exclusão operacional. Dentro do módulo MainActivity, a aplicação aciona um serviço malicioso e registra um BroadcastReceiver ligado ao evento de tela ligada. Esse fluxo obtém WakeLock, para manter a tela ativa, e WifiLock, para manter a conectividade Wi-Fi, preservando condições úteis para comunicação, recebimento de instruções e conclusão das rotinas de criptografia.

A comunicação de comando e controle é implementada com quatro servidores codificados no binário como domínios, não apenas como endereços IP. Os valores ficam concatenados em uma string longa acompanhada por dados sem uso aparente, e o malware alterna entre eles usando APIs e URIs diferentes. Essa escolha aumenta a resiliência operacional porque um domínio pode ser resolvido para novo endereço caso a infraestrutura mude. O servidor pode devolver instruções reconhecidas pelo malware, incluindo rotinas relacionadas a criptografia, decriptação, listagem de aplicativos instalados, limpeza de variáveis internas, remoção de chaves, autodeleção e abertura de canal remoto. Para fins defensivos, o ponto importante é que a família combina ransomware local com capacidade de orquestração remota, e não apenas uma tela estática de bloqueio.

A rotina de criptografia recebe uma resposta com uma string de chave dividida por delimitador, coleta diretórios do dispositivo e, se a enumeração principal falhar, tenta caminhos de armazenamento como /storage e /sdcard. Antes de criptografar, o código verifica permissões, tamanho e resultado do processamento. A análise também descreve uma etapa com geração de chave AES usando uma semente constante, mas essa saída não é preservada em variável e parece funcionar como isca analítica ou erro de implementação. A chave efetiva é composta por um segmento recebido do comando e controle e por outro valor recuperado de SharedPreferences. Na decriptação, a lógica se assemelha à criptografia, removendo a extensão .Lucy e alterando um parâmetro booleano que define o modo de operação.

Superfície afetada

A superfície de risco é composta por dispositivos Android em que o usuário instala aplicativos a partir de links recebidos fora de um fluxo controlado, especialmente quando esses links circulam por mensagens instantâneas e redes sociais. O ataque depende de interação humana para conceder acessibilidade, mas a permissão concedida amplia o controle do aplicativo de forma sensível. Ambientes corporativos com política permissiva de instalação, inventário móvel incompleto ou ausência de defesa móvel dedicada ficam mais expostos porque a cadeia combina disfarce de aplicativo comum, automação de interface e persistência por eventos de inicialização.

Os dados em risco são arquivos acessíveis no armazenamento local do dispositivo e em diretórios que a aplicação consegue enumerar com as permissões disponíveis. O material analisado não sustenta afirmar vazamento real de conteúdo do aparelho, embora a nota de resgate use essa ameaça como pressão psicológica. Também há risco adicional ligado à tentativa de coletar informações de cartão durante a falsa cobrança, pois o operador abandona o modelo típico de criptomoeda e tenta induzir a vítima a fornecer dados financeiros diretamente. Para equipes de segurança, esse detalhe deve ser tratado como componente de fraude e engenharia social dentro do mesmo incidente móvel.

• Dispositivos Android com instalação de aplicativos por links externos a canais confiáveis.
• Usuários que concedem serviço de acessibilidade a aplicativos sem função assistiva legítima.
• Ambientes com baixa visibilidade de permissões sensíveis, administradores de dispositivo e eventos de inicialização.
• Armazenamento local acessível pelo aplicativo, incluindo diretórios enumerados durante a rotina de criptografia.
• Contas e processos corporativos que dependem do aparelho afetado para autenticação, comunicação ou acesso a dados operacionais.

Hunting e telemetria

A detecção deve priorizar comportamento, porque o material disponível não traz hashes, nomes de pacote ou domínios de comando e controle. Em MDM, EDR móvel ou telemetria Android, o sinal mais forte é a combinação de aplicativo recém-instalado, solicitação de acessibilidade sem justificativa funcional, tentativa de obter privilégios de administrador de dispositivo, registro para inicialização automática e atividade de criptografia em massa no armazenamento. A presença de arquivos renomeados com extensão .Lucy é um indicador local direto de impacto, mas tende a aparecer quando a criptografia já ocorreu; por isso, sinais anteriores de permissão e automação são mais úteis para prevenção.

Em rede, a investigação deve procurar comunicação recorrente de um aplicativo móvel suspeito com múltiplos domínios controlados pelo mesmo fluxo de aplicação, especialmente quando há rotação de caminhos HTTP ou APIs distintas. Como os domínios específicos não foram fornecidos, não é adequado criar lista de IoCs. A abordagem defensiva deve correlacionar instalação recente, aumento de tráfego após ativação de tela, manutenção incomum de Wi-Fi ativo e eventos que sugerem persistência. Em análise estática, artefatos como uyqtecppxr, referências a BOOT_COMPLETE, QUICKBOOT_POWERON, WakeLock, WifiLock, SharedPreferences, /storage, /sdcard e .Lucy ajudam a separar essa família de aplicativos benignos de vídeo.

• Aplicativo que solicita acessibilidade logo após instalação e apresenta justificativa relacionada a otimização de vídeo.
• Registro de receptor para BOOT_COMPLETE ou QUICKBOOT_POWERON por aplicativo recém-instalado e não corporativo.
• Criação ou renomeação de arquivos com extensão .Lucy em diretórios de armazenamento do usuário.
• Uso anormal de WakeLock e WifiLock por aplicativo sem necessidade legítima de manter tela e Wi-Fi ativos.
• Comunicação de aplicativo móvel suspeito com múltiplos domínios e URIs diferentes durante a mesma sessão.
• Mensagens de resgate abertas em navegador com falsa autoridade policial e solicitação de pagamento via cartão.

Mitigação

A resposta inicial deve preservar o dispositivo para análise sem permitir que a atividade continue. Em ambiente corporativo, o aparelho suspeito deve ser isolado da rede, removido de fluxos de autenticação sensíveis e avaliado por ferramenta de defesa móvel ou processo forense compatível. O usuário não deve inserir dados de cartão ou tentar interagir com a nota de resgate. Como a variante pode receber instruções remotas e manter conectividade, a contenção precisa ocorrer antes de qualquer tentativa de recuperação. Quando houver backup confiável, a restauração deve priorizar dados validados antes da infecção e exigir reinstalação limpa do sistema ou remoção assistida por processo corporativo aprovado.

A mitigação preventiva exige controle de instalação e governança de permissões. Dispositivos gerenciados devem restringir sideloading, limitar instalação a lojas e catálogos aprovados, alertar sobre concessão de acessibilidade a aplicativos não autorizados e monitorar administradores de dispositivo. A revisão de políticas também deve incluir treinamento específico para mensagens que prometem player, otimização de vídeo ou funcionalidade comum em troca de permissão ampla. O ponto decisivo é reduzir a chance de o usuário conceder acessibilidade a um aplicativo sem função assistiva real.

Após a contenção, a equipe deve revisar logs móveis, inventário de aplicativos e eventos de identidade associados ao aparelho. Se o dispositivo era usado para MFA, e-mail corporativo, VPN ou acesso a aplicações internas, tokens e sessões devem ser reavaliados conforme a política interna, mesmo sem evidência confirmada de exfiltração no material analisado. A extensão .Lucy, o histórico de instalação por link externo e a presença de artefatos de persistência devem orientar o escopo. A recuperação deve terminar com validação de backups, atualização de controles MDM e bloqueio de indicadores comportamentais, não apenas com remoção manual do aplicativo visível.

• Restringir instalação de APKs fora de canais aprovados e registrar exceções de forma auditável.
• Bloquear ou alertar concessão de acessibilidade para aplicativos que não estejam em lista permitida.
• Monitorar privilégios de administrador de dispositivo e revogar permissões suspeitas imediatamente.
• Isolar dispositivos com arquivos .Lucy, preservar evidências e recuperar dados apenas de backups confiáveis.
• Revisar sessões, tokens e usos de autenticação vinculados ao aparelho afetado.
• Criar detecções comportamentais para instalação recente, acessibilidade, persistência por inicialização e atividade de criptografia em massa.