O “Firestarter” abusa do Google Firebase Cloud Messaging para se espalhar

De Warren Mercer , Paul Rascagneres e Vitor Ventura .

• O malware Firestarter recém-descoberto usa o Google Firebase Cloud Messaging para notificar seus autores sobre a localização final da carga útil.
• Mesmo que o comando e controle (C2) seja retirado, a equipe DoNot ainda pode redirecionar o malware para outro C2 usando a infraestrutura do Google.
• A abordagem no upload da carga útil final denota uma política de direcionamento altamente personalizada.

Como funcionou? Os usuários são atraídos para instalar um aplicativo malicioso em seus dispositivos móveis. Esse aplicativo malicioso contém então código malicioso adicional que tenta baixar uma carga com base nas informações obtidas do dispositivo comprometido. Isso garante que apenas dispositivos muito específicos recebam a carga maliciosa.

E daí?A inovação entre os grupos APT não é inédita e não deve ser uma grande surpresa que um grupo continue a modificar suas operações para garantir que sejam o mais dissimuladas possível. Este deve ser outro sinal de alerta para as pessoas em regiões geopolíticas “quentes” de que é inteiramente possível que você se torne vítima de um grupo altamente motivado.

SUMÁRIO EXECUTIVO

A equipe DoNot é conhecida por visar organizações sem fins lucrativos da Caxemira e funcionários do governo do Paquistão. A região da Caxemira está sob disputas contínuas da Índia, China e Paquistão sobre sua propriedade. Isso alimenta um conflito potencial às vezes. Este ator, DoNot, recentemente começou a usar um novo carregador de malware que chamamos de “Firestarter”. Nossa pesquisa revelou que o DoNot vem experimentando novas técnicas para manter uma posição segura nas máquinas das vítimas. Esses experimentos, comprovados no carregador Firestarter, são um sinal de como eles estão determinados a manter suas operações apesar de serem expostos, o que os torna um ator particularmente perigoso operando na área de espionagem. Os mesmos experimentos também mostraram a capacidade de manter suas operações furtivas, pois agora eles têm a capacidade de decidir quais infecções receberão a carga final com base em critérios de identificação geográfica e pessoal. Isso reduz a probabilidade de os pesquisadores acessarem.

DoNot agora está aproveitando o Google Firebase Cloud Messaging (Google FCM) como um canal de comunicação obrigatório com o malware. Este canal de comunicação é criptografado e misturado a outras comunicações realizadas pelo Sistema Operacional Android com a infraestrutura do Google, a equipe DoNot está escondendo parte de seu tráfego entre o tráfego legítimo. Mesmo que os agentes mal-intencionados ainda precisem de uma infraestrutura de comando e controle (C2), a codificada só é necessária no momento da instalação, depois pode ser descartada e facilmente substituída por outra. Assim, se seu C2 for retirado pela polícia ou considerado malicioso, eles ainda podem acessar o dispositivo da vítima e instruí-lo a entrar em contato com um novo C2. Com essa nova tática, apenas o Google tem a capacidade de interromper o malware com eficácia, já que ele ‘

Acreditamos que a propagação é provavelmente feita por meio de mensagens diretas que induzem as vítimas a instalar o malware. Organizações e indivíduos podem se proteger impedindo a instalação de software de fontes desconhecidas no Android e, se possível, detectando o fluxo inicial de rede feito para o C2.

VITIMOLOGIA

A equipe DoNot já é conhecida por ter interesse na Índia e no Paquistão. O nome do arquivo de alguns aplicativos Android mostram o mesmo interesse, por exemplo: kashmir_sample.apk ou Kashmir_Voice_v4.8.apk. Esta nova campanha aponta para a mesma vitimologia de sempre: Índia, Paquistão e a crise da Caxemira.
Os alvos são principalmente usuários finais e organizações sem fins lucrativos vinculadas a esta região do mundo.

FLUXO DO CARREGADOR

A primeira execução do carregador fornece uma isca para fazer a vítima acreditar que não houve instalação maliciosa. A sequência abaixo mostra o que um usuário vê durante a primeira execução.

Assim que a mensagem de desinstalação for exibida, o ícone será removido da interface do usuário. A única maneira de detectar o aplicativo é verificando a lista de aplicativos. Lá, o usuário vê um ícone do aplicativo que parece estar desabilitado, como pode ser visto a seguir.

Se o usuário verificar as permissões, poderá ver que elas existem, mas com o nome “Serviço do Sistema”, feito para enganar o usuário e fazê-lo pensar que está vendo as permissões relacionadas ao sistema e não as permissões do aplicativo.

Enquanto o usuário recebe as mensagens sobre a incompatibilidade, o malware faz o primeiro contato com o C2. Ele enviará informações sobre a identidade e geolocalização da vítima, cruciais para os próximos passos que os operadores irão realizar. O fluxo completo consiste em seis etapas antes que o malware comece a receber comandos do C2, conforme mostrado abaixo.

Depois de obter o token FMC do Google (Etapa 1), os operadores têm tudo o que precisam para enviar a mensagem do FMC do Google contendo a URL do malware para baixar a carga útil. Eles também têm a localização geográfica, endereço IP, IMEI e endereço de e-mail das vítimas, permitindo-lhes decidir quais vítimas devem receber a carga útil.

Usando a análise estática, acompanhando a execução do código até o ponto de confirmar o papel desempenhado pelo mecanismo FMC do Google usado neste carregador, decidimos que deveríamos testá-lo dinamicamente.

Quando o malware recebe uma mensagem do Google FMC, ele verifica se ela contém uma chave chamada “link”. Se existir, ele verificará se começa com “https”, se tudo estiver correto, ele usará o link para baixar a carga de um servidor de hospedagem. Assim que o arquivo chegar, o malware irá importar as classes do payload, podendo agora iniciar o serviço malicioso, que está declarado no manifesto
, como você pode ver na imagem abaixo.

Esta é uma amostra de malware diferente, que contém a carga incorporada e inicia o serviço malicioso.

Depois que a carga estiver no dispositivo vítima, o carregador carregará as classes e iniciará o serviço malicioso. Se o dispositivo for reinicializado, o carregador verificará automaticamente a presença de carga útil no dispositivo e o carregará, se houver.

INSTRUMENTANDO O MALWARE

Corrigimos a amostra de malware para nos permitir controlar os fluxos de mensagens e, então, podemos confirmar o que já estabelecemos estaticamente.

A primeira etapa foi a criação de um projeto Google Firebase associado a uma de nossas contas – o nível de entrada para este serviço é gratuito e, possivelmente, qualquer um poderia fazê-lo. Depois de termos criado nosso projeto, definimos um aplicativo com exatamente o mesmo nome de nossa amostra de malware. Nesse caso, ele foi chamado de “com.chatlitesocial.app.” Isso gerou um arquivo de configuração JSON do Google Services, como o mostrado abaixo, que um desenvolvedor deve adicionar ao seu projeto para usar os serviços.

Agora que temos os IDs, precisamos adicioná-los ao malware. Descompactamos o malware e procuramos a configuração dos serviços do Google, que encontramos no diretório de recursos do arquivo strings.xml. A imagem abaixo mostra as entradas que substituímos pelos valores que obtivemos do arquivo de configuração JSON. 

Finalmente, reconstruímos o APK, assinamos e instalamos em nosso dispositivo de teste. Em seguida, configuramos um ambiente de teste que consistia em um servidor da web HTTPS para registrar a solicitação de malware, um logcat para ver as mensagens de registro de malware e um script que interage com APIs de administração do Google Firebase Cloud Messaging para enviar a mensagem para nossa vítima.

POR QUE UM NOVO CARREGADOR?

Melhor controle dos dispositivos comprometidos, mesmo se o C2 estiver desligado

Este novo carregador fornece pelo menos dois recursos importantes para os invasores. Primeiro, permite-lhes decidir quem recebe a carga, podendo verificar a vítima antes de enviar a carga. Assim, eles podem evitar que a carga útil caia nas mãos dos pesquisadores ou da aplicação da lei. Em segundo lugar, fornece a eles um poderoso mecanismo de persistência fora da banda.

Normalmente, derrubar um C2 é suficiente para tornar um malware inerte, mesmo se ele permanecer ativo no dispositivo da vítima. Isso pode ser feito pelas autoridades policiais ou pelas plataformas de hospedagem, quando souberem. No entanto, pode ser difícil notificar as vítimas e, em alguns casos, é quase impossível. Usar o serviço Google Firebase Messaging como um canal de controle C2 permite que os invasores recuperem o controle do malware mesmo depois que o C2 for removido. Do ponto de vista da rede, essa ação é totalmente inócua, já que toda a comunicação é feita por meio do Google e criptografada com certificados legítimos.

Se um servidor C2 estiver inativo, a operadora pode enviar uma nova mensagem do Google Firebase para fazer o download de uma nova carga de um novo local, que pode ser um novo C2 ou um local de hospedagem. Esta ação é totalmente oculta para os dispositivos comprometidos, não exigindo interação do usuário. Durante nossa pesquisa, descobrimos que outras versões do mesmo malware existiam usando o Google Firebase como um canal de comunicação alternativo. As versões anteriores, entretanto, simplesmente emitiam um comando para iniciar o serviço malicioso.

Sem carga útil final para os analistas

Como a carga útil final não está embutida no aplicativo Android, é impossível para os analistas dissecá-la. Essa abordagem também torna a detecção mais difícil. O aplicativo é um carregador com uma interface de usuário falsa que manipula o destino após instalá-lo.

Como explicamos acima, o malware precisa entrar em contato com o C2 antes que a operadora use o Google Firebase para contatar o malware. É interessante notar que o url C2 não está ofuscado, mas o componente Google Firebase não é tão óbvio. O trecho de código abaixo é responsável por baixar a carga útil.

Na segunda linha, os autores definem o método HTTP como GET, isso não é necessário, pois GET é o padrão. Em seguida, os atores alteram o método para POST chamando setDoOutput (True). Sem definir nenhum dado a ser enviado, os autores emitem o método connect () para contatar o C2. Acreditamos que isso foi feito de propósito para dificultar a análise. Primeiro, não havia necessidade de definir o método como GET e, em seguida, ele foi alterado para POST sem usar o método correto. Finalmente, para que essa abordagem funcionasse, os operadores tiveram que configurar o servidor de hospedagem de carga útil para aceitar o POST sem dados. Isso exigiria interação da perspectiva de configuração dos invasores, pois esse não é um método padrão.

Mesmas cargas úteis finais do que anteriormente, sem trabalho adicional

O carregador foi projetado para carregar uma classe chamada: “com.system.myapplication.Activities.dcteat”

Este nome é igual aos exemplos anteriores do mesmo grupo. Graças a essa escolha, este carregador pode carregar qualquer APK anterior desse ator de ameaça. Não precisa de custo adicional para o invasor e o malware anterior pode ser usado de forma transparente com este carregador.

ESTRUTURA MÓVEL DO DONOT

Identificamos um novo carregador desenvolvido pela DoNot Team APT. Este ator de ameaça é conhecido por desenvolver e usar malware Android. Aqui está um exemplo de análise por RiskIQ . O malware desenvolvido pela equipe DoNot assume o controle dos dispositivos comprometidos. Ele oferece suporte a todos os recursos clássicos de uma estrutura de espionagem:

• Obtenha o histórico de chamadas
• Pegue o catálogo de endereços
• Obtenha o SMS
• Entrada de teclado
• Obtenha arquivos do cartão SD
• Obtenha informações do usuário
• Obtenha informações de rede
• Obtenha a localização do dispositivo
• Obtenha aplicativos instalados
• Obtenha informações do navegador
• Obtenha informações de calendário
• Obtenha informações do WhatsApp

O novo carregador é 100% compatível com o malware padrão usado pela equipe DoNot. Esse carregador torna a análise mais difícil, baixando e carregando dinamicamente a carga final, e torna o malware mais confiável usando a estrutura de mensagens do Google Firebase. Essa estrutura é usada para enviar mensagens nos dispositivos comprometidos com uma URL onde a carga final está localizada. Com o novo carregamento bloqueando o servidor C2 não é suficiente, se o Firebase messaging ainda estiver ativo, o carregador pode baixar uma nova carga de um novo servidor C2.

CONCLUSÃO

Os atores da ameaça continuam a inovar suas operações. A equipe do DoNot evitou ativamente os métodos tradicionais de vários componentes neste novo malware. Eles tentaram fugir e mascarar usando plataformas do Google, eles usaram diferentes opções de configuração para permitir recursos especialmente criados para sua infraestrutura de servidor da web e garantiram que tinham compatibilidade com versões anteriores de seu malware. Avaliamos que esta é uma equipe que tem a capacidade de financiar recursos contínuos a serem integrados em seu arsenal Android. A equipe DoNot continua a se concentrar na Índia e no Paquistão, e esse malware reforça ainda mais isso.

Os mecanismos de fallback incluídos garantem que seu malware permaneça persistente nos dispositivos infectados. Isso é crucial para garantir o acesso de longo prazo às vítimas comprometidas. Isso, junto com seu mecanismo de entrega seletiva, sugere que sua preferência é permanecer sob o radar e permanecer indetectável por longos períodos de tempo para permitir que haja coleta de informações e espionagem suficiente.

COBERTURA

As maneiras como nossos clientes podem detectar e bloquear essa ameaça estão listadas abaixo.

A Proteção Avançada contra Malware ( AMP ) é ideal para impedir a execução do malware usado por esses agentes de ameaças. O Exploit Prevention presente no AMP foi projetado para proteger automaticamente os clientes de ataques desconhecidos como este.

A varredura da Web do Cisco Cloud Web Security ( CWS ) ou do Web Security Appliance (WSA ) evita o acesso a sites maliciosos e detecta o malware usado nesses ataques.

O Email Security pode bloquear emails maliciosos enviados por agentes de ameaças como parte de sua campanha. Dispositivos de segurança de rede, como Firewall de última geração ( NGFW ), Sistema de prevenção de intrusões de última geração ( NGIPS ), Cisco ISR e Meraki MX pode detectar atividades maliciosas associadas a esta ameaça.

O AMP Threat Grid ajuda a identificar binários maliciosos e criar proteção em todos os produtos Cisco Security.

Umbrella , nosso gateway seguro de Internet (SIG), bloqueia a conexão de usuários a domínios, IPs e URLs maliciosos, estejam eles dentro ou fora da rede corporativa.

Os clientes do Conjunto de regras para assinantes do Snort de código aberto podem se manter atualizados baixando o pacote de regras mais recente disponível para compra no Snort.org . As regras 56081 do Snort defendem especificamente contra Firestarter.

IOCS

HASHES

b4c112d402c2555bea91d5c03763cfed87aa0fb0122558554c9a3bc7ac345990
69f257092947e003465f24b9b0b44d489e798bd5b8cf51f7e84bc161937b2e7c
a5cfb2de4ca0f27b012cb9ae56ceacc2351c9b9f16418406edee5e45d1834650
d0a597a24f9951a5d2e7cc71702d01f63ff2b914a9585dbab5a77c69af5d60b5
e7a24751bc009bbd917df71fd4815d1483f52669e8791c95de2f44871c36f7f4
86194d9cb948d61da919e238c48a01694c92836a89c6108730f5684129830541
8770515a5e974a59f023c4c71b0c772299578f1e386f60f9dd203b64e2e2d92e
a074aa746a420a79a38e27b766d122e8340f81221fe011f644d84ff9b511f29a
3d3f61d5406149fd8f2c018fbc842ccef2f645fc22f4e5702368131c1bd4e560
3d40fdc4dc550394884f0b4e38aa8a448f91f8e935c1b51fedc4b71394fa2366
83d174c65f1c301164683c163dab3ea79d56caeda1a4379a5a055723e1cb9d00
0c2494c03f07f891c67bb31390c12c84b0bb5eea132821c0873db7a87f27ccef
b583ae22c9022fb71b06ec1bae58d0d40338432b47d5733bf550972c5cb627c4
c4971a65af3693896fdbb02f460848b354251b28067873c043366593b8dbc6f9
fa85813a90a2d0b3fc5708df2156381fdb168919b57e32f81249f8812b20e00a
fde7ca904d9ae72ea7e242ee31f7fbaee963937341ca2863d483300828a4c6e0
0c2494c03f07f891c67bb31390c12c84b0bb5eea132821c0873db7a87f27ccef
192f699e6ce2cccb2c78397392f4d85566892d9c8cf7de1175feb4d58f97d815
e8605854c8730d2e80d8a5edd8bc83eb7c397a700255754ec9140b9717f7d467
2481f133dd3594cbf18859b72faa391a4b34fd5b4261b26383242c756489bf07
0c2494c03f07f891c67bb31390c12c84b0bb5eea132821c0873db7a87f27ccef

Domínios e endereços IP

178.62.188 [.] 181
bulk [.] Fun
inapturst [.] Top
seahome [.] Top
fif0 [.] Top
apkv6.endurecif [.] Top