Malware de minerador de criptografia

Question

Continuo encontrando meu servidor com 100% de uso de CPU e é um processo com nome ambíguo que está oculto em algum lugar da pasta /etc/ em execução na raiz (sempre uma pasta diferente). A primeira vez que o encontrei procurei e confirmei que era um mineiro, encerrei o processo usando kill -9 PIDe apaguei a pasta. Mas encontrei mais duas vezes e resolvi removê-lo novamente, mas também mudar as senhas da conta que uso para ssh no servidor e também para root, mas acabei de encontrar novamente.

Existe uma maneira de identificar como uma pasta chegou lá, pois ainda deve haver algo em meu servidor que verifica periodicamente esses arquivos e, se não os encontrar, baixa ou extrai-os novamente.

O mineiro estava enviando tráfego para o seguinte endereço: ip162.ip-5-135-85.eu que pertence ahttps://aeon.miner.rocks/

Answer 1

Considere reinstalar o servidor.

Confira os seguintes locais:

• crontab -l depois de usarsudo -su
• crontab -lcom seu usuário administrador
• conteúdo de /etc/rc.locale/etc/apt/sources.list

• os diretórios

  /etc/systemd/system
  /usr/lib/systemd/system
  /lib/systemd/system
  

  por serviços que você não reconhece.

Esses serão os principais culpados.

aeon-stak-cpuzheck /bin/para um arquivo aeon-stak-cpu.

Faça um locate aeon. Isso pode aparecer em mais diretórios.

Não consigo encontrar um malware. aeon é instalado a partir da linha de comando, então espero que alguém tenha uma conexão com sua máquina.

Answer 2

Então finalmente cheguei ao fundo da questão.

Primeiro, eu tinha o nginx rodando como root, que provavelmente era o ponto de entrada original. O Clamscan encontrou e sinalizou um arquivo chamado info.php escondido em /var/www, que provavelmente foi como eles obtiveram acesso inicialmente.

Continuei vendo processos ssh para root@notty, que eu não sabia o que notty significava a princípio, e quando olhei para netstat definitivamente não era nenhuma das minhas sessões. Mas tenho mudado as senhas para outras completamente aleatórias, então não poderia ser que eles soubessem as senhas. Decidi examinar todas as pastas /home/[user]/.ssh do meu usuário e encontrei a mesma chave ssh no arquivo autorizado_keys.

Removi a chave e também mudei o usuário para nginx e não tive problemas desde então.