Amazon Web Services (AWS) tiene un nuevo enfoque posterior a la explotación que ha sido identificado por los investigadores. Esta técnica permite a los hackers utilizar el agente Administrador del sistema (SSM) de la plataforma como un troyano de acceso remoto (RAT) no detectado. Dado que el binario del agente de SSM ha sido firmado por Amazon, los sistemas de detección y respuesta de punto final (EDR) y los programas antivirus lo reconocen automáticamente como software confiable y autorizado. Como consecuencia de esto, la ejecución del agente SSM en calidad de RAT puede tener lugar sin que se activen inmediatamente alarmas o advertencias, evitando así el descubrimiento inicial.
Se recomienda emplear la idea del ataque en lugar del malware común y las puertas traseras, ya que es menos probable que el software de seguridad detecte su mal uso. El concepto de ataque fue desarrollado por expertos en seguridad de Mitiga afecta a las estaciones de trabajo Windows y Linux .
La idea detrás de esto es simple: un adversario que obtuvo acceso con privilegios elevados a un punto final que también tiene instalado el agente de SSM puede reutilizar el agente de SSM, que es una herramienta legal utilizada por los administradores para administrar sus instancias, a fin de llevar a cabo acciones maliciosas. operaciones de manera continua. Esto es posible ya que el agente de SSM se implementa en el punto final. Debido a esto, un adversario que haya obtenido acceso a una computadora alojada en Amazon Web Services (AWS) o en cualquier otro lugar puede continuar accediendo y participar en una variedad de comportamientos nefastos. Cuando un atacante usa el agente SSM de esta manera nefasta, en lugar de utilizar las variedades típicas de malware, que a menudo informa el software antivirus, el atacante puede beneficiarse de la reputación y la autenticidad de este binario, lo que ayuda al atacante a enmascarar sus huellas. .
El agente de SSM incluye funcionalidad compatible como “RunCommand” o “StartSession”, que permite a los atacantes administrar fácilmente el punto final hackeado desde su propia cuenta de AWS. Debido a estas cualidades, pueden alterar el punto final de la forma que deseen, lo que les otorga un amplio control sobre las operaciones del punto final.
Durante el curso de esta investigación , se concentraron en determinar si un agente de SSM es capaz de operar no solo en instancias de Amazon Elastic Compute Cloud (EC2), sino también en tipos de máquinas que no están asociadas con EC2. Hicieron uso de esta función al registrar un agente de SSM para operar en el modo “híbrido” a pesar de que el agente se estaba ejecutando en una instancia EC2.
El agente de SSM puede conectarse y ejecutar instrucciones desde una variedad de cuentas de AWS además de la cuenta de AWS principal que se utiliza para ejecutar la instancia EC2. Todo lo que se requiere es la ejecución de algunos comandos bash básicos. Debido a estos cambios, ahora tiene la capacidad de ejecutar varios procesos de agente de SSM dentro de un único punto final. Esto permite que el proceso del agente no autorizado funcione con nuestra cuenta de AWS, al mismo tiempo que permite que el otro proceso continúe trabajando con la cuenta de AWS inicial sin ningún obstáculo.
Además, al hacer un mal uso de la capacidad del proxy de SSM, pudieron hacer que el agente de SSM se conectara con un punto de enlace que no estaba asociado con una cuenta de AWS.
EXPLOTACIÓN
ESCENARIO 1: SECUESTRO DEL AGENTE SSM
En esta situación hipotética, el ataque consiste en “secuestrar” el proceso del agente de SSM original mediante el registro del agente de SSM para que se ejecute en modo “híbrido” con una cuenta de AWS independiente. El agente de SSM luego interactuará con la cuenta de AWS propiedad del atacante y ejecutará las órdenes recibidas del atacante.
ESCENARIO 2: EJECUCIÓN DE OTRO PROCESO DE AGENTE DE SSM [EJECUCIÓN DE OTRO PROCESO DE AGENTE DE SSM]
En este caso, el actor de amenazas inicia un segundo proceso de agente SSM. El agente de SSM original es entonces libre de continuar interactuando con la cuenta de AWS a la que se conectó originalmente mientras el proceso del agente malicioso interactúa con la cuenta de AWS del atacante.
En la plataforma Linux, puede hacer esto con la ayuda de los espacios de nombres de Linux. El atacante puede acceder a la capacidad “Ejecutar comando” ya que el proceso del agente SSM malicioso está en uso. Otro escenario implica operar el agente en modo “contenedor”, lo que permite al atacante aprovechar la capacidad de “Iniciar sesión” disponible a través de la interfaz de línea de comandos de AWS.
ADMINISTRAR EL AGENTE DE SSM CON UN SERVIDOR SIMULADO EN LUGAR DE UNA CUENTA DE AMAZON WEB SERVICES
Los actores de amenazas pueden encontrar más conveniente administrar agentes sin utilizar sus cuentas de AWS por una variedad de razones. Debido a que la gestión de riesgos real es esencial para cualquier campaña, es posible que les gustaría producir tráfico de red a su IP seleccionada en lugar de tener visibilidad de AWS en su C&C.
Durante el curso de su investigación, encontraron una función en SSM que tiene el potencial de ser explotada para redirigir el tráfico de SSM a un servidor controlado por un atacante. Esto haría posible utilizar el binario válido sin que el tráfico pase por los servidores de AWS. La alteración de los valores de las variables de entorno ‘http_proxy’ y ‘https_proxy’ permite que esta función se conecte al servidor mediante un proxy.
DETECCIÓN
Puede controlar cómo cambian los datos de la instancia en el primer escenario, que implica el enfoque de secuestro. Se asigna una nueva ID de instancia a un agente cada vez que se registra.
La información se puede encontrar en un nuevo directorio; en Linux, se encuentra en “/var/lib/amazon/ssm/i- “, mientras que en Windows, se encuentra en “C:ProgramDataAmazonSSMInstanceDatai- “. Si después del secuestro encuentra más de un directorio con un nombre de instancia diferente al que corresponde a la ID de instancia original, esto es motivo de preocupación. También monitorea los comandos bash/cmd o CreateProcess para iniciar el binario “amazon-ssm-agent” con los siguientes indicadores: “registro”, “código”, “id” y “región”. Puede identificar la ejecución del comando “secuestrar”. Además, puede verificar su cuenta de AWS para asegurarse de que la conexión con este agente haya finalizado.
Puede determinar si hay más de una instancia del siguiente proceso: “amazon-ssm-agent” mientras se ocupa del segundo caso. Se recomienda que solo ejecute una única instancia a la vez. Si hay dos o más de ellos, levanta más banderas rojas.
Si el ataque se lleva a cabo desde la cuenta de AWS (iniciando una sesión, ejecutando un comando o usando cualquier otro método para ejecutar código en EC2 desde la cuenta de AWS), debería poder ver actividades sospechosas que están conectadas a las sesiones. Manager en los registros de CloudTrail. Esto es cierto para ambos escenarios de ataque.
RECOMENDACIONES
- Se recomienda encarecidamente que vuelva a visitar esta opción si el agente de SSM se agregó a la lista de permitidos en sus soluciones antivirus o de detección y respuesta de puntos finales. Debido a que el agente SSM puede haber sido comprometido, como se mencionó anteriormente, ya no es confiable depender exclusivamente de la lista de permitidos. Como resultado, se recomienda enfáticamente eliminar los archivos binarios de SSM de la lista de aquellos que están permitidos. Hacerlo permite que su solución EDR lleve a cabo una investigación y un análisis exhaustivos del comportamiento de estos procesos, buscando activamente cualquier indicador de actividad maliciosa o comportamiento anómalo que pueda estar presente.
- Le proponemos que siga los enfoques de detección que se mencionaron anteriormente y los integre en sus plataformas SIEM (Security Information and Event Management) y SOAR (Security Orchestration, Automation and Response) para identificar y reaccionar de manera efectiva ante este comportamiento malicioso. Debido a que ha implementado estas detecciones, su capacidad para buscar e identificar proactivamente instancias de esta amenaza ha mejorado significativamente.
- El equipo de seguridad de AWS propuso una forma de limitar la aceptación de instrucciones de la cuenta u organización inicial de AWS mediante el uso del punto de enlace VPC (Nube privada virtual) para Systems Manager. De esta manera, puede garantizar que las instancias EC2 solo reaccionarán a las instrucciones que provengan de los principales dentro de su cuenta u organización original de AWS siguiendo los pasos descritos en esta sección.
Es especialista en ciberseguridad con más de 16 años de experiencia en seguridad de la información. Conoce muy bien la inteligencia de amenazas, la gestión de riesgos, la evaluación de vulnerabilidades y las pruebas de penetración, el análisis forense cibernético y la tecnología de seguridad en la nube (AWS, Azure, Google Cloud). Ocupó varios puestos de investigador de ciberseguridad en diferentes empresas. Tiene experiencia en diferentes industrias como finanzas, atención médica, marketing, gobierno, finanzas turísticas, aerolíneas, telecomunicaciones y biometría.