Em nossa publicação anterior, analisamos como o malware pode bloquear dispositivos e também as táticas de intimidação utilizadas para convencer as vítimas a pagar o resgate. Agora que sabemos o que os bandidos podem fazer, vamos falar sobre as técnicas de detecção e de mitigação que os fornecedores de segurança podem usar para impedi-los. Ao compartilhar esses detalhes com outros pesquisadores, esperamos melhorar o conhecimento coletivo da indústria sobre a mitigação de ransomwares móveis.

Detecção e Mitigação do ransomware móvel

Analisar as características técnicas do ransomware móvel nos permite projetar e implementar as técnicas apropriadas de detecção e mitigação. Há várias maneiras de abordar esse problema: nosso ponto de vista é que essas características maliciosas devem aparecer no código do aplicativo. Usamos uma abordagem de análise estática, com alguns truques para resolver casos típicos de cantos (tais como ofuscação através da reflexão).

Figura 1. Várias abordagens de descoberta de ransomware móvel

A típica “mensagem ameaçadora” é clara e compreensível e inclui instruções detalhadas para coagir a vítima a pagar. Isso pode ser detectado através de uma abordagem com machine-learning (aprendizagem por máquina) que classifica o texto automaticamente como “ameaçador” ou “normal”. Depois de um pré-processamento para remover palavras de parada (por exemplo, “o”, “a”) e reduzir palavras à sua forma básica (por exemplo, “bloqueado” se torna “bloqueio”), treinamos um classificador no restante do texto, mostrando ambas as amostras de mensagens “ameaçadoras” de texto e amostras de mensagens seguras. No final do dia, o classificador terá aprendido como distinguir um texto inseguro de um texto seguro.

As técnicas típicas de bloqueio são conhecidas e podem ser detectada por meio de uma execução simbólica leve. Em particular, buscamos o bytecode do aplicativo para todas as subclasses de android.app.Activity que substituem os métodos onKeyUp e onKeyDown . Nós, então, simbolicamente executamos o código dentro desses métodos para descobrir se existem caminhos de código que lidam com botões de início ou de retorno (seta azul na figura abaixo), e acabam retornando como “verdadeiro” (seta vermelha), que indica que o evento não deve ser propagado adiante. Por sua vez, isto significa que nenhum outro aplicativos (até mesmo o lançador legítimo da tela inicial) será enviado para o primeiro plano.

Figura 2. Botões de manipulação de caminhos de código

Para explorar o API de administração do dispositivo, um aplicativo precisa declará-lo no manifesto, conectando-o a um arquivo separado que define as “políticas” que são permitidas para um aplicativo administrador. Ao centrar-se nos comportamentos perigosos (por exemplo, redefinir a senha, bloqueio forçado, limpar dados e criptografar o armazenamento), podemos explorar o gráfico de controle de fluxo de aplicativos para detectar se existe um acionamento de qualquer um desses métodos, sem a intervenção do usuário.

Para este fim, usamos uma versão personalizada do FlowDroid, uma poderosa ferramenta de código aberto para análise estática de bytecode Java e Android. A partir de todos os pontos de entrada, primeiro visitamos o gráfico de amplitude de controle de fluxo, em busca de acionamentos para lockNow() e outros métodos explorados. Se nada for encontrado, tentamos novamente e materializamos os acionamentos reflexivos, se houver algum. Encontramos todos os acionamentos da reflexão Java do API, e, em seguida, trabalhamos no histórico até conseguirmos reconstruir o nome dos métodos conhecidos como “reflexivos”, que às vezes são ofuscados. Após identificarmos os nomes dos métodos, podemos incluí-los como nós no gráfico de controle de fluxo e desenhar as margens de acordo. Se os nomes dos métodos estiverem ofuscados, seguimos até a declaração do objeto String que contém o nome (ofuscado) e depois usamos o reflexo para reexecutar todas as instruções subsequentes até chegar ao acionamento para invoke().

Figura 3. Encontrar abuso da API de administração de dispositivos

Detectamos a criptografia sem supervisão de arquivos em uma veia similar. Mais precisamente, queremos encontrar todas as instâncias do pseudo-loop seguinte, permitindo, claro, algumas variações:

Para isso, potencializamos a análise de fluxo do FlowDroid, configurando-o para detectar fluxos significativos, por exemplo, entre listFiles() e CipherOutputStream(). Tanto a criptografia quanto a análise da exploração do API de administração do dispositivo, procuramos caminhos de código que não foram iniciados em UI, o que significa que nenhuma intervenção do usuário é necessária para ativar essa funcionalidade. Caso contrário, iríamos detectar (como falsos positivos) todos os aplicativos legítimos ao criptografar arquivos em nossos dispositivos.

Infelizmente, todo o processo pode levar vários minutos por aplicativo. Novamente, usando uma abordagem de machine-learning, podemos pré-filtrar aplicativos para determinar, com boa precisão, quais são absolutamente seguros. Os questionáveis ​​podem passar por mais análises. Esta abordagem pode reduzir o tempo necessário para processar um lote de amostras por uma ordem de magnitude.