Visão geral
O Remcos é um trojan de acesso remoto (RAT) que foi introduzido pela primeira vez em julho de 2016 pela empresa alemã Breaking Security. Embora inicialmente tenha sido comercializado como uma ferramenta legítima para administração remota de sistemas Windows, ele foi amplamente adotado por criminosos cibernéticos para fins maliciosos. O malware é normalmente distribuído por meio de e-mails de phishing contendo anexos maliciosos, como documentos do Microsoft Office com macros incorporadas ou arquivos ZIP disfarçados de conteúdo legítimo. Após a execução, esses anexos implantam o Remcos no sistema da vítima. Em alguns casos, os atacantes exploram vulnerabilidades conhecidas para facilitar o processo de infecção.
O Remcos oferece aos atacantes amplos recursos, incluindo keylogging, captura de tela, gravação de áudio e vídeo e execução remota de comandos. Ele também pode coletar informações do sistema, roubar credenciais e fazer download de cargas úteis mal-intencionadas adicionais. A arquitetura modular do malware permite a adição de novas funcionalidades, tornando-o adaptável a várias campanhas maliciosas.
Amostras recentes do Remcos (versão 6.1.1 pro) foram observadas se espalhando por meio de e-mails de spam que trazem um arquivo 7Z malicioso como anexo. Esse arquivo contém um arquivo em lote altamente ofuscado, projetado para evitar a detecção. Dentro do arquivo em lote há dois fluxos de dados criptografados e compactados – especificamente, criptografados por AES e compactados por GZIP – que são descriptografados e descompactados durante a execução. Esse processo resulta, por fim, na implantação da carga útil do Remcos na máquina da vítima.
Detalhes técnicos
O arquivo em lote malicioso é altamente ofuscado e contém código PowerShell codificado em Base64 incorporado. Para evitar a detecção, os atacantes inseriram códigos indesejados em todo o script. Por exemplo, na primeira linha, a substituição da string “ywg” revela um comando echo, indicando a presença de funcionalidade oculta.
Figura 1 – Arquivo em lote ofuscado
Após a execução, o arquivo em lote executa um script do PowerShell incorporado que verifica a presença do arquivo “dwm.bat” no diretório de perfil do usuário. Se o arquivo existir, ele lê seu conteúdo linha por linha, procura uma linha que contenha o marcador ::: e extrai o conteúdo que o segue. Esse conteúdo é um código do PowerShell codificado em Base64, que é decodificado e executado. Se o arquivo “dwn.bat” não estiver presente, o script simplesmente será encerrado.
Figura 2 – Script do PowerShell incorporado
Ignorando AMSI e ETW
O script do PowerShell decodificado define uma função chamada Invoke-SysRoutine, que implementa uma técnica para contornar a AMSI (Antimalware Scan Interface) e o ETW (Event Tracing for Windows). Ele consegue isso resolvendo dinamicamente os endereços de API do sistema em tempo de execução e modificando a memória das funções de destino usando a interoperabilidade do .NET e as chamadas de API nativas do Windows, desativando assim a telemetria de segurança e evitando a detecção.
Ele resolve dinamicamente funções críticas do sistema, como GetProcAddress e GetModuleHandle, decodificando seus nomes em tempo de execução, o que dificulta a análise estática. O script cria delegados personalizados para chamar códigos não gerenciados e modifica a proteção da memória usando o VirtualProtect para corrigir a função AmsiInitialize do AMSI.
Figura 3 – Bypass AMSI
Além disso, ele verifica e corrige vários provedores AMSI na memória para garantir a desativação completa. Se o sinalizador -DisableSvc for usado, ele também terá como alvo a função EtwEventWrite em ntdll.dll, suprimindo efetivamente o registro de eventos de segurança. As proteções de memória são restauradas após a aplicação de patches para manter a estabilidade do sistema.
Figura 4 Patching ETW
Descriptografia e descompressão
Depois de contornar com êxito o AMSI e o ETW, o script do PowerShell incorporado no arquivo em lote localiza o marcador ::, extrai o conteúdo que o segue e divide esses dados usando a barra invertida (\) como delimitador. Os valores codificados em base64 resultantes são armazenados em uma matriz para processamento posterior.
Figura 5: Script do PowerShell lendo elementos criptografados
Os elementos extraídos da matriz são então passados para uma função de descriptografia que usa o AES no modo CBC (Cipher Block Chaining). Essa função descriptografa o conteúdo usando uma chave codificada e um vetor de inicialização (IV), conforme demonstrado no trecho de código a seguir. A saída descriptografada é posteriormente passada para outra função que lida com a descompressão GZIP.
Figura 6 – Decodificação AES
Depois que os dois elementos da matriz são descompactados, o script extrai dois arquivos executáveis. O primeiro executável contém uma função main() vazia, sem nenhuma finalidade ativa, enquanto o segundo é responsável por carregar a carga útil do Remcos.
Figura 7 – Descriptografia AES e descompressão GZIP usando o CyberChef
Em seguida, o script passa os executáveis extraídos para uma função que usa o carregamento de reflexão para executar o binário mal-intencionado diretamente da memória dentro do processo do PowerShell, sem armazenar os binários no disco. Essa técnica permite a execução na memória da carga útil, o que torna a detecção e a análise mais desafiadoras.
Figura 8 – Carga de reflexão
O executável extraído do primeiro elemento do array contém uma função principal vazia, o que indica que o invasor pode estar usando-o como um chamariz ou uma tática de evasão para evitar a detecção.
Carregador Remcos
O executável extraído do segundo elemento da matriz atua como um carregador que carrega a carga útil da Remcos no computador da vítima. Após a execução, o carregador carrega o arquivo “ntdll.dll”, recupera o endereço da função “EtwEventWrite” e altera a proteção de memória dessa função para PAGE_EXECUTE_READWRITE.
Em sistemas de 32 bits, ele adiciona instruções (0xC2 0x14) que fazem a função retornar imediatamente, desativando efetivamente o registro em log do ETW. Em sistemas de 64 bits, o script substitui o início da função EtwEventWrite pela instrução 0xC3, que faz com que a função retorne imediatamente sem fazer nada. Essa alteração desativa o registro de eventos. Uma vez modificado, o script restaura a proteção de memória original para evitar outras alterações, transformando efetivamente o EtwEventWrite em um no-op e ajudando o malware a evitar a detecção por ferramentas de segurança.
Figura 9 – Patching do ETWEventWrite
No estágio final, o carregador procura nos recursos incorporados do assembly uma entrada específica chamada “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.exe”. Se o recurso estiver presente, ele extrai seu conteúdo usando GetManifestResourceStream().
Os dados extraídos são compactados em GZIP e criptografados em AES. Eles são descriptografados usando uma chave predefinida e um vetor de inicialização. Depois de descriptografado, o payload, identificado como Remcos, é executado, permitindo que o invasor controle remotamente o sistema comprometido.
Detalhes da conexão de rede e C&C
Após a execução bem-sucedida, o Remcos RAT envia uma solicitação GET para geoplugin.net/json.gp para recuperar a geolocalização da vítima com base em seu endereço IP público. Essa resposta da API inclui detalhes como país, cidade, região, latitude, longitude, fuso horário etc. Os dados coletados ajudam os atacantes a traçar o perfil das vítimas e adaptar suas operações com base na localização geográfica.
Figura 10 – Coleta de detalhes de geolocalização
Antes de obter controle total sobre a máquina da vítima, o Remcos RAT primeiro coleta informações do sistema e as envia ao servidor de Comando e Controle (C&C) para registrar o dispositivo infectado. Ele inicia uma conexão segura com o servidor C&C usando TLS para facilitar a comunicação criptografada. Cada pacote contém uma sequência de bytes de identificador exclusivo, seguida pelo tamanho dos dados que estão sendo transferidos e um ID de comando que especifica a operação pretendida, conforme mostrado abaixo.
Figura 11 – Pacote inicial para registrar o dispositivo das vítimas
O Remcos utiliza o Command ID 0x4B para exfiltrar informações detalhadas do sistema e do usuário da máquina da vítima para o servidor de Comando e Controle (C2) do atacante. Esses dados são usados para registrar o dispositivo comprometido e estabelecer controle sobre o host infectado. Normalmente, as seguintes informações são coletadas durante esse processo:
- Nome do dispositivo e nome do usuário
- Localização do dispositivo da vítima
- Informações sobre o sistema operacional
- Status da memória
- Versão Remcos
- Caminho do arquivo local do Remcos Keylogger
- Caminho completo da Remcos
- Título do programa ativo
- Nível de privilégio do usuário
- Tempo de atividade do sistema
- Tempo ocioso
- Nome atribuído à Remcos
- IP do servidor C&C
- Tipo de arquivo Remcos
- Informações do processador
Após o registro inicial, o servidor de Comando e Controle (C2) envia um comando com ID 0x01 para o cliente Remcos. Esse comando funciona como um heartbeat ou sinalizador de informações, solicitando que a máquina infectada envie atualizações periódicas de status para o invasor.
Figura 12 – Pacote de beacon
Em resposta, o Remcos envia informações que incluem a telemetria do sistema em tempo de execução, como o título da janela ativa, o tempo de atividade do sistema etc., juntamente com o comando 0x4C. Isso permite que o invasor monitore a atividade da máquina infectada em tempo real e mantenha um controle persistente sobre o dispositivo.
Figura 13 – Resposta à solicitação de beacon
Depois disso, o servidor C&C emite uma solicitação para a máquina infectada usando a ID de comando 0x11 para recuperar as informações de geolocalização que foram coletadas durante o estágio inicial da infecção. Em resposta, o Remcos envia de volta os detalhes de geolocalização usando o mesmo ID de comando 0x11, conforme mostrado abaixo.
Figura 14 – Detalhes de geolocalização da exfiltração
Também foi observado que a ID de comando 0x44 é usada sempre que um arquivo está sendo baixado do servidor C&C. Especificamente, quando um arquivo com um cabeçalho MZ é recuperado, a comunicação inclui o comando 0x44 seguido pelo conteúdo do arquivo, conforme mostrado abaixo.
Figura 15 – Download de carga útil adicional (Fonte: malware-traffic-analysis.net))
Como o Unified SASE as a Service ajuda a reduzir as infecções por Remcos?
Uma estrutura SASE unificada integra segurança de rede e controles de acesso de confiança zero para defender-se contra ameaças como o Remcos RAT, que usa canais de comando e controle (C2) para exfiltração de dados e operações remotas. O SASE oferece visibilidade centralizada do tráfego de rede e aplica políticas de segurança consistentes em todos os locais. Nossos recursos de segurança incorporados, como IDPS avançado, SWG e inteligência contra ameaças em tempo real, podem detectar indicadores de atividade da Remcos, inclusive IDs de comando específicos e padrões HTTP suspeitos. Ao inspecionar as comunicações HTTP de saída, o SASE pode identificar tentativas de exfiltração de dados de geolocalização ou de fornecimento de comandos remotos, bloqueando automaticamente transmissões não autorizadas e minimizando o risco de comprometimento.
Mapeamento MITRE ATT&CK: TTPs
- T1566.001 – Phishing: anexo de spearphishing
- T1059.001 – Interpretador de comandos e scripts: PowerShell
- T1204.002 – Execução pelo usuário: Arquivo malicioso
- T1027 – Arquivos ou informações ofuscados
- T1055.002 – Injeção de processo: Injeção de executável portátil
- T1562.001 – Prejudicar as defesas: Desativar ou modificar ferramentas
- T1003 – Dumping de credenciais do sistema operacional
- T1082 – Descoberta de informações do sistema
- T1016 – Descoberta da configuração da rede do sistema
- T1071.001 – Protocolo da camada de aplicativos: Protocolos da Web
- T1056.001 – Captura de entrada: Registro de teclas
- T1113 – Captura de tela
- T1123 – Captura de áudio
- T1125 – Captura de vídeo
- T1041 – Exfiltração pelo canal C2
- T1020 – Exfiltração automatizada
Referência
https://www.fortinet.com/blog/threat-research/new-campaign-uses-remcos-rat-to-exploit-victims