Agradecimientos: un agradecimiento especial a Michael Tigges por sus extraordinarias contribuciones para esclarecer este incidente.

Contexto

En agosto, Huntress incorporó a una organización después de un incidente, tras la implementación exitosa del ransomware INC. La organización se vio ampliamente afectada (en al menos 175 endpoints) y se encontraron rastros de la actividad de los atacantes en sus controladores de dominio. 

Como lo detallamos antes, las investigaciones posteriores a un incidente limitan nuestra visibilidad de lo ocurrido, porque la telemetría de EDR durante el ataque en sí —que da información valiosa sobre el comportamiento malicioso que activó las detecciones— no está disponible. Ese fue el caso de este incidente: no pudimos ver el panorama completo, porque partes del entorno ya estaban afectadas antes de que empezara la investigación. Sin embargo, los investigadores de Huntress pudieron armar varias partes del ataque que dieron una idea de lo que hicieron los atacantes después de obtener el acceso inicial. Eso incluyó fragmentos de una herramienta BYOVD encontrada en un controlador de dominio y varias tareas programadas con nombres aleatorios.

La actividad observada incluyó varios elementos destacables. Se extendió desde principios hasta finales de agosto, con una pausa de 17 días en el medio. Esto plantea la posibilidad de que la actividad fuera el resultado de distintos actores de amenazas o grupos, uno posiblemente un agente de acceso inicial (IAB), y el otro claramente un afiliado de ransomware. Además, mientras investigábamos la organización, encontramos no una, sino dos notas de rescate que los atacantes habían dejado. 

Notas de rescate

La nota de rescate inicial (INC-README.txt) era representativa de una nota de rescate típica que solemos encontrar en este tipo de incidentes. Los atacantes amenazaron con publicar los datos de la organización víctima si no pagaba, e incluyeron otras secciones, como una en la que afirmaban: "We are not a politically motivated group and we want nothing more than money. If you pay, we will provide you with decryption software and destroy the stolen data."

Figura 1: Extracto de la primera nota de rescate

Los analistas de Huntress también encontraron una segunda nota de rescate que había sido dejada unos 53 minutos después, llamada DATALEAK_PRESS_RELEASE.txt. Aquí, los actores de amenazas amenazaron con publicar un "comunicado de prensa" sobre la víctima si no recibían respuesta en 48 horas. La nota parecía ser un intento adicional de presionar a las víctimas para que pagaran, y los atacantes también advirtieron que empezarían a notificar a los medios, empleados, socios y clientes.

Figura 2: Extracto de la segunda nota de rescate

Cabe notar que se encontraron múltiples copias de la segunda nota de rescate, y todas resultaron ser idénticas, según los hashes de archivo. El resto de la segunda nota de rescate contenía un listado detallado de las rutas de archivos buscadas, los archivos robados, con descripciones detalladas de su contenido. Si suponemos que las afirmaciones de la segunda nota de rescate sobre el contenido de los archivos son verdaderas, esto probablemente significa que el actor de amenazas tuvo bastante tiempo no solo para encontrar y recuperar los datos, sino también para desarrollar una comprensión bastante completa y detallada de lo que robó. 

Ambas notas de rescate ejercieron presión continua sobre la víctima. Además de intentar dar credibilidad al grupo de ransomware o afiliado, las notas de rescate suelen amenazar con una escalada, mediante el aumento de precios, la pérdida permanente de datos, filtraciones públicas de los datos robados, o incluso contactar a clientes o socios.

De vuelta al inicio

Misterios en la cronología

Gran parte de los datos en varios endpoints se habían desvanecido u "oxidado" por el paso del tiempo, ya que algunos registros se "rotaron" mientras el endpoint seguía funcionando y usándose a un ritmo operativo normal. Debido a esto, los investigadores de Huntress no pudieron descubrir el vector de acceso inicial usado en este ataque. 

Sin embargo, aún quedaban varios fragmentos del ataque que los investigadores pudieron recopilar al examinar la telemetría de Huntress EDR y los registros de eventos de Windows disponibles. Pudimos rastrear la actividad maliciosa en los endpoints afectados hasta al menos principios de agosto. Esto incluyó la creación de varias tareas programadas y rastros observables de movimiento lateral. Luego, se identificó una segunda "oleada" de actividad dos semanas después, cuando se instaló AnyDesk como forma de implementar netscan.exe, un controlador vulnerable y varias herramientas. Poco después, se dejaron notas de rescate de INC en el controlador de dominio de la organización.

Dado el momento y las diferencias de actividad entre lo ocurrido a principios y a finales del mes, es posible que la actividad fuera el resultado de distintos actores de amenazas o grupos, uno posiblemente un IAB, y el otro claramente un afiliado de ransomware.

La primera fase del ataque: tareas programadas y movimiento lateral 

Durante el curso de la investigación, descubrimos varias tareas programadas con nombres aleatorios, que probablemente estaban destinadas a ayudar al actor de amenazas a lograr persistencia y habilitar otras partes de su ataque. Uno de los primeros rastros de actividad que encontramos ocurrió a principios de agosto, cuando se registró originalmente la tarea programada Nonweighise\Cancellationizing\Illuminateers, con la descripción "nationhood kinestheticization preironish fictionallyes". Esta tarea programada apuntaba al siguiente implante de PowerShell:

C:\ProgramData\Vendettister\jocularities.ps1

Este script de PowerShell estaba fuertemente ofuscado y se comunicaba con el dominio throughoutes[.]net.  

Durante este período de principios de agosto, también observamos actividad de movimiento lateral mediante una cuenta de usuario comprometida. En concreto, se observó que la cuenta se movía entre endpoints mediante el protocolo de escritorio remoto (RDP). 

Después del registro de la tarea programada y del movimiento lateral, no parecieron existir indicios de ninguna actividad significativa adicional en los endpoints en los que se había implementado el agente de Huntress durante los siguientes 17 días. 

La siguiente fase del ataque: evidencia de ataque BYOVD, notas de rescate

También descubrimos actividad de finales de agosto, donde se registraron tareas programadas adicionales en varios endpoints, mediante la misma cuenta de usuario comprometida que se observó asociada con el movimiento lateral. 

En un endpoint, una tarea programada apuntaba a C:\Program Files\7-Zip\HealthUpdater.exe, que era un ejecutable de vRx renombrado de Vicarius Inc. La herramienta vRX se describe como "una plataforma de ciberseguridad centrada en la remediación que ayuda a los equipos de TI y seguridad a encontrar, priorizar y corregir vulnerabilidades de software". Cabe notar, sin embargo, que se implementó en una carpeta/ruta inusual, y el ejecutable fue renombrado, aunque la información de versión del archivo en el ejecutable no contenía el nombre de archivo original. 

Finalmente, se observó la instalación de la aplicación de escritorio remoto AnyDesk, con una dirección IP de comando y control (C2) de 213.111.185[.]108, en uno de los endpoints. A través de esta instancia de AnyDesk, se implementaron tanto netscan.exe como un BYOVD en varios endpoints. BYOVD es una táctica común en la que los atacantes cargan un controlador legítimo pero vulnerable para obtener acceso a nivel de kernel, por lo general para desactivar las herramientas de seguridad antes de continuar con el compromiso. En este caso, la telemetría de Huntress detectó fragmentos de las herramientas BYOVD; en concreto, se encontró hwau.exe en C:\Users\Public en un controlador de dominio. Esto se usó para cargar un servicio de controlador de kernel (HwAudio) en C:\Users\Public\HWAuidoOs2Ec.sys.

Los atacantes usaron la utilidad de ejecución remota atexec.py de Impacket para ejecutar herramientas en múltiples endpoints mediante la creación y ejecución de tareas programadas temporales. Las tareas se usaron para instalar el controlador que elimina EDR/AV y lanzar el ransomware INC.

Tras la implementación del ransomware, apareció la nota de rescate INC-README.txt, que se ha observado en incidentes similares, así como una segunda nota de rescate, DATALEAK_PRESS_RELEASE.txt, que contenía información muy detallada sobre los datos robados del entorno.

Evidencia sobreviviente y puntos de presión

Incluso cuando los equipos de respuesta llegan después de que se implementó el ransomware, la evidencia que queda puede seguir contando una historia importante. En este incidente, los analistas de Huntress usaron la telemetría y los datos de eventos de Windows que quedaron para reconstruir varias actividades: la persistencia temprana y el movimiento lateral, la implementación de AnyDesk, una herramienta BYOVD diseñada para desactivar los controles de seguridad y el payload del ransomware INC.

Las dos notas de rescate añadieron otra capa al ataque. La segunda nota, con su recuento detallado de los archivos presuntamente robados y las amenazas de contactar a las partes interesadas de la víctima, muestra cómo los operadores de ransomware siguen perfeccionando la presión que ejercen sobre las víctimas más allá del cifrado.

Aunque no se pudo determinar el vector de acceso inicial, la investigación subraya el valor de preservar y revisar cada artefacto disponible después de un incidente. Las tareas programadas, las herramientas de acceso remoto, los servicios de controladores, los registros de eventos e incluso las notas de rescate pueden ayudar a los defensores a entender la progresión de una intrusión, evaluar el alcance del compromiso y fortalecer su respuesta para el próximo ataque.

Las organizaciones pueden dificultar la ejecución de ataques de ransomware al limitar y supervisar el acceso remoto, exigir la autenticación multifactor (MFA) y restringir las cuentas privilegiadas solo a los sistemas que necesitan. Los equipos también deben vigilar tareas programadas inusuales, herramientas de administración remota inesperadas, servicios de controladores nuevos o sin firmar, y actividad diseñada para desactivar productos de seguridad. Por último, deben mantener copias de seguridad probadas y fuera de línea, y un plan de respuesta a incidentes que incluya procedimientos de aislamiento rápido, para que una intrusión pueda contenerse antes de que los atacantes tengan tiempo de moverse lateralmente, robar datos e implementar ransomware.

Tabla de IoC