LightsOut usa aplicativos de lanterna no Google Play para impor anúncios fora de contexto

Adware embutido em 22 aplicativos de lanterna e utilitários para Android ocultava o ícone, ignorava preferências do usuário e acionava anúncios por eventos do dispositivo.

Componente	Adware LightsOut incorporado pelo Solid SDK em 22 aplicativos de lanterna e utilitários distribuídos pelo Google Play.
Vetor	Instalação voluntária de aplicativos aparentemente legítimos; após a primeira execução, o código podia ocultar o ícone e receber decisão de exibição de anúncios por servidor de comando e controle.
Impacto	Exibição intrusiva de anúncios fora do contexto do aplicativo, inclusive após o usuário desabilitar opções relacionadas ou adquirir versão sem anúncios.
Prioridade	Localizar e remover os aplicativos afetados, revisar telemetria de eventos anômalos de anúncios no Android e bloquear comunicação com infraestrutura C2 defangada quando observada.
Alcance	Os 22 aplicativos somavam entre 1,5 milhão e 7,5 milhões de downloads.
IoCs	Servidor C2 defangado hxxp://cloudzad[.]com/ e hashes SHA-256 f5b98f91c4ccb6f9530434adce285e25e503a7afb6ea97a03bea57c319cd2fbc e 52209fa52052b8086ae5213d0a51c053ca07a6f36a131f2627be55db17f39ae7.

Resumo técnico

O caso envolve uma família de adware chamada LightsOut, distribuída por meio de 22 aplicativos de lanterna e utilitários publicados no Google Play. Os aplicativos se apresentavam como ferramentas comuns para Android, mas incorporavam o Solid SDK com lógica maliciosa voltada à geração de receita publicitária abusiva. O alcance informado ficou entre 1,5 milhão e 7,5 milhões de downloads, o que transforma um abuso aparentemente simples de anúncios em um problema operacional relevante para equipes que administram frotas móveis, ambientes BYOD ou dispositivos usados para autenticação e comunicação corporativa.

A atividade central do LightsOut não foi descrita como roubo de dados, execução remota de código ou comprometimento de credenciais. O impacto confirmado está na manipulação da experiência do usuário e na persistência prática do abuso: o código podia ocultar o ícone do aplicativo, dificultando a remoção manual, e podia ignorar escolhas explícitas feitas pelo usuário para desabilitar anúncios. Esse comportamento altera a relação entre permissão, configuração e efeito observado no dispositivo, porque a opção apresentada na interface não controlava de forma confiável a execução real da rotina de anúncios.

O fluxo abusivo dependia de eventos cotidianos do Android. Conexão a Wi-Fi, encerramento de chamada, conexão do carregador e bloqueio de tela foram listados como gatilhos para a exibição de publicidade. Em vez de limitar anúncios à tela do próprio aplicativo, o adware os mostrava fora de um contexto legítimo, interferindo em chamadas e outras atividades do usuário. Houve relato de continuidade da atividade mesmo após compra de versão sem anúncios, o que reforça que a monetização não seguia a expectativa funcional apresentada ao usuário.

Os aplicativos foram comunicados ao Google e removidos da loja. Para defesa, o ponto principal não é tratar o episódio como uma falha genérica do Android, mas como uma combinação de abuso de distribuição, SDK embutido, comando externo e ocultação de presença no dispositivo. A resposta deve priorizar inventário de aplicativos instalados, correlação de reclamações de anúncios fora de contexto, revisão de tráfego para infraestrutura associada e remoção dos pacotes identificados quando ainda estiverem presentes em dispositivos.

Fluxo técnico

A cadeia começa com a instalação de um aplicativo de lanterna ou utilitário aparentemente legítimo. Após a primeira abertura, o componente malicioso incorporado pelo Solid SDK podia ocultar o ícone do aplicativo. Essa ação tem efeito direto na capacidade de resposta do usuário: quando os anúncios passam a aparecer fora de contexto, a origem não fica evidente na tela inicial ou na lista usual de atalhos. A remoção passa a exigir inspeção mais cuidadosa das aplicações instaladas, em vez de uma desinstalação simples a partir do ícone visível.

O segundo ponto técnico é a separação entre a configuração exposta ao usuário e a decisão real de exibição de anúncios. O aplicativo apresentava uma caixa de seleção e um painel para habilitar ou desabilitar serviços adicionais, incluindo publicidade. Entretanto, a rotina maliciosa podia consultar orientação do servidor de comando e controle e exibir anúncios mesmo quando a preferência local indicava bloqueio. Essa característica torna a interface uma camada enganosa: ela coleta ou simula consentimento, mas não impõe a decisão de forma confiável no comportamento do aplicativo.

Os gatilhos observados eram eventos do próprio ciclo de uso do dispositivo. Uma conexão Wi-Fi podia iniciar a lógica de anúncio, assim como o encerramento de uma chamada, a conexão de energia pelo carregador ou o bloqueio da tela. Em um exemplo descrito, o fim de uma chamada levava à verificação das configurações do usuário; se os anúncios estivessem desabilitados, mas a instrução externa determinasse a exibição, o anúncio ainda era mostrado. O resultado prático era uma interrupção fora do aplicativo que originou a atividade, dificultando a atribuição pelo usuário.

A infraestrutura citada inclui o servidor C2 defangado hxxp://cloudzad[.]com/. O papel informado desse componente era orientar capacidades como ocultação do ícone e exibição de anúncios. Não há base no material para afirmar coleta de dados, exfiltração, movimentação lateral ou instalação de outras cargas. A análise defensiva deve manter esse limite: trata-se de adware com controle remoto sobre comportamento publicitário e ocultação de aplicativo, não de uma cadeia confirmada de espionagem ou tomada completa do dispositivo.

Superfície afetada

A superfície afetada são dispositivos Android que instalaram os aplicativos de lanterna e utilitários contendo o LightsOut. O risco cresce em ambientes nos quais usuários podem instalar aplicativos diretamente da loja oficial sem aprovação prévia, especialmente quando o dispositivo é usado para chamadas, acesso a Wi-Fi corporativo, autenticação multifator ou comunicação operacional. O fato de os aplicativos terem sido distribuídos pelo Google Play reduz a percepção de risco do usuário, mas não elimina a necessidade de controle de inventário e reputação de aplicativos.

A ocultação do ícone muda a forma como a superfície deve ser auditada. Um usuário pode não encontrar o aplicativo pela tela inicial, mas o pacote ainda pode aparecer em inventários de MDM, listas de aplicativos instalados, relatórios de proteção móvel ou configurações do sistema. A investigação deve considerar que a ausência de ícone visível não significa ausência do aplicativo. Também é importante tratar reclamações de anúncios após chamadas, bloqueio de tela ou conexão de energia como sinal de possível aplicativo abusivo instalado.

Como os aplicativos foram removidos da loja, a exposição remanescente tende a estar em dispositivos que já haviam feito a instalação antes da remoção. A correção, portanto, não termina com a retirada do Google Play. Organizações precisam localizar instalações existentes, acionar remoção gerenciada quando possível e orientar usuários a reportar publicidade intrusiva que apareça fora de contexto. Em frotas sem MDM, a validação depende de inventário manual, revisão de permissões e inspeção de aplicativos recentemente instalados.

• Dispositivos Android com aplicativos de lanterna ou utilitários afetados instalados antes da remoção da loja.
• Usuários que observaram anúncios após eventos como encerramento de chamada, conexão Wi-Fi, conexão do carregador ou bloqueio de tela.
• Ambientes BYOD ou corporativos sem controle centralizado de instalação de aplicativos.
• Pacotes que não apresentam ícone visível, mas continuam listados como aplicativos instalados no sistema.

Hunting e telemetria

A caça deve começar por inventário de aplicativos móveis e correlação com reclamações de comportamento anômalo. O sinal mais forte é a combinação de aplicativo de lanterna ou utilitário instalado, ausência de ícone visível e anúncios exibidos fora do contexto do aplicativo. Em ambientes com MDM, vale cruzar a lista de pacotes instalados com datas de instalação e relatos de usuários. Em ambientes sem gerenciamento centralizado, a equipe deve orientar a verificação na lista completa de aplicativos do Android, não apenas nos atalhos da tela inicial.

Na rede, a infraestrutura C2 defangada hxxp://cloudzad[.]com/ deve ser tratada como indicador histórico associado ao caso. Quando houver proxy, DNS corporativo, VPN móvel ou telemetria de proteção de endpoint móvel, a defesa pode procurar resoluções, conexões HTTP ou tentativas de contato com domínio C2 defangado. A presença de tráfego não deve ser interpretada automaticamente como vazamento de dados, pois o comportamento confirmado está relacionado à orientação de anúncios e ocultação, mas o contato ajuda a priorizar o dispositivo para contenção.

No endpoint, eventos próximos aos gatilhos descritos são úteis para reconstruir a linha do tempo. Relatos de anúncios imediatamente após chamadas, conexão em rede Wi-Fi, conexão de carregador ou bloqueio de tela devem ser preservados com horário aproximado, modelo do dispositivo e lista de aplicativos instalados. Essa correlação ajuda a diferenciar o LightsOut de publicidade legítima exibida dentro de aplicativos comuns. Quando houver solução de segurança móvel, alertas sobre adware, SDK publicitário abusivo ou ocultação de ícone devem ser revisados em conjunto, e não isoladamente.

• Aplicativos de lanterna ou utilitários instalados em dispositivos que apresentam anúncios fora de contexto.
• Ausência de ícone visível para aplicativo ainda presente na lista de aplicações instaladas.
• Conexões ou resoluções para cloudzad[.]com em telemetria DNS, proxy, VPN ou proteção móvel.
• Anúncios observados após encerramento de chamada, conexão Wi-Fi, conexão de carregador ou bloqueio de tela.
• Hashes SHA-256 informados associados a amostras: f5b98f91c4ccb6f9530434adce285e25e503a7afb6ea97a03bea57c319cd2fbc e 52209fa52052b8086ae5213d0a51c053ca07a6f36a131f2627be55db17f39ae7.

Mitigação

A resposta deve priorizar remoção e validação. Em dispositivos gerenciados, a equipe deve localizar os pacotes afetados no inventário, acionar desinstalação remota quando disponível e confirmar que o aplicativo não permanece instalado sem ícone. Em dispositivos pessoais usados para trabalho, a orientação deve ser objetiva: revisar a lista completa de aplicativos, remover lanternas e utilitários suspeitos associados ao comportamento observado e registrar se os anúncios continuam após a remoção. A continuidade dos anúncios após a remoção indicaria necessidade de nova investigação, mas esse desdobramento não está descrito no caso original.

Bloqueios de rede podem reduzir o contato com a infraestrutura associada, desde que aplicados de forma defensiva e sem depender deles como única correção. O domínio C2 defangado cloudzad[.]com pode ser usado em listas internas de detecção e bloqueio, respeitando o histórico do incidente. Ainda assim, a medida principal é remover o aplicativo, porque a rotina maliciosa reside no dispositivo. Apenas bloquear o domínio pode deixar o pacote instalado, com risco de comportamento residual ou de novas instruções caso a infraestrutura mude em variantes não descritas no material recebido.

Para prevenção, controles de instalação de aplicativos devem tratar categorias aparentemente simples, como lanternas e utilitários, como superfície real de risco. A política de dispositivos móveis pode restringir instalação de aplicativos não aprovados, exigir avaliação de reputação, revisar permissões e monitorar SDKs publicitários abusivos. A defesa também deve criar um caminho simples para usuários reportarem anúncios fora de contexto, especialmente quando aparecem durante chamadas ou ações do sistema. Esse tipo de relato costuma ser tratado como incômodo de usabilidade, mas neste caso é um indicador direto de comportamento malicioso.

A validação final deve confirmar três pontos: os aplicativos afetados não estão mais instalados, não há novas conexões para a infraestrutura associada e os gatilhos descritos não produzem anúncios fora de contexto após a limpeza. Em seguida, convém revisar dispositivos semelhantes que tiveram instalações de utilitários no mesmo período. Como a remoção da loja não apaga instalações existentes, a mitigação só fica completa quando o inventário local mostra ausência dos aplicativos e a telemetria deixa de registrar sinais compatíveis com o LightsOut.

• Inventariar aplicativos de lanterna e utilitários em dispositivos Android gerenciados e não gerenciados.
• Remover pacotes associados ao LightsOut e confirmar ausência na lista completa de aplicativos instalados.
• Criar detecção ou bloqueio para cloudzad[.]com quando a telemetria corporativa observar esse indicador.
• Correlacionar reclamações de anúncios fora de contexto com eventos de chamada, Wi-Fi, carregador e bloqueio de tela.
• Revisar políticas de instalação de aplicativos móveis e aprovação de utilitários aparentemente simples.