Ao investigar as atividades da equipe, encontramos um binário contendo um shell script codificado projetado para roubar credenciais da AWS, o que nos forneceu uma pista sobre o escopo do ataque.

Nós cobrimos o grupo de agentes de ameaça TeamTNT em entradas anteriores, observando que eles estavam ativamente roubando credenciais da Amazon Web Services (AWS), Docker e Linux Secure Shell (SSH), bem como participando de outras atividades, incluindo criptojacking e colocação de backdoors — como IRC bots e shells remotos — dentro de dispositivos Linux. No entanto, o escopo do ataque permaneceu desconhecido. Ao investigar as atividades da equipe, encontramos um binário contendo um shell script codificado projetado para roubar credenciais da AWS, o que nos forneceu uma pista sobre o escopo do ataque.

Figura 1: bot de IRC descartando shell script codificado (detectado como Backdoor.Linux.TSUNAMI.USELVBF21)

Começamos examinando o script descartado de um novo ladrão de credenciais com foco na AWS. Como mostra a imagem na Figura 2, depois que o agente compromete uma instância e executa seu script, ele procura quaisquer credenciais implantadas por meio do serviço de metadados da AWS, conforme destacamos anteriormente. Para coletar essas credenciais, o invasor deve efetuar a execução remota de código (RCE) no alvo inicial, o que pode ser realizado por meio de vários métodos, incluindo a exploração de problemas de configuração incorreta ou exploração de vulnerabilidades não corrigidas e outras falhas de segurança. Uma instância da AWS, por padrão, não tem nenhuma permissão de gerenciamento de acesso de identidade (IAM) anexada. Ao invés disso, essas permissões devem ser definidas pelo administrador da AWS. Os administradores da AWS precisam seguir o princípio do menor privilégio ao anexar funções a uma instância da AWS. Independentemente de a pesquisa ser bem-sucedida ou não, o script cria um arquivo e o carrega em um servidor de web remoto configurado para receber os arquivos roubados.

Figura 2. Shell scripts maliciosos que roubam informações

Embora o script deva ser executado em instâncias da AWS, nossa análise revela que ele foi executado em qualquer tipo de máquina Linux, contêiner ou instância de nuvem quando eles foram comprometidos por esse agente. Além disso, ele não conseguiu recuperar dados úteis na maioria das vezes.

O servidor da web onde o malware carrega seus dados foi configurado (ou mal configurado) para ser definido como um diretório aberto, permitindo assim o acesso a todos os arquivos carregados — incluindo dados sobre alvos a serem comprometidos, arquivos roubados e estatísticas de ataques em andamento.

Figura 3. Abra o diretório com malware, credenciais roubadas e estatísticas

Além de armazenar os dados roubados, o servidor também serve como repositório para as ferramentas de mineração de criptomoedas do Linux que o grupo implanta em sistemas infectados, o que faz parte de seus objetivos.

Figura 4. Outros binários encontrados no diretório aberto

Se o grupo conseguir executar seu script malicioso em uma instância da AWS, o script carrega todas as credenciais que ele pode recuperar do serviço de metadados da instância. Se um administrador da AWS não anexou nenhuma permissão a essas credenciais, ele não concederá ao invasor nenhum acesso adicional. Os administradores da AWS também podem detectar o uso dessas credenciais de instância fora da AWS ativando a descoberta UnauthorizedAccess: IAMUser/InstanceCredentialExfiltration no Amazon GuardDuty.

Figura 5. Exemplo de um relatório com segredos roubados

Conclusão e impacto

Durante nossa pesquisa, observamos mais de 4.000 casos infectados. Embora nem todos eles necessariamente sejam executados em instâncias da AWS, o malware que foi implantado contra eles foi projetado para visar os usuários dessa plataforma (devido ao shell script que procura metadados de serviços da AWS que estão presentes apenas com serviços desta). Do número total, cerca de 5% ou aproximadamente 200 deles continham informações confidenciais sobre clientes da AWS. Observe que suas instâncias não terão permissões definidas, a menos que o usuário especificamente tome medidas para tal.

Com base nos carimbos de data/hora nos nomes dos arquivos, podemos presumir que a campanha começou em 10 de fevereiro de 2021. Além disso, também podemos presumir que o número de arquivos representa o número de máquinas infectadas. Como resultado de observar o TeamTNT por um tempo, podemos notar que eles estão seguindo as tendências do setor de TI e mudando para a nuvem também.

Recomendações e soluções Trend Micro

Dado o maior foco em cloud por grupos de agentes de ameaças, as organizações devem tomar as medidas necessárias para proteger o máximo possível de sua infraestrutura de nuvem. A maioria dos provedores de serviços de nuvem, incluindo AWS, segue o modelo de responsabilidade compartilhada para defendê-la. Seguindo esse modelo, o provedor de cloud é responsável por proteger a infraestrutura — como hardware, software, rede e instalações — necessária para executar o serviço. Por outro lado, os administradores da AWS têm a responsabilidade de proteger seus ativos em execução no serviço em cloud. Embora as especificações sejam diferentes dependendo do tipo de serviço em nuvem que está sendo usado, geralmente se espera que os administradores da AWS protejam seus próprios dados, plataformas, aplicações, sistemas operacionais e configurações de rede, entre outros.

Conforme mencionado anteriormente, a equipe TNT tem como alvo provedores de serviços em nuvem e é capaz de comprometer as instâncias da AWS com base em vários métodos. Portanto, no modelo de responsabilidade compartilhada, o administrador da AWS é responsável por manter suas instâncias seguras. Aconselhamos as organizações a considerar as seguintes medidas de segurança:

• Corrigir e atualizar os sistemas regularmente para reduzir a chance de exploração da vulnerabilidade.

• Aplicar o princípio do menor privilégio, que ajuda a reduzir a superfície de ataque e minimiza o potencial de dano do mesmo. Para este ataque TeamTNT específico, conceder acesso às informações de segurança apenas para aqueles que precisam pode impedir que os agentes da ameaça vazem as informações.

• Priorizar o monitoramento contínuo e a auditoria de dispositivos, especialmente se eles forem usados para acessar a rede da organização.

• Usar a autenticação de chave privada quando tiver SSH ativado em sua instância.

• Usar senhas fortes e sempre habilitar a autenticação multifator em sua conta na nuvem.

A Amazon também oferece recomendações adicionais sobre como proteger os recursos da AWS, bem como serviços como Amazon Guard Duty, Amazon Macie e AWS Security Hub que aprimoram a segurança existente de implementações em nuvem.

Soluções de segurança como Trend Micro Hybrid Cloud Security também podem ajudar na proteção de sistemas nativos em nuvem e suas várias camadas. Ao usar a Trend Micro Cloud One™, as empresas obtêm acesso à proteção para integração contínua e pipeline de entrega contínua (CI/CD) e aplicações. 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 e proteção de tempo de execução de contêiner
• File Storage Security: segurança para arquivos em nuvem e serviços de armazenamento de objetos
• Network Security: camada de rede em nuvem para segurança do sistema de prevenção de intrusão (IPS)
•  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 (IOCs)