Plataforma de mineração Panchan: Chegou um novo botnet Golang ponto a ponto

Escrito por: Stiv Kupchik

Integrado ao malware, há um “godmode”: um painel de administração capaz de editar a configuração de mineração, que é então distribuído para o restante de seus pontos. Para evitar adulteração indesejada, uma chave privada é necessária para acessar o godmode, que é então usado para assinar a configuração de mineração. O malware contém uma chave pública que é usada para verificar a chave privada fornecida. O painel de administração está em japonês, o que dá dicas sobre a geolocalização do criador.

O botnet introduz uma abordagem exclusiva (e possivelmente original) ao movimento lateral por meio da coleta de chaves SSH. Em vez de apenas usar força bruta ou ataques de dicionário em endereços IP randomizados, como a maioria dos botnets, o malware também lê os arquivos id_rsa e known_hosts para coletar credenciais existentes e usá-las para se mover lateralmente pela rede.

O malware é escrito em Golang e usa os recursos de simultaneidade do Golang para a maior parte da lógica principal, executando-os como rotinas simultâneas do GO. O agente de ameaças está acompanhando as novas versões do GO. A versão mais antiga do malware detectado (em março de 2022) foi compilada usando o GO 1.17.7 (lançado em fevereiro de 2022), enquanto a última amostra foi compilada usando o GO 1.18 (lançado em março de 2022). Além disso, o GO 1.18 teve algumas alterações feitas em suas estruturas de dados internos, de modo que nenhuma das ferramentas on-line nem o desmontador IDS pudessem analisar o malware corretamente e corresponder o nome da função ao indicador de função. No Apêndice A: Um mergulho rápido na reversão do GO, descrevemos como superamos isso.

Neste relatório, descreveremos os recursos do malware em detalhes, como o detectamos e o processo pelo qual passamos para tentar atribuí-lo. 

Para obter uma lista de IoCs, consulte o repositório do GitHub aqui.

Atividade de malware

A equipe de pesquisa de segurança da Akamai monitora proativamente a atividade de botnets e malware em nossa rede global de sensores. Notamos a atividade de Panchan pela primeira vez em 19 de março de 2022. A comunicação e a habilidade de worm ponto a ponto do malware chamaram a nossa atenção e justificaram uma investigação mais aprofundada. 

Ao fazer uma engenharia reversa do malware, desenvolvemos scripts para nos “sintonizarmos” à rede do botnet, o que permitiu que a equipe reunisse uma lista completa de máquinas infectadas (pontos do botnet). Encontramos 209 pontos, dos quais 40 estão ativos atualmente. 

Embora os alvos estejam dispersos em todo o mundo, parece haver uma concentração mais pesada de alvos na Ásia.

A nossa atribuição da origem japonesa do agente de ameaças (detalhada mais adiante) pode explicar o maior número de alvos na Ásia. Como não parece que há uma organização por trás deste malware, é plausível que seja mais fácil para o agente de ameaças se manter próximo e familiar.

Olhando para vítimas verticais, a maioria dos IPs das vítimas está registrado em suas plataformas de hospedagem/VPS, portanto não há muita informação. A vertical mais comum entre as vítimas monitoradas foi a educação. Isso pode ser devido à falta de higiene das senhas ou pode estar relacionado ao recurso de movimento lateral exclusivo do malware com chaves SSH roubadas. Pesquisadores em diferentes instituições acadêmicas geralmente colaboram com mais frequência do que funcionários do setor empresarial e precisam de credenciais para autenticar máquinas que estão fora de sua organização/rede. Reforçando essa hipótese, vimos que algumas das universidades envolvidas eram do mesmo país (por exemplo, Espanha) e outras eram da mesma região (por exemplo, Taiwan e Hong Kong).

Explorando os recursos do malware

Vetor de infeção: worm SSH

O malware é capaz de se espalhar por meio do SSH. Ele tem dois métodos para gerar destinos e detalhes de autenticação:

     Chaves SSH existentes

O malware procura no diretório HOME do usuário em execução a configuração e as chaves SSH. Ele lê a chave privada em ~HOME/.ssh/id_rsa e a usa para tentar autenticar qualquer endereço IP encontrado em ~HOME/.ssh/known_hosts. Este é um novo método de coleta de credenciais que não vimos sendo usado em outros tipos de malware.

     Credenciais de força bruta

O malware pode randomizar endereços IP e tentar um ataque de dicionário usando uma lista predeterminada de usuários e senhas. O distribuidor de força bruta é gerado em um processo separado várias vezes, sendo limitado apenas pelo limite definido do sistema operacional para arquivos abertos. Os nomes de usuário e senhas são bastante simples: combinações de strings padrão como "ubuntu," "root," "user," ‘‘debian," "pi" entre outros.

Após uma autenticação bem-sucedida no destino, o malware cria uma pasta oculta com um nome aleatório no diretório raiz / e se copia para a pasta oculta com o nome xinetd usando o sftp.

Em seguida, o malware executa remotamente o binário copiado na máquina de destino (usando nohup) e passa a lista de pontos pela linha de comando. Após uma infecção bem-sucedida, o malware inicia uma operação de POST HTTPS em um webhook no Discord, que é provavelmente usado para o monitoramento de vítimas.

Comunicação ponto a ponto

O protocolo ponto a ponto do botnet é bastante simples. Tudo é enviado em texto simples pela porta TCP 1919. Todos os pontos seguem essa porta e criam uma regra para permiti-lo em iptables. Cada mensagem começa com a plataforma de mineração do pan-chan hi! e termina com finish. Entre eles, o malware envia comandos de configuração separados por novas linhas. Há apenas duas opções de configuração que detectamos: sharepeer e sharerigconfig. 

sharepeer  é bem simples: ela é seguida por um IP, que é então adicionado à lista de pares internos do malware.

sharerigconfig é seguida por uma string codificada em base64, que é, na verdade, uma estrutura JSON que codifica a configuração de mineração e uma assinatura dessa configuração:

A assinatura é validada usando uma chave pública salva internamente para garantir a autenticidade. A lógica de comunicação também é simples: após uma conexão com ou de um ponto, o malware analisa sua configuração salva na memória (que foi obtida anteriormente, quando começou a ser executada), gera a string de mensagem e a envia. Ele também recebe uma mensagem semelhante do outro ponto e a analisa. Novos pontos são adicionados à lista de pontos, enquanto a configuração é substituída se for uma versão mais recente.

Para verificar se há atualizações, o malware se conecta periodicamente a seus pontos salvos.

Godmode

Este é provavelmente o recurso mais exclusivo do malware: ele tem um painel administrativo integrado diretamente ao binário do malware. Para iniciá-lo, precisamos passar a string godmode ao malware como o primeiro argumento da linha de comando (seguido por uma lista de pontos).

Verificação de acesso

Embora o painel de administração esteja integrado ao malware, ele não pode ser acessado por qualquer pessoa. Para impedir o acesso indesejado ao painel, o malware primeiro solicita uma chave privada e, somente após a validação, podemos acessar sua interface.

Não tínhamos a chave privada requisitada; então, em vez disso, fizemos o patch do programa para ignorar a validação da chave e aceitar qualquer chave privada fornecida (só era necessário uma única modificação JZ para JMP).

Painel de administração: estatísticas

Depois de fornecer a chave privada e “fazer login”, somos recebidos com uma tela de status sobre a configuração atual.

A primeira seção são estatísticas dos pontos, que são contatados antes do godmode ser iniciado, com base na lista de pontos que é passada na linha de comando do malware (não fornecemos uma lista de pontos ao analisá-la, daí o zero).

A segunda seção é a configuração de cripto mineração. Ela está no mesmo formato que a configuração de mineração enviada entre os pontos, mas com texto em japonês em vez de inglês. A diferença de idioma é provavelmente devido à facilidade de programação: imprimir textos em japonês é simples, mas analisá-los é mais difícil, de modo que o criador do malware usou o inglês na configuração enviada entre os pontos.

Finalmente, temos um menu com as seguintes opções:

1. Atualizar a tela de status

2. Imprimir a lista ativa de pontos

3. Atualizar as configurações do minerador

4. Sair

Minerador sem arquivo

O malware implanta dois mineradores: xmrig e nbhash. Ambos os binários do minerador são codificados em base64 dentro do próprio binário do malware e são extraídos e executados durante o tempo de execução. No entanto, há uma certa novidade na execução, já que os mineradores não são extraídos para o disco. Em vez disso, o malware usa a função do UNIX memfd_create para criar um arquivo mapeado por memória com o conteúdo binário do minerador, para que ele possa ser executado diretamente da memória sem ter um caminho de sistema de arquivos rastreável. A partir da configuração que extraímos de vários pontos dos botnets, percebemos que o malware usa NiceHash para seus pools e carteiras de mineração. As carteiras NiceHash não são carteiras de blockchain, portanto, não podemos ver os detalhes de transações e mineração sobre eles para medir a receita real.

Anti eliminação

O malware detecta sinais de terminação do Linux (especificamente SIGTERM — 0xF e SIGINT — 0x2) que são enviados a ele e os ignora. Isso dificulta encerrar o malware, mas não impossível, já que o SIGKILL não é manipulado (porque não é possível, de acordo com o padrão POSIX, página 313).

Anti monitoramento

Esse módulo é chamado internamente de anti gerenciador de tarefas, mas ao contrário do seu nome, ele não interfere na operação do gerenciador de tarefas. Em vez disso, o malware procura continuamente os processos top e htop. Depois de encontrá-los, ele encerra os processos do minerador que estão sendo executados no momento.

Persistência

O malware se copia para /bin/systemd-worker e cria um serviço systemd com o mesmo nome. Isso provavelmente é feito para imitar serviços legítimos de systemd para reduzir a suspeita e evitar investigação.

Atribuição

Há uma tela adicional que é apresentada no painel godmode enquanto validamos a chave privada.

A reivindicação de direitos autorais é bastante interessante: ela menciona o Panchan e tem um servidor real no Discord! Clicando o link, parece que podemos realmente nos juntar a esse servidor, e também obtemos o nome de usuário Discord que o Panchan usa. Presumimos que esse servidor seja o mesmo para o qual o malware relata após uma conexão SSH bem-sucedida.

Entramos no servidor, esperando encontrar informações sobre o agente de ameaças e ver as notificações do Discord que o malware envia como parte do fluxo de infeção. Não encontramos nada disso. A sala de bate-papo principal estava vazia, exceto por uma saudação de outro membro feita em março. Pode ser que outros chats só estejam disponíveis para membros mais privilegiados do servidor, e é por isso que não os vemos. A única informação útil que descobrimos foi que o servidor foi criado no início de março de 2022, muito próximo a quando identificamos o malware pela primeira vez.

Pesquisando outras atividades desse usuário, também o encontramos ativo no servidor do Privex (um provedor de VPS) no Discord.

Além do VPS regular, o Privex também oferece VMs pré-instaladas com software de nó blockchain. Isso pode significar que o agente de ameaças está usando-as para hospedar seu próprio servidor ou talvez esteja ativamente direcionando suas VMs para cryptojacking.

Detecção e mitigação

Para ajudar na detecção, criamos um repositório com assinaturas IOCs e Yara e Snort que podem ser usadas para testes de infeções. Também desenvolvemos um script bash que pode ser executado em uma VM. Ele procura os seguintes indicadores de Panchan:

• O processo systemd-worker

• O processo xinetd, se for executado de um caminho diferente de /bin ou /sbin

• Processa o monitoramento na porta TCP 1919

Além disso, a comunicação de saída pelas portas TCP 3380 e 3387 pode indicar tráfego para o pool de cripto mineração.

Para os leitores que desejam defender suas redes de forma proativa, temos as seguintes recomendações:

• Use senhas seguras e complexas. O malware usa um número muito limitado de combinações padrão de nome de usuário e senha que não devem ser configuradas em nenhuma máquina de produção. Criar senhas fortes pode reduzir bastante os impactos do malware.

• Configure a MFA sempre que possível. Usar uma MFA pode impedir qualquer tentativa de login não autorizada. A MFA da Akamai também pode ajudar a proteger contra a coleta de chaves SSH.

• Segmente sua rede sempre que possível. Embora seja legítimo ter máquinas abertas à Internet através do SSH, é aconselhável controlar quem tem a permissão para conectá-las a partir da Internet, assim como quem eles tem permissão de se conectar dentro da rede. A configuração desses controles de acesso reduz os impactos que uma máquina violada pode ter na rede, bem como reduz a superfície de ataque geral.

• Monitore a atividade de recursos de suas VMs. Botnets como este, cujo objetivo final é o cryptojacking, podem aumentar o uso de recursos da máquina para níveis anormais. O monitoramento constante pode alertá-lo sobre atividades suspeitas. No caso do Panchan, o monitoramento do uso de recursos também teria encerrado totalmente a cripto mineração.

Apêndice A: Um mergulho rápido na reversão do GO

Os executáveis GO são compilados estaticamente, o que significa que todas as dependências do executável são compiladas diretamente no binário. Isso cria binários enormes com muitas funções (para referência, nosso malware tinha 30 MB com aproximadamente 3.700 funções).

Para ajudar com rastreamentos de pilha, o GO tem uma estrutura pclntab que combina os nomes e os indicadores de função dentro do binário. Isso existe até em binários removidos para que possamos usá-los para encontrar nomes de funções.

No GO 1.18, essa estrutura foi alterada. Onde antes ele tinha indicadores para locais no binário, agora ele tem compensações de locais específicos: indicadores de função agora são compensações da primeira função GO (que é indicada na estrutura pcln comentada como text_start na imagem acima), os indicadores de nome são compensações do início da matriz de nome de função e ambos são referenciados por compensações em uma matriz diferente que contém dados de função.