Sin rumbo y sin línea de comandos: cómo se mapeó un ataque de ransomware Akira

Agradecimientos: Un agradecimiento especial a Dray Agha por sus amplias contribuciones a esta investigación. 

Contexto

En septiembre, el agente de Huntress se implementó en una organización que había sido blanco de un ataque de ransomware Akira. Como hemos escrito anteriormente, el agente de Huntress a veces se implementa después de que un atacante ya accedió o comprometió el entorno. Esto a veces sucede como respuesta a un incidente; otras veces, una organización todavía está implementando el agente cuando se descubre el compromiso. 

De cualquier forma, una instalación del agente posterior al compromiso puede limitar la telemetría de EDR importante del acceso inicial, el reconocimiento previo, la persistencia o el robo de credenciales que ocurrieron antes de la instalación. Sin embargo, que un flujo de telemetría esté limitado no significa que no existan pistas importantes en otros lugares que puedan ayudar a construir una imagen de lo que sucedió durante el incidente. 

En este incidente, los investigadores de Huntress pudieron reunir múltiples fuentes al estilo arqueológico, incluyendo datos del registro, archivos de registro de Akira y más, para mapear lo que sucedió durante algunas partes del ataque. 

Por ejemplo, incluso sin una línea de comandos de ransomware registrada, la línea de tiempo ofrece evidencia sólida de ejecución: los Shellbags muestran que el actor de amenazas accedió a la carpeta, un archivo de registro de Akira indica que el ransomware la tuvo como objetivo, y un comando de PowerShell concurrente eliminó las copias de sombra de volumen, una acción común de Akira.

El incidente: con qué trabajamos

Después de que el agente de Huntress se instaló a principios de septiembre, se generó una señal de EDR en un controlador de dominio, detectando apenas la punta del iceberg de la actividad. Como se ve en la Figura 1, la señal muestra que svchost.exe se ejecutó desde el directorio C:\PerfLogs\Temp\ bajo la cuenta SYSTEM, cargando config.dll.

Figura 1: Una señal de EDR que alerta sobre actividad del actor de amenazas después de que el agente de Huntress se instaló tras el compromiso 

Vale la pena notar que esta señal indica una parte del ataque en el momento posterior a la instalación del agente de Huntress. Si se hubiera instalado antes, el agente habría detectado otros indicadores de actividad maliciosa. Esto habría ayudado a alertar a la organización de que estaban siendo atacados, para que pudieran actuar sobre el incidente y detenerlo. Pero desde el punto de vista de la investigación, también nos daría una comprensión más profunda de lo que sucedió: qué estaba haciendo el actor de amenazas y cómo logró entrar en primer lugar, lo cual ayudaría a informar a la organización afectada sobre en qué áreas enfocarse durante la remediación.

La investigación

Ante la falta de telemetría y detecciones de EDR, nuestros investigadores tuvieron que arreglárselas con lo que estaba disponible en los endpoints afectados: una mezcla de artefactos del registro de Windows, registros de eventos de Windows y archivos de registro de Akira. Sin embargo, estos artefactos ayudaron a construir una imagen de la actividad del actor de amenazas. 

Los registros de eventos de Windows mostraron que el actor de amenazas accedió al endpoint afectado a través de Terminal Services/RDP, desde una estación de trabajo que no pertenecía al cliente. Poco después, el actor de amenazas accedió a la consola de BitDefender, y varios servicios de Windows asociados con la aplicación antivirus se detuvieron:

Service Control Manager/7036;Bitdefender Endpoint Update Service,stopped

Service Control Manager/7036;Bitdefender Endpoint Integración Service,stopped

Service Control Manager/7036;Bitdefender Endpoint Protected Service,stopped

Service Control Manager/7036;Bitdefender Endpoint Security Service,stopped

Luego, se ejecutó procdump.exe desde la carpeta C:\PerfLogs, presuntamente para realizar un robo de credenciales volcando el contenido del proceso lsass.exe. Esto luego implementó la herramienta de túnel GOST.

Túnel GOST 

Unas cuatro horas después de iniciar los procesos de cifrado de archivos, el actor de amenazas implementó una herramienta de túnel GOST para persistencia. 

GOST (Go Simple Tunnel) es una herramienta de proxy/túnel de red de código abierto (escrita en Go). Es popular para configurar túneles y proxies seguros, lo que puede ayudar a los usuarios a evitar restricciones de red, conectar servicios de forma segura entre redes o reenviar tráfico. Sin embargo, la flexibilidad de GOST (al admitir múltiples protocolos que incluyen cifrado integrado y permitir el encadenamiento de proxies con cifrado) la convierte en una herramienta lucrativa para los actores de amenazas. 

La Figura 1 anterior ilustra la línea de comandos asociada con el lanzamiento del túnel GOST. 

La Figura 2 ilustra el contenido del archivo config.dll.

Figura 2: Config.dll contenido del archivo

La Figura 3 ilustra los resultados de buscar el hash de svchost.exe en VirusTotal.

Figura 3: resultados de VirusTotal

Los atacantes podrían potencialmente usar GOST de varias maneras, incluyendo el túnel de comando y control (C2) (esencialmente retransmitiendo el tráfico de C2 a través de hosts intermediarios comprometidos para dificultar el rastreo del verdadero servidor C2). En 2024, los investigadores de Google Mandiant informaron que un presunto actor con vínculos con China, UNC5330, usó un proxy GOST para ayudar a facilitar la implementación de herramientas maliciosas en endpoints, por ejemplo. 

Los investigadores previamente han señalado el uso de GOST en ataques de afiliados de Akira. Y, como ha señalado CISA, también se ha descubierto que los afiliados de Akira establecen comunicaciones de C2 con otras utilidades de tunelización como Ngrok para iniciar sesiones cifradas que intentan evitar el monitoreo perimetral.

Después de implementar el túnel GOST, el actor de amenazas lanzó RClone desde la carpeta C:\PerfLogs. Anteriormente hemos visto a atacantes usar RClone como un método para la exfiltración de datos, para sincronizar archivos con la nube.

Cifrado de archivos

Los artefactos del Registro de Windows, específicamente los Shellbags, mostraron que el actor de amenazas luego accedió a varias subcarpetas dentro de una carpeta Shares antes de lanzar el primer comando de Akira. 

Sin telemetría de procesos, los analistas de Huntress tuvieron que depender de artefactos de "marca de herramienta" que mostraban los efectos de los procesos. Este tipo de artefactos de "marca de herramienta" son rastros distintivos que las herramientas de los atacantes dejan en un sistema, debido a cómo operan. En este caso, los analistas de Huntress vieron una línea de comandos en los registros de eventos de PowerShell que indicaba que el ransomware se había lanzado:

powershell.exe -Command Get-WmiObject Win32_Shadowcopy , Remove-WmiObject

Curiosamente, esta línea de comandos coincidió con la creación de un archivo de registro de Akira, lo que indica que el ransomware se había lanzado contra la carpeta Shares. 

Menos de un minuto después, los artefactos de Shellbags indicaron que el actor de amenazas revisó una de las subcarpetas de la carpeta Shares a través del Explorador de Windows, probablemente para asegurarse de que el proceso de cifrado estuviera avanzando según lo planeado. 

Esos mismos artefactos mostraron que esta secuencia de eventos ocurrió tres veces más: el actor de amenazas lanzaba el ransomware, se creaban artefactos de PowerShell asociados con el lanzamiento junto con el archivo de registro de Akira, y luego el actor de amenazas accedía a la carpeta de destino a través del Explorador de Windows para asegurarse de que el cifrado hubiera sido exitoso. 

Guía de mitigación

Los defensores pueden tomar varias medidas para evitar esta amenaza, entre ellas: 

• Mantener un inventario completo y preciso de activos, tanto de sistemas físicos como virtuales, así como de aplicaciones. 

• Realizar una reducción de la superficie de ataque, limitando lo que tienes que monitorear y mantener. 

• Para el acceso remoto que deba estar expuesto, asegúrate de implementar la autenticación multifactor (MFA).

• Monitorear los sistemas a los que se accede desde estaciones de trabajo desconocidas, sospechosas y conocidas como maliciosas.

• Monitorear carpetas como C:\PerfLogs en busca de actividad sospechosa, como la creación de archivos o la creación y el lanzamiento de nuevos ejecutables.

Indicadores de compromiso (IOC)