0
0
Os pesquisadores da Mitiga documentaram uma nova técnica de 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 de:
- Os invasores obtendo acesso inicial à máquina (por exemplo, explorando uma vulnerabilidade não corrigida em uma instância/servidor voltada para o público) e
- A presença do SSM Agent, um componente de software que os administradores de sistemas corporativos usam para gerenciar os endpoints da conta da AWS usando o serviço AWS System Manager
“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 criptomoeda e tentar se propagar para outros endpoints dentro da rede – tudo sob o disfarce de usar um software legítimo, o SSM Agent”, explicaram os pesquisadores da Mitiga, Ariel Szarf e Or Aspir.
Cenários possíveis
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 de destino ou privilégios de administrador no sistema Windows de destino, enquanto no segundo ele deve ser capaz de executar pelo menos como usuário privilegiado não root na máquina Linux de destino 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 funcionar no modo ‘híbrido’ com uma conta diferente da AWS, obrigando-o a não escolher o servidor de metadados para consumo de identidade. Em seguida, o SSM Agent se comunicará e executará comandos do invasor na conta de propriedade da AWS”, 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 da AWS do invasor, deixando o Agente SSM original continuar se comunicando com a conta original da AWS.”
E se o agente da ameaça preferir não usar uma conta da AWS para gerenciar os agentes, ele não precisa: há um recurso SSM que pode ser abusado para rotear o tráfego SSM para um servidor controlado pelo invasor (ou seja, não por meio dos servidores da AWS ).
Detecção e prevenção
Transformar o SSM Agent em um trojan de acesso remoto permite que os invasores comprometam os 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 SSM Agent pode ser usado para manipular o terminal por meio de recursos suportados.
O fato de o agente SSM estar pré-instalado em algumas imagens populares de máquina da Amazon e, portanto, já estar instalado e em execução em muitas instâncias EC2 existentes amplia o conjunto de possíveis alvos para adversários, apontaram os pesquisadores.
Felizmente, existem maneiras de detectar o uso dessa técnica e incluem ficar de olho em novos IDs de instância, uso de comandos específicos, conexões perdidas com agentes SSM na conta da 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:
- Remova o binário do SSM Agent da lista de permissões de suas soluções AV e EDR, para que possam ser examinados e o comportamento dos processos analisado quanto a comportamento anômalo/suspeito
- Integre as técnicas de detecção descritas em suas plataformas SIEM e SOAR para ajudar na busca de ameaças.
“Acreditamos firmemente que os agentes de ameaças abusarão disso em ataques no mundo real, se é que já não o fazem. Por isso, entender e mitigar os riscos associados ao seu uso indevido é crucial para proteger os sistemas dessa ameaça em evolução”, observaram, destacando 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 o Systems Manager.
“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 as instâncias do EC2 respondam apenas 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 do VPC Endpoint .
FONTE: HELP NET SECURITY