Ransomware SafePay: cómo funciona y cómo detenerlo

SafePay no es un servicio de pagos. Es un grupo de ransomware de doble extorsión que surgió a fines de 2024 y que solo en 2025 ha reclamado más de 270 víctimas. A diferencia de la mayoría de las operaciones de ransomware, SafePay funciona como un grupo cerrado, no-RaaS (ransomware-as-a-service), lo que significa que el mismo equipo central se encarga del acceso, el despliegue y la extorsión en lugar de alquilar su malware a afiliados.

Huntress investigó personalmente dos incidentes de SafePay, en distintos entornos de clientes, industrias y regiones. Esto es lo que encontramos, cómo opera el grupo y qué puede hacer tu equipo para mantenerlo fuera.

¿Qué es el ransomware SafePay?

SafePay apareció por primera vez en la telemetría de Huntress en octubre de 2024, cuando los analistas observaron dos incidentes de clientes no relacionados que involucraban la misma familia de ransomware. En ambos casos, los archivos cifrados tenían la extensión .safepay, y la nota de rescate se llamaba readme_safepay.txt. Se trataba de una variante que Huntress no había visto antes y sobre la cual no se pudo encontrar información pública en ese momento.

SafePay utiliza un modelo de doble extorsión: primero roba los datos, luego los cifra y después amenaza con filtrar los archivos robados si no se paga el rescate. Al aplicar ingeniería inversa al binario del ransomware se encontró una amplia coincidencia con el código fuente filtrado de LockBit Black, hasta en los indicadores de línea de comandos y la lógica de cifrado compartidos, aunque SafePay agregó sus propias funciones, incluido un interruptor de apagado basado en el idioma cirílico que impide que el malware se ejecute en sistemas configurados con idiomas de Europa del Este.

El grupo mantiene un perfil más bajo que otras marcas de ransomware más grandes, con poca discusión sobre SafePay en foros ilícitos. Su sitio de filtración, accesible a través de Tor y de un enlace menos conocido de TON (The Open Network), simplemente enumera a las víctimas por nombre, y cada una se puede expandir para ver más detalles. En la superficie es una operación discreta, pero el número de víctimas dice lo contrario.

Antecedentes

Durante octubre de 2024, los analistas de Huntress observaron dos incidentes que involucraron el despliegue del ransomware SafePay en infraestructuras de clientes dispares, separadas por sector de negocio y geografía. En ambos incidentes, la extensión de archivo cifrado era .safepay, y el nombre de la nota de rescate era readme_safepay.txt, algo que los analistas de Huntress no habían observado antes. Además, tras el primer incidente, los analistas no pudieron localizar ningún informe público sobre esta variante particular de ransomware.

Presencia en la Dark Web

El grupo de ransomware SafePay es una banda de cibercrimen más oscura que otras, y por eso no hay mucha discusión sobre SafePay en foros ilícitos o salas de chat.

Sin embargo, sí incluyen un enlace onion V3 a su sitio de filtración en su nota de rescate, así como un enlace menos común a un sitio “TON”; aparentemente, “The Open Network”, que afirma ser una “internet descentralizada y abierta, creada por la comunidad usando una tecnología diseñada por Telegram”.

Su sitio de filtración en Tor simplemente enumera a las víctimas pasadas, en las que se puede hacer clic para expandir y ver más detalles.

Al momento de escribir esto, hay 22 víctimas enumeradas. Al hacer clic en su nombre se abre una ventana modal para descargar un archivo de texto que enumera los nombres de archivo y la estructura de carpetas de los datos robados, o los datos mismos si están disponibles. Su carpeta de descargas es susceptible a la indexación de directorios:

Además, el punto de estado del servidor Apache sigue siendo accesible y expone más detalles sobre el servidor backend.

Incidente 1

Durante el incidente 1, la primera indicación observada de la actividad del actor de amenazas fue un intento de ejecutar ShareFinder.ps1, el cual fue detectado y bloqueado por Windows Defender. El actor de amenazas había accedido al endpoint mediante el protocolo de escritorio remoto (RDP), y por eso deshabilitó Windows Defender usando la misma secuencia de comandos LOLBin observada durante un incidente de despliegue del ransomware INC a principios de este año, y luego pudo ejecutar el script de PowerShell ShareFinder.ps1.

Unos 40 minutos después, el mismo usuario archivó archivos del endpoint con WinRAR.exe. Un ejemplo de línea de comandos del atacante archivando archivos se puede ver a continuación:

WinRAR.exe  a -v5g -ed -r -tn1000d -m0 -mt5 -x*.rar -x*.JPEG -x*.RAW
-x*.PSD -x*.TIFF -x*.BMP -x*.GIF -x*.JPG -x*.MOV -x*.pst -x*.FIT
-x*.FIL -x*.mp4 -x*.avi -x*.mov -x*.mdb -x*.iso -x*.exe -x*.dll
-x*.bak -x*.msg -x*.png -x*.zip -x*.ai -x*.7z -x*.DPM -x*.log -x*.dxf
-x*.insp -x*.upd -x*.db -x*.dwg -x*.nc1 -x*.metadata -x*.dg -x*.inp
-x*.dat -x*.TIFF -x*.tiger -x*.pcp -x*.rvt -x*.rws -x*.nwc -x*.tif
-x*.frx -x*.dyf -x*.rcs -x*.diff C:\[redacted].rar
\\[redacted]\C$\Users\

Esto se observó en tres endpoints distintos (archivando archivos de forma remota desde directorios de usuarios en otros endpoints).

Poco después, se instaló FileZilla usando FileZilla_3.67.1_win64_sponsored-setup.exe, y luego se ejecutaron filezilla.exe y fzsftp.exe. También fueron desinstalados rápidamente.

Al día siguiente, este proceso se repitió (se instalaron, ejecutaron y desinstalaron WinRAR y FileZilla).

Esta actividad parece ser una posible exfiltración de datos desde la red: los datos se recopilaron y archivaron con WinRAR y posiblemente se exfiltraron mediante FTP (no se recopiló evidencia de red de esta actividad).

Finalmente, al segundo día después del uso del script de PowerShell, el actor de amenazas regresó, inició sesión mediante RDP y, en aproximadamente 15 minutos, comenzó a ejecutar varios comandos que desplegaron el cifrado de archivos a través de recursos compartidos de red identificados previamente. Un ejemplo de uno de esos comandos se veía así:

"C:\Windows\SysWOW64\regsvr32.exe" /n "/i:-pass=[REDACTED] -enc=3 -uac -path=\\[REDACTED]\[SHARE]\  -uac=[REDACTED]" C:\locker.dll

La plataforma de Huntress generó alertas para esta actividad, como se ilustra en la Figura 6.

Tras estas alertas, se observaron los siguientes comandos como parte de la ejecución del ransomware:

bcdedit / set{default} recoveryenabled no

wmic shadowcopy delete

Ambos comandos fueron detectados y generaron alertas a través de la plataforma de Huntress, pero para ese momento el proceso de cifrado de archivos ya estaba en marcha.

Incidente 2

Durante la investigación del incidente 2, los analistas determinaron que el despliegue del agente de Huntress era extremadamente limitado, lo que redujo la visibilidad, la detección y la respuesta.

Los analistas de Huntress sí observaron un inicio de sesión exitoso inicial en la red en la cuenta Administrator, originado desde la estación de trabajo del actor de amenazas WIN-3IUUOFVTQAR, seguido de múltiples intentos fallidos de inicio de sesión en la cuenta de usuario inexistente Work, desde la misma estación de trabajo. Después de esta actividad, la cuenta Administrator se usó para iniciar sesión con éxito mediante el protocolo de escritorio remoto (RDP).

Los analistas de Huntress no pudieron recuperar una copia del ejecutable del ransomware durante este incidente, debido a que el despliegue del cifrado de archivos probablemente ocurrió desde otro endpoint que no tenía un agente instalado. Esto se respalda con el hecho de que, durante el incidente 1, el ransomware se desplegó mediante rutas UNC.

Además, durante este incidente no hubo indicios de que el actor de amenazas intentara deshabilitar Windows Defender. Más bien, en este caso, Windows Defender sí detectó el proceso del ransomware, pero registró un evento de error Microsoft-Windows-Windows Defender/1119, como se ilustra en la Figura 7.

Lamentablemente, no se pudo evitar la ejecución del ransomware y, al igual que en el primer incidente, se modificaron los archivos canario de ransomware, lo que generó reportes adicionales por parte del Huntress SOC.

Ingeniería inversa

Durante nuestro análisis del binario del ransomware, comenzamos a notar una gran cantidad de similitudes con las muestras de Lockbit analizadas ampliamente a finales de 2022. Esto no es particularmente sorprendente, dado que el código fuente de Lockbit se ha filtrado varias veces.

Uso

El ransomware se ejecuta mediante regsrv32.exe y acepta las siguientes marcas:

Interruptor de apagado por idioma cirílico

Como es relativamente común en el ransomware, antes de ejecutar el cifrado en un endpoint, el malware intenta verificar que no se esté ejecutando en ningún país de Europa del Este. Para esto, llama a GetSystemDefaultUILanguage y comprueba que el ID de idioma resultante sea mayor que los ID de idiomas cirílicos, como se ve en la Figura 8.

Cifrado de cadenas

La mayoría de las cadenas del binario están ofuscadas con un simple ciclo XOR de tres pasos que consiste en una clave aleatoria de un solo byte, el índice del carácter y el primer byte de kernel32.dll ('M').

Terminación de procesos

El malware intenta detener ciertos procesos en ejecución mediante ZwTerminateaProcess. A continuación, la lista de procesos que intenta detener:

• sql

• oracle

• ocssd

• dbsnmp

• synctime

• agntsvc

• isqlplussvc

• xfssvccon

• mydesktopservice

• ocautoupds

• encsvc

• firefox

• tbirdconfig

• mydesktopqos

• ocomm

• dbeng50

• sqbcoreservice

• excel

• infopath

• msaccess

• mspub

• far

• onenote

• outlook

• powerpnt

• steam

• thebat

• thunderbird

• visio

• winword

• wordpad

• notepad

• wuauclt

• onedrive

• sqlmangr

Finalización de servicios

El ransomware intenta detener servicios en ejecución mediante ControlService. A continuación, los servicios que intenta detener:

• vss

• sqlsvc

• memtas

• mepocs

• msexchange

• Sophos

• Veeam

• backup

• GxVss

• GxBlr

• GxFWD

• GxCVD

• GxCIMgr

Ajuste de privilegios

Este malware sigue los pasos necesarios para habilitar SeDebugPrivilege para su token de autenticación en ejecución actual. Esto se hace mediante las siguientes API: ZwOpenProcessToken, LookupPrivilegeValueA, PrivilegeCheck y AdjustTokenPrivileges. Esto es muy común dentro del malware, ya que establecer SeDebugPrivilege evita ciertas verificaciones de acceso a objetos de Windows. Si tienes curiosidad sobre esto, puedes leer más al respecto aquí.

Suplantación de token

Una de las formas en que este malware intenta escalar privilegios es mediante la suplantación de token. La manera en que lo implementan es llamando a DuplicateToken para obtener un token de autenticación de suplantación (de hilo) a partir de un token de autenticación primario (de proceso). Podemos ver esto en el siguiente fragmento de código:

Después de que este identificador de token de autenticación se asigna a una variable global, se usa en otra función que llama a ZwSetThreadInformation. Veamos cómo se llama esto:

Lo que podemos ver arriba es que se crea un hilo en estado suspendido mediante CreateThread, pasando CREATE_SUSPENDED en dwCreationFlags. El propósito de este hilo es enumerar y analizar unidades de red. Si el hilo se crea correctamente, se establece el indicador ThreadHideFromDebugger en el hilo, lo que permite que se ejecute sin que un depurador pueda rastrear la ejecución. Luego, el token de autenticación duplicado se asigna al hilo mediante ZwSetInformationThread. Por último, el hilo puede ejecutarse mediante NtResumeThread.

Creación y administración de hilos

Para aumentar el rendimiento del ransomware, SafePay (o en realidad Lockbit) crea varios hilos de trabajo tanto para el cifrado como para la enumeración de redes. La forma en que hacen esto es interesante, porque en lugar de usar un CreateThread estándar, usan una implementación personalizada que ofrece mejores capacidades antianálisis.

Si el registro está habilitado, se devolverá cuántos hilos se crearon al archivo de registro. Por último, limpian al liberar la memoria asignada para el grupo de hilos, cerrar el puerto de finalización y liberar el contexto criptográfico. El código de limpieza se puede ver en la Figura 10.

Oportunidades de detección 

Evasión de defensas

Observamos que el actor de amenazas deshabilitó algunas configuraciones de Windows Defender usando el binario systemsettingsadminflows.exe. En este caso, el proceso principal de SystemSettings.exe muestra que los cambios se hicieron usando la interfaz gráfica de Configuración de Windows, a la que normalmente se accede a través del Menú. Esto indica que el actor de amenazas se movía de forma interactiva en el escritorio. Si bien un usuario puede hacer esto ocasionalmente también, es poco probable que la mayoría de los usuarios cambien con frecuencia la configuración de Virus y protección contra amenazas de Windows Defender. Estas son configuraciones como Envío automático de archivos y Protección contra amenazas en tiempo real.

Normalmente, estas configuraciones se establecen mediante Directivas de grupo, Directivas de seguridad local, o mediante configuraciones personalizadas durante la configuración inicial del sistema. Los cambios realizados por administradores normalmente se hacen mediante PowerShell, cambios directos en el registro o actualizaciones de las directivas de seguridad (no haciendo clic en los interruptores de la interfaz gráfica). Para muchos entornos, esto puede ser lo suficientemente inusual como para generar una alerta cada vez que ocurra. Proporcionamos las siguientes reglas de Sigma para detectar este comportamiento:

• Configuración de protección contra amenazas de Windows Defender deshabilitada mediante GUI

• Configuración de protección contra amenazas de Windows Defender deshabilitada

Muchos cambios en Defender también se pueden detectar con los registros de eventos de Windows, con eventos como Microsoft-Windows-Windows Defender/5001 (Defender RTP deshabilitado) y Microsoft-Windows-Windows Defender/5007 (cambio de configuración de protección contra malware de Defender). Los siguientes son detectores Sigma disponibles en el repositorio de SigmaHQ que detectan estos cambios:

• Regla de SigmaHQ para deshabilitar RTP

• Regla de registro de eventos de Windows de SigmaHQ para cambio de configuración de protección contra malware

• Regla de evento de Windows de SigmaHQ para cambio de configuración de Defender - Envío de muestras

Escalada de privilegios

El atacante probablemente usó una técnica conocida de escalada de privilegios por bypass de UAC, utilizada a menudo por otros grupos de ransomware como Lockbit y BlackCat/ALPHV. Esta técnica da como resultado un proceso elevado creado por un objeto COM específico, que se puede usar para ejecutar comandos o binarios maliciosos. Cuando se usa esta técnica, el proceso principal es DllHost.exe con el CLSID del objeto COM utilizado (CMSTPLUA en este caso) presente en la línea de comandos. Si bien esto puede ocurrir de forma legítima en ocasiones, en general no debería ser frecuente, especialmente con binarios no firmados, binarios del sistema que se pueden usar para ejecución por proxy, o intérpretes de scripts como proceso secundario ejecutado.

Elastic tiene una buena regla de ejemplo para esta actividad general: UAC Bypass via ICMLuaUtil Elevated COM Interface, y se puede encontrar una versión en Sigma aquí. Para ser aún más específico, puedes detectar usando la misma lógica, pero buscando solo procesos secundarios que:

1. Tengan firmas inválidas (binarios maliciosos)

2. Sean intérpretes de scripts (CMD, PowerShell, etc.).

3. Se puedan usar para ejecución por proxy de binarios del sistema

Estos métodos se pueden usar para encontrar indicios de una posible escalada de privilegios mediante este método de bypass de UAC con este objeto COM.

Creamos un par de reglas Sigma nuevas para detectar algunos de estos comportamientos más interesantes:

• Ejecución por proxy de binarios del sistema mediante la interfaz COM CMSTPLUA

• Ejecución de intérprete de scripts mediante la interfaz COM CMSTPLUA

Recolección de datos

El atacante usó WinRAR para archivar datos antes de la exfiltración. Esta es una herramienta común y conocida que se usa para este fin. Hubo varias cosas interesantes en los comandos utilizados. Aquí tienes un par de reglas Sigma que creamos para detectar parte de este comportamiento, que a menudo se usa con fines maliciosos y es poco común durante el uso típico de WinRAR en la mayoría de los entornos.

• Crear archivo WinRAR - Recorrer subcarpetas

• Crear archivo WinRAR - Especificar tamaño de volumen

Conclusión

En ambos incidentes, se descubrió que la actividad del actor de amenazas se originaba en una puerta de enlace o portal VPN, ya que todas las direcciones IP observadas asignadas a las estaciones de trabajo del actor de amenazas estaban dentro del rango interno. El actor de amenazas pudo usar credenciales válidas para acceder a los endpoints de los clientes, y no se observó que habilitara RDP, ni que creara nuevas cuentas de usuario, ni que estableciera ningún otro mecanismo de persistencia. Durante el incidente 1, se observó que el actor de amenazas usaba un script de PowerShell disponible de forma gratuita para mapear recursos compartidos accesibles, los cuales luego se usaron en el proceso de cifrado de archivos. En ambos incidentes, la nota de rescate dejada como resultado del proceso de cifrado de archivos comienza con las palabras: “Greetings! Your corporate network was attacked by SafePay team,” y continúa indicando que se robaron datos “importantes”, además de dar instrucciones de contacto.

IOC

Además del uso de credenciales conocidas y el acceso mediante RDP, se observaron los siguientes IOC:

Mapeo de MITRE ATT&CK

Un agradecimiento especial a Alden Schmidt, Jonathan Johnson, Matt Anderson, Jamie Levy, John Hammond y otros por su esfuerzo incansable y sus contribuciones a esta investigación e informe.