Em ataques anteriores de mineração de criptomoedas, shell scripts mal-intencionados eram normalmente usados como downloaders. No entanto, casos recentes mostram que agora eles servem a outros propósitos, como, por exemplo, roubar dados confidenciais.

Recentemente, vimos novos ataques em que, novamente, os agentes de ameaças usaram shell scripts para executar atividades maliciosas. Esses scripts vieram de uma imagem aleatória em um repositório de contêiner público. Os usuários devem estar cientes dos riscos de segurança da execução, pois podem conter elementos maliciosos, como backdoors. Com base em ataques anteriores, esses scripts maliciosos eram normalmente usados para implantar mineradores de criptomoeda. Mas casos recentes envolvendo essas novas amostras destacaram como os scripts são desenvolvidos, já que agora eles servem a outros propósitos além de serem downloaders para criptominadores.

Com base em seus URLs de comando e controle, algumas strings, chaves de criptografia e a linguagem usada nas amostras, deduzimos que este último ataque veio do arsenal TeamTNT.

O shell script malicioso usado aqui foi desenvolvido em Bash. Em comparação com ataques semelhantes anteriores, a técnica de desenvolvimento foi muito mais refinada para este script. Não havia mais linhas infinitas de código e os exemplos eram bem escritos e organizados por função com nomes descritivos.

Figura 1. Trecho de código mostrando funções

As primeiras funções chamadas pelo shell script preparam o ambiente, certificando-se de que as próximas fases terão os recursos, ferramentas, potência do computador necessários, etc. Também verifica a presença de soluções de segurança.

O shell script também baixa algumas ferramentas de greyware que serão usadas no futuro para examinar outros destinos. Essas ferramentas executam varredura e mapeamento de rede e serão utilizadas para pesquisar e mapear novas APIs de contêineres vulneráveis.

Depois que o ambiente é configurado, o shell script procura informações confidenciais, obtém uma cópia delas e carrega tudo para um servidor C&C.

Este novo exemplo rouba credenciais da API do Docker também, o que é uma das partes interessantes desse ataque.

Figura 2. Trecho de código mostrando o roubo e exfiltração de credenciais da API do Docker

Em algum momento entre o roubo de credenciais e a implantação do minerador de criptomoeda, o script descarta outra amostra incorporada como codificada em base64. Isso serve para criar um usuário no sistema, com permissões sudo e uma chave SSH-RSA para garantir que eles possam se conectar à máquina infectada e manter o acesso.

Figura 3. Trechos de código mostrando a criação do usuário, usados por invasores para manter o acesso

Somente depois de todas essas etapas o minerador de criptomoeda é baixado, implantado com nome e PATH “furtivos”, e executado.

Uma última etapa adicionada recentemente a este novo ataque implanta um shell reverso, conforme descrito em um blog anterior.

Até agora, esse ataque só foi visto visando plataformas de contêineres. A imagem do contêiner que contém todas as amostras maliciosas foi criada recentemente, com a contagem de download chegando a 2.000 antes que o usuário e a imagem fossem retirados.

Figura 4. Captura de tela da imagem do contêiner contendo as amostras maliciosas

Figura 5. O usuário e a imagem foram retirados

Amostras desse ataque detectado recentemente também foram encontradas equipadas com duas novas rotinas que não eram vistas em ataques anteriores do TeamTNT. Nos exemplos que vimos antes, a rotina verifica apenas os arquivos de credencial na máquina antes de carregá-los. Neste novo exemplo, os desenvolvedores adicionaram rotinas, sendo que o primeiro solicita o serviço de metadados da AWS e tenta obter as credenciais de lá. Isso só acontece porque os invasores podem executar o script, pois estão na instância devido à execução de uma imagem do Docker com backdoor e não há nenhuma técnica especial sendo usada para acessar o serviço de metadados da instância (IMDS). Por padrão, nenhum cargo é anexado a uma instância e essas credenciais terão apenas as permissões anexadas pelo cliente. Os clientes devem seguir o princípio do menor privilégio se decidirem anexar permissões a uma função de instância.

A outra rotina adicionada verifica as variáveis de ambiente para credenciais AWS. Se estiverem presentes, eles serão carregados no servidor C&C.

Figura 6. Trecho de código mostrando o roubo e exfiltração de credenciais AWS

Embora a origem desse ataque tenha sido uma imagem de contêiner mal-intencionada, os scripts de infecção não distinguem onde estão sendo executados, infectando qualquer sistema operacional *nix (Linux, Unix) para recuperar as informações de metadados que o malware precisa executar em uma instância alcance.

 

Conclusão

Ataques como o incidente descrito nesta entrada destacam a importância da vigilância na proteção de sistemas contra comprometimento. Os usuários devem ter em mente que, se estiverem executando uma imagem aleatória, devem ser cautelosos com a possibilidade de um agente de ameaça ter adicionado elementos maliciosos, como backdoors.

Além disso, embora o número de variantes de malware de criptomoeda aumente rapidamente, também parece que os agentes de ameaças que implantam ataques de mineração não estão apenas interessados em minerar criptomoedas. Alguns dos primeiros ataques desse tipo que vimos no passado implantaram seus mineradores sem muitos critérios. Eles usavam scripts maliciosos que serviam como downloaders básicos e diretos, e o minerador era bom o suficiente se rodasse no sistema do alvo.

As táticas agora evoluíram exponencialmente. Os scripts maliciosos estão sendo desenvolvidos para roubar dados mais confidenciais, como credenciais. Eles agora também estão equipados com outras funções, como preparar o ambiente para garantir que ele tenha recursos suficientes para minerar, ser furtivos o suficiente para manter a mineração pelo maior tempo possível e também certificar-se de deixar backdoors caso precisem se conectar remotamente com seus alvos.

Como os ataques agora também procuram credenciais do Docker, implementar a autenticação da API não é suficiente. Os administradores de sistemas também devem se certificar de que a API não seja exposta publicamente e só possa ser acessada por quem precisa.

Para manter seus sistemas protegidos, as empresas devem empregar as seguintes práticas recomendadas:

• Monitore e audite continuamente os dispositivos, especialmente aqueles usados para acessar a rede do escritório.

• Siga o princípio do menor privilégio ao conceder permissões.

• Esteja ciente do modelo de responsabilidade compartilhada.

• Corrigir e atualizar sistemas regularmente para garantir que as defesas dos sistemas sejam atualizadas.

• Escolha senhas fortes e nunca use as padrão.

 

Soluções Trend Micro

A Trend Micro Hybrid Cloud Security defende os sistemas nativos da nuvem e suas camadas. Esta solução unificada emprega perfeitamente a implantação e descoberta automatizadas dentro de conjuntos de ferramentas existentes. Ele é alimentado pela plataforma de serviços de segurança Trend Micro Cloud One™ para criadores em nuvem, que fornece proteção automatizada e flexível, bem como maior visibilidade para ambientes híbridos e multi-cloud. A plataforma Trend Micro Cloud One inclui:

• Workload Security: proteção de tempo de execução para workloads (virtual, físico, nuvem e contêineres)

• Container Security: verificação de imagem de contêiner automatizada e de registro

• File Storage Security: segurança para serviços de armazenamento de arquivos e objetos em nuvem

• Network Security: segurança IPS da camada de rede em nuvem

• Application Security: segurança para funções serverless, APIs e aplicações

• Conformity: segurança em tempo real para infraestrutura em nuvem — proteja, otimize, esteja em conformidade

 

Indicadores de comprometimento

SHA-256	Nome do Arquivo	Detecção de padrão Trend Micro
4ad20bcd0f915acba7817e0639fcbf4f713beb8ac35112134808d4e5f753d519	create_account_dropped.sh	Trojan.SH.MALXMR.UWEKQ
86800f9e3b563eaeba1d84d431b83405b2118300c0ad2deab39a093d4b9093c5	kthreadd	Coinminer.Linux.MALXMR.PUWELO
96a64cccb55f7b42711015054ddd6ac45459643aa17c13248c6e344dc787cbfd	setup.sh	Coinminer.SH.MALXMR.UWEJW
aad97a08a139e8dff1f02f73479a5b00ecca5b512f627082f9c589fd63479c83	bioset	Trojan.Linux. ZYX.USELVLG20
b3daf217ca7339ad9e738f087135af8f63fd46f435711874ccb4bf8ab310f2e5	Daemon	N/A