Los atacantes pueden convertir a los agentes de AWS SSM en troyanos de acceso remoto

Feb 16, 2024

Los investigadores de Mitiga han documentado una nueva técnica posterior a la explotación que los atacantes pueden utilizar para obtener acceso remoto persistente a instancias (servidores virtuales) de AWS Elastic Compute Cloud (EC2), así como a máquinas que no son EC2 (por ejemplo, servidores empresariales locales y servidores virtuales). máquinas y máquinas virtuales en otros entornos de nube).

El éxito de esta técnica de “vivir de la tierra” depende de:

“Después de controlar el Agente SSM, los atacantes pueden llevar a cabo actividades maliciosas, como el robo de datos, cifrar el sistema de archivos (como ransomware), hacer un mal uso de los recursos de los terminales para la minería de criptomonedas e intentar propagarse a otros puntos finales dentro de la red, todo bajo el pretexto de de utilizar un software legítimo, el SSM Agent”, explicaron los investigadores de Mitiga, Ariel Szarf y Or Aspir.

Los investigadores han probado dos escenarios diferentes y el nivel de acceso requerido para ambos es alto. En el primer escenario, el actor de amenazas requiere acceso root en la máquina Linux objetivo o privilegios de administrador en el sistema Windows objetivo, mientras que en el segundo debe poder ejecutarse como al menos un usuario con privilegios no root en la máquina Linux objetivo o como administrador en el sistema Windows de destino.

“[En el primer escenario], el ataque es 'secuestrar' el proceso original del Agente SSM al registrar el Agente SSM para que funcione en modo 'híbrido' con una cuenta de AWS diferente, lo que le obliga a no elegir el servidor de metadatos para el consumo de identidad. Luego, el agente SSM se comunicará y ejecutará comandos del atacante en la cuenta de AWS de su propiedad”, explicaron.

En el segundo escenario, el atacante ejecuta otro proceso del Agente SSM utilizando espacios de nombres de Linux o configurando variables de entorno específicas en Windows. "El proceso del agente malicioso se comunica con la cuenta de AWS del atacante, dejando que el agente SSM original continúe comunicándose con la cuenta de AWS original".

Y si el actor de la amenaza prefiere no utilizar una cuenta de AWS para administrar los agentes, no es necesario que lo haga: existe una característica de SSM de la que se puede abusar para enrutar el tráfico de SSM a un servidor controlado por el atacante (es decir, no a través de los servidores de AWS). ).

Convertir el Agente SSM en un troyano de acceso remoto permite a los atacantes comprometer los puntos finales sin ser detectados por las soluciones de seguridad instaladas. Las comunicaciones de C&C parecen legítimas, no es necesario desarrollar una infraestructura de ataque separada y el Agente SSM se puede utilizar para manipular el punto final a través de funciones compatibles.

El hecho de que el Agente SSM esté preinstalado en algunas imágenes populares de máquinas de Amazon y, por lo tanto, ya esté instalado y ejecutándose en muchas instancias EC2 existentes amplía el grupo de objetivos potenciales para los adversarios, señalaron los investigadores.

Afortunadamente, existen formas de detectar el uso de esta técnica, e incluyen estar atento a nuevos ID de instancia, el uso de comandos específicos, conexiones perdidas con agentes SSM en la cuenta de AWS, nuevos procesos y acciones sospechosas relacionadas con Sessions Manager. en los registros de Amazon CloudTrail.

Los investigadores aconsejan a los administradores de sistemas empresariales que:

“Creemos firmemente que los actores de amenazas abusarán de esto en ataques del mundo real, si es que no lo hacen ya. Por eso, comprender y mitigar los riesgos asociados con su uso indebido es crucial para proteger los sistemas de esta amenaza en evolución”, señalaron, y señalaron que el equipo de seguridad de AWS también ha ofrecido una solución para restringir la recepción de comandos del AWS original. cuenta/organización que utiliza el punto final de Virtual Private Cloud (VPC) para Systems Manager.

“Si sus instancias EC2 están en una subred privada sin acceso a la red pública a través de una dirección EIP pública o una puerta de enlace NAT, aún puede configurar el servicio System Manager a través de un punto final de VPC. Al hacerlo, puede asegurarse de que las instancias EC2 solo respondan a los comandos que se originan en los principales dentro de su cuenta u organización de AWS original. Para implementar esta restricción de manera efectiva, consulte la documentación de la política de VPC Endpoint.