Un vistazo a través de un diminuto orificio a un ataque de ransomware Qilin

Una parte importante del trabajo diario de un analista de seguridad es descubrir qué ocurrió realmente durante un incidente. Podemos hacerlo reconstruyendo pistas (ya sea a través de registros, detecciones de antivirus u otras señales) que nos ayudan a entender cómo el atacante logró el acceso inicial y qué hizo después.

Sin embargo, no siempre es tan claro: a veces hay factores externos que limitan nuestra visibilidad. Es posible que el agente de Huntress no esté implementado en todos los endpoints, por ejemplo, o que la organización afectada instale el agente de Huntress después de que ya ocurrió una vulneración. En estos casos, tenemos que ser creativos y revisar varias fuentes de datos para determinar qué pasó en realidad.

Recientemente analizamos un incidente en el que se dieron ambos factores: el 11 de octubre, una organización instaló el agente de Huntress después del incidente, y al inicio solo en un endpoint. En cuanto a visibilidad, este incidente no era como mirar por el ojo de una cerradura, sino más bien como mirar por un orificio diminuto. Aun así, los analistas de Huntress pudieron obtener mucha información sobre el incidente.

El incidente de Qilin: con qué empezamos

El agente de Huntress se instaló en un solo endpoint tras una infección de ransomware Qilin. ¿Qué significa esto desde la perspectiva de un analista que intenta descubrir qué pasó? Teníamos pocas pistas para empezar: no había telemetría de detección y respuesta para endpoints (EDR) ni de SIEM disponible, y no se activaron los indicadores de ransomware específicos de Huntress. Como además solo teníamos un endpoint, nuestra visibilidad se limitaba a la actividad ocurrida en ese endpoint específico dentro de la infraestructura más amplia del entorno.

Como resultado, todo lo que tenían los analistas de Huntress para empezar a desentrañar este incidente eran las alertas del antivirus administrado (MAV). Una vez que se agregó el agente de Huntress al endpoint, se alertó al SOC sobre detecciones de MAV ya existentes, algunas de las cuales se muestran en la Figura 1.

Figura 1: alertas de MAV que se activaron tras dejarse la nota de rescate 

Los analistas comenzaron a solicitar archivos del endpoint, empezando por un subconjunto específico de los registros de eventos de Windows (WEL).

A partir de esos registros, los analistas pudieron ver que el 8 de octubre de 2025, el actor de amenazas accedió al endpoint e instaló el Total Software Deployment Service, además de una instancia fraudulenta de ScreenConnect RMM, que apuntaba a la dirección IP 94.156.232[.]40. Al buscar la dirección IP en VirusTotal se obtuvo la información que se muestra en la Figura 2.

Figura 2: respuesta de VirusTotal para la dirección IP 94.156.232[.]40

Un aspecto interesante de la instalación fue que, al parecer, LogMeIn se instaló de forma legítima en el endpoint el 20 de agosto de 2025 desde el archivo %user%\Downloads\LogMeIn.msi. Luego, el 8 de octubre, la instancia fraudulenta de ScreenConnect se instaló desde el archivo C:\Users\administrator\AppData\Roaming\Installer\LogmeinClient.msi. Además, la línea de tiempo indica que el 2 de octubre, Windows Defender envió el archivo %user%\Downloads\LogMeIn Client.exe para revisión, y no se tomó ninguna otra acción después de ese evento.

Al pasar de la instalación de ScreenConnect a los eventos de actividad de ScreenConnect dentro de la línea de tiempo, los analistas vieron que el 11 de octubre se transfirieron tres archivos al endpoint a través de la instancia de ScreenConnect ; r.ps1, s.exe y ss.exe. Al indagar un poco más, solo se encontró r.ps1 todavía en el endpoint (que se muestra abajo).

$RDPAuths = Get-WinEvent -LogName
'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational'
-FilterXPath @'
<QueryList><Query Id="0"><Select>
  *[System[EventID=1149]]
</Select></Query></QueryList>
'@

# Get specific properties from the event XML
[xml[]]$xml=$RDPAuths|Foreach{$_.ToXml()}
$EventData = Foreach ($event in $xml.Event) {
  # Create custom object for event data
  New-Object PSObject -Property @{
   TimeCreated = (Get-Date ($event.System.TimeCreated.SystemTime) -Format 'yyyy-MM-dd hh:mm:ss K')
   User = $event.UserData.EventXML.Param1
   Domain = $event.UserData.EventXML.Param2
   Client = $event.UserData.EventXML.Param3
  }
}
$EventData | FT

Según el contenido del script, parece que el actor de amenazas estaba interesado en determinar las direcciones IP, los dominios y los nombres de usuario asociados con los accesos RDP al endpoint.

Sin embargo, el registro de eventos de Windows contenía un mensaje de Microsoft-Windows-PowerShell/4100 que indicaba:

Error Message = File C:\WINDOWS\systemtemp\ScreenConnect\22.10.10924.8404\Files\r.ps1 cannot be loaded because running scripts is disabled on this system.

Este mensaje se registró dentro de los 20 segundos posteriores a la transferencia del script al endpoint, cuando el actor de amenazas intentó ejecutarlo.

Análisis de los registros de PCA

Los otros dos archivos, s.exe y ss.exe, requirieron un poco más de trabajo para desentrañarse, ya que ya no se encontraban en el endpoint. Sin embargo, los analistas de Huntress lograron aprovechar fuentes de datos en el endpoint con Windows 11, específicamente el archivo AmCache.hve y los archivos de registro del Program Compatibility Assistant (PCA), para obtener los hashes de los archivos y constatar que, si bien el actor de amenazas había intentado ejecutarlos, ambos aparentemente fallaron.

El actor de amenazas deshabilitó Windows Defender, lo cual se observó en los registros de eventos de Windows Defender, comenzando con el ID de evento 5001, lo que indica que se deshabilitó la función de protección en tiempo real. A esto le siguieron varios registros con ID de evento 5007, que indican que funciones como SpyNetReporting y SubmitSamplesConsent habían sido modificadas (en este caso, deshabilitadas), además de mensajes de SecurityCenter que indicaban que Windows Defender había entrado en un estado SECURITY_PRODUCT_STATE_SNOOZED. El actor de amenazas luego intentó ejecutar s.exe, lo que fue seguido casi de inmediato por el mensaje “Installer failed” en los registros de PCA. Según las detecciones identificadas en VirusTotal que se muestran en la figura 3, y los comportamientos identificados por VirusTotal, este archivo parece ser un infostealer.

Figura 3: respuesta de VirusTotal para el archivo s.exe

Los mensajes en los registros de PCA indican que el archivo, identificado como un instalador, no logró ejecutarse.

Siete segundos después, el actor de amenazas intentó ejecutar ss.exe, lo que fue seguido de inmediato por el lanzamiento de la aplicación legítima de Windows c:\windows\syswow64\werfault.exe. Los registros de PCA luego contenían tres mensajes consecutivos que indicaban: “PCA resolve is called, resolver name: CrashOnLaunch, result: 0” con respecto a ss.exe, todos indicando que la aplicación no se ejecutó.

De nuevo, antes de intentar ejecutar los dos archivos anteriores, el actor de amenazas deshabilitó Windows Defender a las 2025-10-11 01:34:21 UTC, lo que resultó en que el estado de Windows Defender se reportara como SECURITY_PRODUCT_STATE_SNOOZED. A las 2025-10-11 03:34:56 UTC, el actor de amenazas accedió al endpoint de forma remota, y luego a las 2025-10-11 03:35:13 UTC, hubo múltiples detecciones de Windows Defender por intentos de crear notas de rescate (es decir, Behavior:Win32/GenRansomNote), así como mensajes de Windows Defender que indicaban que los intentos de remediación habían fallado. En ese momento, el estado de Windows Defender se reportó como SECURITY_PRODUCT_STATE_ON. La detección de Windows Defender, junto con el inicio de sesión remoto previo, parece indicar que el ejecutable de ransomware se lanzó desde otro endpoint, dirigido a recursos compartidos de red.

La figura 4 muestra un extracto de una nota de rescate de Qilin encontrada en el endpoint.

Figura 4: extracto de la nota de rescate de Qilin

El ransomware Qilin es una variante de “ransomware como servicio” (RaaS), lo que significa que, si bien la logística del ransomware se gestiona de forma centralizada, cada afiliado probablemente sigue un patrón de ataque distinto, dejando rastros y artefactos diferentes. Por ejemplo, varios incidentes de Qilin observados por los analistas de Huntress comenzaron con el actor de amenazas iniciando sesión a través del protocolo de escritorio remoto (RDP), y todos incluyeron notas de rescate y extensiones de archivos cifrados similares. Sin embargo, solo en un incidente los analistas observaron el uso de s5cmd para exfiltración de datos.

El valor de contar con múltiples fuentes de datos en una investigación

A lo largo de esta investigación, los analistas de Huntress no estaban mirando a través de un ojo de cerradura. Recuerda que el agente de Huntress se instaló después del incidente, por lo que no había telemetría de EDR, ni datos de SIEM, ni señuelos de ransomware sobre los cuales construir una comprensión de la progresión del incidente. Además, en el momento en que se recibieron las alertas de MAV en el portal de Huntress, este era el único endpoint dentro de la infraestructura con un agente de Huntress instalado.

En lugar de mirar a través de un ojo de cerradura, los analistas miraban a través de un agujero de alfiler. Aun así, basarse en múltiples fuentes de datos no solo llevó a una comprensión más profunda de las actividades que el actor de amenazas intentó realizar en el endpoint, sino que también sirvió para validar los hallazgos y dar una imagen más clara de lo que realmente ocurrió. Por ejemplo, entender que el actor de amenazas usó una instancia no autorizada de ScreenConnect para intentar implementar varios archivos maliciosos, incluyendo uno que parecía ser un infostealer, puede ayudar a informar a la empresa afectada cuando intenta determinar el alcance del incidente y cómo responder.

Durante una investigación, en particular una que es sensible al tiempo o que simplemente se asume que lo es, es fácil caer en la trampa de encontrar un artefacto y construir una historia alrededor de él sin verificarlo o validarlo primero. Puede ser fácil pensar: “...esto me parece anómalo…”, sin considerar realmente si es anómalo dentro de la infraestructura misma, en particular si la investigación se realiza mirando a través de un agujero de alfiler. Validar la actividad en múltiples fuentes de datos, y no saltar al primer indicador como base de la actividad maliciosa, da una imagen mucho más precisa de las actividades del actor de amenazas, y sienta las bases para decisiones y remediaciones más precisas.

IOC