Pesquisadores de segurança cibernética descobriram uma nova campanha de cryptojacking direcionada à API Docker Engine com o objetivo de reunir condições para ingressar em um Docker Swarm malicioso controlado por um agente de ameaça.
Isso permitiu que os invasores “usassem os recursos de orquestração do Docker Swarm para fins de comando e controle (C2)”, disseram os pesquisadores da Datadog Matt Muir e Andy Giron em uma análise.
O ataque aproveita o Docker para acesso inicial para executar um minerador de criptomoedas em contêineres vulneráveis, enquanto baixa e extrai cargas adicionais responsáveis pela execução do tráfego coletivo em hosts relacionados usando Docker, Kubernetes ou SSH.
Especificamente, isso envolve a identificação de repositórios de API Docker não autorizados e expostos usando ferramentas de verificação online, como maskan e ZGrab.
Em ambientes vulneráveis, a API Docker é usada para gerar um contêiner Alpine e um script de shell de inicialização (init.sh) é encontrado no servidor remoto (“solscan[.]live”) que, por sua vez, verifica se você está executando como usuário root com ferramentas como curl e wget instaladas antes de baixar o minerador XMRig.
Como outras campanhas de cryptojacking, ele usa o rootkit libproceshider para ocultar o processo malicioso do minerador do usuário ao usar ferramentas de enumeração de processos como top e ps.
O shell script também foi projetado para baixar três outros scripts de shell – kube.lateral.sh, spread_docker_local.sh e spread_ssh.sh – do mesmo servidor para mobilidade conjunta para endpoints Docker, Kubernetes e SSH na rede.
Spread_docker_local.sh “usa maskan e zgrab para verificar o mesmo escopo da LAN […] As portas 2375, 2376, 2377, 4244 e 4243 estão abertas”, disseram os pesquisadores. “Essas portas estão relacionadas ao Docker Engine ou Docker Swarm.”
“Para quaisquer IPs encontrados com portas de destino abertas, o malware tenta gerar um novo contêiner chamado alpine. Este contêiner é baseado em uma imagem chamada upspin, hospedada no Docker Hub pelo usuário nmlmweb3.”
A imagem upspin foi projetada para executar o script init.sh mencionado anteriormente, permitindo assim que o malware do grupo se espalhe como um worm para outros hosts Docker.
Além disso, a tag da imagem Docker usada para recuperar a imagem do Docker Hub é especificada em um arquivo de texto hospedado no servidor C2, permitindo assim que atores mal-intencionados se recuperem facilmente de um possível comprometimento, alterando o conteúdo do arquivo para apontar para um endereço diferente. um. imagem do contêiner.
Um terceiro script de shell, spread_ssh.sh, é capaz de comprometer servidores SSH, bem como adicionar uma chave SSH e um novo usuário chamado ftp que permite que agentes mal-intencionados se conectem remotamente aos hosts e mantenham acesso contínuo.
Ele também procura vários arquivos de autenticação relacionados a SSH, Amazon Web Services (AWS), Google Cloud e Samba nos caminhos de arquivo codificados dentro do GitHub Codespaces (ou seja, o diretório “/home/codespace/” e, se encontrado,). carregue-os no servidor C2.
No estágio final, tanto a carga útil do Kubernetes quanto o movimento lateral do SSH usam outro script de shell chamado setup_mr.sh que detecta e inicia a mina de criptomoeda.
A Datadog disse que também encontrou mais três scripts hospedados no servidor C2 –
- ar.sh, uma variante do init.sh que altera as regras do iptables e limpa logs e cron jobs para evitar detecção
- TDGINIT.sh, que baixa ferramentas de varredura e baixa um contêiner malicioso para cada host Docker identificado
- pdflushs.sh, que instala um backdoor persistente inserindo uma chave SSH controlada por um agente de ameaça no arquivo /root/.ssh/authorized_keys
TDGINIT.sh também é notável por sua manipulação do Docker Swarm, forçando o host a deixar qualquer Swarm existente do qual possa fazer parte e adicioná-lo a um novo Swarm sob o controle do invasor.
“Isso permite que um agente de ameaça estenda sistematicamente seu controle sobre múltiplas instâncias do Docker, transformando efetivamente sistemas vulneráveis em uma botnet para exploração adicional”, disseram os pesquisadores.
Ainda não está claro quem executou o ataque, embora as táticas, estratégias e procedimentos demonstrados se sobreponham aos de um conhecido grupo de ameaças conhecido como TeamTNT.
“Esta campanha mostra que serviços como Docker e Kubernetes são sempre frutíferos para os agentes de ameaças que praticam cryptojacking em grande escala”, disse Datadog.
“A campanha depende da exposição on-line dos endpoints da API Docker sem autenticação. A capacidade do malware de se espalhar rapidamente significa que, mesmo que as chances de acesso inicial sejam muito pequenas, as recompensas são grandes o suficiente para manter as equipes de malware baseadas na nuvem motivadas o suficiente para continuar carregando fora esses ataques “.
O desenvolvimento ocorre no momento em que o Elastic Security Labs está lançando uma campanha de malware Linux visando servidores Apache vulneráveis para estabelecer a persistência do GSocket e erradicar famílias de malware como Kaiji e RUDEVIL (também conhecido como Lucifer) que oferecem negação de serviço (DDoS) e criptomoeda. minas, respectivamente.
“A campanha REF6138 envolveu fraude de criptografia, ataques DDoS e possível lavagem de dinheiro usando APIs de jogos de azar, destacando o uso da evolução do malware e de canais de comunicação privados pelos invasores”, disseram os pesquisadores Remco Srooten e Ruben Groenewoud.
