Descubren el uso indebido del agente de AWS SSM como un troyano encubierto de acceso remoto

descubren el uso indebido del agente de AWS SSM como un troyano encubierto de acceso remoto

Investigadores de ciberseguridad han descubierto una nueva técnica de post-explotación en Amazon Web Services (AWS) que permite que el AWS Systems Manager Agent (SSM Agent) se ejecute como un troyano de acceso remoto en entornos Windows y Linux

Troyano de acceso remoto

“El agente SSM, una herramienta legítima utilizada por los administradores para administrar sus instancias puede ser reutilizado por un atacante que ha logrado un acceso de alto privilegio en un punto final con el agente SSM instalado, para llevar a cabo actividades maliciosas de forma continua”, dijeron los investigadores de Mitiga Ariel Szarf y Or Aspir.

“Esto permite a un atacante que ha comprometido una máquina, alojada en AWS o en cualquier otro lugar, mantener el acceso a ella y realizar diversas actividades maliciosas”.

El Agente de SSM es un software instalado en instancias de Amazon Elastic Compute Cloud (Amazon EC2), servidores locales y máquinas virtuales, lo que permite a los administradores actualizar, administrar y configurar sus recursos de AWS a través de una interfaz unificada.

Las ventajas de usar un Agente de SSM como troyano son múltiples, ya que las soluciones de seguridad de endpoints confían en él y elimina la necesidad de implementar malware adicional que puede desencadenar la detección. Para enturbiar aún más las aguas, un actor de amenazas podría usar su propia cuenta de AWS maliciosa como comando y control (C2) para supervisar de forma remota el agente de SSM comprometido.

Las técnicas posteriores a la explotación detalladas por Mitiga presuponen que un atacante ya tiene permisos para ejecutar comandos en el extremo de Linux o Windows que también tiene un Agente de SSM instalado y en ejecución.

Específicamente, implica secuestrar y registrar un agente de SSM para que se ejecute en modo “híbrido“, lo que le permite comunicarse con diferentes cuentas de AWS distintas de la cuenta de AWS original donde se aloja la instancia EC2. Esto hace que el Agente de SSM ejecute comandos desde una cuenta de AWS propiedad del atacante.

Un enfoque alternativo utiliza la característica de espacios de nombres de Linux para lanzar un segundo proceso del Agente de SSM, que se comunica con la cuenta de AWS del atacante, mientras que el agente de SSM que ya se está ejecutando continúa comunicándose con la cuenta de AWS original.

Por último, pero no menos importante, Mitiga descubrió que se puede abusar de la característica de proxy de SSM para enrutar el tráfico de SSM a un servidor controlado por el atacante, incluido un punto de enlace de cuenta que no sea de AWS, lo que permite al actor de amenazas comandar el agente de SSM sin tener que depender de la infraestructura de AWS.

Se recomienda a las organizaciones que eliminen los archivos binarios de SSM de la lista de permitidos asociada con las soluciones antivirus para detectar cualquier signo de actividad anómala y garantizar que las instancias EC2 respondan a los comandos que solo provienen de la cuenta de AWS original mediante el punto de enlace de Virtual Private Cloud (VPC) para Systems Manager.

“Después de controlar el SSM Agent, los atacantes pueden llevar a cabo actividades maliciosas, como el robo de datos, el cifrado del sistema de archivos (como ransomware), el mal uso de los recursos de los puntos finales para la minería de criptomonedas y el intento de propagarse a otros puntos finales dentro de la red, todo bajo el pretexto de usar un software legítimo, el SSM Agent”, dijeron los investigadores.

Related Post