Unos investigadores advierten de que AWS Systems Manager se puede usar como RAT
El equipo de Mitiga descubre que se puede secuestrar el centro de operaciones para las aplicaciones y recursos de AWS y convertirlo en un troyano de acceso remoto difícil de detectar.
Desde hace muchos años, los atacantes han pasado de utilizar principalmente malware automatizado personalizado a ataques que implican piratería práctica a través de utilidades que ya existen en los ordenadores. Conocido como living of the land, este enfoque también se extiende a la infraestructura de la nube, aprovechando los servicios y herramientas que los proveedores de la nube ponen a disposición como parte de su ecosistema.
Investigadores de la empresa de respuesta a incidentes Mitiga han mostrado recientemente cómo el agente AWS Systems Manager (SSM) podía ser secuestrado por atacantes y convertido en un troyano de acceso remoto (RAT). El agente SSM es una herramienta que los clientes de AWS pueden implementar en instancias EC2, servidores locales y máquinas virtuales en otras nubes para permitir su gestión y monitorización remotas a través del servicio Systems Manager nativo de AWS.
"El concepto es sencillo: cuando un atacante logra la ejecución inicial en un punto final que ya tiene un agente SSM instalado, en lugar de cargar un backdoor o RAT comercial o desarrollado internamente por separado, puede explotar el agente SSM existente para controlar el punto final, convirtiéndolo efectivamente en un RAT en sí mismo", apuntan los investigadores de Mitiga en su informe. "Al ejecutar comandos desde una cuenta AWS separada, de propiedad maliciosa, las acciones llevadas a cabo por el agente SSM permanecerán ocultas dentro de la cuenta AWS original, sin dejar rastro de la intrusión", añaden.
Las ventajas de secuestrar un agente SSM
El agente SSM es una poderosa herramienta que permite la ejecución remota de comandos y la recopilación de datos sobre la máquina, de forma muy similar a como lo haría un programa troyano. La diferencia es que el agente SSM es de código abierto, está desarrollado y firmado digitalmente por Amazon, y está preinstalado en muchas imágenes de máquina de Amazon (AMI) que los clientes pueden implementar en sus instancias EC2, como Amazon Linux, SUSE Linux Enterprise, macOS y Windows Server. También está presente en algunas imágenes de sistema proporcionadas por terceros en AWS Marketplace o desarrolladas por la comunidad.
La principal ventaja para los atacantes es que el agente SSM ya está en la lista blanca de muchas soluciones de detección y respuesta de puntos finales (EDR) o antivirus que probablemente se implementen en un servidor gestionado por AWS. Cero de 71 motores antivirus de VirusTotal han marcado el binario como malicioso.
Además, dado que el agente SSM puede configurarse para comunicarse con una cuenta concreta de Amazon AWS, ofrece a los atacantes una opción sencilla de mando y control sin tener que desarrollar o desplegar la infraestructura adicional que se necesitaría normalmente para alojar un panel de control RAT. Todo lo que necesitan es una cuenta de AWS.
Un paralelismo sería la interfaz PowerShell nativa de Windows y diseñada para automatizar tareas administrativas. Dado que PowerShell es tan potente y viene con su propio lenguaje de scripting, ha sido adoptado a lo largo de los años por un gran número de atacantes, obligando a Microsoft a añadir cada vez más advertencias, protecciones y banderas de seguridad. No obstante, siguen existiendo frameworks completos de posexplotación y movimiento lateral escritos en PowerShell, así como malware de código abierto.
Ejecución de varias instancias del agente SSM
Utilizar el agente SSM como troyano o puerta trasera no es una idea nueva. Otros ingenieros de la nube e investigadores de seguridad han advertido sobre su potencial de abuso. Sin embargo, Mitiga ha ido un paso más allá al mostrar cómo secuestrar el agente de formas más sutiles e incluso sin tener acceso root.
La forma más directa de abusar del agente SSM en un escenario poscompromiso donde el atacante ya tiene privilegios de root o administrador en la máquina es detener el servicio e iniciarlo con un nuevo código de activación que lo vincularía a una cuenta de AWS controlada por el atacante y activaría su modo híbrido. En modo híbrido, el agente establecerá un mecanismo de persistencia que le permitirá volver a iniciarse al reiniciar el sistema.
El problema con este enfoque es que el propietario de la cuenta bajo la cual se ejecuta la instancia EC2 comprometida será capaz de darse cuenta de que algo va mal de inmediato, ya que perderá el acceso SSM a esa máquina en su propia cuenta una vez que el agente sea secuestrado.
Para resolver este problema, Mitigate ha buscado la forma de dejar intacto el agente original y ejecutar una segunda instancia que fuera maliciosa y se conectara a la cuenta del atacante. Y aunque el agente está diseñado para no ejecutarse si ya hay un proceso de agente SSM, esto se puede evitar de varias maneras: aprovechando la función de espacios de nombres de Linux para ejecutar el agente en un espacio de nombres diferente o habilitando el modo "contenedor" para la segunda instancia del agente, que no requiere privilegios de root. El modo contenedor es limitado porque no tiene el módulo RunCommand, pero permite a los atacantes abrir una sesión remota para acceder a la máquina.
Despliegue de un segundo proceso de agente SSM
En máquinas Windows, los investigadores han logrado iniciar un segundo proceso de agente SSM configurando ciertas variables de entorno para colocar la configuración en una ubicación diferente. Irónicamente, una forma de desplegar una segunda instancia de agente SSM sin tener privilegios de root en la propia máquina es aprovechar la instancia SSM existente y emitir comandos a través de ella para configurar la segunda, puesto que el agente ya se está ejecutando con privilegios elevados. Esto requiere acceso a la cuenta de AWS de la víctima que ya se está utilizando para administrar la máquina a través de SSM.
Dicho esto, el requisito de tener una cuenta AWS para controlar un agente SSM secuestrado podría no ser atractivo para todos los atacantes. En primer lugar, si utilizan la misma cuenta para controlar varias máquinas pertenecientes a diferentes víctimas, basta con que una de ellas descubra el peligro, lo comunique a AWS y la cuenta se suspenda.
El agente SSM tiene dos opciones de configuración llamadas http_proxy y https_proxy que se pueden utilizar para enrutar el tráfico del agente SSM a una dirección IP controlada por el atacante en lugar de una de Amazon. Y los investigadores de Mitiga han sido capaces de construir un servidor falso que un atacante podría ejecutar en su extremo para aprovechar la función RunCommand sin depender realmente del servicio AWS SSM.
Detección y prevención de ataques a través del agente SSM
Los investigadores han publicado algunos indicadores de compromiso que podrían utilizarse para detectar si se están ejecutando dos instancias del agente SSM. También recomiendan eliminar el agente SSM de la lista de permitidos de cualquier solución antivirus o EDR para poder analizar su comportamiento y añadir técnicas de detección de este tipo de secuestros a su solución SIEM.
"El equipo de seguridad de AWS han ofrecido una solución para restringir la recepción de comandos de la cuenta/organización original de AWS utilizando el punto final VPC (Virtual Private Cloud) para Systems Manager", cuentan los investigadores. "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 VPC. Al hacerlo, puede asegurarse de que las instancias EC2 solo respondan a comandos originados por los principales dentro de su cuenta u organización AWS original. Para implementar esta restricción de manera efectiva, consulte la documentación de la política VPC Endpoint".
