Mamba: O mais novo membro da família de Ransomwares de Encriptação Total de Disco

Introdução

“You are Hacked ! H.D.D Encrypted, Contact Us For Decryption Key (w889901665@yandex.com) YOURID: 123152Esta mensagem é tudo que resta para as vítimas deste novo Ransomware. Para obter a chave de descriptografia, é necessário contatar “alguém” por e-mail, informar o ID e pagar 1 bitcoin por host afetado como resgate. Sem isso, o sistema sequer inicia. Para este artigo, chamaremos esse RansomwareMamba”, em referência à cobra com veneno paralisante.

Ao que parece, a família de Ransomwares de encriptação em nível de disco está crescendo. Um Ransomware similiar, chamado Petya, ficou famoso em março deste ano devido à sua estratégia de encriptação de disco; embora análises [1] informem que o malware encripta “apenas” a MFT (Master File Table) e não dos dados em si. O Ransomware Mamba difere exatamente nesse ponto. Ele utiliza uma ferramenta de código aberto de encriptação, o DiskCryptor [2], para encriptar todo o disco utilizando um algoritmo forte.

Descobrimos o Mamba no dia 7 de setembro último, durante uma resposta a incidente para uma empresa multinacional que teve alguns servidores comprometidos por esse malware em suas subsidiárias no Brasil, EUA e Índia.

O propósito deste artigo é compartilhar alguns resultados da análise do Mamba e angariar colaboração para melhor entender esta ameaça e seus vetores de intrusão.

A Mensagem de Resgate

Conforme dito na na introdução deste artigo, o Ransomware impede o sistema operacional de carregar ao sobrescrever a MBR (Master Boot Record) do disco de boot por outra que exibe a mensagem de resgate e solicita uma senha de descriptografia, como pode ser visto na Figura 1.

Figura 1: Mensagem de resgate ao ligar a máquina

Não está claro, mas esta nova MBR também solicita ao usuário que informe a senha de decriptação.

Em Busca da Amostra do Malware

Como todos os dados do HDD dos servidores comprometidos foram encriptados, incluindo o próprio Ransomware, iniciamos nossas buscas por mais informação em outro local.

A primeira estratégia foi buscar por partes da mensagem do Ransomware na Web. Para nossa surpresa, ao colocar o texto “contact us for decryption key” YOURID, tivemos apenas um resultado no Google. Ele apontou para uma análise feita utilizando a sandbox Malwr [3] em 29 de agosto deste ano. O resultado nos proporcionou algumas informações muito importantes, como o nome do arquivo (141.exe) e os hashes.

Figura 2: Resultados do Google para partes da “mensagem de resgate”

Buscando pelos hash do arquivo “141.exe” no VirusTotal, encontramos algumas AV Engines ligando a amostra a Ransomware, como a TrendMicro que o chamou de Ransom_HDDCRYPTOR.A.

Figure 3: Análise da TrendMicro para a amostra “141.exe”

Ao mesmo tempo, começamos a buscar pelo malware em outros hosts da rede da companhia infectada. Após algum esforço, utilizando uma solução de “anti-malware”, encontramos um arquivo malicioso em específico em outros hosts. Seu nome era “152.exe”.

Conduzindo uma análise dinâmica do “152.exe” com o TIV (tiv.morphuslabs.com) e sandboxes de “Análise Híbrida” [4], encontramos similaridades entre as strings do memory dump do “152.exe” e a “mensagem de resgate” previamente detectada. Na verdade, encontramos a mensagem exata “You are Hacked ! H.D.D Encrypted, Contact Us For Decryption Key (w889901665@yandex.com) YOURID: 123152” - inclusive o id da mensagem (YOURID) era o mesmo.

À propósito, acreditamos ser muito curioso que até o “YOURID” na análise da sandbox seja igual ao dos hosts comprometidos. Em outras palavras, pode tratar-se de código estático.

Análise Inicial do Mamba

Para melhor entender como o Mamba funciona, realizamos alguns testes em nosso laboratório. No primeiro teste, basicamente rodamos a amostra em uma máquina virtual Windows 8.1. Infelizmente, nada aconteceu, além de um arquivo de log criado no diretório “C:\DC22” informando que “a senha não foi informada”.

Em uma segunda tentativa, informamos uma senha como parâmetro e o resultado foi diferente. Mais arquivos foram gerados no diretório “C:\DC22”, como pode ser visto na Figura 4.

Figura 4: Arquivos criados como resultado da execução de 152.exe com uma senha como argumento

Após alguns segundos, o Windows reiniciou e, quando retornou, o sistema operacional estava aparentemente normal. Estas foram as mensagens encontradas no arquivo “log_file.txt”:

installing driver…
installing driver successfully..
getting share drive information…
Trying to create service…
creating service successfully. rebooting windows…

A partir dessa mensagem, podemos inferir algumas informações:

Um novo serviço foi criado (não há menção de seu nome);
Aparentemente, estão utilizando a ferramenta DiskCryptor;
Aparentemente, desejam obter as credenciais da máquina utilizando o “netpass.exe”;
“netuse.txt” lista os diretórios compartilhados mapeados pelo usuário;

Então, utilizamos o Regshot para descobrir mais informações sobre as mudanças causadas pelo malware ao SO, incluindo o novo serviço criado. Como resultado, descobrimos que um dos novos serviços criados foi o “DefragmentService”. Também descobrimos que o malware criou um novo usuário na máquina chamado “mythbusters” com a senha “123456”.

Estas são as informações dos novo serviço criado:

Figure 5: Falso DefragmentService criado pelo Mamba

De acordo com esse serviço, após a máquina reiniciar, é esperado que o “152.exe”seja chamado com os mesmos parâmetros que informamos na primeira execução. Seguimos observando os processos da máquina, mas o “152.exe” não estava rodando.

Então, tentamos um reiniciar a máquina novamente para checar se a “mensagem de resgate” iria aparecer, mas o sistema reiniciou normalmente.

Realizando uma análise do “dcrypt.exe” e “dccon.exe”, que são a interface gráfica e de linha de comando do DiskCryptor, respectivamente, descobrimos que o parâmetro de senha é precedido por um “-p”. Então tentamos executar o “152.exe” com esse parâmetro antes de partirmos para engenharia reversa.

Para nossa surpresa, desta vez o processo de encriptação funcionou e a “mensagem de resgate” foi exibida durante o boot. A única coisa que notamos de diferente desta vez foi que a senha agora era o próprio “-p” e não a senha informada pelo parâmetro seguinte. Então, pelo que parece, o Mamba espera um segundo argumento para “funcionar corretamente”.

O processo que encriptou o disco foi o “dccon.exe”, chamado por “152.exe”. Durante o processo, foi possível acompanhar a encriptação com o comando “dccon-info pt0” e o resultado foi como a seguir:

Figure 6: Encriptação total de disco realizada pelo Mamba Ransomware.

Após reiniciar a máquina, o que não ocorreu em sua completude, a “mensagem de resgate” foi exibida exatamente igual àquelas das máquinas comprometidas da empresa utilizada nesta análise.

Figure 7: Host do laboratório comprometido

Nesta fase, o arquivo de log possui o seguinte conteúdo:

installing driver…
installing driver successfully..
getting share drive information…
Trying to create service…
creating service successfully. rebooting windows…
Checking resources existence. They are OK…
driver installed before…
starting serviceMain…
ServiceMain: Entry
ServiceMain: Performing Service Start Operations
ServiceMain: Waiting for Worker Thread to complete
ServiceWorkerThread: Entry
ServiceCtrlHandler: Entry
ServiceCtrlHandler: Exit
Starting Mount app…
Checking resources existence. They are OK…
driver installed before…
mount:start…
pass:
123456
mount:mounting share drive…
mount:OS is win2003 or lower…
mount:share drive not found …
mount:exit Mount…
start hard drive encryption…
Checking resources existence. They are OK…
driver installed before…
Trying to create service…

Como podemos ver, neste momento, a senha usada para encriptar o disco foi gravada no arquivo de log.

Próximos passos

Encontramos boa informação sobre essa ameaça até o momento, mas ainda não conseguimos identificar o vetor de infecção. Sabemos que a senha utilizada para encriptar o disco é informada como parâmetro, então, talvez exista algum script ou outro binário que chame o “152.exe” fornecendo-lhe a senha em texto limpo. Também acreditamos que a senha é a mesma para todas as vítimas ou pode ser formada por algo relacionado ao ambiente da vítima, como o hostname ou algo do gênero.

Os atores responsáveis por esta campanha parecem estar fazendo algum dinheiro com a mesma. Contatamos o endereço de e-mail e eles nos pediram 1 BTC por máquina infectada.

Esta foi a mensagem que recebemos:

andy saolis<w889901665@yandex.com>
Your HDD Encrypted By AES 2048Bit
send 1BTC Per HOST to My Bitcoin Wallet , then we give you Decryption key For Your Server HDD!!
My Bitcoin Wallet Address : 1NLnMNMPbxWeMJVtGuobnzWU3WozYz86Bf
We Only Accept Bitcoin , it’s So easy!
you can use Brokers to exchange your money to BTC ASAP
it’s Fast way!
Here:
https://localbitcoins.com/
if You Don’t Have a Account in Bitcoin , Read it First :
https://bitcoin.org/en/getting-started
bitcoin Market :
https://blockchain.info/
https://www.okcoin.com/
https://www.coinbase.com/
https://bitcoinwallet.com/

Um ponto que chamou nossa atenção foi a menção a “servidor” na mensagem de resposta. Seria sua estratégia comprometer apenas servidores? Corrobora com esta hipótese o fato de que outras máquinas com o arquivo “152.exe” não foram comprometidas.

A carteira entregue pelo cybercriminoso recebeu 4 BTC até o momento deste artigo.

Figure 8: Balanço da carteira de bitcoins do criminoso

Estamos abertos a colaboração com a comunidade de segurança da informação para encontrar mais informações sobre essa ameaça.

Mamba sample info

File name: 152.exe
MD5: a50325553a761d73ed765e326a1733a3

Referências:

[1] https://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/
[2] https://diskcryptor.net/wiki/Main_Page
[3] https://www.hybrid-analysis.com/sample/74336da7eb463092a5f1bca3071f96b005f52e6df5826f8b0351e10537ba0459?environmentId=100
[4] https://malwr.com/analysis/YzI4ZTI3NjAxYjNmNDNjZDlmZjhiMjIxMDM3Nzg3NDE/