Pesquisadores de segurança cibernética descobriram uma nova campanha de cryptojacking visando a API Docker Engine com o objetivo de cooptar as instâncias para se juntarem a um Docker Swarm malicioso controlado pelo ator da 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.
Os ataques aproveitam o Docker para acesso inicial para implantar um minerador de criptomoeda em contêineres comprometidos, ao mesmo tempo que buscam e executam cargas úteis adicionais que são responsáveis por conduzir o movimento lateral para hosts relacionados que executam Docker, Kubernetes ou SSH.
Especificamente, isso envolve a identificação de endpoints da API Docker não autenticados e expostos usando ferramentas de varredura da Web, como masscan e ZGrab.
Em endpoints vulneráveis, a API Docker é usada para gerar um contêiner Alpine e, em seguida, recuperar um script de shell de inicialização (init.sh) de um servidor remoto (“solscan(.)stay”) que, por sua vez, verifica se está sendo executado como o usuário root e ferramentas como curl e wget são instalados antes de baixar o minerador XMRig.
Como outras campanhas de cryptojacking, ele usa o rootkit libprocesshider para ocultar o processo de mineração malicioso do usuário ao executar ferramentas de enumeração de processos como high e ps.
O shell script também foi projetado para buscar três outros scripts de shell – kube.lateral.sh, spread_docker_local.sh e spread_ssh.sh – do mesmo servidor para movimentação lateral para endpoints Docker, Kubernetes e SSH na rede.
Spread_docker_local.sh “usa masscan e zgrab para verificar os mesmos intervalos de LAN (…) em busca de nós com portas 2375, 2376, 2377, 4244 e 4243 abertas”, disseram os pesquisadores. “Essas portas estão associadas ao Docker Engine ou ao Docker Swarm.”
“Para quaisquer IPs descobertos com as portas de destino abertas, o malware tenta gerar um novo contêiner com o nome 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 propague de forma semelhante a um worm para outros hosts Docker.
Além do mais, a tag de imagem do Docker usada para recuperar a imagem do Docker Hub é especificada em um arquivo de texto hospedado no servidor C2, permitindo assim que os agentes da ameaça se recuperem facilmente de possíveis remoções, simplesmente alterando o conteúdo do arquivo para apontar para um diferente. imagem do contêiner.
O terceiro shell script, spread_ssh.sh, é capaz de comprometer servidores SSH, bem como adicionar uma chave SSH e um novo usuário chamado ftp que permite que os agentes da ameaça se conectem remotamente aos hosts e mantenham acesso persistente.
Ele também procura vários arquivos de credenciais relacionados a SSH, Amazon Net Providers (AWS), Google Cloud e Samba em caminhos de arquivo codificados no ambiente GitHub Codespaces (ou seja, o diretório “/house/codespace/”) e se encontrado, carrega-os no servidor C2.
No estágio closing, as cargas úteis de movimento lateral do Kubernetes e SSH executam outro script de shell chamado setup_mr.sh que recupera e inicia o minerador de criptomoeda.
A Datadog disse que também descobriu três outros scripts hospedados no servidor C2 –
- ar.sh, uma variante do init.sh que modifica as regras do iptables e limpa logs e tarefas cron para evitar a detecção
- TDGINIT.sh, que baixa ferramentas de varredura e coloca um contêiner malicioso em cada host Docker identificado
- pdflushs.sh, que instala um backdoor persistente anexando uma chave SSH controlada pelo agente de ameaça ao 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 o agente da ameaça expanda seu controle sobre múltiplas instâncias do Docker de forma coordenada, transformando efetivamente os sistemas comprometidos em uma botnet para exploração adicional”, disseram os pesquisadores.
Atualmente não está claro quem está por trás da campanha de ataque, embora as táticas, técnicas e procedimentos exibidos se sobreponham aos de um grupo de ameaças conhecido como TeamTNT.
“Esta campanha demonstra que serviços como Docker e Kubernetes continuam frutíferos para os atores de ameaças que conduzem criptojacking em grande escala”, disse Datadog.
“A campanha depende da exposição dos endpoints da API Docker à Web sem autenticação. A capacidade do malware de se propagar rapidamente significa que, mesmo que as probabilities de acesso inicial sejam relativamente pequenas, as recompensas são altas o suficiente para manter os grupos de malware focados na nuvem motivados o suficiente para continuar conduzindo esses ataques.”
O desenvolvimento ocorre no momento em que o Elastic Safety Labs lança luz sobre uma sofisticada campanha de malware Linux direcionada a servidores Apache vulneráveis para estabelecer persistência through GSocket e implantar famílias de malware, como Kaiji e RUDEDEVIL (também conhecido como Lucifer), que facilitam a negação de serviço distribuída (DDoS) e a criptomoeda. mineração, respectivamente.
“A campanha REF6138 envolveu criptomineração, ataques DDoS e possível lavagem de dinheiro por meio de APIs de jogos de azar, destacando o uso de malware em evolução e canais de comunicação furtivos pelos invasores”, disseram os pesquisadores Remco Srooten e Ruben Groenewoud.