Durante las últimas semanas, una familia de ransomware emergente que se llama a sí misma Avos Locker ha estado intensificando los ataques mientras realiza un esfuerzo significativo para deshabilitar los productos de seguridad de endpoints en los sistemas que atacan.
En una serie reciente de incidentes que involucraban este ransomware, Sophos Rapid Response descubrió que los atacantes habían iniciado los ordenadores objetivo en modo seguro para ejecutar el ransomware, como lo habían hecho los operadores de las familias de ransomware Snatch, REvil y BlackMatter ahora desaparecidas, en ataques que ya hemos documentado aquí.
La razón de esto es que muchos, si no la mayoría, de los productos de seguridad para endpoints no se ejecutan en modo seguro, una configuración de diagnóstico especial en la que Windows deshabilita la mayoría de los controladores y software de terceros y puede hacer que las máquinas protegidas no sean seguras.
No es el ransomware de tu abuelo
Avos en portugués se traduce como “abuelo”, pero no es un ransomware para ancianos.
Los atacantes de Avos Locker no solo estaban reiniciando las máquinas en modo seguro para las etapas finales del ataque, también modificaron la configuración de arranque del Modo seguro para poder instalar y usar la herramienta comercial de administración TI AnyDesk mientras los ordenadores con Windows aún se ejecutaban en Modo seguro. Normalmente, el software de terceros se deshabilitaría en un ordenador que se ha reiniciado en modo seguro, pero estos atacantes claramente tenían la intención de continuar accediendo y controlando de forma remota las máquinas objetivo sin obstáculos.
No está claro si una máquina que se haya configurado de esta manera, con AnyDesk configurado para ejecutarse en Modo seguro, incluso sería administrable de forma remota por su propietario legítimo. El operador de la máquina puede necesitar interactuar físicamente con la computadora para poder administrarla.
En algunos casos, también hemos visto a los atacantes emplear una herramienta llamada Chisel, que crea un túnel a través de HTTP, con los datos cifrados mediante SSH, que los atacantes pueden usar como un canal de retorno seguro a la máquina infectada.
También hay otros indicios de que, en algunos de los ataques, hubo movimiento lateral y otros indicadores de comportamiento malicioso que se guardaron en los registros de eventos de algunas máquinas.
Por ejemplo, este archivo por lotes se creó en la misma máquina en la que se ejecutó, justo antes del ataque.
Y en este caso, hay una entrada de registro de eventos que muestra un script de PowerShell codificado en base64 que se está ejecutando, y los resultados se envían a un archivo llamado execute.bat, que luego se ejecuta y finalmente se elimina.
En otra entrada del Registro de eventos, hay un registro de un puerto configurado como proxy en la máquina objetivo, lo que teóricamente ayudaría a los atacantes a ocultar cualquier movimiento lateral al enrutar todos los comandos a través del ordenador proxy.
También estamos investigando el uso por parte de Avos de un componente de ransomware de Linux que se dirige a los servidores del hipervisor VMware ESXi al eliminar cualquier máquina virtual y luego cifrar los archivos de la máquina virtual. El comando anterior se utilizó para iterar y finalizar cualquier máquina virtual que se estuviera ejecutando en el hipervisor. Todavía no está claro cómo los atacantes obtuvieron las credenciales de administrador necesarias para habilitar ESX Shell o acceder al servidor en sí.
Los atacantes también parecen haber aprovechado otra herramienta comercial de administración de TI conocida como PDQ Deploy para enviar scripts por lotes de Windows a las máquinas que planeaban apuntar. Sophos Rapid Response ha creado un gráfico que destaca las consecuencias de la ejecución de uno de estos archivos por lotes. Los archivos por lotes se ejecutan antes de que el ordenador se reinicie en Modo seguro.
Estos scripts por lotes organizan las etapas de los ataques y sientan las bases para la fase final en la que los ciberdelincuentes implementan el ransomware Avos Locker. Uno de los scripts por lotes que recuperamos se llamó Love.bat (que se muestra arriba), que fue enviado a las máquinas en la red por el servicio PDQDeployRunner. También vimos archivos por lotes llamados update.bat o lock.bat con pequeñas variaciones en ellos.
Estos scripts de orquestación modificaron o eliminaron claves de registro que sabotearon de manera efectiva los servicios o procesos pertenecientes a herramientas de seguridad de endpoints específicas, incluido el Windows Defender integrado y software de terceros de compañías como Kaspersky, Carbon Black, Trend Micro, Symantec, Bitdefender y Cylance. La secuencia de comandos desactiva Windows Update e intenta desactivar los servicios de Sophos, pero la herramienta de protección contra manipulaciones evita que la secuencia de comandos por lotes tenga éxito.
Los atacantes también utilizaron el script por lotes para crear una nueva cuenta de usuario en la máquina infectada (newadmin) y darle una contraseña (password123456), y agregarla al grupo de usuarios Administradores. Luego configuran la máquina para que inicie sesión automáticamente cuando se reinicia en modo seguro. Los atacantes también desactivan ciertas claves de registro utilizadas por algunas redes para mostrar un “aviso legal” al iniciar sesión. La desactivación de estas funciones reduce la posibilidad de que el inicio de sesión automático falle porque un cuadro de diálogo que espera a que un humano haga clic en él está retrasando el proceso.
El penúltimo paso en el proceso de infección es la creación de una clave “RunOnce” en el Registro que ejecuta la carga útil del ransomware, sin archivos, desde donde los atacantes la han colocado en el Controlador de dominio. Este es un comportamiento similar a lo que hemos visto que IcedID y otros ransomware hacen como un método para ejecutar cargas útiles de malware sin permitir que los archivos toquen el sistema de archivos de la máquina infectada.
El último paso en el script por lotes es configurar la máquina para que se reinicie en modo seguro con conexión en red y deshabilitar cualquier mensaje de advertencia o ignorar fallos en el inicio. A continuación, el script ejecuta un comando para reiniciar el equipo, y la infección se pone en marcha. Si por alguna razón el ransomware no se ejecuta, el atacante puede usar AnyDesk para acceder de forma remota a la máquina en cuestión, y volver a intentarlo manualmente.
Detección
Trabajar en modo seguro dificulta aún más la tarea de proteger los ordenadores, ya que Microsoft no permite que las herramientas de seguridad de endpoints se ejecuten en modo seguro. Dicho esto, los productos de Sophos detectan por comportamiento el uso de varias claves Run y RunOnce Registry para hacer cosas como reiniciar en modo seguro o ejecutar archivos después de reiniciar. Hemos estado refinando estas detecciones para reducir los falsos positivos, ya que existen muchas herramientas y software completamente legítimos que utilizan estas claves de registro para operaciones normales.
El ransomware, especialmente cuando ha sido entregado personalmente (como ha sido el caso en estas instancias de Avos Locker), es un problema complicado de resolver porque uno necesita lidiar no solo con el ransomware en sí, sino con cualquier mecanismo que los ciberdelincuentes hayan establecido como una puerta trasera a la red objetivo. Ninguna alerta debe tratarse como de “baja prioridad” en estas circunstancias, por muy benigna que pueda parecer. El mensaje clave para los equipos de ciberseguridad que se enfrentan a un ataque de este tipo es que incluso si el ransomware no se ejecuta, hasta que todos los rastros de la implementación de AnyDesk de los atacantes desaparezcan de todas las máquinas afectadas, los objetivos seguirán siendo vulnerables a intentos repetidos. En estos casos, cuando los atacantes de Avos Locker configuran el acceso a la red de su organización usando AnyDesk, los atacantes pueden bloquear a los defensores o ejecutar ataques adicionales en cualquier momento siempre que las herramientas de acceso remoto de los atacantes permanezcan instaladas y en funcionamiento.
Varias actividades de los actores de amenazas fueron detectadas (y bloqueadas) por las reglas de detección de comportamiento Exec_6a y Exec_15a. La telemetría de Intercept X mostró que el mecanismo de protección CryptoGuard se invocó cuando los atacantes de ransomware intentaron ejecutar su ejecutable. Los productos de Sophos también detectarán la presencia de Chisel (PUA), PSExec (PUA) y PSKill (PUA), pero es posible que no bloqueen automáticamente estos archivos, según las políticas locales configuradas por el administrador de Sophos.
Agradecimientos
SophosLabs y Rapid Response agradecen la ayuda de Fraser Howard, Anand Ajjan, Peter Mackenzie, Ferenc László Nagy, Sergio Bestulic y Timothy Easton por su ayuda con el análisis y la respuesta a amenazas.
Dejar un comentario