O quer estava ruim ficou pior, pois agora, a nova versão do ransomware ESXiArgs impede a recuperação do VMware ESXi.
Os novos ataques de ransomware ESXiArgs agora estão criptografando quantidades mais extensas de dados, tornando muito mais difícil, se não impossível, a recuperação de máquinas virtuais VMware ESXi criptografadas.
Ransomware ESXiArgs impede a recuperação do VMware ESXi
Na sexta-feira passada, um enorme e generalizado ataque de ransomware automatizado criptografou mais de 3.000 servidores VMware ESXi expostos na Internet usando um novo ransomware ESXiArgs.
Relatórios preliminares indicaram que os dispositivos foram violados usando vulnerabilidades antigas do VMware SLP. No entanto, algumas vítimas afirmaram que o SLP foi desativado em seus dispositivos e ainda foi violado e criptografado.
Ao criptografar um dispositivo, um script ‘encrypt.sh’ procura por arquivos de máquina virtual correspondentes às seguintes extensões:
.vmdk
.vmx
.vmxf
.vmsd
.vmsn
.vswp
.vmss
.nvram
.vmem
Para cada arquivo encontrado, o script verifica o tamanho do arquivo e, se o arquivo for menor que 128 MB, criptografa o arquivo inteiro em incrementos de 1 MB.
No entanto, para arquivos maiores que 128 MB, ele calcularia um ‘size_step’, o que faria com que o criptografador alternasse entre criptografar 1 MB de dados e não criptografar pedaços (o size_step em megabytes) de dados.
O script encrypt.sh usa a seguinte fórmula (ligeiramente modificada para facilitar a leitura) para determinar qual size_step deve ser usado:
size_step=((($size_in_kb/1024/100)-1))
Isso significa que, para um arquivo de 4,5 GB, ele geraria um size_step de ’45’, fazendo com que o criptografador alternasse entre criptografar 1 MB do arquivo e ignorar 45 MB do arquivo.
Portanto, como você pode ver, muitos dados permanecem não criptografados quando terminam de criptografar um arquivo.
Para arquivos ainda maiores, como um arquivo de 450 GB, a quantidade de dados ignorados aumenta drasticamente, com o size_step se tornando ‘4607’, agora alternando entre criptografar 1 MB e ignorar 4,49 GB de dados.
Devido a esses grandes blocos de dados não criptografados, os pesquisadores criaram um método para recuperar máquinas virtuais usando arquivos simples grandes e principalmente não criptografados, onde os dados do disco da máquina virtual são armazenados.
Um script criado pela CISA posteriormente automatizou esse processo de recuperação.
Infelizmente, uma segunda onda de ransomware ESXiArgs começou recentemente e inclui uma rotina de criptografia modificada que criptografa muito mais dados em arquivos grandes.
O site BleepingComputer soube da segunda onda depois que um administrador postou no tópico de suporte do ESXiArgs informando que seu servidor foi criptografado e não pôde ser recuperado usando os métodos que funcionaram anteriormente.
Depois de compartilhar as amostras com o BleepingComputer, notaram que o criptografador não havia mudado, mas a rotina ‘size_step’ do script encrypt.sh foi retirada e simplesmente definida como 1 na nova versão.
Essa alteração é ilustrada abaixo em uma comparação entre o cálculo original do encrypt.sh size_step (à esquerda) na primeira onda de ataques, com o novo shell script (à direita) na segunda onda.
O especialista em ransomware Michael Gillespie disse ao BleepingComputer que essa mudança faz com que o criptografador alterne entre criptografar 1 MB de dados e pular 1 MB de dados.
Todos os arquivos com mais de 128 MB agora terão 50% de seus dados criptografados, tornando-os provavelmente irrecuperáveis.
Essa alteração também impede que as ferramentas de recuperação anteriores recuperem máquinas com êxito, pois os arquivos simples terão muitos dados criptografados para serem usados.
Essa segunda onda de ataque também fez uma pequena alteração na nota de resgate ao não incluir mais endereços bitcoin na nota de resgate, conforme mostrado abaixo.
A remoção dos endereços de bitcoin provavelmente ocorreu porque eles foram coletados por pesquisadores de segurança para rastrear pagamentos de resgate.
No entanto, ainda mais preocupante, o administrador que compartilhou as novas amostras disse que o SLP foi desativado em seu servidor, mas ainda foi violado novamente. Eles também verificaram o backdoor vmtool.py visto em ataques anteriores e não foram encontrados.
Com o SLP desativado, fica ainda mais confuso como esse servidor foi violado.
O site BleepingComputer ainda recomenda tentar recuperar servidores ESXi criptografados usando o script de recuperação da CISA.
No entanto, provavelmente não funcionará mais se você foi infectado na segunda onda de ataques usando a nova rotina de criptografia.