Ryuk é uma das variantes de ransomware mais conhecidas dos últimos anos. Desde que apareceu pela primeira vez no verão de 2018, acumulou , especialmente no ambiente empresarial, que é o principal alvo de seus ataques.
1. Informações Gerais
Este documento contém uma análise da variante de ransomware Ryuk, bem como do carregador responsável por introduzir o malware no sistema.
O ransomware Ryuk apareceu pela primeira vez no verão de 2018. Uma das diferenças do Ryuk em relação a outros ransomwares é que ele foca em atacar ambientes corporativos.
No meio de 2019, grupos cibercriminosos atacaram um grande número de empresas espanholas com este ransomware.
Fig. 1: Trecho do El Confidencial sobre o ataque do ransomware Ryuk [1]
Fig. 2: Trecho do El País sobre o ataque realizado com o ransomware Ryuk [2]
Este ano, o Ryuk atacou um número considerável de empresas em vários países. Como você pode ver nas figuras abaixo, os mais afetados foram a Alemanha, a China, a Argélia e a Índia.
Comparando o número de ciberataques, podemos ver que milhões de usuários foram afetados pelo Ryuk e um enorme volume de dados foi comprometido, resultando em prejuízos econômicos significativos.
Fig. 3: Ilustração da atividade global do Ryuk.
Fig. 4: 16 países mais afetados pelo Ryuk
Fig. 5: Número de usuários atacados pelo ransomware Ryuk (em milhões)
De acordo com o funcionamento comum de ameaças desse tipo, este ransomware exibe uma notificação de resgate após a conclusão da criptografia, que deve ser paga em bitcoins para o endereço indicado para recuperar o acesso aos arquivos criptografados.
Este malware evoluiu desde sua primeira aparição.
A variante desta ameaça analisada neste documento foi detectada durante uma tentativa de ataque em janeiro de 2020.
Devido à sua complexidade, este malware é frequentemente atribuído a grupos cibercriminosos organizados, também conhecidos como grupos APT.
Uma parte do código Ryuk apresenta uma semelhança notável com o código e a estrutura de outro ransomware conhecido, o Hermes, que possui várias funções semelhantes. Por essa razão, inicialmente o Ryuk foi associado ao grupo norte-coreano Lazarus, que na época era suspeito de ser responsável pelo ransomware Hermes.
Posteriormente, o serviço Falcon X da CrowdStrike observou que, na verdade, o Ryuk foi criado pelo grupo WIZARD SPIDER [4].
Existem várias evidências que apoiam essa suposição. Primeiro, esse ransomware foi promovido no site exploit.in, que é um conhecido mercado russo de malwares e anteriormente esteve relacionado a alguns grupos APT russos.
Esse fato exclui a teoria de que o Ryuk poderia ter sido desenvolvido pelo grupo APT Lazarus, pois isso não condiz com a forma como esse grupo opera.
Além disso, o Ryuk foi promovido como um ransomware que não funcionaria em sistemas russos, ucranianos e bielorrussos. Esse comportamento é definido por uma função encontrada em algumas versões do Ryuk, onde ele verifica o idioma do sistema em que está sendo executado e interrompe sua operação caso o sistema tenha o idioma russo, ucraniano ou bielorrusso. Finalmente, durante a análise pericial da máquina que foi invadida pelo grupo WIZARD SPIDER, foram encontrados vários "artefatos" que supostamente foram utilizados no desenvolvimento do Ryuk como uma variante do ransomware Hermes.
Por outro lado, os especialistas Gabriela Nicolo e Luciano Martins sugeriram que o ransomware poderia ter sido desenvolvido pelo grupo APT CryptoTech [5].
Isso se deve ao fato de que, alguns meses antes do surgimento do Ryuk, esse grupo postou em um fórum do mesmo site informações de que havia desenvolvido uma nova versão do ransomware Hermes.
Vários usuários do fórum questionaram se a CryptoTech realmente havia criado o Ryuk. Após isso, esse grupo se defendeu e afirmou que tinha provas de que desenvolveram 100% desse ransomware.
2. Características
Começamos com o carregador, cuja tarefa é identificar o sistema em que se encontra, para poder executar a versão "correta" do ransomware Ryuk.
O hash do carregador é o seguinte:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
Uma das características deste loader é que ele não contém nenhum metadado, ou seja, os criadores deste malware não incluíram nenhuma informação nele.
Às vezes, eles incluem dados errôneos para fazer o usuário pensar que está executando um aplicativo legítimo. No entanto, como veremos mais adiante, se a infecção não requer interação do usuário (como no caso deste ransomware), os criminosos não consideram necessário usar metadados.
Fig. 6: Metadados do amostra
A amostra foi compilada em formato de 32 bits, para que possa ser executada tanto em sistemas de 32 bits quanto em 64 bits.
3. Vetor de Penetração
A amostra que carrega e executa o Ryuk entrou em nosso sistema através de uma conexão remota, e as credenciais de acesso foram obtidas por meio de um ataque RDP anterior.
Fig. 7: Registro do ataque
O criminoso conseguiu acessar o sistema remotamente. Depois, ele criou um arquivo executável com nossa amostra.
Esse arquivo executável foi bloqueado pela solução antivírus antes da execução.
Fig. 8: Bloqueio da amostra
Fig. 9: Bloqueio da amostra
Quando o arquivo malicioso foi bloqueado, o criminoso tentou carregar uma versão criptografada do arquivo executável, que também foi bloqueada.
Fig. 10: Conjunto de amostras que o criminoso tentou executar
Finalmente, ele tentou carregar outro arquivo malicioso através do console criptografado
PowerShell para contornar a proteção antivírus. Mas ele também foi bloqueado.
Fig. 11: PowerShell com conteúdo malicioso bloqueado
Fig. 12: PowerShell com conteúdo malicioso bloqueado
4. Loader
Quando executado, ele grava um arquivo ReadMe na pasta %temp%, o que é típico do Ryuk. Este arquivo é um pedido de resgate, contendo um endereço de e-mail no domínio protonmail, que é bastante comum nesta família de malware: msifelabem1981@protonmail.com
Fig. 13: Pedido de resgate
Durante a execução do loader, você pode ver que ele запуска vários arquivos executáveis com nomes aleatórios. Eles são armazenados em uma pasta oculta PUBLIC, mas se a opção de sistema operacional "Mostrar arquivos e pastas ocultos" não estiver ativada «Mostrar arquivos e pastas ocultos», eles permanecerão ocultos. Além disso, esses arquivos são de 64 bits, ao contrário do arquivo pai, que é de 32 bits.
Fig. 14: Arquivos executáveis acionados pela amostra
Como você pode ver na figura acima, o Ryuk executa o icacls.exe, que será utilizado para modificar todas as listas de controle de acesso (ACL), garantindo assim acesso e alteração dos flags.
Ele obtém acesso total sob todos os usuários a todos os arquivos no dispositivo (\/T) independentemente de erros (\/C) e sem exibir quaisquer mensagens (\/Q).
Fig. 15: Parâmetros de execução do icacls.exe acionado pela amostra
É importante considerar que o Ryuk verifica qual versão do Windows está sendo executada. Para isso, ele
realiza a verificação da versão através do GetVersionExW, onde verifica o valor do flag lpVersionInformation, que indica se a versão atual do Windows é mais recente do que Windows XP.
Dependendo se você está usando uma versão mais recente do que o Windows XP, o carregador irá gravar na pasta do usuário local — neste caso, na pasta %Public%.
Fig. 17: Verificação da versão do sistema operacional
O arquivo gravado é o Ryuk. Em seguida, ele o executa, passando seu próprio endereço como parâmetro.
Fig. 18: Execução do Ryuk através do ShellExecute
A primeira coisa que o Ryuk faz é obter os parâmetros de entrada. Desta vez, existem dois parâmetros de entrada (o próprio arquivo executável e o endereço do dropper), que são usados para remover suas próprias trilhas.
Fig. 19: Criação do processo
Você também pode ver que assim que ele executou seus arquivos executáveis, ele se remove, não deixando nenhuma evidência de sua presença na pasta onde foi executado.
Fig. 20: Remoção do arquivo
5. RYUK
5.1 PRESENÇA
O Ryuk, assim como outros malwares, tenta permanecer no sistema o máximo possível. Como mostrado acima, uma das maneiras de alcançar esse objetivo é a criação e execução oculta de arquivos executáveis. Para isso, a prática mais comum é modificar a chave do registro CurrentVersionRun.
Neste caso, você pode ver que para esse fim, o primeiro arquivo executável VWjRF.exe
(o nome do arquivo é gerado aleatoriamente) executa cmd.exe.
Fig. 21: Execução do arquivo VWjRF.exe
Em seguida, é inserido o comando RUN com o nome "svchos". Dessa forma, se você quiser verificar as chaves do registro a qualquer momento, poderá facilmente não perceber essa alteração, considerando a semelhança do nome com svchost. Graças a esta chave, o Ryuk garante sua presença no sistema. Se o sistema ainda não foi infectado, ao reiniciar, o arquivo executável tentará novamente.
Fig. 22: A amostra garante presença na chave do registro
Também podemos ver que este arquivo executável interrompe dois serviços:
"audioendpointbuilder", que, como o nome sugere, corresponde ao áudio do sistema,
Fig. 23: A amostra interrompe o serviço de áudio do sistema
e samss, que é o serviço de gerenciamento de contas. A interrupção desses dois serviços é uma característica do Ryuk. Neste caso, se o sistema estiver conectado a um sistema SIEM, o ransomware tenta interromper o envio de de quaisquer alertas. Dessa forma, ele protege seus próximos passos, uma vez que alguns serviços SAM não poderão iniciar corretamente após a execução do Ryuk.
Fig. 24: A amostra interrompe o serviço Samss
5.2 Privilégios
De forma geral, o Ryuk começa com o movimento lateral dentro da rede ou é iniciado por outro malware, como ou , que, em caso de escalonamento de privilégios, transmite esses direitos elevados para o ransomware.
Previamente, como uma introdução ao processo de implementação, vemos que ele executa o processo ImpersonateSelf, o que significa que o conteúdo de segurança do token de acesso será transferido para o fluxo, onde será imediatamente capturado usando GetCurrentThread.
Fig. 25: Chamada ImpersonateSelf
Em seguida, vemos que ele vincula o token de acesso ao fluxo. Também vemos que uma das flags é DesiredAccess, que pode ser usada para controlar o acesso que o fluxo terá. Neste caso, o valor que edx receberá deve ser TOKEN_ALL_ACESS ou, caso contrário, TOKEN_WRITE.
Fig. 26: Criação do token de fluxo
Em seguida, ele usará SeDebugPrivilege e fará uma chamada para obter os direitos de depuração Debug em relação ao fluxo, resultando na instrução PROCESS_ALL_ACCESS, permitindo acesso a qualquer processo necessário. Agora, considerando que o ransomware já tem um fluxo preparado, resta apenas avançar para a fase final.
Fig. 27: Chamada de SeDebugPrivilege e função de escalonamento de privilégios
Por um lado, temos o LookupPrivilegeValueW, que nos fornece as informações necessárias sobre os privilégios que desejamos elevar.
Fig. 28: Solicitação de informações sobre privilégios para sua elevação
Por outro lado, temos AdjustTokenPrivileges, que permite obter os direitos necessários para o nosso processo. Neste caso, o mais importante é NewState, cujo sinalizador fornecerá os privilégios.
Fig. 29: Configuração de direitos para o token
5.3 Implementação
Nesta seção, mostraremos como o exemplo executa o processo de implementação, já mencionado neste relatório.
O objetivo principal do processo de implementação, assim como o de escalonamento, é obter acesso a cópias de sombra. Para isso, ele precisa operar com um processo com direitos superiores aos do usuário local. Assim que ele obtiver esses direitos mais elevados, ele removerá as cópias e fará alterações em outros processos para impossibilitar o retorno a um ponto de restauração anterior no sistema operacional.
Como costuma acontecer com esse tipo de malware, para executar a implementação, ele utiliza CreateToolHelp32Snapshot, portanto ele tira uma instantânea dos processos atualmente em execução e tenta acessar esses processos por meio de OpenProcess. Assim que obtém acesso ao processo, ele também abre o token com suas informações para obter os parâmetros do processo.
Fig. 30: Obtendo processos do computador
Podemos ver dinamicamente como ele obtém a lista de processos em execução no subprograma 140002D9C usando CreateToolhelp32Snapshot. Depois de obtê-los, ele percorre a lista, tentando abrir os processos um por um usando OpenProcess até que consiga. Neste caso, o primeiro processo que ele conseguiu abrir foi "taskhost.exe".
Fig. 31: Execução dinâmica da rotina para obter o processo
Podemos ver que, em seguida, ele lê as informações do token do processo, então ele chama OpenProcessToken com o parâmetro "20008"
Fig. 32: Lendo informações do token do processo
Ele também verifica se o processo no qual ele irá se infiltrar não é csrss.exe, explorer.exe, lsaas.exe ou se ele possui um conjunto de direitos NT authority.
Fig. 33: Processos excluídos
Podemos ver dinamicamente como ele primeiro realiza uma verificação usando as informações do token do processo em 140002D9C para verificar se a conta cujos direitos estão sendo utilizados no processo é uma conta AUTORIDADE NT.
Fig. 34: Verificação da AUTORIDADE NT
E depois, fora do procedimento, ele verifica se não é csrss.exe, explorer.exe ou lsaas.exe.
Fig. 35: Verificação da AUTORIDADE NT
Após fazer um snapshot dos processos, ele abriu os processos e verificou se nenhum deles era uma exceção, ele está pronto para gravar na memória os processos que serão injetados.
Para isso, ele primeiro reserva uma área na memória (VirtualAllocEx), grava nela (WriteProcessmemory) e cria uma thread (CreateRemoteThread). Para trabalhar com essas funções, ele usa os PIDs dos processos selecionados, que ele obteve anteriormente usando CreateToolhelp32Snapshot.
Fig. 36: Código para injeção
Aqui podemos observar dinamicamente como ele usa o PID do processo para chamar a função VirtualAllocEx.
Fig. 37: Chamada de VirtualAllocEx
5.4 Criptografia
Nesta seção, examinaremos parte deste exemplo relacionada à criptografia. Na próxima figura, você pode ver duas subprogramas chamadas "LoadLibrary_EncodeString" e "Encode_Func", que são responsáveis pela execução do procedimento de criptografia.
Fig. 38: Procedimentos de criptografia
No começo, podemos ver como ele carrega uma string que será usada posteriormente para desofuscar tudo o que é necessário: imports, DLLs, comandos, arquivos e CSP.
Fig. 39: Cadeia de desofuscação
Na figura seguinte, vemos o primeiro import que ele desofusca no registro R4, LoadLibrary. Isso será usado mais tarde para carregar as DLLs necessárias. Também podemos ver outra string no registro R12, que é usada junto com a string anterior para executar a desofuscação.
Fig. 40: Desofuscação dinâmica
Ele continua carregando comandos que ele executará mais tarde para desativar backups, pontos de restauração e modos de início seguro.
Fig. 41: Carregamento de comandos
Em seguida, ele carrega o local onde lançará 3 arquivos: Windows.bat, run.sct e start.bat.
Fig. 42: Locais dos arquivos
Esses 3 arquivos são usados para verificar as permissões que cada um dos locais possui. Se as permissões necessárias não estiverem disponíveis, Ryuk interrompe a execução.
Ele continua carregando strings correspondentes aos três arquivos. O primeiro, DECRYPT_INFORMATION.html, contém informações necessárias para a recuperação dos arquivos. O segundo, PUBLIC, contém a chave pública RSA.
Fig. 43: String DECRYPT INFORMATION.html
Terceira, UNIQUE_ID_DO_NOT_REMOVE, contém uma chave criptografada que será utilizada no próximo subprocesso para executar a criptografia.
Fig. 44: Linha UNIQUE ID DO NOT REMOVE
Finalmente, ele carrega as bibliotecas necessárias juntamente com as importações e CSP (Microsoft Enhanced RSA e AES Cryptographic Provider).
Fig. 45: Carregando bibliotecas
Após a conclusão da desofuscação, ele prossegue para a execução das ações necessárias para a criptografia: percorrendo todos os discos lógicos, executando o que foi carregado no subprocesso anterior, reforçando a presença no sistema, soltando o arquivo RyukReadMe.html, criptografando, percorrendo todas as unidades de rede, acessando os dispositivos descobertos e criptografando-os.
Tudo começa com o carregamento de "cmd.exe" e gravação da chave RSA pública.
Fig. 46: Preparação para a criptografia
Em seguida, ele obtém todos os discos lógicos usando GetLogicalDrives e desativa todos os backups, pontos de restauração e modos seguros de inicialização.
Fig. 47: Desativação de ferramentas de recuperação
Após isso, ele reforça sua presença no sistema, como vimos acima, e grava o primeiro arquivo RyukReadMe.html em TEMP.
Fig. 48: Publicação do aviso de resgate
Na próxima figura você pode ver como ele cria o arquivo, carrega o conteúdo e grava-o:
Fig. 49: Carregando e gravando o conteúdo do arquivo
Para poder executar essas mesmas ações em todos os dispositivos, ele utiliza
"icacls.exe", como mostramos acima.
Fig. 50: Uso de icacls.exe
E, finalmente, ele começa a criptografar arquivos, exceto arquivos "*.exe", "*.dll", arquivos do sistema e outras localizações especificadas em uma lista branca criptografada. Para isso, ele utiliza as importações: CryptAcquireContextW (onde é indicado o uso de AES e RSA), CryptDeriveKey, CryptGenKey, CryptDestroyKey etc. Também é feita uma tentativa de expandir sua ação para dispositivos de rede descobertos usando WNetEnumResourceW e, em seguida, criptografá-los.
Fig. 51: Criptografia de arquivos do sistema
6. Importações e respectivos flags
Abaixo está uma tabela com a lista das importações e flags mais relevantes utilizadas pelo amostra:
7. IOC
Links
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgramsStartupstart.bat
O relatório técnico sobre o ransomware Ryuk foi elaborado por especialistas do laboratório antivírus PandaLabs.
8. Referências
1. "Everis e Prisa Radio sofrem um grave ciberataque que sequestra seus sistemas." https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Publicada em 04/11/2019.
2. "Um vírus de origem russa ataca importantes empresas espanholas." https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Publicada em 04/11/2019.
3. "Artigo VB2019: A vingança de Shinigami: a longa cauda do malware Ryuk." https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Publicada em 11/12/2019.
4. "Big Game Hunting com Ryuk: Outro ransomware direcionado lucrativo." https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Publicada em 10/01/2019.
5. "Artigo VB2019: A vingança de Shinigami: a longa cauda do malware Ryuk." https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Fonte: habr.com
