Los MSP son uno de los objetivos principales del ransomware Akira y Lynx

Resumen

• La Unidad de investigación de amenazas (TRU) de Acronis analizó muestras recientes de las familias Akira y Lynx para observar los últimos cambios y ajustes implementados por los delincuentes.

• Akira y Lynx comparten un modelo de ransomware como servicio (RaaS) y tácticas de doble extorsión.

• Se cree que Lynx es incorporan elementos del código fuente filtrado de LockBit, y Akira comparte similitudes con Conti (que también influyó en LockBit), lo que sugiere un origen común en su base de código.

• Comprometen sistemas mediante credenciales robadas, vulnerabilidades de VPN, reconocimiento, elevación de privilegios, evasión de defensas y exfiltración/cifrado de datos, y atacan sobre todo a pymes con métodos reutilizados pero sofisticados.

• Los grupos delictivos desactivan el software de seguridad, eliminan las instantáneas y borran los registros de eventos para evitar la detección y dificultar la recuperación.

• Dato curioso: una muestra del ransomware Lynx que analizamos puede imprimir una nota de rescate en impresoras conectadas.

Introducción

En nuestros esfuerzos continuos para rastrear bandas de ransomware y sus actividades, destacamos tres grupos que sobresalieron en el primer trimestre de 2025 y en los que no profundizamos en nuestra investigación anterior: Akira y Lynx.

• Akira ha atacado a más de 220 víctimas, entre las que se incluyen muchas pequeñas empresas como bufetes de abogados, empresas de contabilidad y compañías de construcción. También han dirigido sus ataques a algunos proveedores de servicios gestionados (MSP), como Hitachi Vantara[1] y Toppan Next Tech.[2]
• Lynx ha atacado a unas 145 víctimas. Su estrategia de ataques a gran escala indica que las pequeñas empresas suelen ser su blanco principal, aunque apenas se conocen casos concretos. Un caso que sí nos consta es un ataque a una estación de televisión afiliada a CBS con sede en Chattanooga, Tennessee.[3]

[1] https://www.bleepingcomputer.com/news/security/hitachi-vantara-takes-servers-offline-after-akira-ransomware-attack/

[2] https://www.holdings.toppan.com/en/info/toppan_info20250408.pdf

[3] https://www.scworld.com/brief/cbs-affiliate-purportedly-compromised-by-lynx-ransomware-gang

Aunque no todas las víctimas son MSP, estas bandas no hacen distinciones a la hora de elegir cuál será su siguiente "presa". Están listas para atacar a cualquier organización que prometa una recompensa económica atractiva. Dicho esto, los MSP suelen ser los principales objetivos de los ciberdelincuentes porque a través de ellos se puede acceder a una red más amplia de clientes, lo que multiplica la posible recompensa.

Profundicemos en cada una de estas bandas de ransomware:

1. El resurgir imparable del ransomware Akira

2. El ransomware Lynx acecha mas quenunca a las empresas privadas. 

El ransomware Akira surgió en 2022 con un número reducido de operaciones. En 2023 entró en la lista de las 10 principales bandas de ransomware, ya que perpetró 174 ataques en ese año. A raíz de analizar ese pico de actividad, se detectó que sus muestras compartían muchas similitudes con el ransomware Conti. Conti estaba vinculado al grupo de amenazas ruso llamado Wizard Spider, que en 2022 sufrió una fuga de datos que incluía código fuente y mensajes entre sus miembros. Después de ese incidente, Wizard Spider se disolvió. Aún se desconoce si Akira es una reaparición bajo otra identidad del grupo Wizard Spider o un nuevo grupo delictivo que utiliza código filtrado. En 2024, Akira volvió a situarse en la lista de las 10 principales bandas de ransomware por número de ataques (315 víctimas conocidas).

Al inicio de sus operaciones, el ransomware Akira utilizó ataques de phishing y aprovechó algunas vulnerabilidades, incluida Cisco CVE-2023-20269, para obtener acceso a las víctimas. En 2024, Akira se centró principalmente en las VPN de los usuarios al aprovechar diversas vulnerabilidades, incluida SonicWall Firewall CVE-2024-40766, que permitía a los atacantes desactivar firewalls y conectarse a las infraestructuras objetivo.

En 2025, la Unidad de investigación de amenazas (TRU) detectó que los operadores de Akira estaban utilizando credenciales de administrador robadas o compradas para intentar obtener acceso a máquinas y servidores. Cuando lo conseguían, desactivaban el software de seguridad. Cuando fracasaban, lanzaban una exfiltración remota y, a continuación, procedían al cifrado mediante herramientas legítimas que suelen estar en listas blancas y no se escanean ni supervisan.

Tras obtener acceso, los atacantes llevaron a cabo la recopilación de información adicional, realizaron desplazamientos laterales y ejecutaron la activación del cifrador. Además, antes de cifrar los archivos, los operadores de Akira archivaron y exfiltraron los archivos de las víctimas a sus servidores como parte de un esquema de doble extorsión.

La muestra analizada es un archivo PE64 escrito en C/C++ y compilado mediante las herramientas de compilación de Visual Studio. Este archivo se vio por primera vez en circulación a finales de 2024.

La ejecución comienza en la función WinMain, que es extensa y contiene una gran cantidad de código. Al inicio de la función, obtiene la fecha y hora actuales del sistema y genera un archivo de registro en la misma carpeta en la que se ejecutó.

A continuación, la muestra obtiene argumentos de la línea de comando y los compara con la lista guardada. En la siguiente tabla se incluyen los comandos admitidos y su descripción:

Después de guardar valores de los argumentos, la muestra obtiene todas las unidades lógicas disponibles en el sistema. Cada unidad se verifica según su tipo. Si coincide con el valor de una unidad de red y se pasa el argumento "-localonly", esta unidad se omitirá.

El siguiente paso es obtener una lista de todos los procesos que se ejecutan en el sistema. Para ello, la muestra utiliza la función "WTSEnumerateProcess". Esta función se utiliza principalmente para enumerar procesos en servidores remotos, pero Akira utiliza el valor "NULL" como argumento de identificador, lo que significa que esta función enumerará procesos en el sistema local.

A continuación, carga algunos símbolos en un búfer, que posteriormente se descifrará en el bucle. Como resultado, se genera el comando de PowerShell. Este comando eliminará todas las instantáneas mediante el objeto WMI.

A continuación, la muestra establece la información de autenticación que se utilizará para realizar llamadas en el equipo local. Aquí utiliza "CoSetProxyBlanket" con los siguientes argumentos:

●      dwCapabilities = 0 --> Sin indicador de capacidades.

●      pAuthInfo = NULL --> DCOM utiliza la identidad del proxy actual (que puede ser el token del proceso o el token de suplantación).

●      dwImpLevel = 3 --> El proceso del servidor puede suplantar el contexto de seguridad del cliente mientras actúa en nombre del cliente.

●      dwAuthLevel = 3 --> Autentica únicamente al inicio de cada llamada a procedimiento remoto cuando el servidor recibe la solicitud.

●      pServerPrincName = NULL --> Sin autenticación mutua.

●      dwAuthzSvc = NULL --> Sin autorización.

●      dwAuthSvc = NULL --> Sin autenticación.

A continuación, la muestra carga cadenas que se utilizarán en las importaciones desde la biblioteca "fastprox.dll", que es un "marshaller" personalizado de WMI. También utiliza algunas importaciones de la biblioteca COM "wbemprox.dll". Tanto COM como WMI se utilizan aquí para controlar privilegios y ejecutar comandos de Powershell descodificados.

Después de ejecutar el comando, la muestra llama a la función "GetSystemInfo" y comienza a crear hilos. Crea tres tipos diferentes de hilos con distintos números de hilo:

El número de hilos de cifrado depende directamente del número de CPU del ordenador, el cual se obtiene mediante "GetSystemInfo". Por ejemplo, en un ordenador con seis procesadores lógicos, crea dos hilos para analizadores de carpetas, y los otros cuatro se utilizarán para el cifrado. Esos números se escriben en el archivo de registro.

Akira utiliza tanto llamadas a la API de Windows como funciones de CRT (tiempo de ejecución de C) en la rutina de cifrado de archivos. Para iterar a través de carpetas en el sistema, crea un iterador de directorios.

Cuando se encuentra cualquier archivo, realiza una búsqueda de dos símbolos en su nombre: "\" y ".". Esta operación se utiliza para determinar si un archivo es una carpeta. Si el archivo es una carpeta, la muestra comparará su nombre con la lista guardada. Si el nombre coincide, la carpeta se omitirá del cifrado. Si el archivo no es una carpeta, la muestra encontrará su extensión al buscar el último símbolo "." en su nombre y también la comparará con las extensiones guardadas.

Las siguientes carpetas y extensiones de archivo están excluidas del cifrado, ya que podría causar una interrupción en el funcionamiento del sistema: $Recycle.Bin, System Volume Information, Boot, ProgramData, Windows, temp, .dll, .exe, .akira

Cualquier otro archivo se abrirá con derechos de acceso "GENERIC_ALL". La muestra obtiene el resultado de esta operación mediante la función "GetLastError". A continuación, el último código de error se compara con el valor "20h" (32 en decimal), que es el error "ERROR_SHARING_VIOLATION". Si coincide, la muestra llama a una función que finalizará el proceso que bloquea el archivo en cuestión.

Para finalizar procesos, la muestra utiliza la API de Restart Manager. Después de crear una sesión, registra un recurso, que es un nombre de archivo bloqueado. A continuación, la muestra encuentra una lista de procesos que ejecutan ese archivo. Antes de terminar los procesos de esta lista, la muestra obtiene su propio PID para excluirse a sí misma de la terminación.

Akira utiliza ChaCha20 para cifrar archivos. Si el porcentaje de archivo se proporcionó como un argumento, Akira calculará cuántos datos debe leer. Utiliza constantes mágicas predefinidas, que dependen del tamaño de la clave y que en este caso siempre es 256.

Después de que los datos cifrados se escriban, realiza una operación de escritura adicional mediante un búfer de 512 bytes (200 en hexadecimal). Contiene una clave de cifrado ChaCha20, cifrada con RSA.

En las primeras versiones de Akira, se empleaba un algoritmo de cifrado del ransomware Conti modificado, que utilizaba ChaCha20 y RSA. Aunque las últimas muestras utilizan los mismos cifrados, en las primeras versiones, los ciberdelincuentes cometieron un error en la implementación de algoritmos al generar una clave solo una vez durante la ejecución. Lo cual provocó que cada archivo cifrado tuviera el mismo flujo de claves, y, de esta forma, permitió a las empresas de ciberseguridad crear un descifrador. Posteriormente, Akira mejoró su esquema de cifrado y esta clave ahora se genera para cada archivo por separado. La versión de Linux también utiliza ChaCha20 para cifrar archivos, pero utiliza la biblioteca CryptoPP, mientras que las versiones de Windows contienen implementaciones de cifrado en la muestra sin utilizar bibliotecas externas.

Tras una intensa actividad en 2024, Akira continúa operando en 2025. Aunque la muestra analizada comparte algunas similitudes con el código fuente filtrado de Conti, está evolucionando y se ha convertido en una de las amenazas más peligrosas de este año. Por último, no queda claro cuánto tiempo concede Akira a sus víctimas para pagar el rescate, ya que las notas de rescate solo revelan que el precio se calcula por cada víctima, en función de los datos robados, que pueden incluir información bancaria. La Unidad de investigación de amenazas (TRU) pudo documentar un caso en el que los datos de una víctima se divulgaron en menos de cinco días tras el ataque exitoso de Akira.

SHA256

88da2b1cee373d5f11949c1ade22af0badf16591a871978a9e02f70480e547b2

URL

https://akiral2iz6a7qgd3ayp3l6yub7xx2uep76idk3u2kollpj5z3z636bad.onion

https://akiralkzxzq2dsrzsrvbr2xgbbu2wgsmxryd4csgfameg52n7efvr2id.onion

Observado por primera vez a mediados de 2024, Lynx comparte muchas similitudes con el ransomware INC, que TRU analizó en 2023. Lynx actúa en calidad de grupo de ransomware como servicio (RaaS), y busca constantemente a más afiliados. Para ello, publica anuncios en foros clandestinos rusos con el fin de captar a nuevos colaboradores. En sus anuncios publicados, Lynx afirma que su objetivo son únicamente empresas del sector privado, que dispone de su propio generador de ejecutables personalizados del ransomware (su propio "builder"), que es compatible con versiones de Windows y Linux, y que proporciona un servicio para almacenar archivos robados. Además, los afiliados tendrán acceso al panel de administración del sitio de filtración de datos.

En abril de 2024, un usuario en un foro clandestino publicó una oferta para vender tres copias del generador del ransomware INC por "300 000" (posiblemente rublos) cada una. La funcionalidad descrita en la publicación es similar a las muestras analizadas del ransomware INC, pero se desconoce si era código fuente real de INC.

Poco después, apareció el ransomware Lynx. Debido a que el grupo de ransomware INC aún sigue activo en 2025, es poco probable que simplemente cambiara su nombre. Lo más probable es que Lynx haya comprado el generador del ransomware INC en los foros clandestinos y haya ajustado el código.

Traducción del ruso:

"Vendo el código fuente del ransomware INC para solo 3 compradores.

aes-ctr-128 + curve25519-donna

IOCP, la versión de Linux es la misma, tiene una compilación ESXI compatible con todos los sistemas

Panel: React, backend: Node.js + TypeScript, todo empaquetado en Docker; puede iniciarse con un solo comando, sin complicaciones".

Lynx suele utilizar correos electrónicos de phishing para entregar su malware a las víctimas. Cuando los atacantes obtienen acceso a los ordenadores de las víctimas, primero recopilan información del sistema y de la infraestructura, intentan obtener credenciales de usuario y realizan desplazamiento lateral para infectar más ordenadores de la misma red. Tener acceso a los ordenadores de las víctimas también permite a los atacantes investigar el software instalado y buscar posibles vulnerabilidades que posteriormente puedan aprovecharse para ejecutar el ransomware.

En algunos ataques en lo que llevamos de 2025 (al momento de escribir este artículo), hemos observado que si Lynx encuentra algún software de seguridad, su modus operandi es intentar desinstalarlo.

Cuando se realiza este paso, los atacantes primero exfiltran archivos a los servidores y luego activan el cifrador.

La muestra analizada es un archivo PE32, escrito en C\C++. No está empaquetado ni ofuscado.

La muestra admite múltiples comandos. Cada comando y su descripción se guarda en el código:

Después de obtener los argumentos de la línea de comando, la muestra de Lynx los compara con los que tiene guardados. Para los que coincidan, la muestra asignará el valor correspondiente a "1". Para los que no coincidan, la muestra asignará el valor "0". El resultado se guardará en la variable global.

Cuando un argumento requiere información adicional, como la ruta del directorio en el argumento "--dir", Lynx también guarda estos datos mediante un desplazamiento adicional desde la cadena de la línea de comando.

Si se pasa el argumento "--verbose", la muestra de Lynx dará como resultado información diferente, como configuraciones, el estado de algunas operaciones y el progreso del cifrado.

Este argumento obligará a las muestras de Lynx a buscar y montar cualquier unidad oculta en el sistema. Aquí carga una lista guardada de letras de unidad y comienza a verificar cada una. Cuando se encuentra cualquier unidad, comprueba si su tipo es "DRIVE_NO_ROOT_DIR". Si el tipo coincide, lo monta mediante la función "SetVolumeMountPointW".

Lynx utiliza dos métodos para la terminación de procesos; ambos se habilitan mediante argumentos de la línea de comandos. Cuando se pasa el argumento "--kill", se crea una instantánea de todos los procesos en ejecución en el sistema y comienza a iterarlos. El nombre de cada proceso se compara con los de la lista guardada, y los que coincidan se terminarán.

El argumento "--kill" también es responsable de terminar el servicio. Aquí utiliza SC Manager y la función "EnumServicesStatusExW" para obtener una lista de todos los servicios en ejecución en el sistema. A continuación, la muestra de Lynx comparará esta lista con los nombres guardados. Cuando se encuentra una coincidencia, se llamará a la función "ControlService" con el indicador "SERVICE_CONTROL_STOP".

Los siguientes procesos se terminarán para evitar errores por conflictos de uso compartido de archivos durante el cifrado:

sql, veeam, backup, exchange, java, notepad

Servicios terminados:

sql, veeam, backup, exchange

Cuando se proporciona el argumento "--stop-process", la muestra utiliza la API de Restart Manager para terminar procesos durante el proceso de cifrado. Solo se llamará a esta función si otro proceso está ocupando el archivo que Lynx intenta cifrar. La muestra registrará este archivo como un recurso para determinar el proceso. También obtendrá su propio PID para excluirse a sí misma de la terminación.

Antes de iniciar la rutina de cifrado, la muestra de Lynx realiza una búsqueda en todas las unidades del sistema. Cada unidad se verifica según su tipo. Para el cifrado, solo acepta unidades con los indicadores "DRIVE_REMOVABLE", "DRIVE_FIXED" y "DRIVE_REMOTE". Cuando se encuentra una unidad adecuada, se abre un identificador hacia ella y se ejecuta la función "DeviceIoControl" con el parámetro "53C028h" como código de control, que corresponde a "IOCTL_VOLSNAP_SET_MAX_DIFF_AREA_SIZE".

Se trata de un código de control no documentado que modificará el tamaño máximo de una instantánea. Como el parámetro "lpInBuffer" contiene el valor "1", al establecer un tamaño tan reducido se forzará la eliminación de las instantáneas. Después de que se completen esas operaciones, todas las unidades encontradas se pasarán a la rutina de cifrado.

La muestra de Lynx crea hilos con la función "sub_275600" como dirección de inicio. El número de hilos es igual al número de procesadores (obtenido mediante la llamada a "GetSystemInfo") multiplicado por cuatro.

Los hilos con esta dirección de inicio se utilizan para buscar archivos. Cuando la muestra de Lynx entra en una carpeta, crea una nota de rescate en esa carpeta y comienza a buscar archivos mediante las funciones "FindFirstFile" y "FindNextFile". Si el archivo encontrado es una carpeta, la muestra comparará su nombre con la lista guardada. Si el nombre de la carpeta coincide, se omitirá.

Cuando un archivo encontrado no es una carpeta, la muestra también puede excluirlo del cifrado. A continuación, compara extensiones y nombres de archivos. Si el tamaño del archivo es 0, también se omitirá.

Cuando se encuentra un archivo adecuado, la muestra comprueba en primer lugar si hay otro proceso que lo esté ocupando. Si se pasa el argumento "--stop-process", la muestra finalizará el proceso que mantiene el archivo ocupado; en caso contrario, se omitirá el archivo. A continuación, la muestra determina si tiene acceso de escritura a este archivo. Esto se hace al escribir un fragmento de datos al final del archivo. Antes del proceso de escritura, la muestra establece 36 bytes de "2" en el búfer. El número de caracteres que deben establecerse en el búfer, así como el tamaño del búfer que debe escribirse en el archivo, se calcula al sumar la longitud de la cadena "LYNX" y "32".

Si Lynx no logra escribir en ese archivo, intentará obtener su propiedad. Para ello, intentará obtener el privilegio "SeTakeOwnership" y cambiar la propiedad del archivo mediante la creación y configuración de una nueva estructura de lista de control de acceso (ACL), que otorgará privilegios de escritura.

Al inicio de la rutina del hilo, Lynx descodifica la cadena, guardada en formato Base64:

8SPEMzUSI5vf/cJjobbBepBaX7XT6QT1J8MnZ+IEG3g=

Este valor es una clave pública ECC, que se utilizará para generar la clave AES. Cada hilo inicializa los proveedores de cifrado con los indicadores "CRYPT_VERIFYCONTEXT" y "PROV_RSA_AES". A continuación, la muestra genera 32 bytes aleatorios mediante la función "CryptGenRandom".

Posteriormente, la muestra calcula el hash de la clave generada. Las constantes SHA512 se guardan en el binario.

Después de que el hilo lea el archivo encontrado, la muestra crea un hilo de cifrado, le pasa una señal de finalización y finaliza. El hilo de cifrado obtiene datos del anterior, que incluye datos de archivos leídos y claves de cifrado. Según el resultado de "GetQuedCompletionStatus", la muestra saltará a uno de cinco casos.

Durante el proceso de depuración, el primer caso que se activó fue el número dos. Aquí la muestra comprueba en primer lugar algunos valores y, a continuación, realiza una operación de escritura en el archivo actual. Escribirá "116" bytes de datos, lo que incluye la clave de cifrado.

A continuación, la muestra entra en el "Caso 0", donde comprueba si el desplazamiento actual del bloque de cifrado no supera el tamaño del archivo. Cuando entra en este caso por primera vez, el desplazamiento del bloque siempre será "0" y hará que el hilo lea los datos del archivo. Sin embargo, cuando se cumple la condición, la muestra indica que el archivo ya no contiene más datos por cifrar y forzará al hilo a escribir un bloque cifrado en el archivo. Asimismo, establecerá la instrucción de caso con el valor "3".

A continuación, la muestra entra en el "Caso 1". Aquí toma el tamaño del archivo y elimina "116" del mismo. Esto se hace para eliminar del cifrado un fragmento de datos ya escrito.

Después de que se hayan completado todos los preparativos, la muestra entra en un bucle donde cifra los datos del archivo. Aquí llama a la función "sub_AE1110", que utiliza AES para cifrar la clave. Como resultado, el valor "v32" se utiliza como flujo de claves (v16), que se aplicará mediante una operación XOR sobre los datos del archivo. El flujo de claves se volverá a generar cada 16 iteraciones del bucle de cifrado.

Por último, la muestra escribe datos cifrados en el archivo y entra en el "Caso 3", donde añade la extensión ".LYNX" al archivo. Una vez añadida esa extensión, el hilo borra su memoria y comienza a esperar el siguiente archivo.

Lynx almacena un mensaje de nota de rescate en formato Base64. Lynx lo carga y lo pasa a la función "CryptStringToBinaryA", a la que se llama con el indicador "CRYPT_STRING_BASE64".

Aunque el mensaje descodificado no contiene ningún ID de la víctima, este se añade después del proceso de descodificación. Este ID está codificado de forma rígida y es diferente para cada muestra.

Después de completar el proceso de cifrado, la muestra utiliza importaciones del encabezado "Winspool" para encontrar todas las impresoras conectadas. Comprobará los nombres de las impresoras, los comparará con los nombres guardados para evitarlos y enviará notas de rescate a todas las impresoras que se encuentren.

Además de los archivos de texto, la nota de rescate también se escribe como fondo de escritorio al final del proceso de cifrado.

Aunque se desconoce si Lynx es simplemente el ransomware INC con otro nombre, sabemos que comparte similitudes en el código. Las muestras analizadas pueden terminar procesos, montar unidades ocultas, eliminar instantáneas y cifrar archivos en recursos compartidos de red. Aunque el cifrado del archivo es fuerte, los atacantes también cargan archivos a sus servidores como parte de un esquema de doble extorsión, lo que obliga a las víctimas a pagar un rescate no solo por el descifrado, sino también para evitar que se divulguen sus datos privados.

SHA256

571f5de9dd0d509ed7e5242b9b7473c2b2cbb36ba64d38b32122a0a337d6cf8b

URL