Os invasores podem transformar agentes do AWS SSM em trojans de acesso remoto

Feb 16, 2024

Os pesquisadores da Mitiga documentaram uma nova técnica pós-exploração que os invasores podem usar para obter acesso remoto persistente a instâncias AWS Elastic Compute Cloud (EC2) (servidores virtuais), bem como a máquinas não EC2 (por exemplo, servidores corporativos locais e servidores virtuais). máquinas e VMs em outros ambientes de nuvem).

O sucesso desta técnica de “viver da terra” depende:

“Depois de controlar o Agente SSM, os invasores podem realizar atividades maliciosas, como roubo de dados, criptografar o sistema de arquivos (como um ransomware), usar indevidamente recursos de endpoint para mineração de criptomoedas e tentar propagar para outros endpoints dentro da rede – tudo sob o disfarce de usar um software legítimo, o Agente SSM”, explicaram os pesquisadores da Mitiga, Ariel Szarf e Or Aspir.

Os pesquisadores testaram dois cenários diferentes e o nível de acesso necessário para ambos é alto. No primeiro cenário, o agente da ameaça requer acesso root na máquina Linux alvo ou privilégios de administrador no sistema Windows alvo, enquanto no segundo ele deve ser capaz de executar pelo menos como usuário com privilégios não root na máquina Linux alvo ou como administrador em o sistema Windows de destino.

“[No primeiro cenário], o ataque está ‘sequestrando’ o processo original do Agente SSM, registrando o Agente SSM para trabalhar em modo ‘híbrido’ com uma conta AWS diferente, forçando-o a não escolher o servidor de metadados para consumo de identidade. Em seguida, o agente SSM se comunicará e executará comandos do invasor na conta AWS de propriedade”, explicaram.

No segundo cenário, o invasor executa outro processo do SSM Agent usando namespaces do Linux ou definindo variáveis ​​de ambiente específicas no Windows. “O processo do agente malicioso se comunica com a conta AWS do invasor, deixando o Agente SSM original continuar se comunicando com a conta AWS original.”

E se o autor da ameaça preferir não usar uma conta AWS para gerenciar os agentes, ele não precisa fazê-lo: há um recurso SSM que pode ser usado de forma abusiva para rotear o tráfego SSM para um servidor controlado pelo invasor (ou seja, não através dos servidores AWS ).

Transformar o SSM Agent em um trojan de acesso remoto permite que invasores comprometam endpoints sem serem detectados pelas soluções de segurança instaladas. As comunicações C&C parecem legítimas, não há necessidade de desenvolver uma infraestrutura de ataque separada e o Agente SSM pode ser usado para manipular o endpoint por meio de recursos suportados.

O fato de o Agente SSM estar pré-instalado em algumas imagens de máquinas populares da Amazon e, portanto, já estar instalado e em execução em muitas instâncias EC2 existentes amplia o conjunto de alvos potenciais para adversários, apontaram os pesquisadores.

Felizmente, existem maneiras de detectar o uso dessa técnica e incluem ficar atento a novos IDs de instância, ao uso de comandos específicos, conexões perdidas com agentes SSM na conta AWS, novos processos e ações suspeitas relacionadas ao Sessions Manager nos logs do Amazon CloudTrail.

Os pesquisadores aconselham os administradores de sistemas corporativos a:

“Acreditamos firmemente que os agentes de ameaças abusarão disso em ataques no mundo real, se já não o fizerem. Por isso, compreender e mitigar os riscos associados ao seu uso indevido é crucial para proteger os sistemas desta ameaça em evolução”, observaram, e apontaram que a equipe de segurança da AWS também ofereceu uma solução para restringir o recebimento de comandos do AWS original. conta/organização usando o endpoint Virtual Private Cloud (VPC) para Systems Manager.

“Se suas instâncias 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 endpoint VPC. Ao fazer isso, você pode garantir que as instâncias do EC2 respondam apenas aos comandos originados dos principais de sua conta ou organização original da AWS. Para implementar essa restrição de maneira eficaz, consulte a documentação da política do VPC Endpoint.