Durante muchos años, los atacantes han pasado del uso de malware personalizado y automatizado a ataques que implican piratería práctica a través de utilidades que ya existen en las computadoras. Este enfoque, conocido como “vivir la tierra”, también se extiende a la infraestructura de la nube al aprovechar los servicios y herramientas que los proveedores ponen a disposición como parte de su ecosistema. Investigadores de la empresa de respuesta a incidentes Mitiga mostraron recientemente cómo el agente AWS Los atacantes podrían secuestrar Systems Manager (SSM) y transformarlo en un troyano de acceso remoto (RAT). El Agente SSM es una herramienta que los clientes del proveedor estadounidense pueden implementar en instancias EC2, servidores locales, así como máquinas virtuales en otras nubes para administrarlas y monitorearlas a través de su servicio Systems Manager.
“El concepto es simple: cuando un atacante logra con éxito la ejecución inicial en un punto final que ya tiene un agente SSM instalado, en lugar de descargar una puerta trasera o RAT comercial o local, puede explotarlo para controlar el terminal, convirtiéndolo efectivamente en una RAT. en sí mismo”, dijeron los investigadores de Mitiga en su informe. "Al ejecutar comandos desde una cuenta de AWS separada, propiedad de los atacantes, las acciones realizadas por el agente SSM permanecerán ocultas en la cuenta de AWS original, sin dejar rastro de la intrusión".
Los motivos para desviar a un agente del SSM
El Agente SSM es una poderosa herramienta para ejecutar comandos remotos y recopilar datos en la máquina, tal como lo haría un caballo de Troya. La diferencia es que el Agente SSM es de código abierto, está desarrollado y firmado digitalmente por Amazon y viene preinstalado en muchas instancias de máquina (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 del 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á incluido en la lista blanca de muchas soluciones antivirus o de detección y respuesta a incidentes (EDR) que podrían implementarse en un servidor administrado por AWS. Ninguno de los 71 motores antivirus de VirusTotal informó que el binario era malicioso.
Además, debido a que el Agente SSM se puede configurar para comunicarse con una cuenta de AWS específica, proporciona a los atacantes una opción simple de comando y control sin tener que desarrollar o implementar infraestructura adicional que normalmente se requeriría para alojar una interfaz de seguridad. Control de ratas. Todo lo que necesitan es una cuenta de AWS. En paralelo se podría utilizar la interfaz PowerShell, nativa de Windows y diseñada para automatizar tareas administrativas. Debido a que PowerShell es tan poderoso y viene con su propio lenguaje de secuencias de comandos, ha sido adoptado a lo largo de los años por una gran cantidad de atacantes, lo que obligó a Microsoft a agregar más y más advertencias, protecciones y alertas de seguridad. Sin embargo, todavía existen marcos completos de movimiento lateral y posterior a la explotación escritos en PowerShell, así como malware de código abierto.
Ejecutar múltiples instancias de agente SSM
Usar el agente SSM como caballo de Troya o puerta trasera no es una idea nueva. Otros ingenieros de la nube Y investigadores de seguridad han advertido sobre su potencial de abuso. Sin embargo, Mitiga fue más allá al mostrar cómo secuestrar el agente de formas más sutiles e incluso sin tener acceso de root. La forma más directa de abusar del agente SSM en un escenario posterior al compromiso 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 inicio de sesión. activación que lo vincularía a una cuenta de AWS controlada por el atacante y activaría su modo híbrido. En este caso, el agente podrá implementar un mecanismo de persistencia para reiniciar el sistema. El problema con este enfoque es que el propietario de la cuenta bajo la cual se ejecuta la instancia EC2 comprometida puede darse cuenta inmediatamente de que algo anda mal porque perderá el acceso SSM a esa máquina en su propia cuenta una vez que el agente haya sido desviado.
Para resolver este problema, Mitiga buscó formas de dejar intacto al agente original y ejecutar una segunda instancia maliciosa conectándose a la cuenta del atacante. Aunque el agente está diseñado para no ejecutarse si ya existe 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 iniciar sesión de forma remota para acceder a la máquina.
Implementación de un segundo proceso de agente SSM
En máquinas con Windows, los investigadores pudieron 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 implementar una segunda instancia de agente SSM sin tener privilegios de root en la máquina es usar la instancia de SSM existente y emitir comandos a través de ella para configurar la segunda, ya 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 utiliza para administrar la máquina a través de SSM. Dicho esto, la necesidad de tener una cuenta de AWS para controlar un agente SSM secuestrado no es necesariamente atractiva para todos los atacantes.
Primero, si usan la misma cuenta para controlar múltiples máquinas que pertenecen a diferentes víctimas, solo hace falta que uno de ellos descubra el compromiso, lo informe a AWS y la cuenta será suspendida. Resulta que el Agente SSM tiene dos opciones de configuración llamadas http_proxy y https_proxy que pueden usarse para enrutar el tráfico del Agente SSM a una dirección IP controlada por el atacante en lugar de a una dirección de Amazon. Los investigadores de Mitiga pudieron crear un servidor simulado que un atacante podría ejecutar por su cuenta para aprovechar la función RunCommand sin depender del servicio SSM de AWS.
Detectar y prevenir ataques de agentes SSM
Los investigadores publicaron algunos indicadores de compromiso que podrían usarse para detectar que se están ejecutando dos instancias de agente SSM. También recomiendan eliminar el agente SSM de la lista de permitidos de cualquier antivirus o solución EDR para poder analizar su comportamiento y agregar técnicas para detectar este tipo de secuestro a su solución SIEM.
"El equipo de seguridad de AWS proporcionó una solución para restringir la recepción de comandos de la cuenta/organización original de AWS mediante el punto final Nube Privada Virtual para Administrador de Sistemas “, dijeron 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 puerta de enlace NAT, aún puede configurar el servicio Systems Manager a través de un punto final de VPC. Al hacerlo, puede asegurarse de que las instancias EC2 solo respondan a los comandos de las entidades principales en su cuenta de AWS o su organización de origen. Para implementar esta restricción de manera efectiva, consulte la documentación relacionado con la política de endpoints de VPC”.
Otras noticias que te pueden interesar