Conheça o malware PyXie: um novo RAT nefasto escrito em Python

Introdução
Pesquisadores da BlackBerry Cylance descobriram recentemente um RAT (Remote Administrator Tool) em Python, que foi batizado de PyXie. As amostras mais antigas do PyXie mostram o malware no ambiente virtual desde pelo menos 2018, sem chamar muita atenção da indústria de segurança cibernética.
O PyXie faz parte de uma campanha em andamento que tem como alvo uma ampla variedade de indústrias. Foi visto em conjunto com os sinalizadores do Cobalt Strike e com um downloader que tem semelhanças com o Trojan bancário Shifu. Os analistas da BlackBerry Cylance também observaram evidências de tentativas de ataque de ransomware com o PyXie nos setores de saúde e educação.
A BlackBerry Cylance conduziu vários episódios de resposta a incidentes (IR) nos quais o PyXie foi identificado nos hosts do ambiente da vítima.
Os principais destaques da campanha do PyXie incluem:
· binários legítimos do LogMeIn e do Google usados para descarregar payloads;
· um aplicativo Tetris “trojanizado” para carregar e executar os suportes do Cobalt Strike a partir de compartilhamentos internos de rede;
· uso de um downloader que tem semelhanças com o Shifu, chamado “Cobalt Mode”;
· uso do Sharphound para coletar informações do diretório ativo das vítimas;
· um interpretador Python compilado e personalizado que usa opcodes codificados para dificultar a análise;
· uso de um algoritmo RC4 modificado para criptografar payloads com uma chave exclusiva para cada host infectado.
Análise geral do ataque
Primeira etapa — carregamento
A campanha usa uma técnica de carregamento lateral utilizando aplicativos legítimos para carregar os componentes do primeiro estágio do malware. Observamos duas variantes diferentes de carregadores mal-intencionados visando aplicativos populares que podem ser encontrados na maioria dos computadores:
· LMIGuardianDll.dll — carregado lateralmente por um binário assinado (LmiGuardianSvc.exe) do LogMeIn;
· Goopdate.dll — carregado lateralmente por um binário assinado (GoogleUpdate.exe) do Google.
Depois de carregada pelo binário LogMeIn ou Google, a DLL maliciosa localizará sua carga criptografada correspondente. Ela faz isso pegando o caminho completo no qual foi carregada e anexando uma extensão .dat a ele. Por exemplo, se a DLL mal-intencionada se chamar LmiGuardianDLL.dll, o nome do arquivo do payload será LmiGuardianDLL.dll.dat.
A carga criptografada é lida no disco e, em seguida, o AES-128 é descriptografado no modo CBC pelo carregador. O vetor de inicialização de 16 bytes (IV) e a chave simétrica são codificados na DLL e podem variar de amostra para amostra. O resultado da descriptografia é o payload da segunda fase, que é mapeado no espaço de endereço do processo do carregador e executado.
Segunda etapa — instalação e persistência
O malware do segundo estágio é o principal responsável por se instalar, configurar a persistência e gerar um novo processo para injetar o payload do terceiro estágio. O componente da segunda etapa coloca suas impressões digitais na máquina vítima, gerando um hash de identificação de hardware. Esse hash é usado posteriormente como uma semente para várias funções, bem como uma chave de criptografia nos estágios subsequentes.
Identificação do hardware
O ID do hardware é gerado calculando o hash MD5 de um buffer de 80 bytes contendo informações coletadas do sistema, incluindo:
· uma cadeia de processo de marca de 64 bytes obtida por meio de uma sequência de chamadas para a instrução CPUID (com EAX definido nos valores 0x80000002, 0x80000003 e 0x80000004);
· valores de saída de dwNumberOfProcessors e dwProcessorType retornados por uma chamada para GetSystemInfo;
· o número de série do volume da unidade lógica do sistema operacional obtido por meio de uma chamada para GetVolumeInformationA;
· o hash CRC32 do usuário atual obtido por meio de uma chamada para GetUserNameA usando a implementação ZLIB-CRC32 com uma semente de -1 (0xFFFFFFFF).
Mutexes
Dois mutexes são criados para impedir que várias instâncias de payload sejam executados ao mesmo tempo.
O primeiro nome do mutex é gerado usando um algoritmo com esta sequência:
1. O processo infectado com o payload do segundo estágio é obtido chamando a API GetModuleFileNameA.
2. O CRC32 do binário correspondente é calculado.
3. O hash calculado é XORed com o CRC32 do usuário conectado no momento.
4. A representação da cadeia hexadecimal do último hash representa o nome do mutex.
O segundo mutex são os últimos 28 caracteres da representação hexadecimal do hash de ID de hardware MD5:
Escalonamento de privilégios
Se o processo infectado com o payload do segundo estágio estiver em execução com privilégios de administrador, o malware tentará aumentar seus próprios privilégios. Isso é feito criando e iniciando um serviço temporário, que reaparece e é executado como um processo LOCAL SYSTEM. Para permanecer furtivo, o malware exclui o serviço temporário do Service Control Manager.
Instalação
O carregador e seu payload correspondente são copiados para um subdiretório na pasta %APPDATA%. O diretório é escolhido de uma lista de cadeias. A seleção é feita usando o número CRC32 do resultado do módulo 21 (0x15) da cadeia de ID do Hardware.
Persistência
A persistência é obtida com a criação de um valor de registro cujo nome é a representação da sequência hexadecimal de um DWORD gerado dinamicamente na chave do registro HKCU\Software\Microsoft\Windows\VersãoAtual\Executar. O valor do registro está definido para apontar para o caminho do executável do carregador.
Injeção do payload da próxima etapa
O payload do terceiro estágio é descompactado com uma chamada para a API RtlDecompressBuffer e posteriormente injetada em um processo recém-gerado.
O executável direcionado para injeção é escolhido enumerando os executáveis no diretório %SYSTEMROOT%\System32 e pesquisando o primeiro que atenda aos seguintes critérios:
· não está funcionando;
· possui um subsistema GUI;
· possui “Microsoft” nas informações da versão;
· está assinado.
O novo processo é gerado usando a API CreateProcessA, que transmite o caminho para o executável que carregou a segunda etapa com o parâmetro lpCommandLine.
Terceira etapa — downloader “Cobalt Mode”
A terceira etapa é um downloader que foi designado Cobalt Mode com base nas informações de depuração deixadas em algumas das amostras analisadas. Um exemplo do caminho do PDB é mostrado abaixo:
Z:\coding\pyproject\compiled\cobalt_mode\cobalt_mode.pdb
As principais funções do Cobalt Mode incluem:
· conectar-se a um Servidor de Comando e Controle (C&C);
· fazer o download de um payload criptografado;
· descriptografar o payload;
· mapear e executar o payload no espaço de endereço do processo atual;
· gerar um novo processo para injeção de código.
O malware em Cobalt Mode pode realizar uma série de verificações do ambiente. Ele pode determinar se está sendo executado a partir de uma sandbox ou máquina virtual (VM), se um leitor de cartão inteligente está conectado e se as solicitações estão sendo interceptadas com um ataque do homem no meio (man-in-the-middle, ou MitM). Examinar as funções e os valores usados para fazer essas verificações revelou que o código se sobrepõe ao Trojan bancário Shifu.
A configuração do Cobalt Mode é armazenada no malware como um blob JSON compactado. Uma solicitação para o download_url especificado na configuração JSON é feita para recuperar o payload do próximo estágio. O mesmo ID de hardware discutido na análise do segundo estágio é passado na solicitação como o parâmetro hw. O servidor usa esse valor como chave para criptografar um arquivo 7zip, que ele retorna com um algoritmo RC4 modificado. O arquivo contém um interpretador Python personalizado e um arquivo zip contendo o bytecode do PyXie RAT.
Algoritmo RC4 modificado
O algoritmo RC4 modificado usado pelo malware difere do RC4 comum na maneira como gera sua Caixa de Substituição (S-BOX). Depois que a S-BOX é inicializada, a chave é XORada em relação ao S-BOX, em vez de usá-la para trocar valores.
Injeção
O mesmo algoritmo do estágio anterior é usado para selecionar um executável no diretório %SYSTEMROOT%\system32 e gerar um novo processo de injeção. Desta vez, %SYSTEMROOT%\system32\worker.exe é usado como o parâmetro lpCommandLine para a chamada à API CreateProcessA.
PyXie RAT
O payload do estágio final é um RAT em Python completo, compilado em um executável. Em vez de usar o Py2Exe ou o PyInstaller para criar um executável, os autores do malware compilaram seu próprio interpretador Python que carrega um arquivo contendo o bytecode do RAT PyXie da memória.
As funcionalidades do RAT PyXie incluem:
· interceptação do homem no meio (MITM);
· injeção na Web;
· keylogging;
· coleta de credenciais;
· digitalização em rede;
· roubo de cookies;
· limpeza dos logs;
· gravação de vídeos;
· execução de cargas arbitrárias;
· monitoramento de drives USB e exfiltração de dados
· conexão com o servidor WebDav;
· criação de proxy Socks5;
· conexão de rede virtual (VNC);
· roubo de certificado;
· software de inventário;
· enumeração o domínio com Sharphound.
O intérprete personalizado é fornecido com uma biblioteca obscura denominada memzipimport, que importa um arquivo zip contendo o bytecode RAT compilado diretamente da memória. O zip contém mais de 1.500 arquivos de bytecode em Python, muitos dos quais são bibliotecas de terceiros. O RAT principal consiste em aproximadamente 79 arquivos de bytecode.
A análise completa do RAT PyXie pode ser lida (em inglês) no blog Threat Vector, da BlackBerry Cylance.