La cadena de ataque comentada: por qué los manuales antiguos de ransomware nunca mueren

Durante una intrusión de ransomware, encontramos un script lleno de comentarios claros que explicaban qué hacía cada comando y función. Resultaba de inmediato llamativo y fuera de lugar, ya que en Huntress solemos observar que los scripts maliciosos están muy ofuscados.  Comentarios claros y descriptivos en inglés como rem Disable WD Tasks y rem Remove WD context menu precedían a los bloques de código correspondientes; fue como toparse con la confesión detallada de un criminal. Este script autodocumentado fue el hilo que destejió toda la historia. Los comentarios dejaban clarísima la intención del atacante y nos permitieron identificar el origen público del script —un Gist en GitHub— y su uso documentado en ataques anteriores, sobre todo en un caso de ransomware Xinglocker de 2021.

En nuestro caso, este actor de ransomware se movió con rapidez. Pero el SOC de Huntress fue más rápido, y monitoreó al adversario todo el tiempo mientras estuvo en la red:

• El actor de amenazas ingresó a través de RDP
• De inmediato comenzó a manipular las defensas y a eliminar las copias de volumen en la sombra (lo que beneficia al ransomware al eliminar las "copias" locales de los archivos). Luego se movió lateralmente hacia el controlador de dominio.  
• El gran final que el atacante tenía planeado era detonar  C:\Temp\file.exe -n=15 -p=F, un ejecutable con argumentos binarios comunes de ransomware.

Figura 1: Volúmenes en la sombra eliminados mediante movimiento lateral vía WMI

Figura 2: Variaciones de los argumentos del comando de ejecución del ransomware

Figura 3: El archivo de registro de la ejecución de file.exe

Por suerte, Huntress intervino para evitar el cifrado de archivos al detectar algunas de las tácticas más ruidosas que describiremos en este blog. En Huntress, aprovechamos todas las intrusiones como oportunidades de aprendizaje, para investigar de forma iterativa y perfeccionar las detecciones de las técnicas observadas. Este incidente muestra cómo los manuales de estrategia efectivos y de conocimiento público perduran, se comparten y son reutilizados por distintos adversarios, quienes añaden sus propias variaciones con el tiempo. Es prueba definitiva de que los mismos trucos se siguen intentando una y otra vez, y eso nos dice exactamente qué debemos defender.

Conclusiones clave:

• Los manuales de estrategia efectivos se reciclan. El script principal, visto por primera vez hace años, se sigue usando hoy, lo que demuestra que los adversarios no abandonan una herramienta que funciona.
• Los manuales de estrategia evolucionan. El script base se complementó con comandos de PowerShell más nuevos, lo que muestra que, aunque la base es antigua, las tácticas se perfeccionan activamente.
• Los defensores deben apuntar a la técnica, no a la herramienta. El script o la herramienta específica que usa un actor es menos importante que los métodos que emplea. La naturaleza persistente de este manual de estrategia ofrece un conjunto claro y constante de comportamientos para detectar y bloquear.

El manual de estrategia del adversario: un desglose táctico

Figura 4: Extracto del script adversario, desde la plataforma de Huntress

El script original, convenientemente organizado por su autor, revela una lista de verificación de tácticas de evasión de defensas y de deterioro del sistema. Cada comentario rem anuncia el siguiente paso.

Un ataque multifacético contra Defender

El manual de estrategia lanza una serie integral de cambios de configuración dirigidos a las operaciones de Microsoft Defender.

Deshabilitación de componentes principales

Bajo el comentario rem 1 - Disable Real-time protection, el script lanza una serie de ediciones al registro. Estos comandos no son sutiles; apuntan directamente a la configuración de políticas de los motores principales de Defender, estableciendo valores como DisableAntiSpyware y DisableAntiVirus para desactivar de manera efectiva las capacidades principales de escaneo y protección a nivel de política. Estos comandos van mucho más allá de solo apagar el antivirus. Desmantelan sistemáticamente las funciones de soporte al configurar políticas que desactivan el monitoreo de comportamiento, apagan la protección basada en la nube como "Block at First Seen" y evitan que el sistema envíe muestras sospechosas a Microsoft para su análisis. Este enfoque multifacético asegura que cada capa de detección en tiempo real —desde la heurística local hasta la inteligencia en la nube— quede efectivamente ciega.

reg add "HKLM\Software\Policies\Microsoft\Windows Defender\SpyNet" /v "SubmitSamplesConsent" /d "0"

reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Reporting" /v "DisableEnhancedNotifications" /t REG_DWORD /d "1" /f

A continuación, con la sección etiquenada rem Disable WD Tasks, el atacante paraliza la capacidad de Defender para mantenerse a sí mismo. Al usar schtasks para desactivar tareas de escaneos programados, mantenimiento de caché y limpiezas, el script asegura que, incluso si Defender no estuviera totalmente desactivado, ya no pudiera realizar sus funciones automáticas de rutina, dejándolo desactualizado e ineficaz.

Finalmente, el script ejecuta su paso más contundente bajo rem Disable WD services. Aquí, modifica directamente el registro para establecer el tipo Start de servicios esenciales de Defender —como WinDefend y WdFilter— en "Disabled". Este cambio de bajo nivel asegura que los componentes principales del software de seguridad no puedan iniciarse, finalizando la neutralización completa de las defensas del sistema.

reg add "HKLM\System\CurrentControlSet\Services\WinDefend" /v "Start" /t REG_DWORD /d "4" /f

Desactivación de funciones de la interfaz

Otra parte clave de la estrategia del atacante es operar sin alertar al usuario. Estas tácticas se enfocan en eliminar los rastros visibles de Microsoft Defender para mantener una ilusión de normalidad. Los primeros tres comandos están diseñados para eliminar la opción "Scan with Microsoft Defender" que aparece cuando un usuario hace clic derecho en un archivo, carpeta o unidad. Esto evita que un usuario curioso inicie fácilmente un escaneo y descubra un problema.

El comando final es aún más crucial; elimina la clave del registro responsable de iniciar automáticamente el ícono de Windows Defender en la bandeja del sistema. Al asegurarse de que este ícono nunca aparezca, el atacante elimina el indicador visual más obvio de que el software de seguridad está desactivado, lo que le permite continuar su ataque con total sigilo.

reg delete "HKCR\*\shellex\ContextMenuHandlers\EPP" /f

reg delete "HKCR\Directory\shellex\ContextMenuHandlers\EPP" /f

reg delete "HKCR\Drive\shellex\ContextMenuHandlers\EPP" /f

reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "Windows Defender" /f

Prácticamente no hay razón para que esto se haga en circunstancias normales, especialmente cuando se ejecuta con comandos separados en la línea de comandos de esta forma. Definitivamente deberías considerar esto como una señal de comportamiento malicioso.

Reglas Sigma:

Windows Defender Context Menu Removed

Delete Defender Scan ShellEx Context Menu Registry Key 

Desactivación del registro de eventos

Para asegurarse de que sus acciones no puedan ser rastreadas fácilmente, los atacantes emplean tácticas para cegar las propias capacidades de monitoreo del sistema. Esta táctica es un paso crucial de antiforénsica. Los comandos proporcionados apuntan y desactivan los dos autologgers principales de Windows Management Instrumentation (WMI) para Microsoft Defender: el DefenderApiLogger y el DefenderAuditLogger. Estos registradores crean un registro detallado de las actividades de Defender, que es invaluable para los analistas de seguridad y las herramientas EDR durante una investigación.

Al establecer su valor Start en 0, los atacantes desactivan efectivamente estos monitores de seguridad, evitando que el sistema registre su actividad maliciosa. Esto hace que sea significativamente más difícil para los investigadores comprender el alcance total y la cronología de la brecha después de los hechos.

reg add "HKLM\System\CurrentControlSet\Control\WMI\Autologger\DefenderApiLogger" /v "Start" /t REG_DWORD /d "0" /f

reg add "HKLM\System\CurrentControlSet\Control\WMI\Autologger\DefenderAuditLogger" /v "Start" /t REG_DWORD /d "0" /f

Si Microsoft Defender se desactiva de forma legítima, casi nunca se desactivará de esta manera específica. Desactivar estos registros ciega por completo cualquier método de detección que pueda depender de este flujo de telemetría. Este es un muy buen indicador, y debería ocurrir muy raramente en la mayoría de los entornos.

Regla Sigma:

Disabling Windows Defender WMI Autologger Session via Reg.exe

Un manual en evolución: la misma base, nuevas capas

Si el script Gist de 2021 fue la v1.0, entonces el script mejorado que Huntress observó en esta intrusión es una actualización a v2.0. Este manual v2.0, por lo que podemos ver, se basa en los fundamentos del script Gist de 2021 y agrega malicia adicional.

Las adiciones más críticas son:

1. Subversión de los controles de seguridad. Mientras que el script antiguo simplemente apagaba Defender, el nuevo manual usa Set-MpPreference para reprogramar su lógica. Establecer la acción predeterminada para amenazas de alta severidad en '6' (Allow) le indica a la herramienta de seguridad que ignore deliberadamente las mismas amenazas que fue diseñada para detener.
   
   Set-MpPreference -SevereThreatDefaultAction 6 -Force
   Set-MpPreference -HighThreatDefaultAction 6 -Force
   Set-MpPreference -ModerateThreatDefaultAction 6 -Force
   Set-MpPreference -LowThreatDefaultAction 6 -Force

Esta es una actualización táctica significativa respecto al script original. Indica a la herramienta de seguridad que ignore deliberadamente las amenazas, lo que demuestra cómo los atacantes han refinado su enfoque para ser más sutiles, en lugar de simplemente apagar un servicio. Este es un movimiento sigiloso que casi nunca ocurre de forma legítima. Aunque algunos productos de seguridad o herramientas de Monitoreo y Gestión Remota pueden ajustar estas configuraciones, rara vez las establecerán específicamente en "Allow" (6) o en "NoAction" (9) —ambos significan que Defender no intentará contener ninguna amenaza detectada. Este es un excelente indicador que es fácil de monitorear en varias fuentes de datos diferentes.

Reglas Sigma:

Severidad de amenaza de PowerShell Defender con acción predeterminada configurada en 'Allow' o 'NoAction'

Severidad de amenaza de Windows Defender con acción predeterminada configurada en 'Allow' o 'NoAction'

2. Modificación de perfiles de red para el movimiento lateral. La segunda adición clave prepara el terreno para que el ransomware se propague. Cambiar el perfil de red activo a "Private" relaja al instante las reglas del firewall, y a menudo habilita los protocolos de descubrimiento de red y uso compartido de archivos que ayudan a los actores de ransomware a encontrar a su próxima víctima en la red local.
   
   Set-NetConnectionProfile -Name "Network" -NetworkCategory Private
   
   
3. Uso de cmdlets de PowerShell para deshabilitar Defender: Algunos de estos se superponen con los cambios directos en el registro que se hicieron para deshabilitar los componentes de Defender:

Otros son únicos y no estaban cubiertos previamente por otros comandos:

4. Desactivación de las protecciones en el arranque y de la telemetría de EDR. Una evolución principal es el ataque directo a Microsoft Defender for Endpoint (MDE). Mientras que el script original se centraba en el antivirus estándar de Defender, los ataques más recientes usan comandos como reg add "...Services\Sense" /v "Start" /d "4" /f y el aún más contundente sc delete Sense para desactivar o eliminar por completo el servicio principal de MDE. Este es un objetivo crítico para el atacante, ya que corta el vínculo entre el equipo comprometido y el equipo de seguridad corporativo, sacando efectivamente el dispositivo de su red de monitoreo.
   
   Esto suele combinarse con la eliminación de servicios relacionados con la integridad del sistema, como System Guard, usando comandos como sc delete SgrmAgent y sc delete SgrmBroker. Al hacerlo, el atacante evita que el sistema operativo verifique que sus propios componentes principales no hayan sido alterados.
   
   Además, los atacantes apuntan a funciones de seguridad en las etapas más tempranas del proceso de arranque. El comando bcdedit /set {current} disableelamdrivers yes modifica la configuración de arranque para evitar que se carguen los controladores de Early Launch Anti-Malware (ELAM). Esto neutraliza de forma preventiva una capa crítica de protección incluso antes de que arranque el sistema operativo principal. Esto se complementa desactivando otros controladores de bajo nivel como el Microsoft Security Filter Driver (MsSecFlt), que deja ciegas a las herramientas de seguridad que dependen de él para inspeccionar la actividad del sistema. 

Finalmente, para asegurarse de que todo esto ocurra de forma silenciosa, el atacante suprime todas las alertas visibles para el usuario con claves de registro como Notification_Suppress, completando así el compromiso total y sigiloso de las defensas del equipo.

bcdedit /set {current} disableelamdrivers yes

reg add "HKLM\Software\Policies\Microsoft\Windows Defender\UX Configuration" /v "Notification_Suppress" /t REG_DWORD /d "1" /f

reg add "HKLM\SYSTEM\ControlSet001\Services\MsSecFlt" /v "Start" /t REG_DWORD /d "4" /f

reg add "HKLM\System\CurrentControlSet\Services\Sense" /v "Start" /t REG_DWORD /d "4" /f

sc delete Sense

reg add "HKLM\SYSTEM\ControlSet001\Services\MsSecFlt" /v "Start" /t REG_DWORD /d "4" /f

sc delete SgrmAgent

sc delete SgrmBroker

Qué significa esto para los defensores

Se usan los mismos trucos porque todavía funcionan. Tal como observamos recientemente los mismos indicadores en la explotación de varias vulnerabilidades en distintos ataques, queda claro que muchos adversarios no sienten la necesidad de cambiar algo que les funciona. En este caso, el script es un mapa de las debilidades en las posturas de seguridad predeterminadas. Nuestro trabajo como defensores es volver obsoletos estos trucos.

Concéntrate en el comportamiento, no en el artefacto. En lugar de depender de la detección de hashes de scripts específicos o nombres de archivo, crea detecciones para los comportamientos en sí. Una alerta cuando reg.exe modifica el valor Start de un servicio crítico, o cuando PowerShell altera políticas de seguridad, es una defensa duradera. Así, no importa cómo se lleve a cabo este ataque (mediante un script, un binario, una shell interactiva, etc.): siempre podrás detectarlo.

Al fortalecer las defensas contra estas técnicas comunes, podrás prevenir el ransomware tal como lo hicimos en este caso.

Apéndice: lista completa de comandos

A continuación, encontrarás los comandos originales en texto amarillo, mientras que los comandos adicionales más recientes están en texto rojo.

Referencias:

• https://gist.github.com/Dump-GUY/8daef859f382b895ac6fd0cf094555d2 
• https://thedfirreport.com/2021/10/18/icedid-to-xinglocker-ransomware-in-24-hours/