No início deste ano, vimos como o grupo de cibercrimes TeamTNT atacou APIs Docker expostas usando o minerador de criptomoeda XMRig. Com o tempo, observamos como o TeamTNT expandiu a funcionalidade de seus ataques, que passaram a incluir o roubo de credenciais de secure shell (SSH) da Amazon Web Services (AWS) e um comportamento de autorreplicação para propagação.
Aqui, discutimos o último ataque do TeamTNT, que envolve o uso do bot IRC (Internet Relay Chat) do próprio grupo. O bot IRC é chamado TNTbotinger e é capaz de negação de serviço distribuída (distributed denial of service ou DDoS).
É importante observar que os invasores devem primeiro ser capazes de realizar a execução remota de código (remote code execution ou RCE) na máquina de destino inicial para iniciar com sucesso este ataque em um sistema. Agentes mal-intencionados podem executar RCE explorando problemas de configuração incorreta, abusando de vulnerabilidades não corrigidas e aproveitando falhas de segurança, como senhas e chaves fracas ou reutilizadas, ou credenciais vazadas.
Análise técnica
A propagação inicial começa com um script de shell malicioso que é executado na máquina da vítima. O shell script verifica a presença do arquivo /dev/shm/.alsp, que também pode ser um indicador de comprometimento. Se o arquivo não for encontrado, o script começa a fazer seu trabalho.
Figura 1. O script malicioso verifica a presença do arquivo /dev/shm/.alsp em um sistema
O script tentará instalar os pacotes curl, wget, bash, make, gcc e pnscan.
Figura 2. O script malicioso tenta instalar pacotes curl, wget, make, gcc e pnscan
Por causa dos gerenciadores de pacotes usados no script malicioso, especificamente apt-get e yum, assumimos que os autores implementaram suporte para distribuições Linux baseadas em Debian e Red Hat.
O script tentará baixar e executar vários binários, incluindo pnscan, uma ferramenta usada para verificação de portas. Essa ferramenta também é baixada manualmente, caso não seja encontrada no diretório esperado.
A seguir estão os binários executados neste ataque:
- /dev/shm/sbin
- /usr/bin/tshd
- /usr/bin/kube
- /usr/bin/bioset
Depois, o script rouba várias informações confidenciais do sistema infectado, como:
- Chaves RSA (Rivest-Shamir-Adleman) usadas para acesso SSH (path da AWS incluído)
- Bash history
- Arquivos de configuração AWS e Docker
- Grupo /etc, /etc/passwd, /etc/shadow, /etc/gshadow
Os agentes mal-intencionados farão upload dessas informações roubadas usando um arquivo TGZ (tar.gz) por meio de uma solicitação HTTP POST para um URL fornecido pelo invasor. Suspeitamos que as informações coletadas servirão como base de conhecimento para a melhoria dos ataques subsequentes.
Figura 3. Informações roubadas de uma máquina infectada são carregadas por meio de um arquivo TGZ para um URL malicioso
O script também tenta encontrar dispositivos acessíveis, com base na saída do comando ip route, que mostraria rotas para redes acessíveis. Essa informação é então passada para a ferramenta pnscan para uma varredura dos daemons SSH ativos na rede. As chaves encontradas no sistema são usadas para tentativas de autenticação nos dispositivos recém-descobertos. Se essas tentativas forem bem-sucedidas, o mesmo payload é implantado nos novos dispositivos e o ataque se propaga.
Figura 4. O script malicioso executa uma varredura de daemons SSH ativos em uma rede infectada e tenta usar chaves roubadas para acessar dispositivos conectados à rede
Uma análise mais detalhada dos binários relevantes
A plataforma de destino binária é composta por CPUs baseadas no conjunto de instruções x86-64. A primeira camada de todos esses binários é compactada pelo conhecido UPX packer.
/dev/shm/sbin
O binário é compilado usando o compilador Go e contém um arquivo ELF (Formato Executável e de Ligação ou Executable and Linkable Format) que usa criptografia AES (Padrão de Criptografia Avançada ou Advanced Encryption Standard). Presumimos que o packer usado seja uma versão Go do LaufzeitCrypter.
Figura 5. Um binário compilado por Go que contém um arquivo ELF criptografado por AES
Depois de descriptografar o arquivo, encontramos o payload final do binário: um minerador de criptomoedas XMRig.
/usr/bin/tshd
Este shell é ligado à porta 51982 do TCP (Transmission Control Protocol ou Protocolo de Controle de Transmissão). A comunicação é criptografada com uma chave embutida em código.
Figura 6. O shell ligado à porta TCP 51982
/usr/bin/bioset
Este é um shell ligado à porta TCP 1982. A comunicação é criptografada usando o algoritmo de criptografia Blowfish com uma chave embutida em código. Após análise, descobrimos que esta implementação não funciona corretamente em algumas plataformas. O binário também renomeia seu nome de processo para systemd.
Figura 7. O shell ligado à porta TCP 1982
/usr/bin/kube
Este binário é compilado em Go e contém um arquivo ELF criptografado por AES. Ele é carregado dinamicamente durante a execução e o mesmo compactador com a versão Go do LaufzeitCrypter é usado. A chave AES e o vetor de inicialização (initialization vector ou IV) são codificados permanentemente no binário.
O payload desse binário é um bot IRC, que os autores chamaram de TNTbotinger. Este bot apresenta os seguintes comandos DDoS:
Comando DDoS | Função |
PAN <target> <port> <secs> | Um flooder SYN avançado que finaliza a maioria dos drivers de rede |
UDP <target> <port> <secs> | Um flooder UDP (User Datagram Protocol) |
UNKNOWN <target> <secs> | Nonspoof UDP flooder |
RANDOMFLOOD <target> <port> <secs> | Um flooder SYN-ACK |
NSACKFLOOD <target> <port> <secs> | Um flooder ACK de nova geração |
NSSYNFLOOD <target> <port> <secs> | Um flooder SYN de nova geração |
SYNFLOOD <target> <port> <secs> | Um flooder SYN clássico |
ACKFLOOD <target> <port> <secs> | Um flooder ACK clássico |
GETSPOOFS | Um comando que obtém o spoofing atual |
SPOOFS <subnet> | Um comando que muda o spoofing para uma sub-rede |
KILLALL | Um comando que elimina todas as formações de pack atuais |
TNTbotinger também tem os seguintes comandos de bot IRC:
Comando do bot IRC | Função |
NICK <nick> | Altera o nickname do cliente |
SERVER <server> | Altera servidores |
IRC <command> | Envia um comando para o servidor |
DISABLE | Desativa todas as formações de pack do cliente |
ENABLE | Ativa todas as formações de pack do cliente |
KILL | Elimina o cliente |
VERSION | Solicita a versão do cliente |
HELP | Mostra o arquivo de ajuda |
GET <http address> <save as> | Baixa um arquivo da web e o salva em um disco |
UPDATE <http address> <src:bin> | Atualiza o bot |
HACKPKG <http address> <bin name> | Instala um binário sem dependências |
Este bot também possui os seguintes comandos de shell Unix:
Comando shell Unix | Função |
SH <command> | Executa um comando |
ISH <command> | Permite que os recursos de um sistema operacional sejam disponibilizados para usuários interativos |
SHD <command> | Executa um comando daemonizado |
BASH <command> | Executa um comando usando Bash (se aplicável) |
SYSINFO | Coleta informações e relatórios sobre a configuração, instalação e uso do sistema |
RSHELL <server> <port> | Abre shell remoto |
Conclusão e recomendações de segurança
O cenário de ameaças do Linux está em constante evolução. Este último ataque do TeamTNT é um bom exemplo de como todo o segmento de rede, incluindo a nuvem, pode ser comprometido por agentes mal-intencionados. Estamos vendo o quão sério eles são em garantir as taxas de sucesso e estabilidade aumentadas de seus ataques, como evidenciado aqui pelo uso de binários wget/curl do TeamTNT para implantação de payload e uso de redundância de shell de ligação.
Em um ataque de TNTbotinger bem-sucedido, os invasores serão capazes de se infiltrar no sistema infectado. Uma vez dentro, eles serão capazes de ver instâncias vulneráveis em segmentos de rede acessíveis e podem executar RCE em dispositivos que deveriam ser protegidos do mundo externo.
É importante que as empresas adotem práticas de segurança rigorosas, como as seguintes, para manter seus sistemas seguros:
- Implemente políticas que priorizem o monitoramento e auditoria contínuos de dispositivos, especialmente aqueles usados para acessar a rede do escritório.
- Siga o princípio do menor privilégio ao conceder permissões.
- Corrigir e atualizar sistemas regularmente para reduzir a exposição a vulnerabilidades e outras ameaças críticas.
- Certifique-se de que as senhas sejam fortes. Altere as senhas padrão e ajuste as configurações de segurança com base nas necessidades da empresa.
Soluções Trend Micro
A solução Trend Micro Network Defense preserva a integridade das redes, evita violações e ataques direcionados e garante que dados críticos, comunicações, propriedade intelectual e outros ativos intangíveis não sejam explorados por agentes mal-intencionados. Ela fornece um sistema de prevenção de intrusões (intrusion prevention system ou IPS) de última geração, detecção de anomalias, análise de área restrita personalizada e percepção de ameaças.
Soluções de segurança específicas para nuvem, como a Trend Micro Hybrid Cloud Security, podem ajudar a proteger os sistemas nativos da nuvem e suas várias camadas. Ela é alimentada pela plataforma de serviços de segurança Trend Micro Cloud One™ para quem desenvolve em nuvem, que fornece proteção automatizada para aplicações e o pipeline de integração contínua e entrega contínua (CI/CD). Também ajuda a identificar e resolver problemas de segurança mais rapidamente e a melhorar o tempo de entrega para as equipes de DevOps. A plataforma Trend Micro Cloud One inclui:
- Workload Security: proteção de tempo de execução para workloads
- Container Security: varredura avançada de imagem de contêiner, controle de admissão baseado em políticas e proteção de tempo de execução de contêiner
- 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
Nome do Arquivo | Funcionalidade | SHA-256 | Detecção de Trend Micro |
SSH | Shell script dropper, uploader | D9C46904D5BB808F2F0C28E819A31703F5155C4DF66C4C4669F5D9E81F25DC66 | Trojan.SH.MALXMR.UWEKQ |
sbin | XMRig | E52646F7CB2886D8A5D4C1A2692A5AB80926E7CE48BDB2362F383C0C6C7223A2 | Trojan.Linux.BTCWARE.A |
tshd | Bind shell
(TCP port 51982) |
252BF8C685289759B90C1DE6F9DB345C2CFE62E6F8AAD9A7F44DFB3C8508487A | Backdoor.Linux.REKOOBE.AA |
kube | IRC bot | B666CD08B065132235303727F2D77997A30355AE0E5B557CD08D41C9ADE7622D | Trojan.Linux.MALXMR.UWEKY |
bioset | Bind shell (TCP port 1982) | E15550481E89DBD154B875CE50CC5AF4B49F9FF7B837D9AC5B5594E5D63966A3 | Trojan.Linux.MALXMR.UWEKW |