Agente de AWS SSM podría ser utilizado como Troyano de tipo RAT

Investigadores de ciberseguridad han encontrado una nueva técnica de ataque en Amazon Web Services (AWS) que convierte al Agente de AWS Systems Manager (Agente SSM) en un troyano de acceso remoto que podría afectar a sistemas basados en Windows y Linux (los más utilizados mundialmente).

Esta técnica permite a los atacantes mantener un acceso persistente a la máquina comprometida, ya sea alojada en AWS u otro lugar, y llevar a cabo diversas actividades maliciosas.

¿Qué es el Agente SSM?

Es un servicio de administración que ayuda a los clientes a gestionar recursos de AWS y entornos locales desde una única interfaz. AWS Systems Manager proporciona una amplia gama de características para automatizar tareas operativas, realizar inventarios, mantener parches, configurar instancias, administrar políticas de conformidad y mucho más.

Explotación del Agente SSM

El uso de un Agente de SSM como troyano proporciona varias ventajas a los atacantes. En primer lugar, las soluciones de seguridad de end points confían en este agente, lo que evita la necesidad de implementar otro malware que pueda ser detectado fácilmente. Además, el atacante puede utilizar su propia cuenta de AWS maliciosa como comando y control (C2) para supervisar de forma remota al agente de SSM comprometido.

Para llevar a cabo estas técnicas posteriores a la explotación, el atacante debe contar con los permisos necesarios para ejecutar comandos en el punto final de Windows o Linux que tenga instalado y en funcionamiento en el Agente de SSM.

Métodos de ataque

Escenario 1 (Secuestro del Agente)

Una de las técnicas implica registrar el Agente de SSM para que se ejecute en modo "híbrido", lo que le permite comunicarse con cuentas de AWS diferentes a la cuenta original donde se aloja la instancia EC2. Esto habilita al agente de SSM para ejecutar comandos desde una cuenta de AWS propiedad del atacante.

Escenario 2 (Ejecución de otro proceso de Agente de SSM)

Otro enfoque utiliza la función de espacios de nombres de Linux para iniciar un segundo proceso del agente de SSM, el cual se comunica con la cuenta de AWS del atacante, mientras que el agente de SSM que ya está en ejecución sigue comunicándose con la cuenta de AWS original. Estas técnicas complican la detección y permiten al atacante mantener un control remoto y persistente sobre el sistema comprometido.

Detección según cada escenario

En el primer escenario de secuestro del Agente de SSM, se puede monitorear el cambio de datos de la instancia al registrar un nuevo agente, lo que genera una nueva ID de instancia y crea un nuevo directorio. Detectar más de un directorio con un nombre de instancia diferente a la ID original indica actividad sospechosa. También es posible monitorear los comandos bash/cmd y CreateProcess para ejecutar el binario "amazon-ssm-agent" con ciertas banderas sospechosas.

Para el segundo escenario, se debe comprobar si hay más de un proceso "amazon-ssm-agent" en ejecución, ya que solo debe haber una instancia activa a la vez.

En ambos escenarios, si el ataque se lleva a cabo desde la cuenta de AWS, se pueden detectar acciones sospechosas relacionadas con Sessions Manager en los registros de CloudTrail. Estas técnicas ayudan a identificar posibles intentos de ataque y mantener la seguridad en entornos de Amazon EC2.

Apreciación

La investigación de Mitiga ha puesto al descubierto un concepto de seguridad sumamente relevante e innovador en el ámbito de la ciberseguridad: el uso del agente Systems Manager (SSM) como troyano de acceso remoto (RAT) en sistemas Linux y Windows, lo cual permite el control mediante otra cuenta de AWS. Este aviso tiene como objetivo principal crear conciencia sobre la amenaza y su posible impacto en la seguridad de los endpoints. Los beneficios que implica emplear el agente SSM como RAT para un ciber actor, como el aprovechamiento de archivos binarios existentes, la utilización de una cuenta de AWS maliciosa para C&C y la explotación de las características del agente, conllevan riesgos significativos para la seguridad de los endpoints. Dado el amplio uso y la confianza asociada con el agente SSM, resulta imperativo que las organizaciones tomen medidas inmediatas para mitigar esta nueva técnica y salvaguardar sus sistemas y datos de posibles ataques.

El Centro de Ciberinteligencia de Entel CyberSecure recomienda lo siguiente:

Basándose en las recomendaciones emitidas por el equipo de seguridad de AWS considerar lo siguiente:

• Si el agente de SSM se agregó a la lista de permitidos en sus soluciones AV o EDR, se recomienda enfáticamente reconsiderar esta decisión. Dado el posible compromiso del agente de SSM como se mencionó, confiar únicamente en la lista de permitidos ya no es confiable. Por lo tanto, es recomendable eliminar los archivos binarios de SSM de la lista de permitidos. Al hacerlo, permite que su solución EDR examine y analice minuciosamente el comportamiento de estos procesos, buscando activamente cualquier indicación de actividad maliciosa o anomalía sospechosa.
• Para detectar y responder de manera efectiva a esta acción maliciosa, recomendamos seguir las técnicas de detección mencionadas anteriormente e integrarlas en sus plataformas SIEM (Security Information and Event Management) y SOAR (Security Orchestration, Automation and Response). Al implementar estas detecciones, mejora sus capacidades para buscar e identificar proactivamente instancias de esta amenaza.
• El equipo de seguridad de AWS ofreció una solución para restringir la recepción de comandos de la cuenta/organización de AWS original mediante el punto de enlace de la VPC (nube privada virtual) para Systems Manager (https://docs.aws.amazon.com/systems-manager/ más reciente/guía de usuario/setup-create-vpc.html). 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 de System Manager a través de un punto de enlace de la 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 original de AWS. Para implementar esta restricción de manera eficaz, consulte la documentación de la política de puntos de enlace de la VPC ( https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html).
• Proteger el protocolo RDP:
  • Deshabilite los servicios RDP, si no es necesario. La desactivación de servicios no utilizados e innecesarios ayuda a reducir su exposición a las vulnerabilidades de seguridad, y es una buena práctica de seguridad.
  • Si no es posible cerrarlos, límite las direcciones de origen que pueden acceder a los puertos.
  • Proteger el acceso a los sistemas RDP, bloqueando el sistema local en lugar del sistema remoto. Incluso si el primero no tiene valor, la sesión RDP solo estará protegida limitando el acceso al sistema cliente. 
  • Desconectar sesiones RDP en lugar de bloquearlas, esto invalida la sesión actual, lo que impide una reconexión automática de la sesión RDP sin credenciales. 
  • Bloquear bidireccionalmente el puerto TCP 3389 utilizando un firewall o hacerlo accesible sólo a través de una VPN privada. 
  • Habilitar la autenticación de nivel de red (NLA).
• Tener políticas de respaldo periódico que se almacenen fuera de la red organizacional.
• Escanear todos los archivos adjuntos, antes de abrirlos, con un antivirus que detecte comportamientos para combatir los ransomwares.
• Mantener una buena estrategia de respaldo de información: sistemas de copias de seguridad que deben estar aisladas de la red; y políticas de seguridad. Lo anterior permitirá neutralizar el ataque, restaurar las operaciones y evitar el pago del rescate.
• Actualizar los equipos con Windows y Linux a las últimas versiones.
• Mantener listas de control de acceso para las unidades mapeadas en red restringiendo los privilegios de escritura. Con esto podrá identificar el impacto generado por el cifrado de archivos, entendiendo que el secuestro de información se producirá en todas las unidades de red mapeadas en el equipo víctima.
• Seguir las normativas internacionales tales como ISO 27001:2013 en su control A.7.2.2 “Concienciación con educación y capacitación en seguridad de la información” o NIST PR.AT-1: “Todos los usuarios se encuentran entrenados e informados”, a fin de tener bases para divulgar campañas educativas orientadas a nivel de usuarios respecto al correcto uso de las herramientas tecnológicas, haciendo énfasis en cómo proceder al recibir correos de orígenes desconocidos, objeto prevenir que sus usuarios sean víctimas de entes maliciosos.