Pesquisadores de cibersegurança descobriram uma nova campanha de cryptojacking visando a API do Docker Engine com o objetivo de cooptar as instâncias para se juntarem a um Docker Swarm malicioso controlado pelo ator de ameaças.
Isso permitiu aos atacantes "usar os recursos de orquestração do Docker Swarm para fins de comando e controle (C2)", afirmaram os pesquisadores da Datadog, Matt Muir e Andy Giron, em uma análise.
Os ataques se aproveitam do Docker para acesso inicial, a fim de implantar um minerador de criptomoedas em contêineres comprometidos, enquanto também buscam e executam payloads adicionais que são responsáveis por realizar movimentos laterais para hosts relacionados executando Docker, Kubernetes ou SSH.
Especificamente, isso envolve a identificação de endpoints da API do Docker não autenticados e expostos usando ferramentas de varredura da Internet, como masscan e ZGrab.
Nos endpoints vulneráveis, a API do Docker é usada para gerar um contêiner Alpine e, em seguida, recuperar um script de inicialização shell (init.sh) de um servidor remoto ("solscan[.]live") que, por sua vez, verifica se está sendo executado como usuário root e se ferramentas como curl e wget estão instaladas antes de baixar o minerador XMRig.
Como outras campanhas de cryptojacking, ela faz uso do rootkit libprocesshider para esconder o processo do minerador malicioso do usuário quando ferramentas de enumeração de processos como top e ps são executadas.
O script shell também é projetado para buscar outros três scripts shell – kube.lateral.sh, spread_docker_local.sh e spread_ssh.sh – do mesmo servidor para movimento lateral para endpoints Docker, Kubernetes e SSH na rede.
O script spread_docker_local.sh "utiliza masscan e zgrab para escanear as mesmas faixas de LAN [...] por 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 qualquer IP descoberto com as portas alvo 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 é projetada para executar o mencionado script init.sh, permitindo assim que o malware do grupo se propague de maneira semelhante a 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 os atores de ameaça se recuperem facilmente de possíveis desligamentos simplesmente alterando o conteúdo do arquivo para apontar para uma imagem de contêiner diferente.
O terceiro script shell, spread_ssh.sh, é capaz de comprometer servidores SSH, além de adicionar uma chave SSH e um novo usuário chamado ftp que permite aos atores de ameaça se conectar remotamente aos hosts e manter acesso persistente.
Ele também procura por vários arquivos de credenciais relacionados a SSH, Amazon Web Services (AWS), Google Cloud e Samba em caminhos de arquivos codificados dentro do ambiente GitHub Codespaces (ou seja, o diretório "/home/codespace/"), e, se encontrados, os carrega para o servidor C2.
Na etapa final, tanto os payloads de movimento lateral Kubernetes quanto SSH executam outro script shell chamado setup_mr.sh que recupera e lança o minerador de criptomoedas.
A Datadog disse que também descobriu outros três scripts hospedados no servidor C2 -ar.sh, uma variante do init.sh que modifica regras de iptables e limpa logs e trabalhos cron para evitar detecção
TDGINIT.sh, que baixa ferramentas de varredura e solta um contêiner malicioso em cada host Docker identificado dflushs.sh, que instala um backdoor persistente anexando uma chave SSH controlada pelo ator de ameaça ao arquivo /root/.ssh/authorized_keys
O TDGINIT.sh também é notável por sua manipulação do Docker Swarm, forçando o host a deixar qualquer Swarm existente que possa ser parte e adicionar a um novo Swarm sob controle do atacante.
"Isso permite que o ator de ameaça expanda seu controle sobre múltiplas instâncias do Docker de maneira coordenada, transformando efetivamente 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ça conhecido como TeamTNT.
"Esta campanha demonstra que serviços como Docker e Kubernetes continuam frutíferos para atores de ameaças conduzindo cryptojacking em larga escala", disse a Datadog.
A campanha depende de endpoints da API do Docker sendo expostos à Internet sem autenticação.
A capacidade do malware de propagar rapidamente significa que, mesmo que as chances de acesso inicial sejam relativamente pequenas, as recompensas são altas o suficiente para manter grupos de malware focados em nuvem motivados o suficiente para continuar conduzindo esses ataques.
O desenvolvimento vem à medida que os Elastic Security Labs lançaram luz sobre uma sofisticada campanha de malware Linux visando servidores Apache vulneráveis para estabelecer persistência via GSocket e implantar famílias de malware como Kaiji e RUDEDEVIL (também conhecido como Lucifer) que facilitam ataques de negação de serviço distribuído (DDoS) e mineração de criptomoedas, respectivamente.
"A campanha REF6138 envolveu criptomineração, ataques DDoS e potencial lavagem de dinheiro via APIs de jogos de azar, destacando o uso pelos atacantes de malware em evolução e canais de comunicação furtivos", disseram os pesquisadores Remco Sprooten e Ruben Groenewoud.
Publicidade
Em 14 de janeiro a Solyd irá revolucionar a forma como pentest e hacking deve ser ensinado. Se inscreva para ser o primeiro a saber das novidades. Saiba mais...