Variante do Cerberus usa MDM corporativo comprometido para infectar dispositivos Android

Variante do Cerberus usa MDM corporativo comprometido para infectar dispositivos Android

Campanha atingiu mais de 75% dos dispositivos de uma empresa ao abusar da instalação remota de aplicativos por uma plataforma de gerenciamento móvel comprometida.

ComponenteServidor corporativo de MDM usado para distribuir aplicativos a dispositivos Android da organização, além de dois aplicativos maliciosos associados a uma variante do Cerberus.
VetorComprometimento do MDM corporativo e abuso da capacidade legítima de instalação remota de aplicativos em grande volume, com instalação concentrada em uma janela curta de tempo.
ImpactoMais de 75% dos dispositivos da empresa receberam o malware; em dispositivos sem proteção ativa, a variante podia registrar teclas, interceptar SMS, coletar credenciais, acessar dados do Google Authenticator, listar arquivos e aplicativos e iniciar controle remoto via TeamViewer.
PrioridadeTratar MDM como ativo crítico, investigar alterações administrativas e instalações em massa, bloquear comunicação HTTP para C2 na porta 8888 quando observada, isolar dispositivos afetados e validar erradicação antes de devolver acesso corporativo.
ArtefatosA cadeia descrita envolve um módulo principal e um payload DEX salvo como ring0.apk, recebido do servidor de C2 e invocado por reflexão.
C2Comunicação HTTP sem hostname, usando um IP russo não especificado no contexto e escuta na porta 8888.
Resumo técnico

A campanha descreve uma variante do Cerberus para Android distribuída por meio de um servidor corporativo de MDM comprometido. O ponto central do incidente não foi a instalação manual por usuários nem uma loja de aplicativos de terceiros, mas o abuso de um canal administrativo legítimo da própria organização. Depois que o MDM foi comprometido, o operador usou a capacidade de instalar aplicativos remotamente para empurrar dois aplicativos maliciosos a um grande número de dispositivos em um intervalo curto. O resultado foi a infecção de mais de 75% dos aparelhos da empresa, demonstrando que a camada de gerenciamento móvel, quando comprometida, pode se tornar um mecanismo de distribuição lateral dentro do ambiente corporativo.

A variante pertence à família Cerberus Banking Trojan, mas a campanha descrita vai além de capacidades bancárias tradicionais. O malware combina coleta de credenciais, interceptação de SMS, captura de dados do Google Authenticator, registro de teclas, enumeração de arquivos e aplicativos instalados, além de funções de controle remoto associadas ao TeamViewer. A cadeia também baixa um payload DEX adicional, armazenado como ring0.apk, que amplia a capacidade de coleta, execução de ações no telefone e manutenção do próprio malware. O contexto confirma que, nos dispositivos desprotegidos, credenciais usadas no aparelho eram reportadas ao C2 e mensagens SMS eram interceptadas; ao mesmo tempo, não permite afirmar exatamente quais outros dados específicos foram efetivamente extraídos em cada dispositivo.

O incidente evidencia uma distinção operacional relevante: gerenciar dispositivos não é o mesmo que protegê-los. O MDM é desenhado para aplicar políticas, instalar aplicativos e alterar configurações de muitos aparelhos ao mesmo tempo. Essa centralização é útil para administração, mas amplia o impacto de uma conta administrativa comprometida, de uma configuração exposta ou de uma falha de governança. Quando o painel ou a infraestrutura de MDM passa a ser controlado por um invasor, a mesma automação usada para padronizar a frota pode distribuir malware com alcance quase imediato. Nesse caso, os aparelhos com proteção móvel ativa não mantiveram acesso a recursos corporativos, enquanto os aparelhos sem a proteção descrita permaneceram com acesso e executaram o malware.

Fluxo técnico

A sequência começou com a detecção de dois aplicativos maliciosos instalados em muitos dispositivos em 18 de fevereiro de 2020. A concentração temporal das instalações indicava automação, o que reduziu a probabilidade de uma propagação orgânica baseada apenas em ações individuais de usuários. Duas hipóteses foram consideradas: movimentação lateral autônoma do malware ou comprometimento do MDM. A confirmação posterior foi de que o MDM do cliente havia sido comprometido. A partir desse acesso, o operador explorou uma função legítima do MDM, a instalação remota de aplicativos, para atingir uma parcela majoritária da frota móvel.

Depois da instalação, o aplicativo malicioso exibia uma janela simulando uma atualização do serviço de Acessibilidade do Android. Quando o usuário recusava, a solicitação voltava a aparecer, criando pressão contínua para concessão da permissão. Após obter Acessibilidade, o malware podia automatizar interações na interface, clicar em opções de menu e contornar etapas que dependeriam de ação manual. Essa permissão foi usada como alavanca para coleta de dados, persistência e controle, inclusive para desabilitar mecanismos de proteção e manipular telas de configuração do sistema.

O módulo principal iniciava um serviço que enviava ao C2 identificadores do bot, estado de proteção da tela de bloqueio, nome do pacote do aplicativo em primeiro plano e informação sobre acesso de escrita ao armazenamento. Em seguida, recebia uma lista de comandos configurável pelo operador. O aplicativo também registrava um receptor de SMS para coletar mensagens recebidas e enviá-las posteriormente ao C2, juntamente com dados como número de telefone, aplicativo padrão de SMS e localidade. Quando o comando adequado era recebido, o malware baixava um arquivo DEX codificado, salvava o payload no armazenamento externo como ring0.apk e chamava um ponto de entrada desse payload por reflexão.

O módulo principal concentrava funções de exfiltração e controle remoto. Ele podia usar Acessibilidade para capturar credenciais, padrões de desbloqueio, senhas do Gmail e informações visíveis no Google Authenticator. Também podia listar arquivos e aplicativos instalados e enviar arquivos específicos quando solicitado pelo C2. O registro de teclas permitia acompanhar atividades executadas no dispositivo, inclusive entrada de credenciais. Para controle remoto, o malware podia iniciar o TeamViewer, receber parâmetros de conexão do C2 e preencher campos automaticamente por meio de Acessibilidade. Em dispositivos Samsung, a cadeia descrita abusava de Samsung KNOX para conceder permissões automaticamente ao TeamViewer.

O payload ring0.apk adicionava funções de coleta e manutenção. Ele podia coletar contatos, SMS e lista de aplicativos instalados, além de executar ações telefônicas como envio de SMS específico, realização de chamadas e requisições USSD. Também tinha capacidade de mostrar notificações, instalar ou remover aplicativos e abrir atividades com URLs. No lado de manutenção, podia conceder permissões a si mesmo, habilitar o serviço responsável por receber comandos do C2, remover o próprio arquivo de payload para permitir atualização posterior, retirar-se da lista de administradores do dispositivo e remover completamente o malware do aparelho.

Superfície afetada

A superfície afetada inclui dispositivos Android gerenciados pelo MDM corporativo comprometido, especialmente aqueles que receberam as duas aplicações maliciosas na janela curta de instalação. O risco mais alto recai sobre aparelhos que continuavam com acesso a recursos corporativos e não tinham proteção móvel ativa. Nesses dispositivos, a cadeia podia observar credenciais digitadas, interceptar SMS usados em autenticação de dois fatores, capturar informações de aplicativos sensíveis e permitir controle remoto. O contexto também mostra que a organização separava dispositivos protegidos e não protegidos: usuários de aparelhos protegidos não mantinham acesso aos recursos corporativos, enquanto usuários de aparelhos não protegidos mantinham esse acesso junto com a presença do malware.

A plataforma de MDM, por sua natureza, deve ser tratada como componente de alto privilégio. Ela não é apenas um inventário de dispositivos; ela aplica políticas, instala aplicativos e altera configurações em escala. Qualquer conta administrativa, token de integração, fluxo de aprovação de aplicativo, perfil de distribuição ou configuração de política que permita instalação remota passa a ser uma superfície sensível. A campanha também expõe risco em permissões de Acessibilidade e em mecanismos de administração do dispositivo, porque o malware usou essas capacidades para persistir, bloquear desinstalação e interferir em proteções do Android.

O canal de C2 descrito era HTTP, sem hostname, usando um IP russo não especificado e porta 8888. Esse detalhe é suficiente para orientar investigação de rede sem publicar indicador ativo. A ausência de hostname reduz algumas oportunidades de detecção por DNS, mas aumenta a importância de inspeção de conexões diretas por IP e de correlação com processos ou aplicativos Android recém-instalados. Como a proteção de rede no dispositivo não estava ativa no cenário descrito, o bloqueio automático da comunicação com C2 não ocorreu naquele ambiente.

  • Dispositivos Android sob o MDM corporativo comprometido e que receberam os aplicativos maliciosos em instalação remota.
  • Aparelhos sem proteção móvel ativa e com acesso a recursos corporativos, pois combinavam execução do malware com potencial uso de credenciais internas.
  • Contas, perfis e políticas administrativas do MDM capazes de instalar aplicativos em escala.
  • Permissões de Acessibilidade, administração do dispositivo, Play Protect e configurações de energia ou inicialização automática em interfaces MIUI.
  • Sessões e credenciais usadas em dispositivos afetados, incluindo SMS de autenticação e dados visíveis em aplicativos de autenticação.
Hunting e telemetria

A investigação deve começar pela linha do tempo do MDM. A instalação simultânea ou quase simultânea de aplicativos em muitos dispositivos, especialmente sem mudança planejada, é um sinal forte de abuso administrativo. Eventos de criação, alteração ou uso de políticas de instalação, mudanças em grupos de dispositivos, novos perfis de distribuição, contas administrativas acessadas fora do padrão e pacotes enviados a grande volume de aparelhos devem ser correlacionados com a data de 18 de fevereiro de 2020 no cenário descrito. O objetivo não é apenas localizar o aplicativo malicioso, mas reconstruir como o MDM autorizou a distribuição.

No endpoint móvel, sinais relevantes incluem concessão recente de Acessibilidade a aplicativo não esperado, atribuição de privilégios de administrador do dispositivo, tentativas bloqueadas ou anômalas de desinstalação, abertura repetida de telas de permissões, desativação do Google Play Protect e alteração de configurações de inicialização automática ou economia de energia. A presença de ring0.apk no armazenamento externo é um artefato importante, desde que analisado como evidência e não executado. Também são relevantes eventos de instalação ou acionamento do TeamViewer em dispositivos que não deveriam usar controle remoto, principalmente quando associados a preenchimento automatizado de parâmetros de conexão.

Na rede, a telemetria deve priorizar conexões HTTP diretas para IP sem hostname na porta 8888, especialmente originadas de dispositivos móveis corporativos após a janela de instalação dos aplicativos. Como o C2 descrito não usa domínio, a análise precisa incluir logs de proxy, firewall, VPN, proteção de endpoint móvel e qualquer camada que registre destino por IP e porta. Quando houver inspeção no dispositivo, eventos de tentativa de comunicação classificados como site malicioso ou infectante devem ser correlacionados com o pacote instalado e com a identidade do usuário do aparelho.

A análise de identidade também é essencial. O contexto afirma que credenciais usadas em dispositivos desprotegidos foram reportadas ao C2, e que SMS eram interceptados. Portanto, tentativas de login corporativo feitas a partir desses aparelhos devem ser tratadas como potencialmente expostas, principalmente quando combinadas com códigos de autenticação por SMS. O mesmo raciocínio se aplica a administradores que tenham acessado recursos corporativos por dispositivos afetados. A investigação deve separar capacidade do malware, evidência de coleta e uso posterior das credenciais, evitando concluir abuso de conta sem telemetria que sustente essa etapa.

  • Instalações remotas em massa iniciadas pelo MDM em janela curta e sem mudança aprovada.
  • Novas permissões de Acessibilidade concedidas a aplicativos desconhecidos ou não homologados.
  • Privilégios de administrador do dispositivo atribuídos a aplicativos recém-instalados.
  • Eventos de desativação do Google Play Protect ou bloqueio da tela de detalhes do aplicativo.
  • Presença de ring0.apk no armazenamento externo ou evidência de carregamento de DEX por aplicativo suspeito.
  • Conexões HTTP diretas para IP sem hostname na porta 8888, com destino classificado como malicioso quando houver verdict disponível.
  • Uso inesperado de TeamViewer em dispositivos móveis corporativos, especialmente com manutenção de tela desbloqueada.
Mitigação

A resposta deve tratar o MDM como origem provável de distribuição até que a investigação prove o contrário. A primeira medida é conter o canal administrativo: suspender políticas de instalação não essenciais, revisar contas privilegiadas, invalidar sessões administrativas, verificar integrações e preservar logs antes de alterações destrutivas. Em paralelo, dispositivos que receberam os aplicativos maliciosos devem ser isolados do acesso a recursos corporativos. A simples remoção visual de um aplicativo pode não ser suficiente, porque a cadeia descrita inclui privilégios administrativos, bloqueio de desinstalação, desativação de proteção e payload adicional capaz de manutenção.

A erradicação precisa considerar o grau de confiança no dispositivo. No caso descrito, a organização decidiu redefinir todos os dispositivos afetados para estado de fábrica a fim de reduzir o risco de resíduo do malware ou persistência do operador. Essa medida é custosa, mas coerente quando há controle remoto, captura de credenciais, interceptação de SMS e múltiplas técnicas de persistência. Antes de reativar o acesso, o fluxo de reinscrição no MDM deve usar perfis revisados, aplicativos homologados, proteção móvel ativa e validação de que o dispositivo não reinstalou os pacotes maliciosos.

A recuperação de identidade deve acompanhar a limpeza dos aparelhos. Credenciais digitadas em dispositivos desprotegidos durante o período de infecção devem ser consideradas comprometidas, sobretudo contas administrativas ou contas com acesso a recursos internos. Senhas, sessões e fatores baseados em SMS associados a esses usuários precisam ser rotacionados ou invalidados conforme a criticidade. Sempre que possível, a organização deve reduzir dependência de SMS como segundo fator para contas sensíveis, porque o malware descrito interceptava mensagens e podia observar interações do usuário no dispositivo.

No plano preventivo, o MDM precisa de controles equivalentes aos de uma plataforma de administração crítica. Isso inclui autenticação forte para administradores, segregação de funções, aprovação para distribuição em massa, registro detalhado de mudanças, alertas para instalação de aplicativos fora do padrão, revisão de certificados e perfis, além de monitoramento de dispositivos após mudanças de política. A segurança móvel também deve ficar ativa no próprio aparelho, com proteção de rede capaz de bloquear destinos maliciosos, inspeção de permissões sensíveis, detecção de abuso de Acessibilidade e resposta automática quando aplicativos fora da linha de base aparecem em grande escala.

  • Suspensão temporária de políticas de instalação remota não essenciais no MDM enquanto a origem é investigada.
  • Revisão de contas administrativas, sessões ativas, integrações e mudanças recentes na configuração do MDM.
  • Isolamento de dispositivos que receberam os aplicativos maliciosos e bloqueio de acesso a recursos corporativos até a validação de limpeza.
  • Bloqueio e investigação de tráfego HTTP para IP sem hostname na porta 8888 quando observado na telemetria.
  • Redefinição de fábrica para dispositivos em que a integridade não possa ser restabelecida com confiança, seguida de reinscrição controlada.
  • Rotação de credenciais usadas em dispositivos afetados e revisão de contas que dependiam de SMS como fator de autenticação.
  • Ativação de proteção móvel com inspeção de rede, detecção de abuso de Acessibilidade e alerta para instalação remota em massa.

Postar um comentário

0 Comentários