pixabay rat 4075128 640

Pesquisadores alertam que AWS SSM pode ser usado como RAT

Da Redação
07/08/2023

Nos últimos anos, os cibercriminosos evoluíram do uso de malware automatizado personalizado para ataques que envolvem hacking prático por meio de utilitários que já existem nos computadores. Conhecida como living off the land (LotL, ou viver da terra, em tradução livre), essa técnica de ataque também se estende à infraestrutura de nuvem, aproveitando serviços e ferramentas que os provedores de nuvem disponibilizam como parte de seu ecossistema.

Pesquisadores da empresa de resposta a incidentes de nuvem Mitiga mostraram recentemente como o agente AWS Systems Manager (SSM) pode ser sequestrado por invasores e transformado em um trojan de acesso remoto (RAT). O agente SSM é uma ferramenta que os clientes da AWS podem implantar em instâncias EC2 (web service que disponibiliza capacidade computacional segura e redimensionável na nuvem), servidores locais, bem como máquinas virtuais em outras nuvens para habilitar seu gerenciamento remoto e monitoramento por meio do serviço Systems Manager nativo da AWS.

“O conceito é direto: quando um invasor obtém a execução inicial com sucesso em um endpoint que já possui um agente SSM instalado, em vez de fazer upload de um backdoor ou RAT comercial ou desenvolvido internamente, ele pode explorar o agente SSM existente para controlar o endpoint, efetivamente transformando-o em um RAT”, explicam os pesquisadores da Mitiga no relatório. “Ao executar comandos de uma conta separada da AWS de propriedade maliciosa, as ações executadas pelo agente SSM permanecerão ocultas na conta original da AWS, sem deixar vestígios da invasão.”

O agente SSM é uma ferramenta poderosa que permite a execução remota de comandos e a coleta de dados sobre a máquina, da mesma forma que um programa trojan faria. A diferença é que ele é de código aberto, desenvolvido e assinado digitalmente pela Amazon e pré-instalado em muitas Amazon Machine Images (AMIs) que os clientes podem implantar em suas instâncias do EC2, como Amazon Linux, SUSE Linux Enterprise, macOS e Windows Servidor. Também está presente em algumas imagens de sistema fornecidas por terceiros no AWS Marketplace ou desenvolvidas pela comunidade.

O principal benefício para os invasores é que o agente SSM já está na lista de permissões de muitas soluções de detecção e resposta de endpoint (EDR) ou antivírus que provavelmente serão implantadas em um servidor gerenciado pela AWS. Zero de 71 mecanismos antivírus do VirusTotal sinalizaram o binário como malicioso.

Além disso, como o agente SSM pode ser configurado para se comunicar com uma conta específica da AWS, ele oferece aos invasores uma opção fácil de comando e controle sem a necessidade de desenvolver ou implantar infraestrutura adicional que normalmente seria necessária para hospedar um painel de controle RAT. Tudo o que eles precisam é de uma conta da AWS.

Um paralelo seria a interface do PowerShell nativa do Windows e projetada para automatizar tarefas administrativas. Como o PowerShell é tão poderoso e vem com sua própria linguagem de script, ele foi adotado ao longo dos anos por um grande número de invasores, forçando a Microsoft a adicionar avisos, proteções e sinalizadores de segurança cada vez maiores. No entanto, ainda existem estruturas inteiras de pós-exploração e movimento lateral escritas em PowerShell, bem como malware de código aberto.

Usar o agente SSM como um trojan ou backdoor não é uma ideia nova. Outros engenheiros de nuvem e pesquisadores de segurança alertaram sobre seu potencial de abuso. No entanto, a Mitiga deu um passo adiante, mostrando como sequestrar o agente de maneiras mais sutis e até mesmo sem ter acesso root (com privilégio de administrador).

A maneira mais direta de explorar do agente SSM em um cenário pós-comprometimento em que o invasor já possui privilégios de root ou administrador na máquina é interromper o serviço e iniciá-lo com um novo código de ativação que o vincularia a uma conta da AWS controlada pelo invasor e ative seu modo híbrido. No modo híbrido, o agente configurará um mecanismo de persistência que permitirá que ele reinicie na reinicialização do sistema.

O problema com essa abordagem é que o proprietário da conta na qual a instância comprometida do EC2 é executada poderá dizer imediatamente que algo está errado porque perderá o acesso SSM a essa máquina em sua própria conta assim que o agente for sequestrado.

Veja isso
Anúncios do Google usados para phishing direcionado à AWS
AWS corrige falha em repositório de imagens de contêineres

Para resolver esse problema, a Mitiga procurou maneiras de deixar o agente original intocado e executar uma segunda instância que seria desonesta e se conectaria à conta do invasor. E embora o agente seja projetado para não ser executado se já houver um processo de agente SSM, isso pode ser ignorado de várias maneiras: aproveitando o recurso de namespaces do Linux para executar o agente em um namespace diferente ou ativando o modo “contêiner” para o segundo instância do agente que não requer privilégios de root. O modo contêiner é limitado porque não possui o módulo RunCommand, mas permite que invasores abram uma sessão remota para acessar a máquina.

Em máquinas Windows, os pesquisadores conseguiram iniciar um segundo processo de agente SSM configurando certas variáveis de ambiente para colocar a configuração em um local diferente. Ironicamente, uma maneira de implantar uma segunda instância do agente SSM sem ter privilégios de root na própria máquina é aproveitar a instância SSM existente e emitir comandos por meio dela para configurar a segunda, pois o agente já está sendo executado com altos privilégios. Isso requer acesso à conta da AWS da vítima que já está sendo usada para gerenciar a máquina por meio do SSM.

Dito isso, o requisito de ter uma conta da AWS para controlar um agente SSM sequestrado pode não ser atraente para todos os invasores. Primeiro, se eles usarem a mesma conta para controlar várias máquinas pertencentes a diferentes vítimas, basta um deles descobrir o comprometimento, denunciá-lo à AWS e a conta será suspensa.

Acontece que o agente SSM tem duas opções de configuração chamadas http_proxy e https_proxy que podem ser usadas para rotear o tráfego do agente SSM para um endereço IP controlado pelo invasor em vez de um Amazon. E os pesquisadores da Mitiga conseguiram criar um servidor fictício que um invasor poderia executar para aproveitar o recurso RunCommand sem realmente depender do serviço AWS SSM.

Os pesquisadores publicaram alguns indicadores de comprometimento que podem ser usados para detectar se duas instâncias do agente SSM estão em execução. Eles também recomendam remover o agente SSM da lista de permissões de qualquer solução antivírus ou EDR para que possam verificar seu comportamento e adicionar técnicas de detecção para tal sequestro à sua solução SIEM (Security Information and Event Management).

“A equipe de segurança da AWS ofereceu uma solução para restringir o recebimento de comandos da conta/organização original da AWS usando o endpoint VPC (Virtual Private Cloud) para o Systems Manager”, disseram os pesquisadores. “Se suas instâncias do EC2 estiverem em uma sub-rede privada sem acesso à rede pública por meio de um endereço EIP público ou gateway NAT, você ainda poderá configurar o serviço System Manager por meio de um VPC endpoint. Ao fazer isso, você pode garantir que apenas as instâncias do EC2 responda a comandos originados de principais em sua conta ou organização original da AWS. Para implementar essa restrição de maneira eficaz, consulte a documentação da política de VPC Endpoint.”

Compartilhar: