Script de ransomware Python tem como alvo o servidor ESXi para criptografia

Os erros de configuração rapidamente se transformaram em um ataque de ransomware dentro de um hipervisor de máquina virtual

Uma investigação recentemente concluída sobre um ataque de ransomware revelou que os invasores executaram um script Python personalizado no hipervisor da máquina virtual do alvo para criptografar todos os discos virtuais, deixando as VMs da organização offline.

No que foi um dos ataques mais rápidos que a Sophos investigou, desde o momento do comprometimento inicial até a implantação do script de ransomware, os invasores passaram apenas pouco mais de três horas na rede do alvo antes de criptografar os discos virtuais em um servidor VMware ESXi.

O script Python incorpora o texto da nota de resgate.

Os invasores inicialmente acessaram seu ponto de apoio fazendo login em uma conta TeamViewer (uma que não tinha a autenticação multifator configurada), rodando em segundo plano em um computador que pertence a um usuário com credenciais de administrador de domínio na rede do alvo. Os invasores se conectaram 30 minutos após a meia-noite no fuso horário da organização alvo e, dez minutos depois, baixaram e executaram uma ferramenta chamada Advanced IP Scanner para identificar os alvos na rede.

Pouco antes das 2 da manhã, os invasores baixaram um cliente SSH chamado Bitvise e o usaram para fazer login em um servidor VMware ESXi que identificaram usando o Advanced IP Scanner. Os servidores ESXi têm um serviço SSH integrado chamado ESXi Shell que os administradores podem habilitar, mas normalmente é desabilitado por padrão.

A equipe de TI desta organização estava acostumada a usar o ESXi Shell para gerenciar o servidor e habilitou e desabilitou o shell várias vezes no mês anterior ao ataque. No entanto, a última vez que eles habilitaram o shell, eles falharam em desabilitá-lo depois. Os criminosos aproveitaram-se dessa situação fortuita quando descobriram que o projétil estava ativo.

Ransomware Python

Três horas depois que os invasores varreram a rede, eles usaram suas credenciais para fazer login no ESXi Shell e copiaram um arquivo chamado fcker.py para o armazenamento de dados ESXi, que hospeda as imagens de disco virtual usadas pelas VMs executadas no hipervisor.

O script Python usa as funções de comando vim-cmd do ESXi Shell para produzir uma lista dos nomes de todas as máquinas virtuais instaladas no servidor e, em seguida, desliga todas.

Um por um, os invasores executaram o script Python, passando o caminho para os volumes de disco do armazenamento de dados como um argumento para o script. Cada volume individual continha o disco virtual e os arquivos de configurações de VM para várias máquinas virtuais.

Graças a algum trabalho forense sólido, a equipe do Rapid Response recuperou uma cópia do script Python, embora os invasores parecessem ter sobrescrito com outros dados antes de excluir o arquivo.

Com apenas 6kb de comprimento, o pequeno tamanho do script desmente suas habilidades. O script contém variáveis ​​que o invasor pode configurar com várias chaves de criptografia, endereços de e-mail e onde ele pode personalizar o sufixo do arquivo que é anexado aos arquivos criptografados.

O script incorpora o sufixo do arquivo que ele anexa aos arquivos criptografados ( ext ) e endereços de e-mail ( mail, mail2 ) para serem usados ​​para contatar o invasor para o pagamento do resgate como variáveis.

Inicialmente, o script “percorre” o sistema de arquivos de um armazenamento de dados e cria um mapa de diretório da unidade e inventa os nomes de cada máquina virtual no hipervisor, gravando-os em um arquivo chamado vms.txt . Em seguida, ele executa o comando ESXi Shell vim-cmd vmsvc / power.off , uma vez para cada VM, passando os nomes da VM para o comando como uma variável, um de cada vez. Somente quando as VMs forem desligadas, o script começará a criptografar os volumes do armazenamento de dados.

Usando uma única instrução para cada arquivo que criptografa, o script invoca a ferramenta de código aberto openssl para criptografar os arquivos com o seguinte comando:

openssl rsautil -encrypt -inkey pubkey.txt -pubin -out [nome do arquivo] .txt
A função de criptografia de arquivo no script Python

O script sobrescreve o conteúdo do arquivo original apenas com a palavra foda e exclui o arquivo original. Por fim, ele exclui os arquivos que contêm as listagens de diretório, os nomes das VMs e a si mesmo, sobrescrevendo esses arquivos antes de excluí-los.

Chaves de criptografia geradas rapidamente

Uma coisa que notamos ao percorrer o código foi a presença de várias chaves de criptografia embutidas no código, bem como uma rotina para gerar ainda mais pares de chaves de criptografia. Normalmente, um invasor precisaria apenas incorporar a “chave pública” que o invasor gerou em sua própria máquina e seria usada para criptografar arquivos no (s) computador (es) visado (s). Mas esse ransomware parece criar uma chave exclusiva toda vez que é executado.

Chaves públicas incorporadas no ransomware Python

Então, o que está acontecendo com isso?

Aparentemente, toda vez que o malware é executado – e parece que os invasores executaram o script uma vez para cada armazenamento de dados ESXi que eles queriam criptografar – o ransomware gera um par de chaves exclusivo que será usado para criptografar arquivos durante aquela execução específica. No caso de No ataque que investigamos, havia três datastores que os invasores visavam com execuções individuais do script, então o script criou três pares de chaves exclusivos, um para cada datastore.

Para cada execução visando um armazenamento de dados ESXi diferente (caminhos esmaecidos), o script gerou uma chave de criptografia exclusiva

O script não tem capacidade de transmitir essas chaves a qualquer lugar e não há como o invasor prever quais serão as chaves, então o script precisa deixar uma cópia da chave secreta (a chave que o invasor precisaria para descriptografar os arquivos) no sistema de arquivos do computador de destino. Mas seria um erro gigantesco simplesmente deixar essa chave por aí (quem possui a chave secreta poderia, teoricamente, usá-la para descriptografar tudo sem ter que pagar um resgate), então o script escreve uma cópia dessa chave secreta, e em seguida, criptografa a chave secreta usando a chave pública embutida e codificada.

O script executa uma rotina que lista todos os arquivos no caminho fornecido para o script durante a execução. Para cada arquivo, o script gera um código aleatório exclusivo de 32 bytes que ele chama de aeskey e, em seguida, criptografa o arquivo usando a aeskey como um sal no caminho / tmp.

Por fim, ele adiciona o valor aeskey ao arquivo criptografado e adiciona um novo sufixo de arquivo ao nome, sobrescreve o conteúdo do arquivo original com a palavra fuck, em seguida, exclui o arquivo original e move a versão criptografada de / tmp para o local do armazenamento de dados onde o arquivo original foi armazenado.

Os hipervisores são alvos valiosos

Malware executado em um sistema operacional semelhante ao Linux, como o ESXi usa, ainda é relativamente incomum, mas é ainda menos comum para a equipe de TI instalar proteção de endpoint em servidores como esses. Os hipervisores em geral costumam ser alvos bastante atraentes para esse tipo de ataque, uma vez que as VMs que hospedam podem executar serviços ou funções essenciais aos negócios.

As ferramentas de gerenciamento do ESXi podem ativar ou desativar o ESXi Shell de dentro da ferramenta ou localmente no console conectado ao servidor. O padrão do shell é “Parado”.

Os administradores que operam o ESXi ou outros hipervisores em suas redes devem seguir as práticas recomendadas de segurança, evitando a reutilização de senha e usando senhas complexas e difíceis de força bruta de comprimento adequado. Sempre que possível, habilite o uso de autenticação multifator e imponha o uso de MFA para contas com permissões altas, como administradores de domínio.

No caso do ESXi, o uso do ESXi Shell é algo que pode ser ativado ou desativado em um console físico na própria máquina ou por meio das ferramentas normais de gerenciamento fornecidas pela VMware. Os administradores devem permitir que o Shell esteja ativo apenas durante o uso pela equipe e devem desativá-lo assim que a manutenção (como a instalação de patches) for concluída.

A VMware também publicou uma lista de práticas recomendadas para administradores de seus hipervisores ESXi sobre como protegê-los e limitar a superfície de ataque no próprio hipervisor.

Os scripts Python desse tipo são detectados pelos produtos de endpoint da Sophos como Troj / Ransom-GJR.

Agradecimentos

A SophosLabs deseja reconhecer o trabalho de Rajesh Nataraj, Andrew O’Donnell e Mauricio Valdivieso por sua assistência

Fonte: https://news.sophos.com