perfctl: Malware Furtivo Direcionado a Milhões de Servidores Linux

Malware indescritível domina fóruns de desenvolvedores

Nossa história começa com um ataque que monitoramos em um de nossos honeypots. Normalmente, verificamos se alguém já documentou o ataque, pois isso nos permite analisá-lo mais detalhadamente e comparar nossas descobertas com as de outros pesquisadores. No entanto, neste caso, não encontramos nenhum relatório sobre o malware que tinha como alvo nosso honeypot.
O que fizemos, porém, foram inúmeras referências a um malware, isso imediatamente chamou nossa atenção, pois esse era um dos nomes do nosso malware. Estes são emvários idiomas em várias comunidades de desenvolvedores e fóruns, revisamoscuidadosamente essas postagens e descobrimos que os indicadoresde comprometimento mencionados nelas são os mesmos que vimos em nosso ataque. Normalmente, em algumas dessas postagens, você pode encontrar respostas com links para relatórios sobre o malware escritos por pesquisadores. Mas, neste caso, no entanto, nenhum deles tinha ligações com esses relatórios. Aqui estão algumas das postagens que encontramos: Reddit, freelancer, Stack Overflow (espanhol), forobeta (espanhol), brainycp (russo), natnetwork (indonésio), Proxmox (alemão), Camel2243 (chinês), svrforum (coreano), exabytes, virtualmin, serverfault e muitos outros.perfctl
O nome perfctl vem do processo de criptomineração que drena os recursos do sistema, causando problemas significativos para muitos desenvolvedores Linux. Ao combinar “perf” (uma ferramenta de monitoramento de desempenho do Linux) com “ctl” (comumente usado para indicar controle em ferramentas de linha de comando), os autores do malware criaram um nome que parece legítimo. Isso torna mais fácil para os usuários ou administradores ignorarem durante as investigações iniciais, pois se mistura com os processos típicos do sistema.
No final de nossa pesquisa, vimos o primeiro relatório coberto pelos pesquisadores da Cado Security, mas eles contam apenas uma parte muito pequena da história do malware perfctl.

O fluxo de ataque

Depois de explorar uma vulnerabilidade (como no nosso caso) ou uma configuração incorreta, a carga principal é baixada de um servidor HTTP controlado pelo invasor.

Em nosso caso, a carga útil principal foi chamada de httpd e demonstrou várias camadas de execução, apresentando um design deliberado para garantir a persistência e evitar a detecção. Uma vez executado, o payload principal copia a si mesmo da memória para um novo local no diretório ‘/tmp’, executa o novo binário a partir daí, encerra o processo original e exclui o binário inicial para cobrir seus rastros.

A carga principal agora é executada a partir do diretório /tmp com um nome diferente. Com base no que vimos, o malware escolheu o nome do processo que o executou originalmente, portanto, parece menos suspeito, se o sistema for examinado.

No nosso caso, o malware foi executado por sh, portanto, o nome do malware foi alterado de httpd para sh. Neste ponto, ele funciona como um dropper e um processo local de comando e controle (C2). O malware contém um exploit para CVE-2021-4043, que está tentando executar para obter privilégios de root no servidor.

O malware continua a se copiar da memória para meia dúzia de outros locais, com nomes que aparecem como arquivos de sistema convencionais. Ele também descarta um rootkit e alguns utilitários populares do Linux que foram modificados para servir como rootkits terrestres do usuário (ou seja, ldd, lsof). Um criptominerador também é descartado e, em algumas execuções, também observamos alguns softwares de proxy-jacking transferidos de um servidor remoto e executados. 

Como parte de sua operação de comando e controle, o malware abre um soquete Unix, cria dois diretórios no diretório /tmp e armazena dados que influenciam sua operação. Esses dados incluem eventos de host, locais das cópias de si mesmo, nomes de processos, logs de comunicação, tokens e informações de log adicionais. Além disso, o malware usa variáveis de ambiente para armazenar dados que afetam ainda mais sua execução e comportamento.

Todos os binários são empacotados, removidos e criptografados, indicando esforços significativos para contornar os mecanismos de defesa e dificultar as tentativas de engenharia reversa. O malware também usa técnicas avançadas de evasão, como suspender sua atividade quando detecta um novo usuário nos arquivos btmp ou utmp e encerrar qualquer malware concorrente para manter o controle sobre o sistema infectado.

Abaixo está o fluxo de ataque completo:

Figura 1: Todo o fluxo de ataque

Como observado anteriormente, vários arquivos são gravados no disco ou modificados, principalmente nos diretórios /tmp,/usr e /root, conforme mostrado no diagrama abaixo.

Figura 2: Arquivos descartados ou gravados no disco

Neste blog e seus apêndices, explicaremos a finalidade desses arquivos e o papel que cada um desempenha no fluxo de ataque.

Destaques do Ataque Perfctl

O binário principal httpd é um ELF empacotado, despojado e ofuscado (MD5: 656e22c65bf7c04d87b5afbe52b8d800). Se você digitar o URL de download no navegador, o número inteiro 1 será impresso na tela. Se você tentar baixar o arquivo .php sem um agente de usuário específico, receberá um arquivo com o número inteiro 1. Essa resposta indica que esse arquivo é completamente inocente. Mas se você usar o agente de usuário correto, ele descartará o malware (tamanho de ~ 9 MB). Esta é uma maneira inteligente de ocultar o malware.
Depois de baixado e executado, o malware se copia da memória usando outro nome de processo em execução e salva o ID do processo em execução em /tmp/.apid.

Figura 3: httpd está copiando a si mesmo da memória

Em seguida, o Httpd para e exclui a si mesmo. Essa técnica é chamada de ‘mascaramento de processo’ ou ‘substituição de processo’ e é feita para evasão e ofuscação de defesa. Isso pode tornar a vida dos pesquisadores de segurança um pouco mais difícil de seguir o fluxo de execução de malware.
O novo binário Httpd agora é salvo no diretório /tmp sob o nome do processo que o executou sh em nosso caso, mas também vimos outros nomes quando usamos outros processos para executá-lo. O binário sh também está copiando a si mesmo da memória para vários locais, pois ele se salva como e também como /root/.config/cron/perfcc, /usr/bin/perfcc e . No anexo 3 – A carga principal abaixo, discutimos em detalhes sobre isso e explicamos nossa hipótese de por que o agente da ameaça escolheu esses nomes. Isso mostra uma ideia em relação à persistência, pois o autor do malware cria muitos locais para os quais o malware é copiado.libpprocps.so/usr/lib/libfsnkdev.so

Persistência

O invasor modifica o script ~/.profile, que configura o ambiente durante o login do usuário. Esse script foi projetado para executar o malware primeiro, seguido pela carga de trabalho legítima que deve ser executada no servidor. Ele verifica se /root/.config/cron/perfcc é um arquivo executável e, em caso afirmativo, executa o malware.
Além disso, o script garante que, em ambientes Bash, o arquivo ~/.bashrc seja executado, aplicando configurações específicas do usuário, como aliases e variáveis de ambiente, provavelmente para manter as operações normais do servidor enquanto o malware é executado. Por fim, o script suprime erros mesg para evitar avisos visíveis durante a execução.
O binário wizlmsh é descartado para /usr/bin (MD5: ba120e9c7f8896d9148ad37f02b0e3cb). É um binário muito pequeno (12kb), que é executado como um serviço em segundo plano. Inicialmente, ele recebe argc e argv e verifica a execução da carga útil principal (httpd) depois de ser gravada em /tmp como sh ou bash ou qualquer outro nome. É responsável pela persistência do malware perfctl.

Figura 4: função principal do wizlmsh

Evasão de Defesa

O rootkit tem várias finalidades. Um dos principais objetivos é conectar várias funções e modificar sua funcionalidade. O rootkit em si é um arquivo de objeto compartilhado (.so) LSB ELF de 64 bits chamado libgcwrap.so (MD5: 835a9a6908409a67e51bce69f80dd58a). O rootkit está usando LD_PRELOAD para se carregar antes de outras bibliotecas. 

Figura 5: O conteúdo LD_Preload revisado

Ele faz várias manipulações interessantes, incluindo o gancho aos símbolos Libpam. Especificamente, para a função pam_authenticate, que é usada pelo PAM para autenticar usuários. Conectar ou substituir essa função pode permitir ações não autorizadas durante o processo de autenticação, como ignorar verificações de senha, registrar credenciais ou modificar o comportamento dos mecanismos de autenticação.

Figura 6: Funções dos ganchos do rootkit

Além disso, o rootkit também foi projetado para conectar símbolos Libpcap, especificamente à função pcap_loop, que é amplamente usada para capturar tráfego de rede. Isso é usado para impedir a gravação do tráfego de malware.
Os agentes de ameaças também estão usando alguns rootkits terrestres do usuário. Eles descartam alguns utilitários legítimos, como ldd. Esses utilitários foram modificados para ocultar elementos de ataque específicos. Portanto, se o crontab manipulado for usado, por exemplo, ele não mostrará cron jobs criados durante o ataque. 
Na primeira etapa, o malware substitui o /etc/profile para que o caminho seja definido em /bin/.local/bin:$PATH. Nesse caminho, o agente da ameaça está ignorando o diretório de onde os utilitários são chamados. Vimos em alguns malwares executar 2 binários e em outros 4 binários, dependendo de quais utilitários existem originalmente no servidor. 
Em nossos ataques, o malware derrubou crontab, lsof, ldd e top. Esses binários ajustados ocultarão atividades maliciosas, caso alguém os esteja usando. 

Figura 7: O novo conteúdo inserido pelo agente da ameaça em ‘/etc/profile’

No apêndice 5 – Rootkits terrestres do usuário, explicamos em detalhes por que achamos que esses utilitários foram escolhidos pelo agente da ameaça.

Impacto principal

O principal impacto do ataque é o sequestro de recursos. Em todos os casos, observamos um criptominerador monero (XMRIG) executado e esgotando os recursos da CPU do servidor. O criptominerador também é embalado e criptografado. Uma vez descompactado e descriptografado, ele se comunica com pools de criptomineração.
Conforme refletido na Figura 8 abaixo, os pools de criptomineração são acessados via TOR.

Figura 8: Tráfego de criptomineração

Além disso, em alguns dos ataques que vimos por meio de vários fornecedores. Vimos a comunicação com os seguintes domínios: bitping.com, earn.fm, speedshare.app e repocket.com.proxy-jacking
O domínio repocket.com, por exemplo, está associado à plataforma Repocket, que é um serviço que permite aos usuários ganhar dinheiro compartilhando sua largura de banda de internet não utilizada. 
Além disso, podemos observar o uso do daemon bitping, que fornece serviços de pagamento de largura de banda semelhantes.

Figura 9: Fazendo login no bitping

Comunicação TOR

O binário sh também está iniciando a comunicação via Tor com poucos servidores (ou seja, 80.67.172.162, 176.10.107.180, 78.47.18.110, 95.217.109.36, 145.239.41.102).
Enquanto a comunicação é criptografada, você pode observar o log TOR deixado em nosso honeypot.
 

Figura 10: Registro de sessões do TOR

Inteligência adicional sobre ameaças

Registramos várias dezenas de ataques de perfctl. Vimos 3 servidores de download envolvidos nesses ataques (46.101.139.173, 104.183.100.189 e 198.211.126.180). 
Os dois primeiros endereços IP parecem estar vinculados a servidores vulneráveis que foram invadidos anteriormente pelo agente da ameaça e o terceiro pode ser de propriedade do agente da ameaça. Todos os 3 endereços IP armazenam e ocultam artefatos usados nesta campanha. 
Na maioria dos ataques, vemos que os binários foram descartados do endereço IP 46.101.139.173. Uma inspeção desse endereço IP mostrou que este é um servidor web comprometido.

Figura 11: Site comprometido serve como servidor de download

Iterando sobre este servidor de download, vemos um site comprometido em um servidor na Alemanha.
Percebemos alguns artefatos, bem escondidos entre os scripts do site. Vemos 3 cargas úteis principais. Um deles é o avatar.php, que foi usado como parte do ataque ao nosso honeypot. Ao usar o navegador para acessar a página da Web com avatar.php ou baixá-la sem um agente de usuário específico, 1 é exibido na tela ou em um arquivo .php com o dígito 1. 
Além disso, há outro arquivo chamado aoip, que foi carregado 2 meses depois e outros dois dark.css e csdark.css que foram carregados posteriormente.

Figura 12: Arquivos hospedados no servidor Web

Figura 13: Arquivos hospedados no servidor Web

Figura 14: Arquivos hospedados no servidor Web

O AOIP binário é uma replicação da carga útil principal (sh/httpd).
Csdark.css e dark.css não foram analisados durante esta pesquisa, mas parecem muito interessantes.
No endereço IP 198.211.126.180, encontramos apenas o arquivo checklist.php que é a carga útil principal (sh / httpd).

Figura 15: Site comprometido serve como servidor de download

No endereço IP 104.183.100.189, encontramos outro site comprometido inocente.

Figura 16: Site comprometido serve como servidor de download

Parece que este site armazena este arquivo XML que, quando decodificado (base64), é na verdade o script rconf. 

Figura 17: XML mal-intencionado

Pelo que vemos nessessites, existem poucos artefatos usados para executar a exploração de servidores Linux mal configurados e vulneráveis (em nossos ataques registrados).Identificamos uma lista muito longa de quase 20 mil listas de fuzzing de travessia de diretório, em busca de arquivos de configuração e segredos expostos por engano. Existem também alguns arquivos de w-up (como o XML) que o invasor pode executar para explorar a configuração incorreta. Na tabela abaixo você pode ver a análise dos caminhos, que mostra que o perfctl está procurando principalmente explorar configurações incorretas.

Detecção de malware “Perfctl”

Para detectar o malware Perfctl, você procura picos incomuns no uso da CPU ou lentidão do sistema se o rootkit tiver sido implantado em seu servidor. Isso pode indicar atividades de criptomineração, especialmente durante períodos ociosos.

Monitorando o comportamento suspeito do sistema

1. Inspecione os diretórios /tmp, /usr e /root em busca de binários suspeitos, especialmente ocultos ou disfarçados de arquivos do sistema (por exemplo, perfctl, sh, libpprocps.so, perfcclibfsnkdev.so). Inspecione seu diretório /home, procure o diretório /.local/bin com vários utilitários instalados, como ldd, top etc.
2. Monitore processos para alto uso de recursos, como binários como httpd ou sh se comportando de maneira incomum ou executados em locais inesperados como /tmp.
3. Verifique os logs do sistema para modificações nos arquivos ~/.profile e /etc/ld.so.preload.

Análise de tráfego de rede

1. Capture o tráfego de rede para detectar a comunicação baseada em TOR com IPs externos como 80.67.172.162, 176.10.107.180, etc.
2. Procure conexões de saída para pools de criptomineração ou serviços de proxy-jacking.
3. Monitore o tráfego para hosts ou IPs mal-intencionados conhecidos (por exemplo, 46.101.139.173, 104.183.100.189 e 198.211.126.180).

Monitoramento de integridade de arquivos e processos

Detecte modificações nos principais utilitários do sistema, como ldd, top, lsof e crontab, que podem ter sido substituídos por versões trojanizadas.

Análise de log

Revise os logs quanto ao uso não autorizado de binários do sistema, presença de cron jobs suspeitos e erros no mesg para detectar possíveis adulterações.

Detecção de Malware “Perfctl” com Aqua Security

Primeiro, podemos ver alguns incidentes de tempo de execução. Abaixo, você pode ver alertas indicando que alguns novos binários foram descartados e executados, o que significa um desvio em nosso contêiner, além do objeto compartilhado descartado durante o tempo de execução. Estes são os arquivos de malware httpd adicionais e o rootkit.

Figura 18: Tela de incidentes no Aqua Security Platform

Podemos continuar a investigação desse ataque examinando os registros de auditoria desses incidentes. Durante este incidente, houve umbove 22K eventos de auditoria, portanto, precisaremos procurar eventos específicos, ou seja, investigar o ataque.

Figura 19: Tela de logs de auditoria no Aqua Security Platform

Podemos filtrar hosts, contêineres, impor grupos, recursos de nuvem ou até mesmo pods específicos. Decidimos pesquisar eventos específicos com base na estrutura MITRE. Usamos a técnica de mascaramento que é usada para descrever eventos descartados e executados. Houve 465 incidentes, agora podemos revisar todos os arquivos que foram descartados (ou modificados) durante o ataque.

Figura 20: Tela de logs de auditoria no Aqua Security Platform

Podemos aprender, por exemplo, sobre a troca de alguns binários por rootkits terrestres do usuário.

Figura 21: Tela de logs de auditoria no Aqua Security Platform

Você também pode aprender sobre o tráfego de entrada ou configurar a escuta de porta.
 

Figura 22: Tela de logs de auditoria no Aqua Security Platform

Mitigação do malware “Perfctl”

1. Corrigir vulnerabilidades: Certifique-se de que todas as vulnerabilidades sejam corrigidas. Particularmente aplicativos voltados para a Internet, como servidores RocketMQ e CVE-2021-4043 (Polkit). Mantenha todos os softwares e bibliotecas do sistema atualizados.
2. Restringir a execução de arquivos: defina noexec em /tmp, /dev/shm e outros diretórios graváveis para evitar que malware execute binários diretamente desses locais.
3. Desabilitar serviços não utilizados: desabilite todos os serviços que não são necessários, especialmente aqueles que podem expor o sistema a invasores externos, como serviços HTTP.
4. Implemente o gerenciamento rigoroso de privilégios: restrinja o acesso root a arquivos e diretórios críticos. Use o RBAC (Controle de Acesso Baseado em Função) para limitar o que os usuários e processos podem acessar ou modificar.
5. Segmentação de rede: isole servidores críticos da Internet ou use firewalls para restringir a comunicação de saída, especialmente o tráfego TOR ou conexões com pools de criptomineração.
6. Implante a proteção em tempo de execução: use ferramentas avançadas de detecção comportamental e antimalware que podem detectar rootkits, criptomineradores e malware sem arquivo, como perfctl.

Apêndices

Apêndice 1: Acesso inicial

CVE-2023-33246 é uma vulnerabilidade encontrada no RocketMQ, que é um software que gerencia mensagens. Esta vulnerabilidade permite a execução não autorizada de comandos em sistemas onde o RocketMQ está instalado. Esse problema ocorre porque o RocketMQ não verifica adequadamente quem está tentando acessá-lo, o que significa que qualquer pessoa, mesmo sem permissão, pode fazer alterações ou executar comandos. O problema é agravado porque as partes do RocketMQ que lidam com o armazenamento e entrega de mensagens não foram projetadas para serem diretamente acessíveis pela Internet e não exigem autenticação para realizar operações confidenciais, como atualizar configurações. Isso torna relativamente fácil para os invasores explorarem essa vulnerabilidade.
O acesso inicial foi obtido por meio dessa vulnerabilidade (CVE-2023-33246), levou ao download e execução do script de shell rconf com o seguinte comando: 

Figura 23: Script de execução

Na Figura 24 abaixo, você pode observar todo o script rconf, a seguir faremos um detalhamento e explicação do conteúdo. 

Figura 24: O script rconf

Apêndice 2: Análise de script de execução

Conforme ilustrado na Figura 25 abaixo, o script começa com uma função que parece executar uma solicitação HTTP GET simplificada usando um soquete TCP diretamente, imitando algum comportamento básico do comando curl. O agente da ameaça está usando isso, caso o servidor de destino não contenha curl ou wget.

Figura 25: Um trecho do script rconf, ilustrando a implementação de um comando HHTP get request

Como você pode ver na Figura 26 abaixo, o script continua com uma condição if simples, que garantirá que a arquitetura do sistema operacional do servidor atacado seja x86_64. Isso mostra que o agente da ameaça tem como alvo uma arquitetura específica e não será executado no arm, por exemplo.

Figura 26: Um trecho do script rconf, ilustrando a inspeção da arquitetura do host de destino

Em seguida, o agente da ameaça verifica se o diretório /tmp existe e tem permissões de leitura, gravação e execução. Esse diretório será usado posteriormente para armazenar logs, que o malware atualizará e dos quais o malware lerá as instruções ou o status do sistema.

Figura 27: Um trecho do script ‘rconf’, ilustrando a inspeção do caminho ‘/tmp’

Conforme ilustrado na Figura 28 abaixo, o agente da ameaça também verifica se o diretório /tmp está montado com permissões executáveis. Se a opção noexec for encontrada nas opções de montagem (sem permissões de execução), ela remontará /tmp com a opção exec, permitindo a execução de binários do diretório /tmp. Isso pode ser necessário para scripts ou aplicativos que exigem a execução de arquivos temporários armazenados em /tmp.

Figura 28: Um trecho do script ‘rconf’, ilustrando uma inspeção mais aprofundada do diretório ‘/tmp’

Além disso, o agente da ameaça está criando dois diretórios no caminho /tmp, que serão usados posteriormente como auxiliares ao executar a carga principal.

Figura 29: Um trecho do script ‘rconf’, ilustrando a criação de diretórios no caminho ‘/tmp’

Em seguida, o agente da ameaça está definindo a variável de ambiente como , se ainda não estiver definida. A2ZNODElocalhost

Figura 30: Um trecho do script ‘rconf’, ilustrando a inspeção das variáveis de ambiente

Além disso, o agente da ameaça também está definindo a variável de ambiente VEI para rmq, que pode significar índice explorado por vulnerabilidade para RocketMQ ou algo semelhante. Em seguida, esse script processa o arquivo anexando o valor da variável VEI () a ele. Se o arquivo não existir ou estiver vazio, ele verificará se existe um arquivo secundário . Em caso afirmativo, o script processa o conteúdo de , classifica e remove duplicatas e acrescenta o valor de VEI. Se não existir, ele gravará diretamente o valor de VEI em . Por fim, ele desativa a variável VEI/tmp/.xdiag/veirmq/tmp/.xdiag/vei/tmp/.xdiag/vei.1/tmp/.xdiag/vei/tmp/.xdiag/vei.1/tmp/.xdiag/vei

Figura 31: Um trecho do script ‘rconf’, ilustrando a preparação do diretório ‘/tmp’ para a operação de malware e registro

Por fim, esse script gerencia a instalação da carga útil principal, garantindo que nenhuma outra instância esteja em execução, baixando o arquivo necessário e iniciando um servidor web. Ele usa curl, wget ou a função de download personalizada (mencionada acima), verifica o arquivo baixado e o executa se for válido. O script também inclui proteções para impedir que várias instalações ocorram simultaneamente. Isso é importante porque a curvatura inicial desse script rconf é executada iterativamente várias vezes durante o ataque.

Figure 32: A snippet from the ‘rconf’ script, illustrating download and installation of the malware under the name ‘httpd’

Now the main payload avatar.php was downloaded, renamed to httpd and executed, we can focus on this binary.

Appendix 3: The main payload (‘httpd’ and ‘sh’) analysis

Analysis of httpd

The binary httpd is a packed ELF (MD5: 656e22c65bf7c04d87b5afbe52b8d800) bears many detections in VirusTotal, including general Linux Trojan, Coinminer, Exploitation tool for CVE-2021-4034, malware dropper etc.

Our analysis shows that in a way all these detections are correct, as in a nutshell this is a multipurpose malware-dropper that contains all the above. Its operation is very interesting as it incorporates dozens of techniques to remain hidden and persistent. Based on our analysis below we speculate the campaign with this malware started about a year ago, and it remained quite anonymous and undetected.

As per the main payload, it is named in the download server as avatar.php, after it is downloaded, it’s renamed to httpd. The machine is fingerprinted by various commands such as uname −a, then it starts unpacking itself. 

Next, the httpd executable is copied from the running process into to /tmp directory, as illustrated in Figure 33 below. What’s interesting is that it finds the name of the process name that ran it, and saves itself under the /tmp directory with the same name. It also saves the pid under the /tmp/.apid. Lastly, httpd deletes itself.

Figure 33: httpd copies itself from memory

This technique is called “process masquerading” or “process replacement”. It is often done for the following reasons:

1. Defense Evasion: By deleting the original binary and copying itself to another location, the malware avoids detection from static file-based security measures that might be monitoring the original location. The /tmp directory is a common target because it is typically writable and frequently used for temporary files, making it less suspicious.
2. Obfuscation: Deleting the original binary and killing itself can make it harder for security analysts to trace back the activity to the original payload, thereby complicating forensic analysis.

Analysis of sh

The binary sh (MD5: 656e22c65bf7c04d87b5afbe52b8d800) is an exact copy of httpd. After sh is executed, it sleeps for 10 minutes. Next it collects information about the OS. 

Next, sh drops nine binaries. Four are exact duplication of sh/httpd. A cryptominer and a rootkit (discussed below in ‘The Rootkit’ section). There are 3 lean binaries ldd, top and wizlmsh. The first 2 are user land rootkits, in some executions we also saw lsof and crontab. Wizlmsh is used to ensure the malware is running.

The malware opens a Unix socket to communicate with all the process it will run in the future. Via /tmp/.xdiag/int/.per.s, it writes logs, which will later be used by other dropped components as part of the attack. 

The malware is also running various operations such as shutting down security controls, as seen in the example below:

Figure 34: Shutting down security controls

The binary sh is also copying itself from memory to various location, as illustrated below it saves itself as libpprocps.so and also as /root/.config/cron/perfcc, /usr/bin/perfcc, and /usr/lib/libfsnkdev.so.

Figure 35: sh copying itself from memory 

This is a tactic used for persistence, stealth, and possibly for privilege escalation. Below we discuss the various path chosen:

1. The path /root/.config/cron/perfcc: This path is quite deceptive because it mimics a configuration directory under the root user, which might be overlooked by security scans assuming it’s a legitimate config file. The inclusion of cron in the path suggests an attempt to associate the malware with cron jobs.
2. The path /usr/bin/perfcc: The path /usr/bin is a standard directory for executable programs accessible to all users. Placing malware here could allow it to be executed like a normal system command, making detection harder. Naming the malware perfcc might be an attempt to masquerade as a legitimate system utility or command, reducing suspicion.
3. The binaries /usr/lib/libpprocps.so and /usr/lib/libfsnldev.so: These paths suggest the malware is impersonating shared libraries. /usr/lib is commonly used for storing shared libraries required by installed applications. The path libpprocps.so might be intended to appear related to the legitimate procps, a library and set of commands that includes utilities like ps, top, etc., which are used to display information about currently running processes. 

The choice of these paths generally reflects a strategy to blend in with normal system operations, either by appearing as a utility or library that might regularly be executed or loaded by other processes.

Appendix 4: The main rootkit (libgcwrap.so)

The rootkit has several purposes. One of the main purposes is to hook various functions and modify their functionality. The rootkit itself is an ELF 64-bit LSB shared object (.so) file named libgcwrap.so. The rootkit is using LD_PRELOAD to load itself before other libraries. 

As illustrated in Figure 36 below, the rootkit strings are encrypted with XOR and this function is iterating through an array, while performing XOR decryption on each element in the array. 

Figure 36: XOR decrypt array

You can see in Figure 37 below the function responsible to decrypt a string by iterating over each byte of the input string, doing XOR with the key 0xAC.xor_decrypt

Figure 37: XOR decrypt  

Ele faz várias manipulações interessantes, incluindo o gancho aos símbolos Libpam. Especificamente, para a função pam_authenticate, que é usada pelo PAM para autenticar usuários. Conectar ou substituir essa função pode permitir ações não autorizadas durante o processo de autenticação, como ignorar verificações de senha, registrar credenciais ou modificar o comportamento dos mecanismos de autenticação.

Além disso, o rootkit também foi projetado para conectar símbolos Libpcap, especificamente à função pcap_loop, que é amplamente usada para capturar tráfego de rede. 

Abaixo, discutimos o que o invasor está tentando fazer com esses ganchos:

1. Manipulação de tráfego de rede: ao conectar pcap_loop, um invasor pode alterar o comportamento de aplicativos que dependem do libpcap para capturar o tráfego de rede. Isso pode incluir ferramentas de monitoramento de segurança, analisadores de rede e outros sistemas que executam análise de pacotes. A manipulação dessa função pode levar a detecções perdidas, logs de tráfego alterados ou vazamento de dados confidenciais.
2. Espionagem de dados: a função conectada pode ser modificada para copiar furtivamente determinados dados que passam pela rede para um local controlado por um invasor, criando efetivamente um caminho de exfiltração de dados.
3. Persistência e evasão: colocar código malicioso em /tmp e conectar funções críticas como pcap_loop pode ser parte de uma estratégia para manter a persistência em um host com detecção mínima. Essa configuração permite que um invasor continue atividades maliciosas mesmo depois que as cargas primárias forem detectadas e removidas.

Apêndice 5: Rootkits de terra do usuário ‘top’, ‘ldd’, ‘crontab’ e ‘lsof’

O malware Perfctl está caindo no caminho /home/??? /.local/bin/ 4 binários. No nosso caso, top, ldd, lsof e crontab. 

Abaixo está o trecho executando top:

Figura 38: execução superior

Como visto na Figura 38 acima, na primeira linha o script verifica se a variável de ambiente ABWTRX está configurada, se existir este shell script não será executado. Isso provavelmente é para verificar se o binário existe originalmente no servidor ou não.

Em seguida, as variáveis r e m são definidas como top e perfctl de acordo. Assumimos que perfctl, neste caso, é o objeto a ser ocultado, que é o criptominerador.

Em seguida, o script itera sobre os binários /.local/bin para salvá-los na variável de ambiente PATH. Agora o script verifica se a variável de ambiente AAZHDE está definida. Apenas um lembrete. O script inicial, quando o servidor é comprometido pela primeira vez, define a variável de ambiente AAZHDE. Esta é uma inspeção para verificar se o curso “normal” da execução desse malware permanece. Provavelmente para evitar a execução da sandbox.

Se AAZHDE estiver definido, o topo binário é executado passando todos os argumentos que foram passados durante a execução do script.

Se AAZHDE não estiver definido, o script executará vários comandos. Incluindo, 2 comandos de interceptação. Esses comandos de interceptação executam a exclusão do diretório quando o script existe ou se ele é interrompido por um usuário. Em seguida, ele recria e define a variável de ambiente AAZHDE como 1./tmp/smpr/tmp/smpr

Em seguida, o criptominerador é interrompido e o arquivo é excluído. Finalmente, AAZHDE é desdefinido e top é executado./tmp/.apid

Por fim, a variável de ambiente AAZHDE é desconfigurada e o topo binário é executado.

Abaixo está o snippet executando ldd:

Figura 39: execução de ldd

Este trecho é muito semelhante ao do top. Como visto na Figura 37 acima, na primeira linha o script verifica se a variável de ambiente ABWTRX está configurada, se existir este script de shell não será executado. Isso provavelmente é para verificar se o criptominerador está em execução ou não (chegaremos a isso a seguir), se o criptominerador estiver executando este script sai, caso contrário, ele executa e executa o criptominerador.

O topo binário recebe 2 parâmetros, como ponteiro para um executável e um ponteiro para o argv. Ele executa várias etapas, incluindo inicialização, configuração do ambiente, operações criptográficas, manipulação de dados e, eventualmente, execução de outro programa. Ele também executa loop infinito para manter o processo em execução em segundo plano.

Figura 40: binário superior

Você pode ver duas funções modify_lookup_table_with_offset e libc_xor_cipher, que são usadas para ofuscar várias seções na memória. Em seguida, há várias verificações das variáveis de ambiente e erros.

Por fim, se todas as condições forem atendidas, vemos a execução de um binário (fornecido como argumento durante a execução superior).

Figura 41: binário superior

O Top é usado para monitoramento em tempo real do desempenho e dos processos do sistema. Assim, se um desenvolvedor encontrar uma lentidão no sistema correspondente à atividade de criptomineração e pedir para verificar a CPU de todos os processos em execução, o novo temperado com top não mostrará o consumo de CPU do criptominerador.

Ldd é usado para exibir as bibliotecas compartilhadas (dependências dinâmicas) exigidas por um executável ou uma biblioteca compartilhada. Ele mostra de quais bibliotecas um aplicativo depende, bem como os caminhos para essas bibliotecas. O agente da ameaça deseja ocultar bibliotecas e dependências maliciosas usadas pelo malware, impedindo a detecção durante as inspeções. 

O Crontab é usado para agendar e gerenciar tarefas recorrentes (cron jobs) para serem executadas em horários especificados em sistemas Linux/Unix.

lsof Lista os arquivos abertos e mostra quais processos os estão usando, incluindo arquivos, soquetes e conexões de rede.

Faz todo o sentido que o agente da ameaça esteja tentando modificar os resultados desses utilitários, pois eles podem ser usados por desenvolvedores ou engenheiros de segurança para avaliar o servidor e entender o que está atacando a máquina. 

Apêndice 6: Comunicação de soquete Unix

O binário sh está abrindo um soquete Unix para escrever e ler de vários arquivos no diretório /tmp.

Na tabela abaixo, revisamos esses arquivos:

Por exemplo, conforme ilustrado na Figura 40 abaixo, no arquivo abaixo, o malware inseriu o resultado de ls no diretório /tmp.

Figura 42: conteúdo do arquivo lgctr

Apêndice 7: