Cyril FrançoisSamir Bousseaden

Desvendando o REMCOS RAT: Uma análise aprofundada de um malware 2024 disseminado, Parte Um

Parte um: Introdução ao REMCOS e análise do seu procedimento de inicialização

10 min de leituraAnálise de malware
Dissecando o REMCOS RAT: Uma análise aprofundada de um malware 2024 generalizado, Parte Um

No primeiro artigo desta série em várias partes, os pesquisadores de malware da equipe do Elastic Security Labs apresentam uma breve introdução à ameaça REMCOS e exploram a primeira metade de seu fluxo de execução, desde o carregamento de sua configuração até a limpeza dos navegadores da web da máquina infectada.

Introdução

O Elastic Security Labs continua sua análise de ameaças de alto impacto, concentrando-se nas complexidades internas da versão 4.9.3 do REMCOS. Pro (novembro 26, 2023).

Desenvolvido pela Breaking-Security, o REMCOS é um software que começou como uma ferramenta de teste de intrusão (red teaming), mas desde então foi adotado por ameaças de todos os tipos, visando praticamente todos os setores.

Quando realizamos nossa análise em meados de janeiro, essa era a família de malware mais prevalente relatada pelo ANY.RUN. Além disso, permanece em desenvolvimento ativo, como evidenciado pelo recente anúncio do lançamento da versão 4.9.4 pela empresa em março 9, 2024.

Todas as amostras que analisamos foram derivadas do mesmo REMCOS 4.9.3. Configuração profissional x86. O software é codificado em C++ com uso intensivo da classe std::string para suas operações relacionadas a strings e bytes.

O REMCOS possui uma ampla gama de funcionalidades, incluindo técnicas de evasão, escalonamento de privilégios, injeção de processos, recursos de gravação, etc.

Esta série de artigos oferece uma análise abrangente dos seguintes tópicos:

  • Execução e capacidades
  • Estratégias de detecção e busca usando consultas ES|QL da Elastic
  • Recuperação de aproximadamente 80% dos seus campos de configuração.
  • Recuperação de cerca de 90% dos seus comandos de C2.
  • Exemplos de endereços virtuais abaixo de cada captura de tela do IDA Pro
  • E muito mais!

Para quaisquer dúvidas ou comentários, entre em contato conosco nas redes sociais @elasticseclabs ou no Slack da Comunidade Elastic.

Carregando a configuração

A configuração REMCOS é armazenada em um blob criptografado dentro de um recurso chamado SETTINGS. Esse nome aparece de forma consistente em diferentes versões do REMCOS.

O malware começa carregando o bloco de configuração criptografado de sua seção de recursos.

Para carregar a configuração criptografada, utilizamos o seguinte script Python e o módulo Lief .

import lief

def read_encrypted_configuration(path: pathlib.Path) -> bytes | None:
	if not (pe := lief.parse(path)):
    		return None

	for first_level_child in pe.resources.childs:
    		if first_level_child.id != 10:
        		continue

    	for second_level_child in first_level_child.childs:
        		if second_level_child.name == "SETTINGS":
            			return bytes(second_level_child.childs[0].content)

Podemos confirmar que a versão 4.9.3 mantém a mesma estrutura e esquema de descriptografia descritos anteriormente pelos pesquisadores da Fortinet:

Denominamos “configuração criptografada” a estrutura que contém a chave de descriptografia e o bloco de dados criptografados, que se apresenta da seguinte forma:

struct ctf::EncryptedConfiguration
{
uint8_t key_size;
uint8_t key[key_size];
uint8_t data
};

A configuração ainda é descriptografada usando o algoritmo RC4, como pode ser visto na captura de tela a seguir.

Para descriptografar a configuração, utilizamos o seguinte algoritmo.

def decrypt_encrypted_configuration(
	encrypted_configuration: bytes,
) -> tuple[bytes, bytes]:
	key_size = int.from_bytes(encrypted_configuration[:1], "little")
	key = encrypted_configuration[1 : 1 + key_size]
	return key, ARC4.ARC4Cipher(key).decrypt(encrypted_configuration[key_size + 1 :])

A configuração é usada para inicializar um vetor global que chamamos de g_configuration_vector dividindo-o com a string \x7c\x1f\x1e\x1e\x7c como delimitador.

Forneceremos uma explicação detalhada da configuração mais adiante nesta série.

Desvio do UAC

Quando o enable_uac_bypass_flag (índice 0x2e) está habilitado na configuração, o REMCOS tenta um bypass do UAC usando uma técnica conhecida baseada em COM.

Antes disso, o REMCOS mascara seu processo em um esforço para evitar ser detectado.

O REMCOS modifica a estrutura PEB do processo atual, substituindo o caminho da imagem e a linha de comando pela string explorer.exe , enquanto salva as informações originais em variáveis globais para uso posterior.

A técnica bem conhecida explora a API CoGetObject para passar o moniker Elevation:Administrator!new: , juntamente com o CMSTPLUA CLSID e ICMLuaUtil IID, para instanciar uma interface COM elevada. O REMCOS então usa o método ShellExec() da interface para iniciar um novo processo com privilégios de administrador e sair.

Essa técnica foi previamente documentada em um artigo da Elastic Security Labs de 2023: Explorando as formas de burlar o UAC do Windows: técnicas e estratégias de detecção.

Abaixo, segue uma captura de tela recente da detecção dessa vulnerabilidade usando o agente Elastic Defend.

Desativar o UAC

Quando o disable_uac_flag está habilitado na configuração (índice 0x27), o REMCOS desabilita o UAC no registro definindo o valor HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\SystemEnableLUA para 0 usando o binário do Windows reg.exe .

Instalação e persistência

Quando enable_install_flag (índice 0x3) é ativado na configuração, o REMCOS se instalará na máquina host.

O caminho de instalação é construído utilizando os seguintes valores de configuração:

  • install_parent_directory (índice 0x9)
  • install_directory (0x30)
  • install_filename (0xA)

O binário do malware é copiado para {install_parent_directory}/{install_directory}/{install_filename}. Neste exemplo, é %ProgramData%\Remcos\remcos.exe.

Se o enable_persistence_directory_and_binary_hiding_flag (índice 0xC) estiver habilitado na configuração, a pasta de instalação e o binário do malware serão definidos como super ocultos (mesmo que o usuário habilite a exibição de arquivos ou pastas ocultos, o arquivo é mantido oculto pelo Windows para proteger arquivos com atributos de sistema) e somente leitura, aplicando a eles atributos de somente leitura, oculto e de sistema.

Após a instalação, o REMCOS estabelece a persistência no registro dependendo de quais das seguintes opções estão habilitadas na configuração:

  • enable_hkcu_run_persistence_flag (índice 0x4) HKCU\Software\Microsoft\Windows\CurrentVersion\Run\
  • enable_hklm_run_persistence_flag (índice 0x5) HKLM\Software\Microsoft\Windows\CurrentVersion\Run\
  • enable_hklm_policies_explorer_run_flag (índice 0x8) HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run\

O malware é então reiniciado a partir da pasta de instalação usando ShellExecuteW, seguido pelo encerramento do processo inicial.

Injeção de processo

Quando o enable_process_injection_flag (índice 0xD) está habilitado na configuração, o REMCOS se injeta em um processo especificado ou em um processo do Windows escolhido de uma lista codificada para evitar a detecção.

O enable_process_injection_flag pode ser um valor booleano ou o nome de um processo alvo. Quando definido como verdadeiro (1), o processo injetado é escolhido da melhor maneira possível dentre as seguintes opções:

  • iexplorer.exe
  • ieinstal.exe
  • ielowutil.exe

Nota: existe apenas um método de injeção disponível no REMCOS; quando falamos de injeção de processo, estamos nos referindo especificamente ao método descrito aqui.

REMCOS usa uma técnica clássica ZwMapViewOfSection + SetThreadContext + ResumeThread para injeção de processo. Isso envolve copiar-se para o binário injetado através da memória compartilhada, mapeada usando ZwMapViewOfSection e então sequestrar seu fluxo de execução para o ponto de entrada REMCOS usando os métodos SetThreadContext e ResumeThread .

Começa por criar o processo alvo em modo suspenso usando a API CreateProcessW e recuperar o seu contexto de thread usando a API GetThreadContext .

Em seguida, cria uma memória compartilhada usando a API ZwCreateSection e a mapeia no processo de destino usando a API ZwMapViewOfSection , juntamente com o identificador do processo remoto.

Em seguida, o arquivo binário é carregado no processo remoto copiando seu cabeçalho e seções para a memória compartilhada.

Se necessário, serão providenciadas realocações. Então, o PEB ImageBaseAddress é corrigido usando a API WriteProcessMemory . Em seguida, o contexto da thread é configurado com um novo ponto de entrada apontando para o ponto de entrada do REMCOS, e a execução do processo é retomada.

A seguir, apresentamos a detecção dessa técnica de injeção de processo realizada pelo nosso agente:

Configurando o modo de registro de logs

O REMCOS possui três valores de modo de registro que podem ser selecionados com o campo logging_mode (índice 0x28) da configuração:

  • 0: Nenhum registro
  • 1: Iniciar minimizado no ícone da bandeja do sistema
  • 2: Registro no console

Definir este campo como 2 habilita o console, mesmo quando a injeção de processo está habilitada, e expõe informações adicionais.

Limpando navegadores

Quando o enable_browser_cleaning_on_startup_flag (índice 0x2B) estiver ativado, o REMCOS excluirá os cookies e as informações de login dos navegadores da web instalados no host.

De acordo com a documentação oficial, o objetivo dessa funcionalidade é aumentar a segurança do sistema contra roubo de senhas:

Atualmente, os navegadores compatíveis são o Internet Explorer, o Firefox e o Chrome.

O processo de limpeza envolve a exclusão de cookies e arquivos de login dos diretórios conhecidos dos navegadores usando as APIs FindFirstFileA, FindNextFileA e DeleteFileA :

Quando a tarefa é concluída, o REMCOS imprime uma mensagem no console.

Vale a pena mencionar dois campos relacionados na configuração:

  • enable_browser_cleaning_only_for_the_first_run_flag (índice 0x2C)
  • browser_cleaning_sleep_time_in_minutes (índice 0x2D)

O valor de configuração browser_cleaning_sleep_time_in_minutes determina quanto tempo o REMCOS ficará inativo antes de executar a tarefa.

Quando enable_browser_cleaning_only_for_the_first_run_flag estiver ativado, a limpeza ocorrerá apenas na primeira execução do REMCOS. Em seguida, o valor de registro HKCU/SOFTWARE/{mutex}/FR é definido.

Em execuções subsequentes, a função retorna diretamente se o valor existe e está definido no registro.

Este é o fim do primeiro artigo. A segunda parte abordará a segunda metade do fluxo de execução do REMCOS, desde seu sistema de monitoramento até a primeira comunicação com seu C2.

Compartilhe este artigo